From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 01620388C027 for ; Mon, 22 Feb 2021 09:50:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 01620388C027 Received: by mail-wr1-x42c.google.com with SMTP id n4so18373817wrx.1 for ; Mon, 22 Feb 2021 01:50:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qD5sTup5OYYYGmVBUqLQJPb5QqsjBZmRNWDsvVEGDcI=; b=g52wBBBpI3HZGYi2ODICwMt+auddU+e4bsAF4QRtP2GDPo+auJoBi/m/3KmaWfWmW7 8WM2m1XcFBYmeZk2ztOTMxC6VRDgXcD7BbL6TQwtGhL0kOKgME294chFaYp9yC+WnQ6s mB6Z3T95K9DGPjxxA/FURcyodQA3xGszOFVqajsoYozi6cZauh/XG7FNCC/HMZLHp2u1 7o3SaFnCVFpkUEZHBala3HUkvThDNqApREM8SHi1AR98OwBMWimC91dJ4n+kyH65R+4f J/99H4+clyVqWT5ioXDnYozt/1DK5jQIYGoU1fP5eFJK3rb2VCndD/e934/gvMNBDTQp /ZVA== X-Gm-Message-State: AOAM530AlK5qXFw2eWzj42EyX6CGOfw8hiEANmM+VsJGoTUAu7rc+HRi z7PiTqf2jWNcPxZkS+t4RdnT3Qp4Pyku3A== X-Google-Smtp-Source: ABdhPJwS3+FzpZ1eLBJDdJPN8ZvREU9fxwSi7QlsfQCjbvUYtGvmUDUnLxKbtqC3r6sty/j+mYdMXA== X-Received: by 2002:adf:fb52:: with SMTP id c18mr8134310wrs.4.1613987408516; Mon, 22 Feb 2021 01:50:08 -0800 (PST) Received: from [10.19.0.2] ([217.138.207.232]) by smtp.gmail.com with ESMTPSA id r9sm958896wmq.26.2021.02.22.01.50.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Feb 2021 01:50:08 -0800 (PST) Subject: Re: problems with memory allocation and the alignment check To: "gcc@gcc.gnu.org" References: <80753cbc54ef69b4fc136f791666197fc8b1f8bb.camel@cyberfiber.eu> From: Gabriel Ravier Message-ID: <05af3a7c-5bda-463e-d112-2fb62104ede3@gmail.com> Date: Mon, 22 Feb 2021 10:50:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 09:50:11 -0000 On 2/22/21 10:37 AM, Michael J. Baars wrote: > On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote: >> On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars >> wrote: >>> Hi, >>> >>> I just wrote this little program to demonstrate a possible flaw in both malloc and calloc. >>> >>> If I allocate a the simplest memory region from main(), one out of three optimization flags fail. >>> If I allocate the same region from a function, three out of three optimization flags fail. >>> >>> Does someone know if this really is a flaw, and if so, is it a gcc or a kernel flaw? >> There is no flaw. GCC (kernel, glibc) all assume unaligned accesses >> on x86 will not cause an exception. > Is this just an assumption or more like a fact? I agree with you that byte aligned is more or less the same as unaligned. IIRC it's a fact, unless you change EFLAGS to enable the unaligned access exception flag, which is forbidden by the ABI. >> Thanks, >> Andrew >> >>> Regards, >>> Mischa.