This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] fix BZ 18116 - build failure on ppc64le: setcontext.S uses power6 mtfsf when not supported
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: munroesj at linux dot vnet dot ibm dot com
- Cc: Martin Sebor <msebor at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Steven Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Mon, 16 Mar 2015 15:58:24 -0400
- Subject: Re: [PATCH] fix BZ 18116 - build failure on ppc64le: setcontext.S uses power6 mtfsf when not supported
- Authentication-results: sourceware.org; auth=none
- References: <550715C8 dot 7020508 at redhat dot com> <55071C00 dot 9080008 at redhat dot com> <1426535456 dot 13272 dot 21 dot camel at sjmunroe-ThinkPad-W500>
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
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?