From patchwork Thu Feb 20 08:55:48 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 3685191 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 90A7DBF13A for ; Thu, 20 Feb 2014 08:58:33 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id AC3A82018A for ; Thu, 20 Feb 2014 08:58:32 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A21822017B for ; Thu, 20 Feb 2014 08:58:31 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WGPRL-0004wk-Py; Thu, 20 Feb 2014 08:57:08 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WGPQk-00068b-Hf; Thu, 20 Feb 2014 08:56:30 +0000 Received: from mail-lb0-f177.google.com ([209.85.217.177]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WGPQV-00065r-Kp for linux-arm-kernel@lists.infradead.org; Thu, 20 Feb 2014 08:56:17 +0000 Received: by mail-lb0-f177.google.com with SMTP id 10so1100895lbg.36 for ; Thu, 20 Feb 2014 00:55:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gIpFR6/oFf8lk+PMK/GGrQKxmRwxTg7yzk9AiqZ29io=; b=V9Rvb/kEKxBTDVtmxRLBFsU9Q5IY07fHQV7jIPn1ExLFprKZWVDmQX69nhBbFXq9yx 87sVkF4NiVD43AVk3sl/qlQXmrSkQ+9yxrJJHMzyB59CZO62v6XY2B3L5ULOeeD8JgvV S47BoVpASPPUdTGOCwU9cWSjBSbC7N0nHVga0iHXKrLN+E3mHG1TqwFPEz98WDkUaAX1 h6qEaH5/SAA8X66xiRc6R0wNARTTIB2oUsuqeUeQRyKcZYNio/Kt8C9+JFaZh3ryy6Bq 3EfhgUwmftjCDGRKHfwnu2KqixSbrAelNnzHgVwqsrYOBLagOaLdafTHHd5jNVUripV0 jJDA== X-Gm-Message-State: ALoCoQkwciiDV1OgiX2Vq4K1yciRN/uv2VEITnOqlY6vqQTcGgYWRFKyaGwWi5boR/8FikRLFS8M MIME-Version: 1.0 X-Received: by 10.152.206.104 with SMTP id ln8mr368204lac.67.1392886548104; Thu, 20 Feb 2014 00:55:48 -0800 (PST) Received: by 10.112.29.200 with HTTP; Thu, 20 Feb 2014 00:55:48 -0800 (PST) In-Reply-To: References: <1390768248-1688-1-git-send-email-ard.biesheuvel@linaro.org> <20140217122334.GA19102@arm.com> <20140217174247.GA8361@arm.com> <20140217180237.GC8361@arm.com> Date: Thu, 20 Feb 2014 09:55:48 +0100 Message-ID: Subject: Re: [PATCH] arm64: add workaround for ambiguous C99 stdint.h types From: Ard Biesheuvel To: Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140220_035615_883697_3A40D2DD X-CRM114-Status: GOOD ( 20.01 ) X-Spam-Score: -2.6 (--) Cc: Will Deacon , Dave P Martin , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 17 February 2014 19:17, Ard Biesheuvel wrote: > On 17 February 2014 19:02, Catalin Marinas wrote: >> On Mon, Feb 17, 2014 at 05:57:22PM +0000, Ard Biesheuvel wrote: >>> On 17 February 2014 18:42, Catalin Marinas wrote: [...] >>> > For other intrinsics that we use like __builtin_ctzl(), do we need to >>> > explicitly include gcc headers? I don't think we do and I really don't >>> > like such arm_neon.h include which brings in other user headers. Don't >>> > we have any work around this? >>> >>> Well, I talked to the toolchain guys at the time and they really >>> disliked the idea of coding directly against the __builtins because >>> they are not considered a stable interface, especially because the >>> interface that /is/ considered stable (arm_neon.h) is supported both >>> on ARM and on arm64. >> >> Than we don't use the Neon __builtins in the kernel. >> >>> > My inbox only has some discussion in May last year on the linaro-kernel >>> > list without any clear conclusion (it could be that I deleted other >>> > emails). >>> >>> There was some discussion, indeed, but for ARM, with the conclusion >>> being the fix I mentioned in the patch: 09096f6a0ee2 ("ARM: 7822/1: >>> add workaround >>> for ambiguous C99 stdint.h types"), only in that case, the ambiguity >>> is (unsurprisingly) about the 32 bit types, not the 64 bit ones. >> >> My worry is that some future toolchain may include something else in >> this file and get other type conflicts. It really looks fragile. >> > > Well, the GCC folks are quite careful not to depend on arbitrary user > headers when the -ffreestanding option is set. Also, the real problem > is the fact that Linux defines C99 types, but does so in an > incompatible way. (I.e., one could also argue that the Linux typedefs > should be based on GCC's builtin #defines of __INT64_TYPE, > __UINT64_TYPE, etc if defined). So the chances of something similar > reappearing all of a sudden are quite slim imo. > Perhaps this alternative approach would be better? tells us exactly which types it thinks should be used for typedef'ing [u]int64_t. Anyway, I am perfectly happy to park this until a real use case shows up. I have some crypto coded up in intrinsics, but we won't know if it's fast enough until I manage to run it on actual hardware. Regards, Ard. diff --git a/include/linux/types.h b/include/linux/types.h index 4d118ba11349..78344874fff0 100644 --- a/include/linux/types.h +++ b/include/linux/types.h @@ -108,9 +108,9 @@ typedef __u16 uint16_t; typedef __u32 uint32_t; #if defined(__GNUC__) -typedef __u64 uint64_t; -typedef __u64 u_int64_t; -typedef __s64 int64_t; +typedef __UINT64_TYPE__ uint64_t; +typedef __UINT64_TYPE__ u_int64_t; +typedef __INT64_TYPE__ int64_t; #endif I mean, we are already depending explicitly on __GNUC__, and GNUC