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

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.