From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id A8AFA3858D28 for ; Tue, 1 Nov 2022 13:57:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A8AFA3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x32b.google.com with SMTP id c18-20020a056830349200b0066c47e192f0so3802988otu.12 for ; Tue, 01 Nov 2022 06:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=dti79BJxWL/EhhBb2BxFSqqEDXVq6dY+Ve5TmA2FbsI=; b=Bi2lq7twocpX7k0UeDyfmz0UCE75OCRVRgRL7f8Sn2+fdGXGXh5Ote6bZEyZJAsHHw hD8THsUp+JNaU5azoZ7mBVaRYyUSlUAPNvFRonP9Ik7upN95htafv5Nje0q36SwAlfjW yWzJjdN8vGYS0RVrQMK8Ehmx0FYD7hlcf6Q945wrql4fj9BdvpWcIEdKyNdDnb2L5tm9 lctl+KAyyP+cVeLqETWT6jhWEqm4dz2Oue9NUuNVSAVhkXZAoMIkCtyHD769K39QcjQH lZIXJnumf/cPU7qCCM0nlTGdHOzt6FiVlcjEYrRR2wHGxXrjZ0eP38ZMw+Od/+UDkif/ nDsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dti79BJxWL/EhhBb2BxFSqqEDXVq6dY+Ve5TmA2FbsI=; b=0tDenak2+Et09ssBIddrulQAuXLiIV9cdF48o6KRnzs1VdpvhGFMeoYUCwk7F3OEXf 9oydqcWydkyUT/0ytIOs2emm8caOLcDZaGGgq6bfYdyyQlkvip5OQ4ZLy72/z3+xXd6S OJDRoaoyjokbsu38Cp6HyPtFhlM1nhLQOdoFB6d8UXNx72MGtD3PDhvQZWTi+PgpcU6g KeY0F44rK0a/iejpJQSOJhdbfALfzG1w4G7ISXxtJRCZhip61/TsPxEpReCHP2tyykFY ckjDDD9RYwlOaA/stsXUMO2GGAnnNePUGKP2PFiec3+OqlY373HfNbwZhjATiL5xshX1 IXhw== X-Gm-Message-State: ACrzQf0mCWLZQepMtQwSrHkT4Cj1/u/PAftHx6Il4x6ZwsDVDPjTQaNv i7IzK1iX9HvP7t4b5m/iPJL+nsWFATYNP6Aa X-Google-Smtp-Source: AMsMyM7/f4mMHENMYK75zTvwAlJnk8ySxI3wzEpcA4Wker+IzA+Fj2oQbkAn8fCF7IWkNRr4lhk0LA== X-Received: by 2002:a05:6830:25d4:b0:661:e2a4:96d2 with SMTP id d20-20020a05683025d400b00661e2a496d2mr9141280otu.383.1667311020870; Tue, 01 Nov 2022 06:57:00 -0700 (PDT) Received: from [192.168.15.31] ([191.17.238.148]) by smtp.gmail.com with ESMTPSA id w22-20020a4ae4d6000000b00480dac71228sm3400796oov.24.2022.11.01.06.56.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 06:57:00 -0700 (PDT) Message-ID: <118fd536-3493-0476-5f59-32f7fd7f27b1@linaro.org> Date: Tue, 1 Nov 2022 10:56:56 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 01/11] stdlib/longlong.h: Remove incorrect lvalue to rvalue conversion from asm output constraints Content-Language: en-US From: Adhemerval Zanella Netto To: Fangrui Song , Joseph Myers Cc: libc-alpha@sourceware.org References: <20221028173532.876027-1-adhemerval.zanella@linaro.org> <20221028173532.876027-2-adhemerval.zanella@linaro.org> <20221028213233.anuo3qzfssgjg4g6@google.com> <7eb7deb7-4431-c32f-daa4-0f9f0d560dec@linaro.org> Organization: Linaro In-Reply-To: <7eb7deb7-4431-c32f-daa4-0f9f0d560dec@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 31/10/22 15:32, Adhemerval Zanella Netto wrote: > > > On 28/10/22 18:32, Fangrui Song wrote: >> On 2022-10-28, Joseph Myers wrote: >>> On Fri, 28 Oct 2022, Adhemerval Zanella via Libc-alpha wrote: >>> >>>> From: Fangrui Song >>>> >>>> An output constraint takes a lvalue. While GCC happily strips the >>>> incorrect lvalue to rvalue conversion, Clang rejects the code by >>>> default: >>> >>> We treat GCC as the upstream source of this file. >> >> I tried gcc-patches in 2021-10 >> https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581722.html >> stdlib/longlong.h: Remove incorrect lvalue to rvalue conversion from asm output constraints >> >> If the GCC patch is not favored, the clang build will have to use -fheinous-gnu-extensions :( > > I recall this conversion, thanks for bring this up again. I don't have a strong > preference, using -fheinous-gnu-extensions might be an option. It would require > an additional configure check and add the flag on each file. Using -fheinous-gnu-extensions does not seem to be a long-term solution, clang accepts it but still throws an warning: warning: invalid use of a cast in an inline asm context requiring an lvalue: accepted due to -fheinous-gnu-extensions, but clang may remove support for this in the future And we do not have a -Wno-heinous-gnu-extensions to suppress it. But what really worries me that eventually clang decides to remove it. >From gcc thread, it is unlikely that the cast would be removed since they provide a diagnostic way. So I am open to suggestion on how to proceed. One option would be to start provide proper static inline function, so we can remove the cast; and adapt the glibc code to use it. However it would result in a quite large patch, and it would need to modify multiple projects (gcc, gmp, glibc at least). Another option would be to check at configure time if cast in inline asm context is supported and disable the cast if not. I am inclined for the later.