we are starting the wide int merge

we are starting the wide int merge

[Kenneth Zadeck]

please hold off on committing patches for the next couple of hours as we 
have a very large merge to do.
thanks.

kenny

Re: we are starting the wide int merge

[Mike Stump]

On May 6, 2014, at 8:19 AM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
> please hold off on committing patches for the next couple of hours as we have a very large merge to do.
> thanks.

All done…  It is in.

Re: we are starting the wide int merge

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 5249 bytes --]

On Tue, 2014-05-06 12:20:54 -0700, Mike Stump <mikestump@comcast.net> wrote:
> On May 6, 2014, at 8:19 AM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
> > please hold off on committing patches for the next couple of hours as we have a very large merge to do.
> > thanks.
> 
> All done…  It is in.

My build robot experiences errors like this:


g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o alias.o -MT alias.o -MMD -MP -MF ./.deps/alias.TPo /home/jbglaw/repos/gcc/gcc/alias.c
In file included from /home/jbglaw/repos/gcc/gcc/real.h:25:0,
                 from /home/jbglaw/repos/gcc/gcc/rtl.h:27,
                 from /home/jbglaw/repos/gcc/gcc/alias.c:25:
/home/jbglaw/repos/gcc/gcc/wide-int.h: In instantiation of 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
/home/jbglaw/repos/gcc/gcc/alias.c:346:28:   required from here
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
   WIDE_INT_REF_FOR (T2) yi (y, precision);
                         ^
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
/home/jbglaw/repos/gcc/gcc/wide-int.h: In instantiation of 'unsigned int wi::get_binary_precision(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
/home/jbglaw/repos/gcc/gcc/wide-int.h:1785:54:   required from 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]'
/home/jbglaw/repos/gcc/gcc/alias.c:346:28:   required from here
/home/jbglaw/repos/gcc/gcc/wide-int.h:1638:27: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
    get_binary_result (x, y));
                           ^
/home/jbglaw/repos/gcc/gcc/wide-int.h: In function 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
/home/jbglaw/repos/gcc/gcc/wide-int.h:1803:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
/home/jbglaw/repos/gcc/gcc/wide-int.h: In function 'unsigned int wi::get_binary_precision(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
/home/jbglaw/repos/gcc/gcc/wide-int.h:1639:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
make[1]: *** [alias.o] Error 1


...at least for:
rl78-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219615)
microblazeel-linux (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219701)
msp430-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219703)
arc-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219789)
...but not for:
arm-eabi (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219709)
bfin-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219778)
(and several others.)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:              Alles sollte so einfach wie möglich gemacht sein.
the second  :                          Aber nicht einfacher.  (Einstein)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: we are starting the wide int merge

[Mike Stump]

On May 6, 2014, at 2:17 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Tue, 2014-05-06 12:20:54 -0700, Mike Stump <mikestump@comcast.net> wrote:
>> On May 6, 2014, at 8:19 AM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>>> please hold off on committing patches for the next couple of hours as we have a very large merge to do.
>>> thanks.
>> 
>> All done…  It is in.
> 
> My build robot experiences errors like this:
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o alias.o -MT alias.o -MMD -MP -MF ./.deps/alias.TPo /home/jbglaw/repos/gcc/gcc/alias.c
> In file included from /home/jbglaw/repos/gcc/gcc/real.h:25:0,
>                 from /home/jbglaw/repos/gcc/gcc/rtl.h:27,
>                 from /home/jbglaw/repos/gcc/gcc/alias.c:25:
> /home/jbglaw/repos/gcc/gcc/wide-int.h: In instantiation of 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
> /home/jbglaw/repos/gcc/gcc/alias.c:346:28:   required from here
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
>   WIDE_INT_REF_FOR (T2) yi (y, precision);

I’m pretty sure this:

Index: gcc/wide-int.h
===================================================================
--- gcc/wide-int.h	(revision 210113)
+++ gcc/wide-int.h	(working copy)
@@ -1442,7 +1442,6 @@ namespace wi
   struct int_traits <unsigned int>
     : public primitive_int_traits <unsigned int, false> {};
 
-#if HOST_BITS_PER_INT != HOST_BITS_PER_WIDE_INT
   template <>
   struct int_traits <HOST_WIDE_INT>
     : public primitive_int_traits <HOST_WIDE_INT, true> {};
@@ -1450,7 +1449,6 @@ namespace wi
   template <>
   struct int_traits <unsigned HOST_WIDE_INT>
     : public primitive_int_traits <unsigned HOST_WIDE_INT, false> {};
