This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] fix BZ 18116 - build failure on ppc64le: setcontext.S uses power6 mtfsf when not supported

On 03/16/2015 03:50 PM, Steven Munroe wrote:
> On Mon, 2015-03-16 at 14:08 -0400, Carlos O'Donell wrote:
>> On 03/16/2015 01:41 PM, Martin Sebor wrote:
>>> The attached patch fixes a glibc build failure with gcc 5 on
>>> powerpc64le caused by a recent change in gcc where the compiler
>>> defines the _ARCH_PWR6 macro when processing assembly files
>>> but doesn't invoke the assembler in the corresponding machine
>>> mode (unless it has been explicitly configured to target POWER
>>> 6 or later). A bug had been filed with gcc for this (65341) but
>>> was closed as won't fix. Glibc relies on the _ARCH_PWR6 macro
>>> in a few .S files to make use of Power ISA 2.5 instructions
>>> (specifically, the four-argument form of the mtfsf insn).
>>> A similar problem had occurred in the past (bug 10118) but
>>> the fix that was committed for it didn't anticipate this new
>>> problem. The fix in the proposed patch introduces the .machine
>>> "power6" directive unconditionaly, regardless of whether
>>> _ARCH_PWR6 is defined.
>> For avoidance of doubt the `#ifdef _ARCH_PWR6` need cleaning up,
>> but that's another issue orthogonal to this patch. If gcc no longer
>> defines _ARCH_PWR6 when invoking the assembler, then glibc has use
>> it's own configury to determine exactly which of the two code
>> segments to include in the final assembly.
> I believe that problem is different then stated. With GCC-5.0 the gcc
> driver for the powerpc64le target defaults to power8. This sets the
> _ARCH_PWR8, _ARCH_PWR7, _ARCH_PWR6, etc. macros. But without an explicit
> -mcpu=power6|7|8, gcc will not pass a -mpower6|7|8 option to the
> assembler.

So the macro is set, but the assembler support is now orthogonal 
to the macro.
> The 4 operand form of mtfsf and require for the handled the extended
> FPSCR with Decimal Floating Point support. The DFP feature is supported
> on POWER6|7|8 but I don't think it is supported for Freescale e5500.

That would be an orthogonal issue that would still need fixing outside
of this correction.

> So the 4 operand form should be used only for powerpc processors that
> also support DFP.

I suggest breaking that out into a distinct bug.

> stops passing the -many or -mpowerX option for the assembler (as). As
> far as I know the compiler continues to set the _ARCH_PWRx defines based
> on the defaults or -mcpu= option.


> GCC will generate the appropriate .machine for code it generates but
> this creates a problem for existing asm source codes. And 


> So the code should use #ifdef _ARCH_PWR6 to both assert .machine power6
> and use the 4 operand form of mtfsf. The #else leg should use the 2
> operand mtfsf only.  But we may need to assert .macine power6 again to
> allow us of the vector ops.
> PS still waiting for my account access to cleared so I cant do much with
> this yet.

You can do everything except checkin the code?

If you review Martin's patch and it looks good as a fix for the immediate
build failures, please ACK it?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]