[BUILDROBOT] "error: null argument where non-null required" on multiple targets

[BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jan-Benedict Glaw]

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

Hi!

I'm not 100% sure, but I *think* that this patch

	2015-11-15  Jonathan Wakely  <jwakely@redhat.com>
	
		PR libstdc++/68353
		* include/bits/basic_string.h: Test value of _GLIBCXX_USE_C99_WCHAR
		not whether it is defined.
		* include/ext/vstring.h: Likewise.

uncovered errors like this:

/---------------------------------------
| g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -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 -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../../gcc/gcc/c-family/c-common.c
| In file included from ../../../gcc/gcc/c-family/c-common.c:31:0:
| ../../../gcc/gcc/c-family/c-common.c: In function ‘void c_common_nodes_and_builtins()’:
| ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null required (argument 1) [-Werror=nonnull]
|      ? get_identifier_with_length ((str), strlen (str))  \
|                                                      ^
| 
| ../../../gcc/gcc/c-family/c-common.c:5501:22: note: in expansion of macro ‘get_identifier’
|    char32_type_node = get_identifier (CHAR32_TYPE);
|                       ^~~~~~~~~~~~~~
| 
| cc1plus: all warnings being treated as errors
| Makefile:1085: recipe for target 'c-family/c-common.o' failed
\---------------------------------------

Shows up when using a newly build compiler to build the
contrib/config-list.mk targets. So these targets probably need some
small touch-ups.

avr-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
mipsel-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
mipsisa64r2-sde-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
mipsisa64sb1-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
mips-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
powerpc-eabialtivec	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
powerpc-eabispe		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
powerpc-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
ppc-elf			http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
sh-superh-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077

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: 181 bytes --]

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Moore, Catherine]

> -----Original Message-----
> From: Jan-Benedict Glaw [mailto:jbglaw@lug-owl.de]
> Sent: Sunday, December 06, 2015 4:49 PM
> To: Denis Chertykov; Moore, Catherine; Eric Christopher; Matthew Fortune;
> David Edelsohn; Alexandre Oliva; Kaz Kojima; Oleg Endo
> Cc: Jonathan Wakely; gcc-patches
> Subject: [BUILDROBOT] "error: null argument where non-null required" on
> multiple targets
> 
> Hi!
> 
> I'm not 100% sure, but I *think* that this patch
> 
> 	2015-11-15  Jonathan Wakely  <jwakely@redhat.com>
> 
> 		PR libstdc++/68353
> 		* include/bits/basic_string.h: Test value of
> _GLIBCXX_USE_C99_WCHAR
> 		not whether it is defined.
> 		* include/ext/vstring.h: Likewise.
> 
> uncovered errors like this:
> 
> /---------------------------------------
> | g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -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 -Werror -fno-
> common  -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -
> I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -
> I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -
> I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -
> I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o c-family/c-common.o -
> MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo
> ../../../gcc/gcc/c-family/c-common.c
> | In file included from ../../../gcc/gcc/c-family/c-common.c:31:0:
> | ../../../gcc/gcc/c-family/c-common.c: In function ‘void
> c_common_nodes_and_builtins()’:
> | ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null
> required (argument 1) [-Werror=nonnull]
> |      ? get_identifier_with_length ((str), strlen (str))  \
> |                                                      ^
> |
> | ../../../gcc/gcc/c-family/c-common.c:5501:22: note: in expansion of macro
> ‘get_identifier’
> |    char32_type_node = get_identifier (CHAR32_TYPE);
> |                       ^~~~~~~~~~~~~~
> |
> | cc1plus: all warnings being treated as errors
> | Makefile:1085: recipe for target 'c-family/c-common.o' failed
> \---------------------------------------
> 
> Shows up when using a newly build compiler to build the contrib/config-
> list.mk targets. So these targets probably need some small touch-ups.
> 
> avr-rtems		http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478544
> mipsel-elf		http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478844
> mipsisa64r2-sde-elf	http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478855
> mipsisa64sb1-elf	http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478865
> mips-rtems		http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478877
> powerpc-eabialtivec	http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478922
> powerpc-eabispe		http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478932
> powerpc-rtems		http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478956
> ppc-elf			http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478968
> sh-superh-elf		http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=479077
> 

Is there an easy way to reproduce the MIPS problems that you reported?  I don't seem to be able to do it with a cross-compiler targeting mipsel-elf.
Thanks,
Catherine

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jan-Benedict Glaw]

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

