Message ID | 20151217183448.GC27807@lug-owl.de |
---|---|
State | New |
Headers | show |
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
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