This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Add OPTION_MASK_ISA_X86_64 and support TARGET_BI_ARCH == 2
- From: Iain Sandoe <idsandoe at googlemail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Mike Stump <mikestump at comcast dot net>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 8 Apr 2012 12:38:13 +0100
- Subject: Re: PATCH: Add OPTION_MASK_ISA_X86_64 and support TARGET_BI_ARCH == 2
- References: <CAFULd4YKFWuQLnu_LcpbOmn1q00V=Z6rHU=OTDPnRMuU6FP5xQ@mail.gmail.com> <CAMe9rOqAdpnKUbFyn475zA6qbSc6k5qSF=0DU7k=FTyAZ+YNPg@mail.gmail.com> <28756905-85A0-4319-93CB-CC35D0601F96@comcast.net> <yddwr62t982.fsf@manam.CeBiTec.Uni-Bielefeld.DE> <CAMe9rOryTt05L9C77mKB=w6P8nVSdxE3yUq8qFyh6gYwrKY5kA@mail.gmail.com> <20120330180556.GA9392@bromo.med.uc.edu> <CAMe9rOpLh+LkKWuyp86tojQ22UfTqbxK2SrrEHdj3OJv3AAObA@mail.gmail.com> <20120330202328.GA9998@bromo.med.uc.edu> <CAMe9rOov++xzP==hJ9YKME+BO9Z7QxA1ADr847KoWsxB6OLBiA@mail.gmail.com> <CAMe9rOr3vTS1k6tstsk-fsdkVbYkOuks85sFS8wsAH+j8evcXg@mail.gmail.com> <20120331192444.GA15969@bromo.med.uc.edu>
On 31 Mar 2012, at 20:24, Jack Howarth wrote:
The latest gcc-pr52784-2.patch patch also allows current gcc trunk
bootstrap on i386-apple-darwin10.
Despite the fact that bootstrap is restored, there remain problems
with this patch and some more work is needed.
(a) [trivial] the option 'mx32' is in i386.opt, which means it is
exposed to all sub-targets, even if they don't support it.
$ ./gcc/xgcc -Bgcc ../tests/hello.c -mx32 -o hc
register name `%rbp'
register name `%rsi'
(b) [serious] the m64 ObjC multi-lib is broken on i?86-darwin* (and
likely there are other more subtle effects).
This is because the code in config/darwin.c that Joseph pointed out
(earlier in this thread) is called for SUBSUBTARGET_OVERRIDE_OPTIONS.
That code sets defaults for, and checks errors for, flags that apply
to *-*-darwin* (and are needed for LTO as well as c-family).
In the case of the ObjC ABI (fobjc-abi-version=) we need to default it
to "2" @ m64 (and default it to 0 or 1 depending on the darwin version
I accept that some of this could possibly be done in driver-self-
specs; however, we allow m32/m64 to be unspecified on the c/l and to
default for the target. I'm also not yet sure whether %:version-
compare() would be applicable to fobjc-abi-version.
Thus, the current trunk implementation is broken by your patch and we
need to address that pending other solutions (I'm also very short of
free time for Darwin right now - to experiment with the specs solution).
It is possible that there is an options handling issue, (although I
might also have misunderstood) viz:
;; ISA support
Target RejectNegative Negative(m64) Report InverseMask(ISA_64BIT)
Generate 32bit i386 code
Target RejectNegative Negative(mx32) Report Mask(ABI_64)
Generate 64bit x86-64 code
Target RejectNegative Negative(m32) Report Mask(ABI_X32)
Generate 32bit x86-64 code
from gccint.pdf (section 8.2):
The option will turn oï another option othername, which is the option
with the leading â-â removed. This chain action will propagate
Negative property of the option to be turned oï.
As a consequence, if you have a group of mutually-exclusive options,
Negative properties should form a circular chain. For example, if
â-a â, â-b â and â-c â are mutually exclusive, their
respective Negative properties
should be âNegative(b )â, âNegative(c )â and âNegative(a )â.
I read this as "if the User specifies -a on the command line the
inverse of -b *and* the inverse of -c will be applied".
so that when -m64 is issued, the *inverse* of Mask(ABI_X32) should be
applied and then the *inverse* of InverseMask(ISA_64BIT) - which would
(correctly, for the case we're considering) set MASK_ISA_64BIT.
However, in the example above this does NOT happen - if I set a
breakpoint at the entry of x86_internal_override_options - ISA_64BIT
ends up as 0 when -m64 is specified on the c/l for i?86-darwin*.
The x86_isa_explicit stuff doesn't appear to get set either, although
global_options_set.x_x86_isa... does, which I've used in the attached
so is this an options bug or misunderstanding on my part?
An interim solution to the current scenario (tested by the chaps
across the darwin range) is attached.
Is that OK for trunk?
NOTE: I can't apply any patch at present, unless it's considered to be
trivial, since my personal FSF (c) assignment is in the process of
being transferred to my new employer.
Description: Text document