On Mon, 2015-12-14 18:54:28 +0000, Moore, Catherine <Catherine_Moore@mentor.com> wrote:
> > avr-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
> > mipsel-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
> > mipsisa64r2-sde-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
> > mipsisa64sb1-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
> > mips-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
> > powerpc-eabialtivec	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
> > powerpc-eabispe	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
> > powerpc-rtems	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
> > ppc-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
> > sh-superh-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077
> 
> Is there an easy way to reproduce the MIPS problems that you
> reported?  I don't seem to be able to do it with a cross-compiler
> targeting mipsel-elf.

What's your build compiler? For these builds, where it showed up, I'm
using a freshly compiles HEAD/master version. So basically, compile a
current GCC for your build machine:

	.../configure --prefix=/tmp/foo --disable-multilib \
		--enable-languages=all,ada,go
	make
	make install

...and then put that compiler into your $PATH and build a cross compiler:

	.../configure --target=mipsel-elf --enable-werror-always \
		--enable-languages=all,ada,go
	make all-gcc

(This is how contrib/config-list.mk does its test builds, which is
what I'm calling.)

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: 181 bytes --]

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jeff Law]

On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:
> On Mon, 2015-12-14 18:54:28 +0000, Moore, Catherine <Catherine_Moore@mentor.com> wrote:
>>> avr-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
>>> mipsel-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
>>> mipsisa64r2-sde-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
>>> mipsisa64sb1-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
>>> mips-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
>>> powerpc-eabialtivec	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
>>> powerpc-eabispe	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
>>> powerpc-rtems	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
>>> ppc-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
>>> sh-superh-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077
>>
>> Is there an easy way to reproduce the MIPS problems that you
>> reported?  I don't seem to be able to do it with a cross-compiler
>> targeting mipsel-elf.
>
> What's your build compiler? For these builds, where it showed up, I'm
> using a freshly compiles HEAD/master version. So basically, compile a
> current GCC for your build machine:
Right.  This is something that only shows up when using the trunk to 
build the crosses.

When I looked, I thought I bisected it to the delayed folding work.

jeff

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jan-Benedict Glaw]

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

On Tue, 2015-12-15 10:43:58 -0700, Jeff Law <law@redhat.com> wrote:
> On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:
> >On Mon, 2015-12-14 18:54:28 +0000, Moore, Catherine <Catherine_Moore@mentor.com> wrote:
> >>>avr-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
> >>>mipsel-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
> >>>mipsisa64r2-sde-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
> >>>mipsisa64sb1-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
> >>>mips-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
> >>>powerpc-eabialtivec	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
> >>>powerpc-eabispe	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
> >>>powerpc-rtems	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
> >>>ppc-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
> >>>sh-superh-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077
> >>
> >>Is there an easy way to reproduce the MIPS problems that you
> >>reported?  I don't seem to be able to do it with a cross-compiler
> >>targeting mipsel-elf.
> >
> >What's your build compiler? For these builds, where it showed up, I'm
> >using a freshly compiles HEAD/master version. So basically, compile a
> >current GCC for your build machine:
> Right.  This is something that only shows up when using the trunk to build
> the crosses.
> 
> When I looked, I thought I bisected it to the delayed folding work.

Shall I bisect one of the cases anew, with the "Test value of
_GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that uncovered
it, applied? Starting with some arbitrary old revision?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:          GDB has a 'break' feature; why doesn't it have 'fix' too?
the second  :

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

Re: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Jeff Law]

On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> On Tue, 2015-12-15 10:43:58 -0700, Jeff Law <law@redhat.com> wrote:
>> On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:
>>> On Mon, 2015-12-14 18:54:28 +0000, Moore, Catherine <Catherine_Moore@mentor.com> wrote:
>>>>> avr-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478544
>>>>> mipsel-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478844
>>>>> mipsisa64r2-sde-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478855
>>>>> mipsisa64sb1-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478865
>>>>> mips-rtems		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478877
>>>>> powerpc-eabialtivec	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478922
>>>>> powerpc-eabispe	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478932
>>>>> powerpc-rtems	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478956
>>>>> ppc-elf		http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=478968
>>>>> sh-superh-elf	http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=479077
>>>>
>>>> Is there an easy way to reproduce the MIPS problems that you
>>>> reported?  I don't seem to be able to do it with a cross-compiler
>>>> targeting mipsel-elf.
>>>
>>> What's your build compiler? For these builds, where it showed up, I'm
>>> using a freshly compiles HEAD/master version. So basically, compile a
>>> current GCC for your build machine:
>> Right.  This is something that only shows up when using the trunk to build
>> the crosses.
>>
>> When I looked, I thought I bisected it to the delayed folding work.
>
> Shall I bisect one of the cases anew, with the "Test value of
> _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that uncovered
> it, applied? Starting with some arbitrary old revision?
Yes.  I'd really like to see config-list.mk working again.  The first 
step is always building a test the developers can easily work with.


