"*INTERNAL*" appended to function name bootstrap failure

"*INTERNAL*" appended to function name bootstrap failure

[David Edelsohn]

	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

Re: "*INTERNAL*" appended to function name bootstrap failure

[Mark Mitchell]

> 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

Re: "*INTERNAL*" appended to function name bootstrap failure

[David Edelsohn]

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

Re: "*INTERNAL*" appended to function name bootstrap failure

[Mark Mitchell]

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

Re: "*INTERNAL*" appended to function name bootstrap failure

[David Edelsohn]

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

Re: "*INTERNAL*" appended to function name bootstrap failure

[Jakub Jelinek]

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

Re: "*INTERNAL*" appended to function name bootstrap failure

[David Edelsohn]

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

Re: "*INTERNAL*" appended to function name bootstrap failure

[Andreas Jaeger]

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

Re: "*INTERNAL*" appended to function name bootstrap failure

[David Edelsohn]

	I was able to bootstrap after updating again.  I suspect that the
patch was modified in the tree.

David

Re: "*INTERNAL*" appended to function name bootstrap failure

[Andreas Jaeger]

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

Re: "*INTERNAL*" appended to function name bootstrap failure

[Alexandre Oliva]

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