> On Mon, Jun 16, 2014 at 11:06:04AM +0200, Jan Hubicka wrote:
> > >
> > > Are the attached files acceptable?
> >
> > The testcase looks OK to me, but it already should be fixed on mainline
> > by patch https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01315.html that
> > prevents dummy to be marked as constant.
> >
> > You can however modify the testcase to have
> > __attribute__ ((weak)) const int foo=0;
>
> And the same for weak alias rather than straight weak definition like
> the above?
Yes, if you add const to your testcase, it will get miscompiled by mainline
again.
>
> > This needs your decl_replaceable change to not be optimized to if (0),
> > because of the explicit const modifier.
>
> The case I care about actually has "dummy" as const (with the intent
> that it be allocated in a read-only section if the dummy definition is
> used). So for me it's important that this regression be fixed too.
Yep, GCC since 90's was optimizing reads from weak const attributes, but it
because worse because I added code walking through aliases.
>
> > I did not change ctor_for_folding to reject variables above as I was not
> > quite
> > sure we want to support this kind of interposition and I am still not quite
> > certain.
> > C++ is quite clear about the transformation replacing initialized const by
> > its value.
>
> My concern is about C, not C++. This kind of interposition has always
> been supported in unix C, even prior to GCC, going back to sysv or
> earlier, as a documented feature (historically #pragma weak). It
> should not regress. If fixing it results in an regression with regards
> to optimizability of C++, perhaps this could be made
> language-specific, or (better) the C++ front-end could add an
> additional internal-use-only attribute to weak definitions it
> generates internally that permits constant-folding them, while not
> breaking the semantics for weak definitions provided by the user at
> the source level.
Yes, I see your point and clearly we should not optimize with explicit weak
attribute.
I wonder if decl_replaceable_p is however correct check here or if we want
explicit check
for weak visibility.
I am concerned about const variables w/o weak attribute with -fPIC (because for
those decl_replaceable_p returns true, too). Consider following testcase:
struct t
{
static const int dummy=0;
const int *m();
} t;
int
main()
{
return *t.m();
}
int
main2()
{
return t.dummy;
}
const int *
t::m()
{
return &dummy;
}
Here main2 is optimized by C++ FE to return 0, while backend is affraid to
optimize
main() after inlining anticipating that dummy may be interposed. However moving
t::m
inside of the unit will make dummy comdat and it will get optimizing.
Adding another method and keying the t into other unit will make it optimized,
too.
This is not very consistent. But perhaps we need a flag from C++ FE to tell us
what variables may not be interposed, because perhaps the c variant with -fPIC
const int dummy=0;
int
main()
{
return t;
}
Jason?
A C variant of the testcase:
const int dummy=0;
const static int * d=&dummy;
int
main()
{
return dummy;
}
int
main2()
{
return *d;
}
seems optimized to return 0 (with -fPIC) for ages, too, but here at least
frontend won't substitute first dummy for 0.
Honza
