[Bug middle-end/25140] aliases, including weakref, break alias analysis

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau at gmail dot com

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 60214 has been marked as a duplicate of this bug. ***

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[bigotp at acm dot org]

------- Comment #11 from bigotp at acm dot org  2010-08-13 20:11 -------
(In reply to comment #9)
> (In reply to comment #8)
> > Hm, I only can see references to "symbol" not to either function or variable
> > declaration in the documentation.  Can you cite the part that makes you think
> > it restricts the use to functions?
> 
> It's documented in the section on function attributes, but not listed in the
> section on variable attributes.  Compare 'deprecated' or 'weak', which are
> listed in both places.

Is there any intention to restrict use of weakref to functions?  It seems to
be exactly what I want to use to allow a translation unit to reference a
memory-mapped register by its vendor-defined name, while not making that
name a global symbol that impacts other translation units, nor providing the
actual register address until the final link phase:

static volatile uint16_t P1IN __attribute((weakref("__P1IN")));
uint16_t c3 () { return P1IN; }

with __P1IN = 0x0020; in a linker script.

Other approaches seem to require that I have a definition for __P1IN
available at the time the object file is generated, which means I'd have a
potential for conflict if a different object file happened to include a
header that gave the register a different address; or that I use:

volatile uint16_t P1IN __attribute((weak));
uint16_t c3 () { return P1IN; }

which clutters the namespace.

Heck, I'll submit a patch to gcc/doc/extend.texi that explicitly allows use
of weakref on variables if that'd help.


-- 

bigotp at acm dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bigotp at acm dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-05-09 16:49 -------
For globals we could track this properly by using the varpool nodes instead of
the DECL_UID to do disambiguation.

Queued.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-09-26 10:09:53         |2010-05-09 16:49:58
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[geoffk at gcc dot gnu dot org]

------- Comment #9 from geoffk at gcc dot gnu dot org  2009-09-26 12:15 -------
(In reply to comment #8)
> Hm, I only can see references to "symbol" not to either function or variable
> declaration in the documentation.  Can you cite the part that makes you think
> it restricts the use to functions?

It's documented in the section on function attributes, but not listed in the
section on variable attributes.  Compare 'deprecated' or 'weak', which are
listed in both places.

It does say 'symbol' in referring to the target, but I doubt it's really
supposed to mean that you can declare a function as a weakref to a variable
(and that couldn't work anyway on most platforms, the variable will be in a
non-executable region of memory).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-26 12:01 -------
Hm, I only can see references to "symbol" not to either function or variable
declaration in the documentation.  Can you cite the part that makes you think
it restricts the use to functions?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[geoffk at gcc dot gnu dot org]

------- Comment #7 from geoffk at gcc dot gnu dot org  2009-09-26 11:51 -------
I looked up 'weakref' in the GCC documentation because I'd forgotten exactly
what it was supposed to do, and noticed that it's actually documented as
applying only to functions.  So, maybe we could just say that this attribute is
only allowed for functions, and produce an error on line 3.

Alexandre's original mail proposing the extension,
<http://gcc.gnu.org/ml/gcc/2005-10/msg00235.html>, suggests the attribute for
both variables and functions, but the explanation of why you'd want this
feature only talks about functions.

The weakref documentation does specifically talk about the case where the
function is referenced both via the weakref and directly through the original
symbol, and I think the typical use cases actually do this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-26 11:29 -------
Whoever designed this feature should be beaten with a cluebat for not asking
people on how this will interact with aliasing.

IMHO the testcase should be declared invalid and it should be documented that
an aliased or weakreffed var may be only accessed via its original declaration
(x in this case).

Case closed for me.  Any other way not only breaks points-to analysis but
also trivial alias checks throughout the compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[geoffk at geoffk dot org]

------- Comment #5 from geoffk at geoffk dot org  2005-11-30 01:01 -------
Subject: Re:  aliases, including weakref, break alias analysis


On 29/11/2005, at 5:55 AM, aoliva at gcc dot gnu dot org wrote:

> Make it a weak alias, then.

A weak alias is still an alias and still not supported by Mach-O.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[aoliva at gcc dot gnu dot org]

------- Comment #4 from aoliva at gcc dot gnu dot org  2005-11-29 13:55 -------
Make it a weak alias, then.

Anyhow, the point is that the alias infrastructure in GCC is available for all
ports.  If some port limits what kinds of aliases you can use, then, well, too
bad.  But the smarts to get alias analysis to follow symbol aliases is missing
for all kinds of aliases, not only weakrefs, and the good news is that fixing
it for regular and weak aliases will fix it for weakrefs as well, unless you
try really hard to keep weakrefs broken just to make a point :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[geoffk at geoffk dot org]

------- Comment #3 from geoffk at geoffk dot org  2005-11-28 19:22 -------
Subject: Re:  aliases, including weakref, break alias analysis


On 28/11/2005, at 10:40 AM, aoliva at gcc dot gnu dot org wrote:

> ------- Comment #2 from aoliva at gcc dot gnu dot org  2005-11-28  
> 18:40 -------
> I'd change the testcase s/weakref/alias/, so as to make it clear  
> that the error
> has nothing to do with the newly-introduced weakref, but rather  
> with regular
> aliases, that weakref builds upon.

If you do that, it won't work on Darwin, because Darwin doesn't have  
aliases.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[aoliva at gcc dot gnu dot org]

------- Comment #2 from aoliva at gcc dot gnu dot org  2005-11-28 18:40 -------
I'd change the testcase s/weakref/alias/, so as to make it clear that the error
has nothing to do with the newly-introduced weakref, but rather with regular
aliases, that weakref builds upon.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-28 17:06 -------
Confirmed, the problem is that middle-end does not know that x and y are really
the same variable


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2005-11-28 17:06:36
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140