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: Martin Sebor <msebor at redhat dot com>
- Cc: munroesj at linux dot vnet dot ibm dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Mar 2015 10:55: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> <1426538231 dot 13272 dot 28 dot camel at sjmunroe-ThinkPad-W500> <55074888 dot 5060408 at redhat dot com> <55076687 dot 7010903 at redhat dot com> <1426553899 dot 7010 dot 11 dot camel at oc8268013063 dot ibm dot com> <55079FC0 dot 3000806 at redhat dot com>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Mon, 2015-03-16 at 21:30 -0600, Martin Sebor wrote:
> On 03/16/2015 06:58 PM, Steven Munroe wrote:
> > On Mon, 2015-03-16 at 17:25 -0600, Martin Sebor wrote:
> >> On 03/16/2015 03:18 PM, Martin Sebor wrote:
> >>> On 03/16/2015 02:37 PM, Steven Munroe wrote:
> >>>> On Mon, 2015-03-16 at 11:41 -0600, 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.
> >>>> I think this patch is incorrect for the architecture. The 4 operand form
> >>>> of mtfsf should only be used with processors that support the DFP
> >>>> category.
> >>>> So the .machine power6 should not be moved above the #ifdef.
> >>>> The .machine should be in the #ifdef _ARCH_PWR6 #else "leg" specifically
> >>>> around the mtfsf 4 operand form following the PPC_FEATURE_HAS_DFP test.
> >>> That's where the directive currently is, i.e., only in the
> >>> #else block.
> >>> The problem is that the four operand mtfsf is used in both
> >>> blocks. That causes the error when the assembler sees the
> >>> #if block without the .machine "power6" directive.
> >>> Since the Power 2.5 instruction is used in both conditionally
> >>> included blocks the proposed patch introduces the directive
> >>> unconditionally, outside either.
> >>> Another way to fix the problem would be to do both of:
> >>> a) move the .machine directive to the #if block
> >>> b) change the #else block to avoid using the four operand
> >>> form of the mtfsf instruction.
> >> Attached is a patch that does this. It moves the .machine
> >> directive from the "false" branch of the block controlled
> >> by the _ARCH_PWR6 macro to the "true" branch, and replaces
> >> the four operand mtfsf instruction in the "false" branch
> >> with its opcode.
> >> This way when _ARCH_PWR6 is defined by GCC we can safely
> >> assume the assembler supports the four-operand form of
> >> the instruction and so we just put it in the right machine
> >> mode in case GCC didn't specify the appropriate -power6
> >> or better option. When the macro isn't defined we assume
> >> that the assembler doesn't support the four operand form
> >> and so we hardcode its opcode. The preceding runtime test
> >> will jump over it if it isn't supported by the cpu.
> > It simpler and more correct to place
> > .machine push
> > .machine "power6"
> > +
> > + mtfsf 0xff,fp0,1,0
> > +
> > + .machine pop
> > around all instances of the 4 operand form of mtfsf.
> You mean around each of the instances, as in the attached patch,
> as opposed to around the whole #if/#else block? Would you mind
> explaining in what way you think it's more correct than the first
> patch (a single pair of .machine directives around the whole
> conditional block)?
I mean around each instance of mtfsf 0xff,fp0,1,0
What you suggested is only correct and safe for IBM POWER hardware
Power6 and later. It is not safe or correct for powerpc64 chips from
other manufacturer that implement a subset of the PowerISA-2.05 (or
Also the *context code is not platform (/powerpc64/swapcontext.S
vs /powerpc64/power6/swapcontext.S) qualified.
So this code has to work when compiled for older (then power6) processor
that but is actually running on power6 or later processor that
implements DPF (PPC_FEATURE_HAS_DFP).
> > This also avoid the used of .long hex constants for the
> > PPC_FEATURE_HAS_DFP true case in the #else.
> > Also I don't see the need to resort to #if __BIG_ENDIAN__ tests as this
> > is not architectural issue, but an artifact of GCC configuration rules.
> The endian tests are necessary in this version of the patch
> because the big-endian encoding of the mtfsf instruction is
> different from its powerpc64le encoding. If we assume the
> assembler supports the four operand form of the instruction
> even if the _ARCH_PWR6 macro isn't defined then we don't need
> to hardocode its opcode and thus don't need the __BIG_ENDIAN__
> preprocessor tests.
The endian test is only necessary if you use .long hex instruction
encoding. What I suggest allows you to use that instruction mnemonic and
as will handle the endian.
For example if you need to change which register the FPSCR is returned
is quite tricky to encode (and error prone) in Hex. We can assume that
as will translate the mnemonic correctly and the mnemonic is easier to
> > What I suggest would be correct for the current situation and more
> > likely to remain correctly function for the future. This is important
> > give the flexibility given to implementations in the PowerISA for
> > embedded implementations (where DFP is optional) as exemplified by PA
> > Semi and FreeScale 64-bit implementations.
> I'm not attached to any particular implementation of the fix
> although I do think the first one is simpler and thus easier
> to maintain, and the second is more robust because it doesn't
> assume support for the four-operand form of the instruction,
> either in the assembler or in the cpu. But it's obviously your
> call as the powerpc maintainer.
"Every thing should be a simple as possible, but no simpler."
This is attributed to Albert Einstein, The original statement in German
is longer and more elegant and precise.
Net, we want the simplest solutions that is correct given what the
PowerISA allows and the hardware implementations we are aware of.