jeff

config-list.mk and obsoleted configurations (was: [BUILDROBOT] "error: null argument where non-null required" on multiple targets)

[Jan-Benedict Glaw]

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

On Thu, 2015-12-17 11:05:42 -0700, Jeff Law <law@redhat.com> wrote:
> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> > Shall I bisect one of the cases anew, with the "Test value of
> > _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that
> > uncovered it, applied? Starting with some arbitrary old revision?
> Yes.  I'd really like to see config-list.mk working again.  The
> first step is always building a test the developers can easily work
> with.

Will do. Have a good starting point?

  Oh, there are some targets that were obsoleted today. I think the
OpenBSD3 and the two knetbsd configurations will need an
--enable-obsolete. I suggest this (untested) patch:

contrib/
2015-12-17  Jan-Benedict Glaw  <jbglaw@lug-owl.de>
    
	* config-list.mk (LIST): Add --enable-obsolete to recently obsoleted
	targets x86_64-knetbsd-gnu, i686-knetbsd-gnu and i686-openbsd3.0 .

diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index 8d39e68..ab8060b 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2015-12-17  Jan-Benedict Glaw  <jbglaw@lug-owl.de>
+
+	* config-list.mk (LIST): Add --enable-obsolete to recently obsoleted
+	targets x86_64-knetbsd-gnu, i686-knetbsd-gnu and i686-openbsd3.0 .
+
 2015-12-06  Tobias Burnus  <burnus@net-b.de>
 
 	* download_prerequisites: Download ISL 0.15 instead of 0.14.
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index f0e39d6..0f15464 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -28,7 +28,8 @@ LIST = aarch64-elf aarch64-linux-gnu \
   hppa64-hpux11.0OPT-enable-sjlj-exceptions=yes hppa2.0-hpux11.9 \
   i686-pc-linux-gnu i686-apple-darwin i686-apple-darwin9 i686-apple-darwin10 \
   i486-freebsd4 i686-freebsd6 i686-kfreebsd-gnu \
-  i686-netbsdelf9 i686-knetbsd-gnu i686-openbsd i686-openbsd3.0 \
+  i686-netbsdelf9 i686-knetbsd-gnuOPT-enable-obsolete \
+  i686-openbsd i686-openbsd3.0OPT-enable-obsolete \
   i686-elf i686-kopensolaris-gnu i686-symbolics-gnu i686-pc-msdosdjgpp \
   i686-lynxos i686-nto-qnx \
   i686-rtems i686-solaris2.10 i686-wrs-vxworks \
@@ -74,7 +75,7 @@ LIST = aarch64-elf aarch64-linux-gnu \
   vax-netbsdelf vax-openbsd visium-elf x86_64-apple-darwin \
   x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \
-  x86_64-knetbsd-gnu x86_64-w64-mingw32 \
+  x86_64-knetbsd-gnuOPT-enable-obsolete x86_64-w64-mingw32 \
   x86_64-mingw32OPT-enable-sjlj-exceptions=yes xstormy16-elf xtensa-elf \
   xtensa-linux \
   i686-interix3OPT-enable-obsolete



MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of: 23:53 <@jbglaw> So, ich kletter' jetzt mal ins Bett.
the second  : 23:57 <@jever2> .oO( kletter ..., hat er noch Gitter vorm Bett, wie früher meine Kinder?)
              00:00 <@jbglaw> jever2: *patsch*
              00:01 <@jever2> *aua*, wofür, Gedanken sind frei!
              00:02 <@jbglaw> Nee, freie Gedanken, die sind seit 1984 doch aus!
              00:03 <@jever2> 1984? ich bin erst seit 1985 verheiratet!

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

