[PATCH][C] Fix PR39983, more &a vs. &a[0] issues

H.J. Lu hjl.tools@gmail.com
Mon Mar 29 04:44:00 GMT 2010


On Sun, May 3, 2009 at 8:41 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, May 3, 2009 at 9:31 AM, Richard Guenther <rguenther@suse.de> wrote:
>>
>> This fixes PR39983 - a case where the gimplification time fixup of
>> &a vs. &a[0] doesn't work because we do not gimplify static initializers.
>>
>> Thus I revisited yet another option of fixing the C frontend for real
>> instead of fixing things up after-the-fact.  The following is what
>> comes out of this (and x86-64 {,-m32} testing).
>>
>> The fallout is in builtin folding where the builtins accept void *
>> typed arguments and in the aliasing warning machinery.  Both due
>> to the fact that int a[25] now decays to (int *)&a instead of &a
>> (or &a[0] after fixup) just like struct { int a[25]; } x; x.a always
>> did.  Both are latent missed optimizations / warnings anyway.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu for all C family
>> languages with {,-m32}.
>>
>> Are the C frontend changes ok for trunk?
>>
>> Thanks,
>> Richard.
>>
>> 2009-05-03  Richard Guenther  <rguenther@suse.de>
>>
>>        PR c/39983
>>        * c-typeck.c (array_to_pointer_conversion): Do not built
>>        ADDR_EXPRs of arrays of pointer-to-element type.
>>        * c-gimplify.c (c_gimplify_expr): Revert change fixing
>>        up wrong ADDR_EXPRs after-the-fact.
>>        * c-common.c (strict_aliasing_warning): Strip pointer
>>        conversions for obtaining the original type.
>>        * builtins.c (fold_builtin_memset): Handle array types.
>>        (fold_builtin_memory_op): Handle folded POINTER_PLUS_EXPRs
>>        and array types
>>
>>        * gcc.c-torture/compile/pr39983.c: New testcase.
>
> This triggered:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
>

This also caused:

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


-- 
H.J.



More information about the Gcc-patches mailing list