-#endif
 }
 
 namespace wi

will fix it.  If someone can confirm that would be great.

Re: we are starting the wide int merge

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

On Tue, 2014-05-06 15:54:05 -0700, Mike Stump <mikestump@comcast.net> wrote:
> On May 6, 2014, at 2:17 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> > On Tue, 2014-05-06 12:20:54 -0700, Mike Stump <mikestump@comcast.net> wrote:
> > > On May 6, 2014, at 8:19 AM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
> > > > please hold off on committing patches for the next couple of
> > > > hours as we have a very large merge to do.  thanks.
> > > All done…  It is in.
> > My build robot experiences errors like this:
[...]
> I’m pretty sure this:
[...]
> will fix it.  If someone can confirm that would be great.

I addad that patch to two (darkeye and gcc76) of the builders. Won't
probably take too long :)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                http://catb.org/~esr/faqs/smart-questions.html
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: we are starting the wide int merge

[Mike Stump]

On May 6, 2014, at 3:54 PM, Mike Stump <mikestump@comcast.net> wrote:
> 
> I’m pretty sure this:

> will fix it.  If someone can confirm that would be great.

I tried that on my p7 and on my x86_64 machines, they both build fine.

Re: we are starting the wide int merge

[Mike Stump]

On May 6, 2014, at 3:54 PM, Mike Stump <mikestump@comcast.net> wrote:
> 
>> My build robot experiences errors like this:
>> 
>> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o alias.o -MT alias.o -MMD -MP -MF ./.deps/alias.TPo /home/jbglaw/repos/gcc/gcc/alias.c
>> In file included from /home/jbglaw/repos/gcc/gcc/real.h:25:0,
>>                from /home/jbglaw/repos/gcc/gcc/rtl.h:27,
>>                from /home/jbglaw/repos/gcc/gcc/alias.c:25:
>> /home/jbglaw/repos/gcc/gcc/wide-int.h: In instantiation of 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
>> /home/jbglaw/repos/gcc/gcc/alias.c:346:28:   required from here
>> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
>>  WIDE_INT_REF_FOR (T2) yi (y, precision);
> 
> I’m pretty sure this:

I checked this in, sorry for the breakage.

	* wide-int.h (wi::int_traits <HOST_WIDE_INT>): Always define.

Committed revision 210128.

Re: we are starting the wide int merge

[Christophe Lyon]

I have noticed build failures too (arm, aarch64).

It also looks like the git-svn-id property is now wrong/incomplete.
For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has:
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706
138bc75d-0d04-0410-961f-82ee72b054a4

How does it map to the SVN commit in trunk?

Thanks,

Christophe.


On 6 May 2014 23:17, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Tue, 2014-05-06 12:20:54 -0700, Mike Stump <mikestump@comcast.net> wrote:
>> On May 6, 2014, at 8:19 AM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>> > please hold off on committing patches for the next couple of hours as we have a very large merge to do.
>> > thanks.
>>
>> All done…  It is in.
>
> My build robot experiences errors like this:
>
>
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o alias.o -MT alias.o -MMD -MP -MF ./.deps/alias.TPo /home/jbglaw/repos/gcc/gcc/alias.c
> In file included from /home/jbglaw/repos/gcc/gcc/real.h:25:0,
>                  from /home/jbglaw/repos/gcc/gcc/rtl.h:27,
>                  from /home/jbglaw/repos/gcc/gcc/alias.c:25:
> /home/jbglaw/repos/gcc/gcc/wide-int.h: In instantiation of 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
> /home/jbglaw/repos/gcc/gcc/alias.c:346:28:   required from here
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
>    WIDE_INT_REF_FOR (T2) yi (y, precision);
>                          ^
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1787:25: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
> /home/jbglaw/repos/gcc/gcc/wide-int.h: In instantiation of 'unsigned int wi::get_binary_precision(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1785:54:   required from 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]'
> /home/jbglaw/repos/gcc/gcc/alias.c:346:28:   required from here
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1638:27: error: incomplete type 'wi::int_traits<long int>' used in nested name specifier
>     get_binary_result (x, y));
>                            ^
> /home/jbglaw/repos/gcc/gcc/wide-int.h: In function 'bool wi::ltu_p(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1803:1: warning: control reaches end of non-void function [-Wreturn-type]
>  }
>  ^
> /home/jbglaw/repos/gcc/gcc/wide-int.h: In function 'unsigned int wi::get_binary_precision(const T1&, const T2&) [with T1 = generic_wide_int<wi::extended_tree<96> >; T2 = long int]':
> /home/jbglaw/repos/gcc/gcc/wide-int.h:1639:1: warning: control reaches end of non-void function [-Wreturn-type]
>  }
>  ^
> make[1]: *** [alias.o] Error 1
>
>
> ...at least for:
> rl78-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219615)
> microblazeel-linux (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219701)
> msp430-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219703)
> arc-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219789)
> ...but not for:
> arm-eabi (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219709)
> bfin-elf (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=219778)
> (and several others.)
>
> MfG, JBG
>
> --
>       Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
> Signature of:              Alles sollte so einfach wie möglich gemacht sein.
> the second  :                          Aber nicht einfacher.  (Einstein)

