diff mbox

we are starting the wide int merge

Message ID 87ha4ml0xv.fsf@talisman.default
State New
Headers show

Commit Message

Richard Sandiford May 19, 2014, 6:47 a.m. UTC 
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.

> In file included from .././../gcc-4.10-20140518/gcc/xcoffout.c:29:
> .././../gcc-4.10-20140518/gcc/tree.h:4576:3: warning: extraneous template 
> parameter list in template specialization
>   template <>
>   ^~~~~~~~~~~

Oops, fixed below, applied as obvious.

> .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a 
> cast in a inline asm context requiring an l-value: remove the cast or 
> build with -fheinous-gnu-extensions
>           umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ());
>           ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is PR 61146.  You can get around it by adding -fheinous-gnu-extensions
to BOOT_CFLAGS.

> This means this clang-based system is not able to bootstrap GCC trunk
> on amd64.
>
> Perhaps looking into this first may affect the failure on i486?

'Fraid it won't help.  We don't use umul_ppmm (or even include
longlong.h) for 486.

Thanks,
Richard


gcc/
	* tree.h: Remove extraneous template <>.

Comments

Richard Sandiford May 19, 2014, 5:33 p.m. UTC | #1 
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
diff mbox

Patch

Index: gcc/tree.h
===================================================================
--- gcc/tree.h	2014-05-19 07:45:30.378667987 +0100
+++ gcc/tree.h	2014-05-19 07:46:07.364991104 +0100
@@ -4573,7 +4573,6 @@  #define ANON_AGGRNAME_FORMAT "__anon_%d"
     unsigned int get_len () const;
   };
 
-  template <>
   template <int N>
   struct int_traits <extended_tree <N> >
   {