Re: [PATCH] proposed fix for bug # 61144

[Jan Hubicka <hubicka@ucw.cz>]

> 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