Re: we are starting the wide int merge

[Andreas Schwab]

Christophe Lyon <christophe.lyon@linaro.org> writes:

> It also looks like the git-svn-id property is now wrong/incomplete.
> For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has:
>     git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> How does it map to the SVN commit in trunk?

This is a commit on the wide-int branch (the one that created it).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: we are starting the wide int merge

[Christophe Lyon]

On 7 May 2014 09:48, Andreas Schwab <schwab@suse.de> wrote:
> Christophe Lyon <christophe.lyon@linaro.org> writes:
>
>> It also looks like the git-svn-id property is now wrong/incomplete.
>> For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has:
>>     git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706
>> 138bc75d-0d04-0410-961f-82ee72b054a4
>>
>> How does it map to the SVN commit in trunk?
>
> This is a commit on the wide-int branch (the one that created it).
>

I had a bug in my script while parsing the output of git log,
hopefully fixed now.

Re: we are starting the wide int merge

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]

On Tue, 2014-05-06 12:20:54 -0700, Mike Stump <mikestump@comcast.net> wrote:
> On May 6, 2014, at 8:19 AM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
> > please hold off on committing patches for the next couple of hours as we have a very large merge to do.
> > thanks.
> 
> All done…  It is in.

Just found one more:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/vaxbuild/repos/gcc/gcc -I/home/vaxbuild/repos/gcc/gcc/. -I/home/vaxbuild/repos/gcc/gcc/../include -I/home/vaxbuild/repos/gcc/gcc/../libcpp/include  -I/home/vaxbuild/repos/gcc/gcc/../libdecnumber -I/home/vaxbuild/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/vaxbuild/repos/gcc/gcc/../libbacktrace    -o loop-iv.o -MT loop-iv.o -MMD -MP -MF ./.deps/loop-iv.TPo /home/vaxbuild/repos/gcc/gcc/loop-iv.c
In file included from /home/vaxbuild/repos/gcc/gcc/real.h:25:0,
                 from /home/vaxbuild/repos/gcc/gcc/rtl.h:27,
                 from /home/vaxbuild/repos/gcc/gcc/loop-iv.c:54:
/home/vaxbuild/repos/gcc/gcc/wide-int.h: In instantiation of ‘fixed_wide_int_storage<N>::fixed_wide_int_storage(const T&) [with T = long long unsigned int; int N = 160]’:
/home/vaxbuild/repos/gcc/gcc/wide-int.h:724:15:   required from ‘generic_wide_int<T>::generic_wide_int(const T&) [with T = long long unsigned int; storage = fixed_wide_int_storage<160>]’
/home/vaxbuild/repos/gcc/gcc/loop-iv.c:2628:48:   required from here
/home/vaxbuild/repos/gcc/gcc/wide-int.h:1172:45: error: incomplete type ‘wi::int_traits<long long unsigned int>’ used in nested name specifier
   WI_BINARY_RESULT (T, FIXED_WIDE_INT (N)) *assertion ATTRIBUTE_UNUSED;
                                             ^
/home/vaxbuild/repos/gcc/gcc/wide-int.h:1173:47: error: incomplete type ‘wi::int_traits<long long unsigned int>’ used in nested name specifier
   wi::copy (*this, WIDE_INT_REF_FOR (T) (x, N));
                                               ^
make[1]: *** [loop-iv.o] Error 1






This happened for bfin-elf, see http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=220155

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
 Signature of:                    Don't believe in miracles: Rely on them!
 the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: we are starting the wide int merge

