From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by sourceware.org (Postfix) with ESMTPS id 5021B3858D28 for ; Fri, 5 Nov 2021 13:54:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5021B3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f53.google.com with SMTP id r8so13833158wra.7 for ; Fri, 05 Nov 2021 06:54:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=V/mS+/UsDFLSvgLk/aXkPqG0xzddbRp8RUyYsVqIPX8=; b=u9HdWyfP0l+ZeOHRNvEoPKc7qiJD16KCx5f0KoB4D2FzLjbMTTc/BahtGqlDLf6tXC HzgKQLIGNw2Vl48UCsXqpJctnDDvpRLkkR6Xu/8lC1g4mvQ3/KZc/7XWW2ba6LT3zUaV JsgIMda4QqEI0MsSxSjWlMrbv0b/YIeQJ2FGjPLUtTHbRBBytegJX1Y31TfV2FrAPTSR IMzCWF8j7pq7U8z1w3JE2Rx7Hmv09/QhGtoJioSsJ+pGYBNcKc0QcJoGwWzPLSaL9QaJ eTtUb6cfm6YjlHavg75JPOS0EyPVmz5GVmxGK4u4GLhyb/qZWA839O2UbogZVCUaCBd8 96+g== X-Gm-Message-State: AOAM532LF0djmwZQpB0W1Rtu8AUaAbIpXheXXFl9E1cGTDjmbsVdr8Ro mTfZ77wLt/4w1hgh65jdVuE= X-Google-Smtp-Source: ABdhPJzkJXTSMBOwkeK1Z/xCZ2dnjRSYuYfuOF7WKWIs4MEuKpv1OQuL6lXdcDjvbmzHqyHG3IMa9g== X-Received: by 2002:adf:f5ca:: with SMTP id k10mr13237146wrp.161.1636120491394; Fri, 05 Nov 2021 06:54:51 -0700 (PDT) Received: from ?IPV6:2001:8a0:f912:1a00:d3db:ac91:4b9e:1449? ([2001:8a0:f912:1a00:d3db:ac91:4b9e:1449]) by smtp.gmail.com with ESMTPSA id f6sm7667768wmj.40.2021.11.05.06.54.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Nov 2021 06:54:50 -0700 (PDT) Message-ID: <1104add7-1cb0-efa1-f58a-c2d21846c5dc@palves.net> Date: Fri, 5 Nov 2021 13:54:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.arch/i386-avx.exp with clang Content-Language: en-US To: Tom de Vries , Andrew Burgess Cc: gdb-patches@sourceware.org References: <20211104135559.5875-1-tdevries@suse.de> <20211105093300.GG918204@redhat.com> <20211105115404.GA1816063@redhat.com> <8074d4d8-fe21-bccf-3fb6-f4be2ea67f7b@palves.net> <1f6ed2db-5d31-9338-226e-3e1a5a7c225b@suse.de> <4a98d0ce-b473-7a44-f399-3a604a5b2516@suse.de> From: Pedro Alves In-Reply-To: <4a98d0ce-b473-7a44-f399-3a604a5b2516@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 13:54:54 -0000 On 2021-11-05 13:35, Tom de Vries wrote: > On 11/5/21 2:20 PM, Pedro Alves wrote: >> On 2021-11-05 13:15, Tom de Vries wrote: >>> On 11/5/21 1:55 PM, Pedro Alves wrote: >>>> On 2021-11-05 12:23, Tom de Vries via Gdb-patches wrote: >>>> >>>>>> No, but in gdb/testsuite/lib/attribute.h we do setup a compatibility >>>>>> macro for 'noclone', so there's definitely precedent for using >>>>>> attributes that might not be supported everywhere. >>>>>> >>>>> >>>>> Right, I'm aware of this, but that's a typical case where we have no >>>>> portable alternative. >>>> >>>> We actually do -- _Alignas is standard C11. This fixes the test as well: >>>> >>>> _Alignas(32) v8sf_t data[] = >>>> >>> >>> I was referring to the noclone, but ok, I was not aware of the _Alignas, >>> good to know, thanks. >>> >>> Anyway, in the latest version this is not relevant anymore, since the >>> precise alignment implementation has an extra benefit, as explained in >>> the post. >>> >> >> OOC, is that benefit important here? >> > > So, this is the post I mentioned ( > https://sourceware.org/pipermail/gdb-patches/2021-November/183183.html ). > > Well, the benefit is that it prevents accidental overalignment, which is > the reason that this problem escaped detection and/or fixing for so long. > > Without that, I could do a thinko and specify too small an alignment and > have the test passing accidentally, only to fail in a different setup. > The code made no effort at all to align the object, which is I think the main reason why it went missed. As soon as you write some explicit alignment, I don't think that your proposal helps that much. The new allocator won't help _finding_ the places that miss alignment directives. I'm honestly not finding the benefit compelling enough to justify the complication, compared to using alignas/_Alignas, which is what actual user code will be using. My .2c, anyhow.