Re: config-list.mk and obsoleted configurations

[Jeff Law]

On 12/17/2015 11:34 AM, Jan-Benedict Glaw wrote:
> On Thu, 2015-12-17 11:05:42 -0700, Jeff Law <law@redhat.com> wrote:
>> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
>>> Shall I bisect one of the cases anew, with the "Test value of
>>> _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that
>>> uncovered it, applied? Starting with some arbitrary old revision?
>> Yes.  I'd really like to see config-list.mk working again.  The
>> first step is always building a test the developers can easily work
>> with.
>
> Will do. Have a good starting point?
The biggest problem is the breakage around wither USE_C99_WCHAR or 
delayed folding.  I think I counted 30+ targets that were effected.

Once that's settled, I suspect anything remaining will be pretty minor.

I'd disable interix completely.

Not sure what to do with avr-rtems at this point.

>    Oh, there are some targets that were obsoleted today. I think the
> OpenBSD3 and the two knetbsd configurations will need an
> --enable-obsolete. I suggest this (untested) patch:
>
> contrib/
> 2015-12-17  Jan-Benedict Glaw  <jbglaw@lug-owl.de>
>
> 	* config-list.mk (LIST): Add --enable-obsolete to recently obsoleted
> 	targets x86_64-knetbsd-gnu, i686-knetbsd-gnu and i686-openbsd3.0 .
Seems fine to me once it's gone through whatever testing you want to do.

jeff

Re: config-list.mk and obsoleted configurations

[Jan-Benedict Glaw]

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

On Thu, 2015-12-17 11:39:24 -0700, Jeff Law <law@redhat.com> wrote:
> On 12/17/2015 11:34 AM, Jan-Benedict Glaw wrote:
> > On Thu, 2015-12-17 11:05:42 -0700, Jeff Law <law@redhat.com> wrote:
> > > On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> > > > Shall I bisect one of the cases anew, with the "Test value of
> > > > _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that
> > > > uncovered it, applied? Starting with some arbitrary old revision?
> > > Yes.  I'd really like to see config-list.mk working again.  The
> > > first step is always building a test the developers can easily work
> > > with.
> >
> > Will do. Have a good starting point?
> The biggest problem is the breakage around wither USE_C99_WCHAR or delayed
> folding.  I think I counted 30+ targets that were effected.

It's probably delayed folding; seems the USE_C99_WCHAR stuff only
uncovers it, doesn't it?

> Once that's settled, I suspect anything remaining will be pretty minor.
> 
> I'd disable interix completely.

Seems to be not hard to fix. Breaks with:

g++ -fno-PIE -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 -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace  \
../../../gcc/gcc/config/i386/winnt.c
../../../gcc/gcc/config/i386/winnt.c: In function ‘void i386_pe_unique_section(tree, int)’:
../../../gcc/gcc/config/i386/winnt.c:376:8: error: ‘flag_writable_rel_rdata’ was not declared in this scope
   if (!flag_writable_rel_rdata)
        ^~~~~~~~~~~~~~~~~~~~~~~

../../../gcc/gcc/config/i386/winnt.c: In function ‘unsigned int i386_pe_section_type_flags(tree, const char*, int)’:
../../../gcc/gcc/config/i386/winnt.c:432:8: error: ‘flag_writable_rel_rdata’ was not declared in this scope
   if (!flag_writable_rel_rdata)
        ^~~~~~~~~~~~~~~~~~~~~~~

../../../gcc/gcc/config/i386/t-interix:22: recipe for target 'winnt.o' failed




jbglaw@pluto:~/src/toolchain/gcc [master] $ git grep flag_writable_rel_rdata
gcc/ChangeLog-2012:     Add new flag variable flag_writable_rel_rdata.
gcc/config/i386/cygming.opt:Common Report Var(flag_writable_rel_rdata) Init(0)
gcc/config/i386/winnt.c:  if (!flag_writable_rel_rdata)
gcc/config/i386/winnt.c:  if (!flag_writable_rel_rdata)



> Not sure what to do with avr-rtems at this point.

My buildrobot just fails at the very same USE_C99_WCHAR issue right
now. Is there something more hidden, later on in the build?