[Richard Sandiford]

Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> On Tue, 2014-05-06 12:20:54 -0700, Mike Stump <mikestump@comcast.net> wrote:
>> On May 6, 2014, at 8:19 AM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>> > please hold off on committing patches for the next couple of hours
>> > as we have a very large merge to do.
>> > thanks.
>> 
>> All done…  It is in.
>
> Just found one more:
>
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/vaxbuild/repos/gcc/gcc -I/home/vaxbuild/repos/gcc/gcc/. -I/home/vaxbuild/repos/gcc/gcc/../include -I/home/vaxbuild/repos/gcc/gcc/../libcpp/include  -I/home/vaxbuild/repos/gcc/gcc/../libdecnumber -I/home/vaxbuild/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/vaxbuild/repos/gcc/gcc/../libbacktrace    -o loop-iv.o -MT loop-iv.o -MMD -MP -MF ./.deps/loop-iv.TPo /home/vaxbuild/repos/gcc/gcc/loop-iv.c
> In file included from /home/vaxbuild/repos/gcc/gcc/real.h:25:0,
>                  from /home/vaxbuild/repos/gcc/gcc/rtl.h:27,
>                  from /home/vaxbuild/repos/gcc/gcc/loop-iv.c:54:
> /home/vaxbuild/repos/gcc/gcc/wide-int.h: In instantiation of ‘fixed_wide_int_storage<N>::fixed_wide_int_storage(const T&) [with T = long long unsigned int; int N = 160]’:
> /home/vaxbuild/repos/gcc/gcc/wide-int.h:724:15:   required from ‘generic_wide_int<T>::generic_wide_int(const T&) [with T = long long unsigned int; storage = fixed_wide_int_storage<160>]’
> /home/vaxbuild/repos/gcc/gcc/loop-iv.c:2628:48:   required from here
> /home/vaxbuild/repos/gcc/gcc/wide-int.h:1172:45: error: incomplete type ‘wi::int_traits<long long unsigned int>’ used in nested name specifier
>    WI_BINARY_RESULT (T, FIXED_WIDE_INT (N)) *assertion ATTRIBUTE_UNUSED;
>                                              ^
> /home/vaxbuild/repos/gcc/gcc/wide-int.h:1173:47: error: incomplete type ‘wi::int_traits<long long unsigned int>’ used in nested name specifier
>    wi::copy (*this, WIDE_INT_REF_FOR (T) (x, N));
>                                                ^
> make[1]: *** [loop-iv.o] Error 1

Looks like this is specific to 32-bit HOST_WIDE_INTs.  The problem was
that loop-iv.c was using HOST_WIDEST_INT and no template specialisations
were defined for that.

Richard B's patch to force HOST_WIDE_INT to 64 bits will fix this.

Thanks,
Richard

iq2000-elf: wide-int fallout (was: we are starting the wide int merge)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

[...]

Just found this for iq2000:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o wide-int.o -MT wide-int.o -MMD -MP -MF ./.deps/wide-int.TPo /home/jbglaw/repos/gcc/gcc/wide-int.cc
/home/jbglaw/repos/gcc/gcc/wide-int.cc:37:56: error: unable to emulate 'TI'
 typedef unsigned int UTItype __attribute__ ((mode (TI)));
                                                        ^
make[1]: *** [wide-int.o] Error 1



