This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, x86, Darwin] update darwin's x86 output.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]