This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: we are starting the wide int merge
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Gerald Pfeifer <gerald at pfeifer dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Mon, 19 May 2014 18:33:24 +0100
- Subject: Re: we are starting the wide int merge
- Authentication-results: sourceware.org; auth=none
- References: <5368FD99 dot 2010607 at naturalbridge dot com> <A41D2B7B-480F-475B-B1CB-9FD001F5622C at comcast dot net> <alpine dot LSU dot 2 dot 11 dot 1405102137220 dot 2722 at tuna dot site> <alpine dot LSU dot 2 dot 11 dot 1405161854490 dot 2259 at tuna dot site> <87a9agztw1 dot fsf at talisman dot default> <alpine dot LSU dot 2 dot 11 dot 1405182101570 dot 4553 at tuna dot site> <87ha4ml0xv dot fsf at talisman dot default>
Richard Sandiford <rdsandiford@googlemail.com> writes:
> Gerald Pfeifer <gerald@pfeifer.com> writes:
>> On Sat, 17 May 2014, Richard Sandiford wrote:
>>> To rule out one possibility: which GCC are you using for stage1?
>>
>> I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
>> FreeBSD 8, 9 and 10 all build fine on i386 (= i486) and amd64.
>>
>> When I use the system compiler, which is GCC 4.2 on FreeBSD 8 and 9
>> and clang on FreeBSD 10, things fail on FreeBSD 10...
>>
>> ...with a bootstrap comparison failure of stages 2 and 3 on i386:
>> https://redports.org/~gerald/20140518230801-31619-208277/gcc410-4.10.0.s20140518.log
>
> Do you get exactly the same comparison failures using clang and GCC 4.2
> as the stage1 compiler? That would rule out the system compiler
> miscompiling stage1.
I couldn't reproduce this with GCC 4.2 but I could with clang.
The problem is that the C++ frontend's template instantation code has
several instances of foo (..., bar (...), bar (...), ...), where bar (...)
can create new decls. The numbering of the decls can then depend on which
order the compiler chooses to evaluate the function arguments. This later
causes code differences if the decl uids are used as tie-breakers to get
a stable sort.
I was just unlucky that this happened to trigger for the new wi:: code. :-)
I'm testing a patch now. It might need more than one iteration, but hopefully
I'll have something to submit tomorrow.
Thanks,
Richard