On Tue, Sep 17, 2013 at 8:45 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Sep 17, 2013 at 08:37:57AM -0700, Xinliang David Li wrote:
>> >> char a[10000];
>> >>
>> >> void foo(int n)
>> >> {
>> >> int* b = (int*)(a+n);
>> >> int i = 0;
>> >> for (; i < 1000; ++i)
>> >> b[i] = 1;
>> >> }
>> >>
>> >> int main(int argn, char** argv)
>> >> {
>> >> foo(argn);
>> >> }
>> >
>> > But that's just a bug that should be fixed (looking into it).
>>
>> This kind of code is not uncommon for certain applications (e.g, group
>> varint decoding). Besides, the code like this may be built with
>
> That is irrelevant to the fact that it is invalid.
>
>> -fno-strict-aliasing.
>
> It isn't invalid because of aliasing violations, but because of unaligned
> access without saying that it is unaligned (say accessing through
> aligned(1) type, or packed struct or similar, or doing memcpy).
> On various architectures unaligned accesses don't cause faults, so it
> may appear to work, and even on i?86/x86_64 often appears to work, as
> long as you aren't trying to vectorize code (which doesn't change anything
> on the fact that it is undefined behavior).
ok, undefined behavior it is. By the way, ICC does loop versioning on
the case and therefore has no problem. Clang/LLVM vectorizes it with
neither peeling nor versioning, and it works fine to. For legacy code
like this, GCC is less tolerant.
thanks,
David
>
> Jakub
