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

[Chris Lattner]

On Oct 26, 2009, at 3:34 PM, Douglas Gregor wrote:
>>
>> void foo() {
>> const int x[] = { 1, 2,3,4,5,6,7,8 };
>> bar(x);
>> }
>
> I believe that GCC is non-conforming in this regard, because  
> recursive calls to "foo" would not have distinct "x" pointers. Note  
> that this was fixed in GCC 4.3.4, so that they no longer promote the  
> automatic variable to a constant if its address has been taken, as  
> described in this bug report:
>
> 	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38615
>
>> My understanding is that -fmerge-all-constants doesn't default to  
>> being on.  I don't think this should be tied to it.
>
>
> There are 3 levels of "merge-constants" in GCC:
>
>  -fno-merge-constants: default at -O0, merges nothing
>  -fmerge-constants: default at -O, -O2, -O3, -Os. merges "x" in your  
> example with GCC < 4.3.4, but shouldn't (according to the bug  
> report) with GCC >= 4.3.4.
>  -fmerge-all-constants: must be explicitly-specified; merges "x" in  
> your example (always), which is non-conforming behavior
>
> 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.  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?

-Chris