From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 3E553385B50A for ; Tue, 10 Jan 2023 12:26:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3E553385B50A 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-oi1-x233.google.com with SMTP id n8so9905173oih.0 for ; Tue, 10 Jan 2023 04:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=t1/ZGDOzw/NrpTRCdA9fHFqY2pXFE7HSznlyb90EPbc=; b=v2K8Xzh06gBaHp5uin9RPMnZ+Ab/S5KG8t0rm6xFo1iDHX8KfxB/jOM5OFXjBGzzsr nOIq27Q2SHA9ICQTYrGBPcZeRv5lfMG/W/dfogU79AavHeHo8f79PjJpmA2t2hnXANmZ fXuGS+GfNeYc5D5k6Iy5uDduXBojg+oHKSHyfjBEa2we0lW8PRli1OKdB/nwTzDhGufC EadvOPVdE564CsJkJLbwgHL05IzBowoWRBvTIVa8IS1aEs3wJqLt2gWeAa35+Ut1HO6D UCeWWz5/cgMlve+vhQlAOAM0nOUNE8DCAZGHpruTdM4Zxmp4RGpKV2K6N2eILEHanii3 YeAw== 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:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t1/ZGDOzw/NrpTRCdA9fHFqY2pXFE7HSznlyb90EPbc=; b=M0QNg7l0bB4gTrP8D3F1koVIMCNAGDnIE3fbM8y4RcJQC065TYO70SvXmjiZbdgaNl KMklwE9Zk37QpRVOYHGVqkhfVQ+Ga1EWH/ppj7fQ2oncs/oYILgoCue9UiLlTTDCR+ek xPgZhSEGpYHz2YfdBA20G5s5HsjUv4IlWdnpibEejFXKEcNgz9jIWZ9FO4UxM8nA+/uF 2hHWKHdzNCyWYJs27t+PWK7WnBhgefVFxsqe+ZlLWnnZ06hgKz/rOlpmFZYSleQUFxis 5drjJlhOFG/aetMj4vg5uN9wQOkxye9fFyjQ9FmlDcVvOO1QinpRreBjJZoOnOUKWu2P yBKA== X-Gm-Message-State: AFqh2krFu+knvZwHlE1V5eDDIlDbBjShV/XQ5gwk+cUChLE1rJ9QuXYm aRqaXRH4CQR3rynlVGbKXdUa3w== X-Google-Smtp-Source: AMrXdXsCfK92BthtlHeAj6bf4KB5rtDMC0B0Nan7kKN8iL1Ao1jRUtnjnVjlD4xkXvrH+pHr0D0bbw== X-Received: by 2002:a05:6808:318:b0:35c:1be2:ff86 with SMTP id i24-20020a056808031800b0035c1be2ff86mr30799187oie.39.1673353576366; Tue, 10 Jan 2023 04:26:16 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:a93a:8d00:c4d9:6d86:9f2b? ([2804:1b3:a7c0:a93a:8d00:c4d9:6d86:9f2b]) by smtp.gmail.com with ESMTPSA id w10-20020a056830144a00b00661a05691fasm5901083otp.79.2023.01.10.04.26.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Jan 2023 04:26:15 -0800 (PST) Message-ID: Date: Tue, 10 Jan 2023 09:26:13 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] longlong.h: Do no use asm input cast for clang Content-Language: en-US To: Segher Boessenkool , joseph_myers@mentor.com Cc: Richard Biener , gcc-patches@gcc.gnu.org References: <20221130181625.2011166-1-adhemerval.zanella@linaro.org> <20221130232456.GT25951@gate.crashing.org> <3e4bc189-7d73-f875-b425-61dde1a86e34@linaro.org> <20221212235240.GF25951@gate.crashing.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <20221212235240.GF25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 12/12/22 20:52, Segher Boessenkool wrote: > On Mon, Dec 12, 2022 at 02:10:16PM -0300, Adhemerval Zanella Netto wrote: >> On 30/11/22 20:24, Segher Boessenkool wrote: >>> I understand that the casts should be no-ops on the asm side (maybe they >>> change the sign) and they are present as type-checking. Can we implement >>> this type-checking in a different (portable) way? I think the macro you use >>> should be named like __asm_output_check_type (..) or so to indicate the >>> intended purpose. > > I didn't write that. Please quote correctly. Thanks! > >> I do not think trying to leverage it on clang side would yield much, it >> seems that it really does not want to support this extension. I am not >> sure we can really make it portable, best option I can think of would to >> add a mix of __builtin_classify_type and typeof prior asm call (we do >> something similar to powerp64 syscall code on glibc), although it would >> still require some gcc specific builtins. >> >> I am open for ideas, since to get this header to be clang-compatible on >> glibc it requires to get it first on gcc. > > How do you intend to modify all the existing copies of the header that > haven't been updated for over a decade already?> > If you think changing all user code that uses longlong.h is a good idea, > please change it to not use inline asm, use builtins in some cases but > mostly just rewrite things in plain C. But GCC cannot rewrite user code > (not preemptively anyway ;-) ) -- and longlong.h as encountered in the > wild (not the one in our libgcc source code) is user code. > > If you think changing the copy in libgcc is a good idea, please change > the original in glibc first? That's my original intention [1], but Joseph stated that GCC is the upstream source of this file. Joseph, would you be ok for a similar patch to glibc since gcc is reluctant to accept it? [1] https://sourceware.org/pipermail/libc-alpha/2022-October/143050.html