This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, x86, Darwin] update darwin's x86 output.
- From: Mike Stump <mikestump at comcast dot net>
- To: IainS <developer at sandoe-acoustics dot co dot uk>
- Cc: Richard Henderson <rth at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Mike Stump <mrs at gcc dot gnu dot org>
- Date: Mon, 1 Nov 2010 12:09:50 -0700
- Subject: Re: [Patch, x86, Darwin] update darwin's x86 output.
- References: <0C9D7B56-EE4B-4638-9352-DEF5829D1E3A@sandoe-acoustics.co.uk> <4CCDFE05.5020308@redhat.com> <0B67C020-0605-41FC-9575-6A9F61CB61F5@sandoe-acoustics.co.uk> <B08B4C9A-C2C6-40A5-AAC0-7ABF34624A98@sandoe-acoustics.co.uk>
On Nov 1, 2010, at 4:57 AM, IainS wrote:
> Looking closer, it seems that I've merged code that was dead in the original :-(
Yes, that's a distinct possibility. The old code did it one way, it was fixed up to do it better, but this remnant remained. I'd remove it and proceed forward. Worse case scenario would be we find a fault down the road and have to change the code that builds up a plus to instead wrap a const around it. I'm thinking this code should fall over often and fairly quickly if we get it wrong. For example, a mere bootstrap with -mdynamic-no-pic on a -m32 style build should excise it sufficiently well.
> I tested this hypothesis by placing a gcc_unreachable () after the case PLUS:
> and bootstrapping (with -mdynamic-no-pic in boot flags) and doing make check-gcc with
> -m32/-mdynamic-no-pic
Sounds sufficient.
> OK for trunk?
Ok with the rth please format this better fix and the dropping of the dead code rth pointed out.
I'd pre-approve the mh-*darwin changes as well, either to have just a mh-darwin, if both architectures are now the same, or to have one per architecture. Preference for the former, unless you have visibility into more code that might want to go into one but not the other file. If -m64 warns and needs something different, I'd rather have two files, unless we want to make it not warn. Similar comment about the .opt file. If we know of things that might go into it in the future, I'm fine with leaving a stub. Doing then undoing and redoing configure work is just annoying.