c++: undefined local static variable

c++: undefined local static variable

[scott snyder]

hi -

For a recent cvs version of g++ (2.96 20000724 on i686-pc-linux-gnu),
the following input generates a reference to a symbol that is
not present in the assembly code:

-------------------------------------------------------------------
struct Cleaner
{
  ~Cleaner();
};

template <class T>
void bar ()
{
  static Cleaner cleanup;
}


inline
void foo() { bar<int>(); }
-------------------------------------------------------------------

$ ./cc1plus -quiet x.cc
$ grep cleanup x.s
	pushl	$cleanup.6


The assembly code contains a reference to the symbol `cleanup.6', which
is nowhere defined.

thanks,
sss
>From rth@cygnus.com Wed Jul 26 15:03:00 2000
From: Richard Henderson <rth@cygnus.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Toshiyasu Morita <tm@netcom.com>, gcc-bugs@gcc.gnu.org, Jorn Wolfgang Rennecke <amylaar@cygnus.com>, gcc-patches@gcc.gnu.org
Subject: Re: (i386-linux x sh-elf) build breakage
Date: Wed, 26 Jul 2000 15:03:00 -0000
Message-id: <20000726150338.A25523@cygnus.com>
References: <200007112040.NAA06981@netcom.com> <20000717170342.A13413@cygnus.com> <oru2dl17xk.fsf@guarana.lsd.ic.unicamp.br> <20000725114629.C23874@cygnus.com> <orpuo1slif.fsf@guarana.lsd.ic.unicamp.br> <20000725190157.A24388@cygnus.com> <orhf9dsket.fsf@guarana.lsd.ic.unicamp.br>
X-SW-Source: 2000-07/msg00697.html
Content-length: 623

On Tue, Jul 25, 2000 at 11:19:22PM -0300, Alexandre Oliva wrote:
> > There's not enough abstraction here to make it worth the ugliness.
> > You might as well not put all this widgetry in insn-attr.h at all.
> 
> Ok.  How about insn-addr.h?

Err, no, the whole point being that since these things are the
same each and every time, there's no point in generating them
at all.  So I'd been suggesting putting them in a non-generated
header.  Which, I'm not sure off-hand, since you'd want to move
all the other length attribute crap out of insn-attr.h at the
same time.

Perhaps just ignore the suggestion to move them.



r~
>From wilson@cygnus.com Wed Jul 26 18:07:00 2000
From: Jim Wilson <wilson@cygnus.com>
To: gcc-bugs@gcc.gnu.org
Cc: jason@cygnus.com
Subject: dwarf2 abort with block extern decl for inline function
Date: Wed, 26 Jul 2000 18:07:00 -0000
Message-id: <200007270107.SAA16770@wilson.cygnus.com>
X-SW-Source: 2000-07/msg00698.html
Content-length: 2217

This testcase hits an abort in add_abstract_origin_attribute when compiled
with -O -gdwarf-2.

inline int
foo (int i)
{
  return i;
}

static void
bar ()
{
  int foo ();
  signed int foo ();
}

This was broken by this change:

2000-04-25  Jason Merrill  <jason@casey.cygnus.com>

	* dwarf2out.c (gen_subprogram_die): The class-scope declaration DIE
	is the primary DIE for a member function.
	(gen_decl_die): Call set_decl_origin_self here.

The patch actually does something a bit different than the ChangeLog entry
describes.  It changes the conditions in which gen_abstract_function is
called.  Before the patch, we always called gen_abstract_function if
decl_ultimate_origin returns non-null.  Now, we call gen_abstract_function
apparently only if we have a C++ member function reference.  This means
that if we have a block extern reference to a C inline function, there is
no die for the abstract instance of the function when we try to emit debug
info for the declaration, and thus we hit the abort.  The dwarf2 code
deliberately tries to emit debug info for block extern references, so this
should work.

This happens to work by accident in most cases, because duplicate_decls
will set DECL_IGNORED_P if different_binding_level is true.  Thus if we
have one duplicate decl, the testcase works.  But if we have two dupliacate
decls, then DECL_IGNORED_P is not copied from olddecl to newdecl for the
second one, and then DECL_IGNORED_P gets clobbered when we copy newdecl to
olddecl.

One could perhaps argue that this is a bug in duplicate_decls.  If we
copy DECL_IGNORED_P from olddecl to newdecl, then this problem goes away.
However, I still think that there is a flaw in dwarf2out.c.  It shouldn't
be relying on duplicate_decls to set DECL_IGNORED_P.  In gen_decl_die,
in the case FUNCTION_DECL, first we have
	DECL_CONTEXT (decl) == NULL_TREE
when we decide whether to emit debug info, then we have
	! class_scope_p (context_die)
when we decide whether to emit the abstract instance.  The first test is more
general than the second, so we end up unhandled cases.  I think those
two tests need to be the same, but I'm not sure which test is the correct one.
I suspect the first test is the right one.

Jim
>From law@cygnus.com Wed Jul 26 19:14:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: ICE in `find_reloads', at reload.c:4106 
Date: Wed, 26 Jul 2000 19:14:00 -0000
Message-id: <14739.964664126@upchuck>
References: <200006151747.NAA27641@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-07/msg00699.html
Content-length: 2503

  In message <200006151747.NAA27641@hiauly1.hia.nrc.ca>you write:
  > > Though I wonder if the no input reloads restriction could be further
  > > refined -- the idea behind that restriction is we can't guarantee
  > > that cc0 will always have the right value after emitting the reload
  > > insns.
  > 
  > I am currently testing.
  > 
  > 2000-06-15  J. David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* reload.c (find_reloads): Don't reload a nonoffsettable memory address
  > 	into an offsettable base register when no_input_reloads is true.
  > 
  > --- reload.c.orig	Thu Jun  1 10:50:59 2000
  > +++ reload.c	Wed Jun 14 20:20:03 2000
  > @@ -3560,7 +3560,8 @@
  >  	   so we don't bother with it.  It may not be worth doing.  */
  >  	else if (goal_alternative_matched[i] == -1
  >  		 && goal_alternative_offmemok[i]
  > -		 && GET_CODE (recog_data.operand[i]) == MEM)
  > +		 && GET_CODE (recog_data.operand[i]) == MEM
  > +		 && !no_input_reloads)
  >  	  {
  >  	    operand_reloadnum[i]
  >  	      = push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,
  > 
  > It results in roughly the following code for the line that previously
  > aborted:
  > 
  >         movzwl $387,-(sp)
  > 	cmpl _maxtype,*_typevec
  > 	clrl r1
  > 	adwc $0,r1
  > 	pushl r1
  > 	calls $2,_my_friendly_assert
  > 
  > My guess is that "clrl r1; adwc $0,r1; pushl r1" is as efficient if not
  > more so than "clrl -(sp); adwc $0,(sp)".  It is clear that the compiler
  > wants to generate sCODE instructions with auto inc and dec's.  This is
  > not allowed by the vax sltu and sgeu instruction constraints, and thus
  > the reload attempt.  This doesn't happen very often, thus I wonder if
  > it is worth trying to find a way to handle this case.
  > 
  > There are not many cc0 friendly instructions on the vax, except for a
  > few that don't muck with the carry bit C.  It might be tricky to try
  > to further optimise the no_input_reload constraint.
IMHO, the vax machine description is in error.  This insn uses cc0 and
therefore must never need reloading.

You may be able to fix the problem by writing a tighter predicate, another
would be to actually include the set of cc0 within that pattern, then
split it up into multiple patterns after reload.  ie

(define_insn "sltu"
  [(set (match_operand:SI 0 "general_operand" "=ro")
        (ltu (compare (op1, op2)) (const_int 0)))]
  ""
  "#"

Then have a splitter which emits a cmpsi insn followed by an insn that looks
like the current sltu.  
jeff