See build 222669 (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=222669)
for more details.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:             17:44 <@uschebit> Evangelist ist doch ein Vertriebler
the second  :           für unverkäufliche Produkte, oder? (#korsett, 20120821)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: iq2000-elf: wide-int fallout (was: we are starting the wide int merge)

[Oleg Endo]

On Fri, 2014-05-09 at 00:48 +0200, Jan-Benedict Glaw wrote:
> [...]
> 
> Just found this for iq2000:
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o wide-int.o -MT wide-int.o -MMD -MP -MF ./.deps/wide-int.TPo /home/jbglaw/repos/gcc/gcc/wide-int.cc
> /home/jbglaw/repos/gcc/gcc/wide-int.cc:37:56: error: unable to emulate 'TI'
>  typedef unsigned int UTItype __attribute__ ((mode (TI)));
>                                                         ^
> make[1]: *** [wide-int.o] Error 1

I also just ran into that.  Seems to be a host issue.  This one seems to
fix it: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00527.html

Another wide-int merge fallout I ran into:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61120

Cheers,
Oleg

UTItype fallout (was: wide-int fallout)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On Fri, 2014-05-09 00:48:39 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> Just found this for iq2000:
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-latest/include -I/opt/cfarm/mpfr-latest/include -I/opt/cfarm/mpc-latest/include  -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace    -o wide-int.o -MT wide-int.o -MMD -MP -MF ./.deps/wide-int.TPo /home/jbglaw/repos/gcc/gcc/wide-int.cc
> /home/jbglaw/repos/gcc/gcc/wide-int.cc:37:56: error: unable to emulate 'TI'
>  typedef unsigned int UTItype __attribute__ ((mode (TI)));
>                                                         ^
> make[1]: *** [wide-int.o] Error 1
> 
> See build 222669 (http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=222669)
> for more details.

That isn't actually fallout from the wide-int merge, but of later
added code.

Other targets affected are moxie-elf, aarch64_be-elf, alpha-linux,
cr16-elf, ppc-linux, hppa-linux, arc-elf, younameit.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:              Alles sollte so einfach wie möglich gemacht sein.
the second  :                          Aber nicht einfacher.  (Einstein)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: we are starting the wide int merge

[Gerald Pfeifer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 628 bytes --]

On Tue, 6 May 2014, Mike Stump wrote:
> All done…  It is in.

Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
fail as follows:

  Comparing stages 2 and 3
  warning: gcc/cc1obj-checksum.o differs
  warning: gcc/cc1-checksum.o differs
  warning: gcc/cc1plus-checksum.o differs
  Bootstrap comparison failure!
  gcc/fold-const.o differs
  gcc/simplify-rtx.o differs
  gcc/tree-ssa-ccp.o differs

(FreeBSD/i386 really builds for i486, but retains the original name;
I'm traveling with limited access, but would not be surprised for this
to also show up for i386-*-linux-gnu or i486-*-linux-gnu.)

Gerald

Re: we are starting the wide int merge

[Gerald Pfeifer]

On Sat, 10 May 2014, Gerald Pfeifer wrote:
> Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
> fail as follows:
> 
>   Comparing stages 2 and 3
>   warning: gcc/cc1obj-checksum.o differs
>   warning: gcc/cc1-checksum.o differs
>   warning: gcc/cc1plus-checksum.o differs
>   Bootstrap comparison failure!
>   gcc/fold-const.o differs
>   gcc/simplify-rtx.o differs
>   gcc/tree-ssa-ccp.o differs
> 
> (FreeBSD/i386 really builds for i486, but retains the original name;
> I'm traveling with limited access, but would not be surprised for this
> to also show up for i386-*-linux-gnu or i486-*-linux-gnu.)

Is anybody able to reproduce this, for example on a GNU/Linux system?

This tester of mine hasn't been able to bootstrap for nearly a week,
and timing-wise it would be really a coincidence were this not due to
wide-int.

Gerald

Re: we are starting the wide int merge

[Richard Sandiford]

Gerald Pfeifer <gerald@pfeifer.com> writes:
> On Sat, 10 May 2014, Gerald Pfeifer wrote:
>> Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
>> fail as follows:
>> 
>>   Comparing stages 2 and 3
>>   warning: gcc/cc1obj-checksum.o differs
>>   warning: gcc/cc1-checksum.o differs
>>   warning: gcc/cc1plus-checksum.o differs
>>   Bootstrap comparison failure!
>>   gcc/fold-const.o differs
>>   gcc/simplify-rtx.o differs
>>   gcc/tree-ssa-ccp.o differs
>> 
>> (FreeBSD/i386 really builds for i486, but retains the original name;
>> I'm traveling with limited access, but would not be surprised for this
>> to also show up for i386-*-linux-gnu or i486-*-linux-gnu.)
>
> Is anybody able to reproduce this, for example on a GNU/Linux system?
>
> This tester of mine hasn't been able to bootstrap for nearly a week,
> and timing-wise it would be really a coincidence were this not due to
> wide-int.

i386-linux-gnu won't bootstrap for me because there are no out-of-line
definitions of the sync_* routines.  I think this is expected.
i486-linux-gnu seems to bootstrap fine.

To rule out one possibility: which GCC are you using for stage1?

Thanks,
Richard

Re: we are starting the wide int merge

[Gerald Pfeifer]

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

...and an interesting failure on amd64:
https://redports.org/~gerald/20140518230801-31619-208275/gcc410-4.10.0.s20140518.log


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 <>
  ^~~~~~~~~~~
.././../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 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?

Gerald

Re: we are starting the wide int merge

[Richard Sandiford]

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 <>.

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> >
   {

Re: we are starting the wide int merge

[Richard Sandiford]

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