* Bootstrap failure on irix6.5 possibly caused by new C++ parser? @ 2002-12-29 9:30 Kaveh R. Ghazi 2002-12-30 11:44 ` Mark Mitchell 0 siblings, 1 reply; 15+ messages in thread From: Kaveh R. Ghazi @ 2002-12-29 9:30 UTC (permalink / raw) To: mark; +Cc: gcc Mark, I'm getting a new bootstrap failure on mips-sgi-irix6.5 today on the trunk. It occurs after the 3-stage when building libstdc++-v3: > /caip/u58/ghazi/gcc-testing/build/gcc/xgcc -shared-libgcc > -B/caip/u58/ghazi/gcc-testing/build/gcc/ -nostdinc++ > -L/caip/u58/ghazi/gcc-testing/build/mips-sgi-irix6.5/libstdc++-v3/src > -L/caip/u58/ghazi/gcc-testing/build/mips-sgi-irix6.5/libstdc++-v3/src/.libs > -B/usr/local/mips-sgi-irix6.5/bin/ -B/usr/local/mips-sgi-irix6.5/lib/ > -isystem /usr/local/mips-sgi-irix6.5/include -nostdinc++ > -I/caip/u58/ghazi/gcc-testing/build/mips-sgi-irix6.5/libstdc++-v3/include/mips-sgi-irix6.5 > -I/caip/u58/ghazi/gcc-testing/build/mips-sgi-irix6.5/libstdc++-v3/include > -I../../../../egcc-CVS20021228/libstdc++-v3/libsupc++ > -I../../../../egcc-CVS20021228/libstdc++-v3/libmath -g -O2 > -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline > -fdiagnostics-show-location=once -ffunction-sections -fdata-sections > -c ../../../../egcc-CVS20021228/libstdc++-v3/src/codecvt.cc -DPIC -o > .libs/codecvt.o > ../../../../egcc-CVS20021228/libstdc++-v3/src/codecvt.cc: In member function ` > virtual int std::codecvt<char, char, mbstate_t>::do_encoding() const': > ../../../../egcc-CVS20021228/libstdc++-v3/src/codecvt.cc:100: internal compiler error: RTL > flag check: RTX_INTEGRATED_P used with unexpected rtx code `UnKnown' in > priority, at haifa-sched.c:808 > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. > make[4]: *** [codecvt.lo] Error 1 The annoying part is that the failure goes away if I add --save-temps, so I assume it's not possible to provide a .ii file that reproduces the crash in a cross compiler. :-( If you still think it would be useful to provide it let me know. Bootstrap previously succeeded on 12/26 for irix6.2, as shown here: http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg01174.html and for irix6.5 a couple of days before that. So I think it's possible or perhaps even likely that this was caused by the new parser. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-29 9:30 Bootstrap failure on irix6.5 possibly caused by new C++ parser? Kaveh R. Ghazi @ 2002-12-30 11:44 ` Mark Mitchell 2002-12-30 12:39 ` Graham Stott 0 siblings, 1 reply; 15+ messages in thread From: Mark Mitchell @ 2002-12-30 11:44 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: gcc > Bootstrap previously succeeded on 12/26 for irix6.2, as shown here: > http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg01174.html and for > irix6.5 a couple of days before that. So I think it's possible or > perhaps even likely that this was caused by the new parser. Sounds like we could have some flaky memory accesses in the new parser, certainly. Do you have any way to give me access to your box? (I no longer have access to an IRIX box.) Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-30 11:44 ` Mark Mitchell @ 2002-12-30 12:39 ` Graham Stott 2002-12-30 12:58 ` Mark Mitchell 0 siblings, 1 reply; 15+ messages in thread From: Graham Stott @ 2002-12-30 12:39 UTC (permalink / raw) To: Mark Mitchell; +Cc: Kaveh R. Ghazi, gcc Mark, It looks like there's a similar problem for powerpc-eabisim target according to a more recent post by Andreas. Since it appears on cross sim target it should be easier for you to investigate than the IRIX native. --------------------------------------------------------------------------------------------------------- In file included from /mmix/cross-sources/combined/libstdc++-v3/src/ctype.cc:36: /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim/bits/ctype_noninline.h: In member function `virtual const char* std::ctype<char>::do_toupper(char*, const char*) const': /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim/bits/ctype_noninline.h:69: internal compiler error: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code `UnKnown' in write_dependence_p, at alias.c:2241 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. make[3]: *** [ctype.lo] Error 1 make[3]: Leaving directory `/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src' I configured on i686-linux-gnu with: # /mmix/cross-sources/combined/configure --target=powerpc-eabisim --prefix=/mmix/powerpc-eabisim/install --enable-languages=c,c++,objc,f77,ada --disable-nls --with-newlib --with-gnu-as -with-gnu-ld --with-gcc-version-trigger=/mmix/cross-sources/combined/gcc/version.c Andreas -------------------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-30 12:39 ` Graham Stott @ 2002-12-30 12:58 ` Mark Mitchell 2002-12-30 14:39 ` Andreas Jaeger 2002-12-31 12:33 ` Graham Stott 0 siblings, 2 replies; 15+ messages in thread From: Mark Mitchell @ 2002-12-30 12:58 UTC (permalink / raw) To: Graham Stott; +Cc: Kaveh R. Ghazi, gcc --On Monday, December 30, 2002 06:21:13 PM +0000 Graham Stott <graham.stott@btinternet.com> wrote: > Mark, > > It looks like there's a similar problem for powerpc-eabisim target > according to a more recent post by Andreas. Since it appears on cross sim > target it should be easier for you to investigate than the IRIX native. I didn't see that when I did it, but I probably did something very slightly different. Does it reproduce with a preprocessed source file for you? If so, would you send it to me with command-line flags? Otherwise, I will try to build the cross environment again. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-30 12:58 ` Mark Mitchell @ 2002-12-30 14:39 ` Andreas Jaeger 2002-12-30 19:28 ` Graham Stott 2002-12-31 12:33 ` Graham Stott 1 sibling, 1 reply; 15+ messages in thread From: Andreas Jaeger @ 2002-12-30 14:39 UTC (permalink / raw) To: Mark Mitchell; +Cc: Graham Stott, Kaveh R. Ghazi, gcc Mark Mitchell <mark@codesourcery.com> writes: > --On Monday, December 30, 2002 06:21:13 PM +0000 Graham Stott > <graham.stott@btinternet.com> wrote: > >> Mark, >> >> It looks like there's a similar problem for powerpc-eabisim target >> according to a more recent post by Andreas. Since it appears on cross sim >> target it should be easier for you to investigate than the IRIX native. > > I didn't see that when I did it, but I probably did something very slightly > different. > > Does it reproduce with a preprocessed source file for you? If so, would you > send it to me with command-line flags? Otherwise, I will try to build the > cross environment again. It does not reproduce directly for me: arthur:/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src:[1]$ /mmix/powerpc-eabisim/build/gcc/xgcc - shared-libgcc -B/mmix/powerpc-eabisim/build/gcc/ -nostdinc++ -L/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src -L/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src/.libs -nostdinc -B/mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/ -isystem /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/targ-include -isystem /mmix/cross-sources/combined/newlib/libc/include -B/mmix/powerpc-eabisim/install/powerpc-eabisim/bin/ -B/mmix/powerpc-eabisim/install/powerpc-eabisim/lib/ -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/include -L/mmix/powerpc-eabisim/build/ld -nostdinc++ -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include -I/mmix/cross-sources/combined/libstdc++-v3/libsupc++ -I/mmix/cross-sources/combined/libstdc++-v3/libmath -g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -c /mmix/cross-sources/combined/libstdc++-v3/src/ctype.cc -o ctype.o -v Reading specs from /mmix/powerpc-eabisim/build/gcc/specs Configured with: Thread model: single gcc version 3.4 20021230 (experimental) /mmix/powerpc-eabisim/build/gcc/cc1plus -quiet -nostdinc++ -nostdinc -nostdinc++ -v -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include -I/mmix/cross-sources/combined/libstdc++-v3/libsupc++ -I/mmix/cross-sources/combined/libstdc++-v3/libmath -iprefix /mmix/powerpc-eabisim/build/gcc/../lib/gcc-lib/powerpc-eabisim/3.4/ -isystem /mmix/powerpc-eabisim/build/gcc/include -isystem /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/include -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/bin/include -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/lib/include -D__GNUC__=3 -D__GNUC_MINOR__=4 -D__GNUC_PATCHLEVEL__=0 -isystem /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/targ-include -isystem /mmix/cross-sources/combined/newlib/libc/include -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/include /mmix/cross-sources/combined/libstdc++-v3/src/ctype.cc -D__GNUG__=3 -quiet -dumpbase ctype.cc -auxbase-strip ctype.o -g -O2 -Wall -Wno-format -W -Wwrite-strings -Winline -version -fno-implicit-templates -fdiagnostics-show-location=once -o /tmp/ccaxW6Kc.s ignoring nonexistent directory "/mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/include" ignoring nonexistent directory "/mmix/powerpc-eabisim/install/powerpc-eabisim/bin/include" ignoring nonexistent directory "/mmix/powerpc-eabisim/install/powerpc-eabisim/lib/include" ignoring nonexistent directory "/mmix/powerpc-eabisim/install/powerpc-eabisim/include" GNU C++ version 3.4 20021230 (experimental) (powerpc-eabisim) compiled by GNU C version 3.2.1 20020927 (prerelease) (SuSE Linux). #include "..." search starts here: #include <...> search starts here: /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include /mmix/cross-sources/combined/libstdc++-v3/libsupc++ /mmix/cross-sources/combined/libstdc++-v3/libmath /mmix/powerpc-eabisim/build/gcc/include /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/targ-include /mmix/cross-sources/combined/newlib/libc/include End of search list. In file included from /mmix/cross-sources/combined/libstdc++-v3/src/ctype.cc:36: /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim/bits/ctype_noninline.h: In member function `virtual const char* std::ctype<char>::do_toupper(char*, const char*) const': /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim/bits/ctype_noninline.h:69: internal compiler error: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code `UnKnown' in write_dependence_p, at alias.c:2241 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. arthur:/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src:[1]$ /mmix/powerpc-eabisim/build/gcc/xgcc -shared-libgcc -B/mmix/powerpc-eabisim/build/gcc/ -nostdinc++ -L/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src -L/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src/.libs -nostdinc -B/mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/ -isystem /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/targ-include -isystem /mmix/cross-sources/combined/newlib/libc/include -B/mmix/powerpc-eabisim/install/powerpc-eabisim/bin/ -B/mmix/powerpc-eabisim/install/powerpc-eabisim/lib/ -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/include -L/mmix/powerpc-eabisim/build/ld -nostdinc++ -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include -I/mmix/cross-sources/combined/libstdc++-v3/libsupc++ -I/mmix/cross-sources/combined/libstdc++-v3/libmath -g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -c /mmix/cross-sources/combined/libstdc++-v3/src/ctype.cc -o ctype.o -v -save-temps Reading specs from /mmix/powerpc-eabisim/build/gcc/specs Configured with: Thread model: single gcc version 3.4 20021230 (experimental) /mmix/powerpc-eabisim/build/gcc/cc1plus -E -D__GNUG__=3 -quiet -nostdinc++ -nostdinc -nostdinc++ -v -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim -I/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include -I/mmix/cross-sources/combined/libstdc++-v3/libsupc++ -I/mmix/cross-sources/combined/libstdc++-v3/libmath -iprefix /mmix/powerpc-eabisim/build/gcc/../lib/gcc-lib/powerpc-eabisim/3.4/ -isystem /mmix/powerpc-eabisim/build/gcc/include -isystem /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/include -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/bin/include -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/lib/include -D__GNUC__=3 -D__GNUC_MINOR__=4 -D__GNUC_PATCHLEVEL__=0 -isystem /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/targ-include -isystem /mmix/cross-sources/combined/newlib/libc/include -isystem /mmix/powerpc-eabisim/install/powerpc-eabisim/include /mmix/cross-sources/combined/libstdc++-v3/src/ctype.cc -Wall -Wno-format -W -Wwrite-strings -Winline -fno-implicit-templates -fdiagnostics-show-location=once -O2 ctype.ii ignoring nonexistent directory "/mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/include" ignoring nonexistent directory "/mmix/powerpc-eabisim/install/powerpc-eabisim/bin/include" ignoring nonexistent directory "/mmix/powerpc-eabisim/install/powerpc-eabisim/lib/include" ignoring nonexistent directory "/mmix/powerpc-eabisim/install/powerpc-eabisim/include" #include "..." search starts here: #include <...> search starts here: /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include/powerpc-eabisim /mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/include /mmix/cross-sources/combined/libstdc++-v3/libsupc++ /mmix/cross-sources/combined/libstdc++-v3/libmath /mmix/powerpc-eabisim/build/gcc/include /mmix/powerpc-eabisim/build/powerpc-eabisim/newlib/targ-include /mmix/cross-sources/combined/newlib/libc/include End of search list. /mmix/powerpc-eabisim/build/gcc/cc1plus -fpreprocessed ctype.ii -quiet -dumpbase ctype.cc -auxbase-strip ctype.o -g -O2 -Wall -Wno-format -W -Wwrite-strings -Winline -version -fno-implicit-templates -fdiagnostics-show-location=once -o ctype.s GNU C++ version 3.4 20021230 (experimental) (powerpc-eabisim) compiled by GNU C version 3.2.1 20020927 (prerelease) (SuSE Linux). /mmix/powerpc-eabisim/build/gcc/as -mppc -V -Qy -o ctype.o ctype.s GNU assembler version 2.13.90 (powerpc-eabisim) using BFD version 2.13.90 20021230 arthur:/mmix/powerpc-eabisim/build/powerpc-eabisim/libstdc++-v3/src:[0]$ Note the second invocation, with -save-temps, did not produce any error at all :-( Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-30 14:39 ` Andreas Jaeger @ 2002-12-30 19:28 ` Graham Stott 0 siblings, 0 replies; 15+ messages in thread From: Graham Stott @ 2002-12-30 19:28 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Mark Mitchell, Kaveh R. Ghazi, gcc Andreas Jaeger wrote: > Note the second invocation, with -save-temps, did not produce any > error at all :-( > > Andreas Same here. I get the same original abort but the --save-temps .ii compile doesn't trigger. It's sounding like a GC problem I'll try an always collect build to see if it'll trigger using save-temps Graham ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-30 12:58 ` Mark Mitchell 2002-12-30 14:39 ` Andreas Jaeger @ 2002-12-31 12:33 ` Graham Stott 2002-12-31 12:45 ` Mark Mitchell 1 sibling, 1 reply; 15+ messages in thread From: Graham Stott @ 2002-12-31 12:33 UTC (permalink / raw) To: Mark Mitchell; +Cc: Kaveh R. Ghazi, gcc Hi Mark, It's a memory trample bug in the new parser. I've identified where we are trampling memory the memory. It's occuring in cp_parser_init_declarator within this block of code --------------------------------------------------------------------------------- if (cp_parser_token_starts_function_definition_p (token)) { if (!function_definition_allowed_p) { /* If a function-definition should not appear here, issue an error message. */ cp_parser_error (parser, "a function-definition is not allowed here"); return error_mark_node; } else { tree *ac; /* Neither attributes nor an asm-specification are allowed on a function-definition. */ if (asm_specification) error ("an asm-specification is not allowed on a function-definition"); if (attributes) error ("attributes are not allowed on a function-definition"); /* This is a function-definition. */ *function_definition_p = true; /* Thread the access checks together. */ ac = &access_checks; while (*ac) ac = &TREE_CHAIN (*ac); *ac = declarator_access_checks; /* Parse the function definition. */ decl = (cp_parser_function_definition_from_specifiers_and_declarator (parser, decl_specifiers, prefix_attributes, declarator, access_checks)); /* Pull the access-checks apart again. */ *ac = NULL_TREE; return decl; } } ------------------------------------------------------------------------------- It's the "*ac = NULL_TREE" that's trampling over memory. I suspect we are missing a bit of GTY(()) magic for the access_checks list. I think I can see why the access_list returned by cp_parser_stop_deferring_access_checks are not accessible via a GTY(()) tagged root so they might be GC if collect kicks in. Cheers Graham ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 12:33 ` Graham Stott @ 2002-12-31 12:45 ` Mark Mitchell 2002-12-31 13:07 ` Graham Stott 0 siblings, 1 reply; 15+ messages in thread From: Mark Mitchell @ 2002-12-31 12:45 UTC (permalink / raw) To: Graham Stott; +Cc: Kaveh R. Ghazi, gcc --On Tuesday, December 31, 2002 07:11:41 PM +0000 Graham Stott <graham.stott@btinternet.com> wrote: > It's the "*ac = NULL_TREE" that's trampling over memory. > > I suspect we are missing a bit of GTY(()) magic for the access_checks > list. > > I think I can see why the access_list returned by > cp_parser_stop_deferring_access_checks are not accessible via a GTY(()) > tagged root so they might be GC if collect kicks in. Oh, heck. That's annoying. I do not like it that our GC stuff makes us globalize local variables so that we can get them registered. Anyhow, thanks for the debugging! I will try to come up with a patch to send you to test. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 12:45 ` Mark Mitchell @ 2002-12-31 13:07 ` Graham Stott 2002-12-31 13:10 ` Mark Mitchell 0 siblings, 1 reply; 15+ messages in thread From: Graham Stott @ 2002-12-31 13:07 UTC (permalink / raw) To: Mark Mitchell; +Cc: Kaveh R. Ghazi, gcc Mark Mitchell wrote: > > > --On Tuesday, December 31, 2002 07:11:41 PM +0000 Graham Stott > <graham.stott@btinternet.com> wrote: > >> It's the "*ac = NULL_TREE" that's trampling over memory. >> >> I suspect we are missing a bit of GTY(()) magic for the access_checks >> list. >> >> I think I can see why the access_list returned by >> cp_parser_stop_deferring_access_checks are not accessible via a GTY(()) >> tagged root so they might be GC if collect kicks in. > > > Oh, heck. That's annoying. I do not like it that our GC stuff makes > us globalize local variables so that we can get them registered. > > Anyhow, thanks for the debugging! I will try to come up with a patch to > send you to test. > > Thanks, > I'm already testing a patch which looks to fix the problem. It's past the last point of failure and going well. Graham ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 13:07 ` Graham Stott @ 2002-12-31 13:10 ` Mark Mitchell 2002-12-31 13:24 ` Kaveh R. Ghazi 2002-12-31 13:42 ` Graham Stott 0 siblings, 2 replies; 15+ messages in thread From: Mark Mitchell @ 2002-12-31 13:10 UTC (permalink / raw) To: Graham Stott; +Cc: Kaveh R. Ghazi, gcc --On Tuesday, December 31, 2002 08:01:12 PM +0000 Graham Stott <graham.stott@btinternet.com> wrote: > Mark Mitchell wrote: >> >> >> --On Tuesday, December 31, 2002 07:11:41 PM +0000 Graham Stott >> <graham.stott@btinternet.com> wrote: >> >>> It's the "*ac = NULL_TREE" that's trampling over memory. >>> >>> I suspect we are missing a bit of GTY(()) magic for the access_checks >>> list. >>> >>> I think I can see why the access_list returned by >>> cp_parser_stop_deferring_access_checks are not accessible via a GTY(()) >>> tagged root so they might be GC if collect kicks in. >> >> >> Oh, heck. That's annoying. I do not like it that our GC stuff makes >> us globalize local variables so that we can get them registered. >> >> Anyhow, thanks for the debugging! I will try to come up with a patch to >> send you to test. >> >> Thanks, >> > > I'm already testing a patch which looks to fix the problem. It's past the > last point of failure and going well. Cool. Care to send it along, and I'll review it for you? Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 13:10 ` Mark Mitchell @ 2002-12-31 13:24 ` Kaveh R. Ghazi 2002-12-31 14:00 ` Graham Stott 2002-12-31 13:42 ` Graham Stott 1 sibling, 1 reply; 15+ messages in thread From: Kaveh R. Ghazi @ 2002-12-31 13:24 UTC (permalink / raw) To: graham.stott, mark; +Cc: gcc > From: Mark Mitchell <mark@codesourcery.com> > > > > I'm already testing a patch which looks to fix the problem. It's past the > > last point of failure and going well. > > Cool. Care to send it along, and I'll review it for you? Me too, I'd like to see if it fixes the irix65 problem I have. -- Kaveh R. Ghazi ghazi@caip.rutgers.edu ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 13:24 ` Kaveh R. Ghazi @ 2002-12-31 14:00 ` Graham Stott 2002-12-31 14:37 ` Mark Mitchell 2003-01-01 15:23 ` Kaveh R. Ghazi 0 siblings, 2 replies; 15+ messages in thread From: Graham Stott @ 2002-12-31 14:00 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: mark, gcc [-- Attachment #1: Type: text/plain, Size: 826 bytes --] Kaveh R. Ghazi wrote: > > From: Mark Mitchell <mark@codesourcery.com> > > > > > > I'm already testing a patch which looks to fix the problem. It's past the > > > last point of failure and going well. > > > > Cool. Care to send it along, and I'll review it for you? > > Me too, I'd like to see if it fixes the irix65 problem I have. > > -- > Kaveh R. Ghazi ghazi@caip.rutgers.edu > Ok attached is rough patch for cp/parser.c without changelog because I'm still treg testing here, It does fix the powerpc-eabi abort. The patch works by storing the access_checks and declarator_access_checks on a TREE_LIST for the duration of their active scope. I'm using a TREE_LIST because assuming that the corresponding routines are recusive, otherwise I could just make these global statics with GTY marker. Cheers Graham [-- Attachment #2: parser.c.diff --] [-- Type: text/x-diff, Size: 6323 bytes --] Index: parser.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v retrieving revision 1.10 diff -c -p -r1.10 parser.c *** parser.c 31 Dec 2002 20:28:27 -0000 1.10 --- parser.c 31 Dec 2002 20:58:03 -0000 *************** typedef struct cp_parser_context GTY (() *** 1189,1194 **** --- 1189,1199 ---- struct cp_parser_context *next; } cp_parser_context; + /* ???? */ + static GTY(()) tree declarator_access_checks_lists; + + static GTY(()) tree access_checks_lists; + /* Prototypes. */ /* Constructors and destructors. */ *************** cp_parser_simple_declaration (parser, fu *** 6697,6702 **** --- 6702,6710 ---- /* We no longer need to defer access checks. */ access_checks = cp_parser_stop_deferring_access_checks (parser); + access_checks_lists = chainon (access_checks_lists, + build_tree_list (NULL_TREE, access_checks)); + /* Keep going until we hit the `;' at the end of the simple declaration. */ saw_declarator = false; *************** cp_parser_simple_declaration (parser, fu *** 6726,6732 **** error ("mixing declarations and function-definitions is forbidden"); /* Otherwise, we're done with the list of declarators. */ else ! return; } /* The next token should be either a `,' or a `;'. */ token = cp_lexer_peek_token (parser->lexer); --- 6734,6743 ---- error ("mixing declarations and function-definitions is forbidden"); /* Otherwise, we're done with the list of declarators. */ else ! { ! access_checks_lists = TREE_CHAIN (access_checks_lists); ! return; ! } } /* The next token should be either a `,' or a `;'. */ token = cp_lexer_peek_token (parser->lexer); *************** cp_parser_simple_declaration (parser, fu *** 6742,6747 **** --- 6753,6759 ---- cp_parser_error (parser, "expected `,' or `;'"); /* Skip tokens until we reach the end of the statement. */ cp_parser_skip_to_end_of_statement (parser); + access_checks_lists = TREE_CHAIN (access_checks_lists); return; } /* After the first time around, a function-definition is not *************** cp_parser_simple_declaration (parser, fu *** 6770,6775 **** --- 6782,6788 ---- /* Mark all the classes that appeared in the decl-specifier-seq as having received a `;'. */ note_list_got_semicolon (decl_specifiers); + access_checks_lists = TREE_CHAIN (access_checks_lists); } /* Parse a decl-specifier-seq. *************** cp_parser_init_declarator (parser, *** 9642,9651 **** declarator_access_checks = cp_parser_stop_deferring_access_checks (parser); /* If the DECLARATOR was erroneous, there's no need to go further. */ if (declarator == error_mark_node) ! return error_mark_node; /* Figure out what scope the entity declared by the DECLARATOR is located in. `grokdeclarator' sometimes changes the scope, so --- 9655,9673 ---- declarator_access_checks = cp_parser_stop_deferring_access_checks (parser); + /* Prevent the declarator_access_checks from being reclaimed by the GC. */ + declarator_access_checks_lists = chainon (declarator_access_checks_lists, + build_tree_list (NULL_TREE, + declarator_access_checks)); + + /* If the DECLARATOR was erroneous, there's no need to go further. */ if (declarator == error_mark_node) ! { ! declarator_access_checks_lists = TREE_CHAIN (declarator_access_checks_lists); ! return error_mark_node; ! } /* Figure out what scope the entity declared by the DECLARATOR is located in. `grokdeclarator' sometimes changes the scope, so *************** cp_parser_init_declarator (parser, *** 9679,9684 **** --- 9701,9707 ---- error message. */ cp_parser_error (parser, "a function-definition is not allowed here"); + declarator_access_checks_lists = TREE_CHAIN (declarator_access_checks_lists); return error_mark_node; } else *************** cp_parser_init_declarator (parser, *** 9708,9713 **** --- 9731,9739 ---- /* Pull the access-checks apart again. */ *ac = NULL_TREE; + /* We are finished with the elaboration list it can now be discarded. */ + declarator_access_checks_lists = TREE_CHAIN (declarator_access_checks_lists); + return decl; } } *************** cp_parser_init_declarator (parser, *** 9724,9729 **** --- 9750,9756 ---- { cp_parser_error (parser, "expected constructor, destructor, or type conversion"); + declarator_access_checks_lists = TREE_CHAIN (declarator_access_checks_lists); return error_mark_node; } *************** cp_parser_init_declarator (parser, *** 9737,9742 **** --- 9764,9770 ---- && token->type != CPP_SEMICOLON) { cp_parser_error (parser, "expected init-declarator"); + declarator_access_checks_lists = TREE_CHAIN (declarator_access_checks_lists); return error_mark_node; } *************** cp_parser_init_declarator (parser, *** 9751,9757 **** /* Check that the number of template-parameter-lists is OK. */ if (!cp_parser_check_declarator_template_parameters (parser, declarator)) ! return error_mark_node; /* Enter the newly declared entry in the symbol table. If we're processing a declaration in a class-specifier, we wait until --- 9779,9788 ---- /* Check that the number of template-parameter-lists is OK. */ if (!cp_parser_check_declarator_template_parameters (parser, declarator)) ! { ! declarator_access_checks_lists = TREE_CHAIN (declarator_access_checks_lists); ! return error_mark_node; ! } /* Enter the newly declared entry in the symbol table. If we're processing a declaration in a class-specifier, we wait until *************** cp_parser_init_declarator (parser, *** 9846,9851 **** --- 9877,9884 ---- `explicit' constructor cannot be used. */ ((is_parenthesized_init || !is_initialized) ? 0 : LOOKUP_ONLYCONVERTING)); + + declarator_access_checks = TREE_CHAIN (declarator_access_checks); return decl; } ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 14:00 ` Graham Stott @ 2002-12-31 14:37 ` Mark Mitchell 2003-01-01 15:23 ` Kaveh R. Ghazi 1 sibling, 0 replies; 15+ messages in thread From: Mark Mitchell @ 2002-12-31 14:37 UTC (permalink / raw) To: Graham Stott, Kaveh R. Ghazi; +Cc: gcc --On Tuesday, December 31, 2002 09:07:48 PM +0000 Graham Stott <graham.stott@btinternet.com> wrote: > Kaveh R. Ghazi wrote: >> > From: Mark Mitchell <mark@codesourcery.com> >> > > >> > > I'm already testing a patch which looks to fix the problem. It's >> > > past the last point of failure and going well. >> > >> > Cool. Care to send it along, and I'll review it for you? >> >> Me too, I'd like to see if it fixes the irix65 problem I have. >> >> -- >> Kaveh R. Ghazi ghazi@caip.rutgers.edu >> > > Ok attached is rough patch for cp/parser.c without changelog because I'm > still treg testing here, It does fix the powerpc-eabi abort. > > The patch works by storing the access_checks and declarator_access_checks > on a TREE_LIST for the duration of their active scope. I'm using a > TREE_LIST because assuming that the corresponding routines are recusive, > otherwise I could just make these global statics with GTY marker. This looks like the right idea, and yes these routines can be recursive. I'd prefer that, instead of global variables, you tuck the roots away inside the cp_parser struct. (You'll note that there are almost no global variables in the new parser.) I think you can use just one variable in the cp_parser struct, instead of maintaining the two separate lists-of-lists, too. Also it looks like you're adding things with "chainon", but taking them off the front of the list. Shouldn't you be using "tree_cons" instead of "chainon"? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 14:00 ` Graham Stott 2002-12-31 14:37 ` Mark Mitchell @ 2003-01-01 15:23 ` Kaveh R. Ghazi 1 sibling, 0 replies; 15+ messages in thread From: Kaveh R. Ghazi @ 2003-01-01 15:23 UTC (permalink / raw) To: graham.stott; +Cc: gcc, mark > From: Graham Stott <graham.stott@btinternet.com> > > > > > Me too, I'd like to see if it fixes the irix65 problem I have. > > > > Ok attached is rough patch for cp/parser.c without changelog because I'm > still treg testing here, It does fix the powerpc-eabi abort. > Graham Hmm, very mysteriously the irix6.5 problem has disappeared. I was able to bootstrap from a 12/30 CVS checkout and again from 12/31. http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg01338.html If the problem arises again I'll let you know. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bootstrap failure on irix6.5 possibly caused by new C++ parser? 2002-12-31 13:10 ` Mark Mitchell 2002-12-31 13:24 ` Kaveh R. Ghazi @ 2002-12-31 13:42 ` Graham Stott 1 sibling, 0 replies; 15+ messages in thread From: Graham Stott @ 2002-12-31 13:42 UTC (permalink / raw) To: Mark Mitchell; +Cc: Kaveh R. Ghazi, gcc Mark Mitchell wrote: > > Cool. Care to send it along, and I'll review it for you? > > Thanks, > Sure once I've done prelimary regression tests this end. Graham ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-01-01 15:23 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-29 9:30 Bootstrap failure on irix6.5 possibly caused by new C++ parser? Kaveh R. Ghazi 2002-12-30 11:44 ` Mark Mitchell 2002-12-30 12:39 ` Graham Stott 2002-12-30 12:58 ` Mark Mitchell 2002-12-30 14:39 ` Andreas Jaeger 2002-12-30 19:28 ` Graham Stott 2002-12-31 12:33 ` Graham Stott 2002-12-31 12:45 ` Mark Mitchell 2002-12-31 13:07 ` Graham Stott 2002-12-31 13:10 ` Mark Mitchell 2002-12-31 13:24 ` Kaveh R. Ghazi 2002-12-31 14:00 ` Graham Stott 2002-12-31 14:37 ` Mark Mitchell 2003-01-01 15:23 ` Kaveh R. Ghazi 2002-12-31 13:42 ` Graham Stott
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).