Re: [C++ PATCH] Inline even functions containing static variables (take 2)

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Mar 20, 2001 at 04:46:07PM +0000, Jason Merrill wrote:
> >>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:
> 
> > Here is a second attempt against today's trunk. I tried to incorporate
> > feedback into it.
> 
> Great.
> 
> > Discriminator for VAR_DECLs is now stored in lang_decl_flag's (instead of
> > DECL_ACCESS)
> 
> But VAR_DECLs can have DECL_ACCESS, too: think static data members.

What do you think is better then:
to find out if u2.access or u2.discriminator should be used, do:
#define DECL_DISCRIMINATOR_P(decl)				\
  (TREE_CODE (decl) == VAR_DECL					\
   && DECL_CONTEXT (decl)					\
   && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL)

and use it to find out whether DECL_DISCRIMINATOR is valid (and in
lang_mark_tree), or use some free bit to signalize whether discriminator is
set, or store it somewhere else?

Also, wouldn't it be a good idea to add testcase like:
namespace x {
  static int i = 4;
};

int foo()
{
  using x::i;
  return i++;
}

int main()
{
  return foo() + foo() != 9;
}

into testsuite, so that this would be caught by make check? I haven't seen
DECL_ACCESS be used on VAR_DECL neither in g++ testsuite nor in KDE/aspell nor
any other C++ package we ship.

> 
> > expand_static_init call has been moved from grok_reference_init to
> > cp_finish_decl (ie. after maybe_commonize_var).
> 
> Thanks, but this still isn't quite right.  We want to obscure a
> non-constant initializer before we get to maybe_commonize_var, just as we
> do for non-reference decls.  Basically, grok_reference_init should return
> like store_init_value, and check_initializer should do the same thing with
> the result.

Ok, will try.
> 
> Also, please extend this to handle local classes properly.  And remember
> that we will eventually want to handle string constants the same way.

I'd prefer if this could be done in a separate patch, so that it does not
get too large.

	Jakub