This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Is UBSan supposed to produce a finding for _mm_load_sd and _mm_store_sd
- From: Jeffrey Walton <noloader at gmail dot com>
- To: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Wed, 21 Feb 2018 21:28:02 -0500
- Subject: Re: Is UBSan supposed to produce a finding for _mm_load_sd and _mm_store_sd
- Authentication-results: sourceware.org; auth=none
- References: <CAH8yC8mKZBjs-jyh2RfCsbC4O84ACZXbeQ0t1QsWt2XhnSBTUg@mail.gmail.com> <alpine.DEB.2.21.1712081823081.11927@stedding.saclay.inria.fr>
- Reply-to: noloader at gmail dot com
On Fri, Dec 8, 2017 at 12:28 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Fri, 8 Dec 2017, Jeffrey Walton wrote:
> ...
>> According to the Intel Intrinsics Guide (e.g., _mm_load_sd):
>>
>> Load a double-precision (64-bit) floating-point element from memory
>> into the lower of dst, and zero the upper element. mem_addr does
>> not need to be aligned on any particular boundary.
>>
>> Should GCC be producing a finding in this case? Is there a way to work
>> around it without an extra memcpy?
>
> The way _mm_load_sd is currently implemented in gcc, yes, sanitizers are
> right to complain. Intel could have named the thing _mm_loadu_sd if that's
> what they meant. It would be simple to change if we decide to do so, please
> file a PR in bugzilla.
>
> Workaround: define a typedef for double with
> __attribute__((__aligned__(1))), and use _mm_set_sd(*(newtype*)p), that's
> how it will likely be done if we change emmintrin.h.
Thanks again Marc.
I opened an issue at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 .
Jeff