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

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 .




MfG, JBG

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

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

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

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

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