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: Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>
- To: "Carlos O'Donell" <carlos at redhat 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 14:50:56 -0500
- 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>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
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
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.
So the 4 operand form should be used only for powerpc processors that
also support DFP.
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