* "*INTERNAL*" appended to function name bootstrap failure @ 2001-12-04 11:34 David Edelsohn 2001-12-04 11:36 ` Mark Mitchell 0 siblings, 1 reply; 11+ messages in thread From: David Edelsohn @ 2001-12-04 11:34 UTC (permalink / raw) To: Mark Mitchell, Nathan Sidwell; +Cc: gcc AIX bootstrap failed today because of a syntax error in the assembly output while trying to compile libstdc++-v3/libsupc++/eh_aux_runtime.cc . The syntax error is that G++ is appending " *INTERNAL*" to the function name. gcc/cp/mangle.c says: We also need to provide mangled names for the maybe-in-charge constructor, so we treat it here too. mangle_decl_string will append *INTERNAL* to that, to make sure we never emit it. Guess what? We're emitting it! David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-04 11:34 "*INTERNAL*" appended to function name bootstrap failure David Edelsohn @ 2001-12-04 11:36 ` Mark Mitchell 2001-12-04 12:57 ` David Edelsohn 2001-12-05 5:35 ` Andreas Jaeger 0 siblings, 2 replies; 11+ messages in thread From: Mark Mitchell @ 2001-12-04 11:36 UTC (permalink / raw) To: David Edelsohn, Nathan Sidwell; +Cc: gcc > Guess what? We're emitting it! Find the change that started causing this, and then we can fix it. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-04 11:36 ` Mark Mitchell @ 2001-12-04 12:57 ` David Edelsohn 2001-12-04 14:03 ` Mark Mitchell 2001-12-05 5:35 ` Andreas Jaeger 1 sibling, 1 reply; 11+ messages in thread From: David Edelsohn @ 2001-12-04 12:57 UTC (permalink / raw) To: Mark Mitchell; +Cc: Nathan Sidwell, gcc >>>>> Mark Mitchell writes: Mark> Find the change that started causing this, and then we can fix it. This appears to be another secondary build error. None of the changes in gcc/cp nor in libstdc++-v3/libsupc++ seem to have caused the problem. I will try a few changes in gcc, but it seems less likely to have caused this problem. David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-04 12:57 ` David Edelsohn @ 2001-12-04 14:03 ` Mark Mitchell 2001-12-04 14:07 ` David Edelsohn 0 siblings, 1 reply; 11+ messages in thread From: Mark Mitchell @ 2001-12-04 14:03 UTC (permalink / raw) To: David Edelsohn; +Cc: Nathan Sidwell, gcc --On Tuesday, December 04, 2001 03:57:01 PM -0500 David Edelsohn <dje@watson.ibm.com> wrote: >>>>>> Mark Mitchell writes: > > Mark> Find the change that started causing this, and then we can fix it. > > This appears to be another secondary build error. None of the > changes in gcc/cp nor in libstdc++-v3/libsupc++ seem to have caused the > problem. I will try a few changes in gcc, but it seems less likely to > have caused this problem. That's pretty strange. This could be a change to debugging generation as well, I suppose. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-04 14:03 ` Mark Mitchell @ 2001-12-04 14:07 ` David Edelsohn 2001-12-04 14:11 ` Jakub Jelinek 0 siblings, 1 reply; 11+ messages in thread From: David Edelsohn @ 2001-12-04 14:07 UTC (permalink / raw) To: Mark Mitchell; +Cc: Nathan Sidwell, gcc >>>>> Mark Mitchell writes: Mark> That's pretty strange. This could be a change to debugging generation Mark> as well, I suppose. I updated to a day ago removing recent "gcc" common changes but retaining all recent "cp" changes and the problem went away. However, when I updated back to the present in "gcc", the problem did not return. I am rebuilding again from scratch to see if I somehow encountered a non-atomic commit causing this problem. David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-04 14:07 ` David Edelsohn @ 2001-12-04 14:11 ` Jakub Jelinek 2001-12-04 14:17 ` David Edelsohn 0 siblings, 1 reply; 11+ messages in thread From: Jakub Jelinek @ 2001-12-04 14:11 UTC (permalink / raw) To: David Edelsohn; +Cc: Mark Mitchell, Nathan Sidwell, gcc On Tue, Dec 04, 2001 at 05:07:04PM -0500, David Edelsohn wrote: > >>>>> Mark Mitchell writes: > > Mark> That's pretty strange. This could be a change to debugging generation > Mark> as well, I suppose. > > I updated to a day ago removing recent "gcc" common changes but > retaining all recent "cp" changes and the problem went away. However, > when I updated back to the present in "gcc", the problem did not return. > I am rebuilding again from scratch to see if I somehow encountered a > non-atomic commit causing this problem. Wasn't this http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00352.html ? Jakub ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-04 14:11 ` Jakub Jelinek @ 2001-12-04 14:17 ` David Edelsohn 0 siblings, 0 replies; 11+ messages in thread From: David Edelsohn @ 2001-12-04 14:17 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Mark Mitchell, Nathan Sidwell, gcc >>>>> Jakub Jelinek writes: Jakub> Wasn't this http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00352.html ? It could be related. The problem definitely went away when I removed that patch. I had bootstrapped since rth's patch, so I didn't think reverting rth's patch would fix anything. If this was a separate, later patch, I could have updated in between. David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-04 11:36 ` Mark Mitchell 2001-12-04 12:57 ` David Edelsohn @ 2001-12-05 5:35 ` Andreas Jaeger 2001-12-05 7:48 ` David Edelsohn 1 sibling, 1 reply; 11+ messages in thread From: Andreas Jaeger @ 2001-12-05 5:35 UTC (permalink / raw) To: Mark Mitchell; +Cc: David Edelsohn, Nathan Sidwell, gcc Mark Mitchell <mark@codesourcery.com> writes: >> Guess what? We're emitting it! > > Find the change that started causing this, and then we can fix it. I get the same problem on i686-linux, my SPECcpu tester has the same problem: /opt/gcc-3.1-devel/bin/g++ -c -o mrGrid.o -DHAS_ERRLIST -DFMAX_IS_DOUBLE -ffast-math -fwritable-strings -Wno-deprecated -Wno-non-template-friend -I. -DNDEBUG -O2 -march=athlon -malign-double mrGrid.cc /tmp/ccootV1g.s: Assembler messages: /tmp/ccootV1g.s:842: Warning: missing operand; zero assumed /tmp/ccootV1g.s:842: Error: undefined symbol `INTERNAL' in operation Looking throught the log files, it should be part of this diff: http://www.suse.de/~aj/SPEC/CINT/d-permanent/200112041728.int/gcc-200112041728.diff.bz2 The only non ada diff is the appended patch. I hope that my scripts are correct and that this is really the relevant bit. Alexandre, can you have a look, please? Andreas Index: gcc/ChangeLog =================================================================== RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v retrieving revision 1.12137 retrieving revision 1.12138 diff -c -p -r1.12137 -r1.12138 *** ChangeLog 2001/12/04 15:09:51 1.12137 --- ChangeLog 2001/12/04 17:10:57 1.12138 *************** *** 1,5 **** --- 1,8 ---- 2001-12-04 Alexandre Oliva <aoliva@redhat.com> + * tree.c (get_callee_fndecl): Only use DECL_ABSTRACT_ORIGIN if + it has DECL_SAVED_TREE. + * c-decl.c (duplicate_decls): Revert rth's patch. If newdecl is in a different binding level, get its abstract origin to be olddecl. Index: gcc/tree.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree.c,v retrieving revision 1.224 retrieving revision 1.225 diff -c -p -r1.224 -r1.225 *** tree.c 2001/12/04 10:34:40 1.224 --- tree.c 2001/12/04 17:11:05 1.225 *************** get_callee_fndecl (call) *** 4379,4390 **** if (TREE_CODE (addr) == ADDR_EXPR && TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL) { ! addr = TREE_OPERAND (addr, 0); ! if (! DECL_INITIAL (addr) && DECL_ABSTRACT_ORIGIN (addr)) ! addr = DECL_ABSTRACT_ORIGIN (addr); ! return addr; } /* We couldn't figure out what was being called. */ --- 4379,4399 ---- if (TREE_CODE (addr) == ADDR_EXPR && TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL) { ! tree fn = TREE_OPERAND (addr, 0); ! /* If fn is a declaration of a function in a nested scope that ! was globally declared inline, we don't set its DECL_INITIAL. ! However, we can't blindly follow DECL_ABSTRACT_ORIGIN because ! the C++ front-end uses it for cdtors to refer to their ! internal declarations, that are not real functions. ! Fortunately those don't have trees to be saved, so we can tell by ! checking their DECL_SAVED_TREE. */ ! if (! DECL_INITIAL (fn) ! && DECL_ABSTRACT_ORIGIN (fn) ! && DECL_SAVED_TREE (DECL_ABSTRACT_ORIGIN (fn))) ! fn = DECL_ABSTRACT_ORIGIN (fn); ! return fn; } /* We couldn't figure out what was being called. */ -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-05 5:35 ` Andreas Jaeger @ 2001-12-05 7:48 ` David Edelsohn 2001-12-05 8:27 ` Andreas Jaeger 0 siblings, 1 reply; 11+ messages in thread From: David Edelsohn @ 2001-12-05 7:48 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Mark Mitchell, Nathan Sidwell, gcc I was able to bootstrap after updating again. I suspect that the patch was modified in the tree. David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-05 7:48 ` David Edelsohn @ 2001-12-05 8:27 ` Andreas Jaeger 2001-12-06 9:45 ` Alexandre Oliva 0 siblings, 1 reply; 11+ messages in thread From: Andreas Jaeger @ 2001-12-05 8:27 UTC (permalink / raw) To: David Edelsohn; +Cc: Mark Mitchell, Nathan Sidwell, gcc David Edelsohn <dje@watson.ibm.com> writes: > I was able to bootstrap after updating again. I suspect that the > patch was modified in the tree. It's not fixed for me on i686-linux, I did an update 4 hours ago: $ cat gcc/LAST_UPDATED Wed Dec 5 13:40:56 CET 2001 Wed Dec 5 12:40:56 UTC 2001 I'll try again now and will send reports tomorrow, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: "*INTERNAL*" appended to function name bootstrap failure 2001-12-05 8:27 ` Andreas Jaeger @ 2001-12-06 9:45 ` Alexandre Oliva 0 siblings, 0 replies; 11+ messages in thread From: Alexandre Oliva @ 2001-12-06 9:45 UTC (permalink / raw) To: David Edelsohn; +Cc: Mark Mitchell, Nathan Sidwell, gcc On Dec 5, 2001, Andreas Jaeger <aj@suse.de> wrote: > David Edelsohn <dje@watson.ibm.com> writes: >> I was able to bootstrap after updating again. I suspect that the >> patch was modified in the tree. > It's not fixed for me on i686-linux, I did an update 4 hours ago: I installed a quick fix for the problem, but it unfortunately missed some cases. The patch I've just posted fixes them. It just needs approval to go in (hint, hint :-) Sorry about the breakage :-( -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist *Please* write to mailing lists, not to me ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-12-06 17:34 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-04 11:34 "*INTERNAL*" appended to function name bootstrap failure David Edelsohn 2001-12-04 11:36 ` Mark Mitchell 2001-12-04 12:57 ` David Edelsohn 2001-12-04 14:03 ` Mark Mitchell 2001-12-04 14:07 ` David Edelsohn 2001-12-04 14:11 ` Jakub Jelinek 2001-12-04 14:17 ` David Edelsohn 2001-12-05 5:35 ` Andreas Jaeger 2001-12-05 7:48 ` David Edelsohn 2001-12-05 8:27 ` Andreas Jaeger 2001-12-06 9:45 ` Alexandre Oliva
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).