> >   Oh, there are some targets that were obsoleted today. I think the
> >OpenBSD3 and the two knetbsd configurations will need an
> >--enable-obsolete. I suggest this (untested) patch:
> >
> >contrib/
> >2015-12-17  Jan-Benedict Glaw  <jbglaw@lug-owl.de>
> >
> >	* config-list.mk (LIST): Add --enable-obsolete to recently obsoleted
> >	targets x86_64-knetbsd-gnu, i686-knetbsd-gnu and i686-openbsd3.0 .
> Seems fine to me once it's gone through whatever testing you want to do.

Will verify that it's needed and if it is (as suspected), I'll commit
it properly.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of: 17:45 <@Eimann> Hrm, das E90 hat keinen Lebenszeit Call-Time Counter mehr
the second  : 17:46 <@jbglaw> Eimann: Wofür braucht man das?
              17:46 <@jbglaw> Eimann: Für mich ist an 'nem Handy wichtig, daß ich mein
                              Gegeüber hören kann. Und daß mein Gegenüber mich versteht...
              17:47 <@KrisK> jbglaw: was du meinst ist wodka.
              17:47 <@KrisK> jbglaw: es klingelt und man hört stimmen

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

Re: config-list.mk and obsoleted configurations

[Jeff Law]

On 12/17/2015 11:58 AM, Jan-Benedict Glaw wrote:
> On Thu, 2015-12-17 11:39:24 -0700, Jeff Law <law@redhat.com> wrote:
>> On 12/17/2015 11:34 AM, Jan-Benedict Glaw wrote:
>>> On Thu, 2015-12-17 11:05:42 -0700, Jeff Law <law@redhat.com> wrote:
>>>> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
>>>>> Shall I bisect one of the cases anew, with the "Test value of
>>>>> _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that
>>>>> uncovered it, applied? Starting with some arbitrary old revision?
>>>> Yes.  I'd really like to see config-list.mk working again.  The
>>>> first step is always building a test the developers can easily work
>>>> with.
>>>
>>> Will do. Have a good starting point?
>> The biggest problem is the breakage around wither USE_C99_WCHAR or delayed
>> folding.  I think I counted 30+ targets that were effected.
>
> It's probably delayed folding; seems the USE_C99_WCHAR stuff only
> uncovers it, doesn't it?
>
>> Once that's settled, I suspect anything remaining will be pretty minor.
>>
>> I'd disable interix completely.
>
> Seems to be not hard to fix. Breaks with:
I know, but it's not worth fixing IMHO.  Interix has been a dead product 
for a long time.  We almost got rid of it several years ago, but someone 
objected and said they'd maintain it.  I asked Trevor to put it back on 
the deprecated list a little while ago.

AFAICT it hasn't been building since 2012.  I fixed some of the problems 
a few months ago, but just can't really justify anyone's time to figure 
out which way to #define this away to preserve prior behaviour and to 
continue to keep it working over time.


>
>> Not sure what to do with avr-rtems at this point.
>
> My buildrobot just fails at the very same USE_C99_WCHAR issue right
> now. Is there something more hidden, later on in the build?
avr-rtems has deeper issues, which ultimately look like the same problem 
you're seeing with delayed folding, but aren't the same problem.

Essentially avr-rtems's definitions of various standard types are all 
conditional on flags with a default that is NULL.  Those are ultimately 
passed to one of the str* functions and GCC throws a warning/failure.

There's no way to fold those down to a constant, (or even to prove the 
NULL case couldn't happen IIRC).  So even once the current delayed 
folding issue gets fixed, avr-rtems will remain broken.

It's also unclear how long avr-rtems will be around.  I get the sense 
it's on its last legs -- and given we have both avr and rtems coverage 
via other targets, I don't think building avr-rtems is really all that 
helpful.

Jeff

Re: config-list.mk and obsoleted configurations

[Trevor Saunders]

