[cfe-commits] Patch to change how const arrays/structs are handled

[Chris Lattner]

On Oct 28, 2009, at 9:25 PM, Douglas Gregor wrote:

>>>
>>> So, we either need to tie this patch to -fmerge-all-constants  
>>> (where we allow such non-conforming behavior) or we need to keep  
>>> track of whether declarations have had their address taken (to  
>>> implement the equivalent of -fmerge-constants).
>>
>> Ok, I think it makes perfect sense to support this.  The question  
>> is whether we should default to doing this or not at various  
>> optimization levels.
>
> I'd like to have the behavior of GCC's -fmerge-constants at all  
> optimization levels. We could also support -fmerge-all-constants as  
> an explicit flag, but I don't think that's as important.
>
>> This optimization is a very nice win for common coding patterns,  
>> and the LLVM backend isn't "safe" in this respect anyway (it merges  
>> 'static' global constants with identical initializers).  How much  
>> does it matter?
>
> How much does what matter? The optimization? Correctness of the  
> example?

The correctness.  We know that a large amount of code builds with GCC  
4.2 (and llvm-gcc for that matter) which do have this misfeature.   
Code doesn't actually compare the addresses of different instances of  
variables from recursive calls and expect them to compare unequal in  
practice.

-Chris

> We won't know the latter until it breaks something, but I'd be  
> nervous about intentionally breaking code like this.