This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: const weak variables are inlined.
On Wed, May 7, 2008 at 12:15 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>
> On Wed, May 7, 2008 at 8:38 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > On Wed, 7 May 2008, Mark Mitchell wrote:
> >
> > > Christian BRUEL wrote:
> > >
> > > > This is a problem if the variable is replaced at link time by a strong one,
> > > > like in:
> > >
> > > > const int __attribute__((weak)) vaca = 0;
> > >
> > > This one is a little tricky, actually.
> > >
> > > I think we need to actually have some documentation that says what this means.
> > > Normally, of course, doing the substitution of a const variable with its
> > > initializer is valid. In fact, in C++ it's *required*.
> >
> > (The above example is only valid in C++ with "extern" added; otherwise the
> > compiler gives an error.)
> >
> > I think this is similar to the issue of not analysing the contents of a
> > function, where it was said
> > <http://gcc.gnu.org/ml/gcc/2008-01/msg00171.html> that marking the
> > function weak will achieve that effect. So for C I think neither const
> > volatile nor const weak variables should have their initializers used for
> > optimization. (I do not think this optimization belongs in the C front
> > end at the early stage where it's presently handled; the earliest point it
> > should be done is gimplification-time folding along with most of the other
> > folding presently done at parse time. But that's a separate matter.)
>
> CCP and SCCVN do this optimization as well. I don't see why volatile const
> should disable the optimization. The problem with disabling it for const weak
> is that basically propagation from constant extern initializers in
> libraries built
> with -fPIC would be disabled.
>
> So I am all for option 2) which we currently implement and suggest to emit
> a warning for explicitly weaked constants.
>
There is a bug on const int with PIC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35501
H.J.