On Thu, Dec 17, 2015 at 12:53:20PM -0700, Jeff Law wrote:
> On 12/17/2015 11:58 AM, Jan-Benedict Glaw wrote:
> >On Thu, 2015-12-17 11:39:24 -0700, Jeff Law <law@redhat.com> wrote:
> >>On 12/17/2015 11:34 AM, Jan-Benedict Glaw wrote:
> >>>On Thu, 2015-12-17 11:05:42 -0700, Jeff Law <law@redhat.com> wrote:
> >>>>On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> >>>>>Shall I bisect one of the cases anew, with the "Test value of
> >>>>>_GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that
> >>>>>uncovered it, applied? Starting with some arbitrary old revision?
> >>>>Yes.  I'd really like to see config-list.mk working again.  The
> >>>>first step is always building a test the developers can easily work
> >>>>with.
> >>>
> >>>Will do. Have a good starting point?
> >>The biggest problem is the breakage around wither USE_C99_WCHAR or delayed
> >>folding.  I think I counted 30+ targets that were effected.
> >
> >It's probably delayed folding; seems the USE_C99_WCHAR stuff only
> >uncovers it, doesn't it?
> >
> >>Once that's settled, I suspect anything remaining will be pretty minor.
> >>
> >>I'd disable interix completely.
> >
> >Seems to be not hard to fix. Breaks with:
> I know, but it's not worth fixing IMHO.  Interix has been a dead product for
> a long time.  We almost got rid of it several years ago, but someone
> objected and said they'd maintain it.  I asked Trevor to put it back on the
> deprecated list a little while ago.
> 
> AFAICT it hasn't been building since 2012.  I fixed some of the problems a
> few months ago, but just can't really justify anyone's time to figure out
> which way to #define this away to preserve prior behaviour and to continue
> to keep it working over time.

 and killing it will help move towards killing other things you dislike
 like sdb and dbx.

> 
> >
> >>Not sure what to do with avr-rtems at this point.
> >
> >My buildrobot just fails at the very same USE_C99_WCHAR issue right
> >now. Is there something more hidden, later on in the build?
> avr-rtems has deeper issues, which ultimately look like the same problem
> you're seeing with delayed folding, but aren't the same problem.
> 
> Essentially avr-rtems's definitions of various standard types are all
> conditional on flags with a default that is NULL.  Those are ultimately
> passed to one of the str* functions and GCC throws a warning/failure.

hWell, it might be the only target that has warnings because of that,
but from a quick look it seems like any target that uses avr-stdint.h or
newlib-stdint.h could theoretically have null values for those macros.
Without a bit of digging I'm not sure how much of that is real and how
much is completely theoretical archs that would have any number of other
problems.

Trev


> 
> There's no way to fold those down to a constant, (or even to prove the NULL
> case couldn't happen IIRC).  So even once the current delayed folding issue
> gets fixed, avr-rtems will remain broken.
> 
> It's also unclear how long avr-rtems will be around.  I get the sense it's
> on its last legs -- and given we have both avr and rtems coverage via other
> targets, I don't think building avr-rtems is really all that helpful.
> 
> Jeff

Re: config-list.mk and obsoleted configurations

[Jeff Law]

>
> hWell, it might be the only target that has warnings because of that,
> but from a quick look it seems like any target that uses avr-stdint.h or
> newlib-stdint.h could theoretically have null values for those macros.
> Without a bit of digging I'm not sure how much of that is real and how
> much is completely theoretical archs that would have any number of other
> problems.
The other targets don't trip over it for various reasons.  You have to 
dig into how the target stuff is setup in the avr port.  I outlined it a 
while back then went and had a beer to erase the memory of how that 
stuff got expanded.

jeff

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

[Moore, Catherine]

> -----Original Message-----
> From: Jeff Law [mailto:law@redhat.com]
> Sent: Thursday, December 17, 2015 1:06 PM
> To: Jan-Benedict Glaw
> Cc: Moore, Catherine; Denis Chertykov; Eric Christopher; Matthew Fortune;
> David Edelsohn; Alexandre Oliva; Kaz Kojima; Oleg Endo; Jonathan Wakely;
> gcc-patches
> Subject: Re: [BUILDROBOT] "error: null argument where non-null required"
> on multiple targets
> 
> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> > On Tue, 2015-12-15 10:43:58 -0700, Jeff Law <law@redhat.com> wrote:
> >> On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:
> >>> On Mon, 2015-12-14 18:54:28 +0000, Moore, Catherine
> <Catherine_Moore@mentor.com> wrote:
> >>>> Is there an easy way to reproduce the MIPS problems that you
> >>>> reported?  I don't seem to be able to do it with a cross-compiler
> >>>> targeting mipsel-elf.
> >>>
> >>> What's your build compiler? For these builds, where it showed up,
> >>> I'm using a freshly compiles HEAD/master version. So basically,
> >>> compile a current GCC for your build machine:
> >> Right.  This is something that only shows up when using the trunk to
> >> build the crosses.
> >>
Thanks -- I have now reproduced the problem.