Is UBSan supposed to produce a finding for _mm_load_sd and _mm_store_sd

Is UBSan supposed to produce a finding for _mm_load_sd and _mm_store_sd

[Jeffrey Walton]

I have some code that loads a 64-bit integer into a XMM register. It
loads the integer from a byte array:

    byte v[8] = ...
    __m128i t = _mm_castpd_si128(
        _mm_load_sd((const double *)(v)));

It is producing a finding for an unaligned load. I get similar
findings for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd.

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?

A similar Clang issue is at http://bugs.llvm.org/show_bug.cgi?id=20670 .

Thanks in advance,

Jeff

Re: Is UBSan supposed to produce a finding for _mm_load_sd and _mm_store_sd

[Marc Glisse]

On Fri, 8 Dec 2017, Jeffrey Walton wrote:

> I have some code that loads a 64-bit integer into a XMM register. It
> loads the integer from a byte array:
>
>    byte v[8] = ...
>    __m128i t = _mm_castpd_si128(
>        _mm_load_sd((const double *)(v)));
>
> It is producing a finding for an unaligned load. I get similar
> findings for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd.
>
> 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.

-- 
Marc Glisse

Re: Is UBSan supposed to produce a finding for _mm_load_sd and _mm_store_sd

[Jeffrey Walton]

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