From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97385 invoked by alias); 8 Dec 2017 17:29:01 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 96918 invoked by uid 89); 8 Dec 2017 17:29:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*R:D*gcc.gnu.org, H*R:D*gnu.org, walton, Walton X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Dec 2017 17:28:59 +0000 Received: from afontenayssb-151-1-14-211.w82-121.abo.wanadoo.fr (HELO stedding) ([82.121.220.211]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2017 18:28:56 +0100 Date: Fri, 08 Dec 2017 17:29:00 -0000 From: Marc Glisse Reply-To: "gcc-help@gcc.gnu.org" To: Jeffrey Walton cc: "gcc-help@gcc.gnu.org" Subject: Re: Is UBSan supposed to produce a finding for _mm_load_sd and _mm_store_sd In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2017-12/txt/msg00031.txt.bz2 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