Re: const weak variables are inlined.

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Thu, May 8, 2008 at 7:29 AM, Mark Mitchell <mark@codesourcery.com> wrote:
>
> Jason Merrill wrote:
>
> > Mark Mitchell wrote:
> >
> > > I'm not crazy about any of these options.  My leaning is actually to
> pick (2), since it seems as good as any, and is backwards-compatible; it's
> what we already do...
> > >
> >
> > I agree.  The weakness will still affect uses of the address of the
> variable.
> >
>
>  Joseph thinks we should not do the optimization, for consistency with weak
> functions, which we refuse to inline.  Do we also refuse to inline non-weak
> functions not explicitly declared inline if we're in a shared library, on
> the grounds that the function might be replaced at link-time?

explicitly declared weak inline functions cause an error since

2008-03-27  Richard Guenther  <rguenther@suse.de>

        PR c/32511
        * c-common.c (handle_weak_attribute): Reject combination of
        weak and inline.

and implicitly weak (-fPIC) inline functions are still inlined.

Which would suggest we should also error for

const int x __attribute__((weak)) = 5;

>  Anyhow, I think that the consistency with functions arguments is good, but
> to me it doesn't outweigh the other arguments.  I'd hate to see "const"
> variables not be optimized in shared libraries, and it seems weird for weak
> to act differently from shared-library-ness.

Just it is not as Joseph thinks?

>  So, I guess I'm inclined to add a note to the documentation for "weak" that
> says that the compiler is free to replace uses of non-volatile const weak
> variables as rvalues with their initializers.
>
>  Objections to that plan?

See above.

Richard.