* 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: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
* 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
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).