<div dir="ltr">On Wed, Sep 4, 2013 at 2:14 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> If we have a linkonce_odr unnamed_addr constant A and an internal<br>
> non-unnamed_addr constant B, it isn't a legal transformation to drop the<br>
> unnamed_addr from A and change the references to B to refer to A instead.<br>
> Imagine what would happen if we performed this transformation in two<br>
> translation units. :)  (It would be legal to simply drop A, and change all<br>
> the references to refer to B instead, but that doesn't cause any issues in<br>
> the scenario you present.)<br>
<br>
</div>True. I was trying to come up with a case where this would kick in<br>
from C++ and existing optimizations, but got the example wrong. I<br>
first noticed the problem when trying to extend the logic to handle<br>
non unnamed_addr symbols that just happen to not have the address<br>
taken, in which case it is easy to construct an example where an ELF<br>
linker produces a hidden symbol and we want a default one.<br>
<br>
The "low level" problem still exists, since the IR spec doesn't<br>
required unnamed_addr to be in sync. For example, given<br>
<br>
TU1:<br>
linkonce_odr unnamed_addr @foo....<br>
<br>
TU2:<br>
linkonce_odr @foo.....<br>
<br>
we would end up with a hidden symbols in TU1 and the linker then<br>
produces a hidden symbol in the final output, which is invalid because<br>
of TU2.<br><br></blockquote><div><br></div><div>We could just specify this the other way: if we have two definitions and either is unnamed_addr, the merged definition is also unnamed_addr.  Is there some reason we shouldn't?</div>
<div><br></div><div>-Eli</div></div></div></div>