Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3966642ybi; Tue, 18 Jun 2019 09:21:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqxynYNub9OG9iZdlHq9K31uSw6RL7pDNIV+i0I0B0svVa+asLBpRYgRogVHioP/KYvvEMjh X-Received: by 2002:a17:902:fa2:: with SMTP id 31mr90878979plz.38.1560874918081; Tue, 18 Jun 2019 09:21:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560874918; cv=none; d=google.com; s=arc-20160816; b=ulPGETbR6awiftYHgF3Jnl9R5R82I/FTNhEirUpQ1EGrSFSbY5LAPzctMHw0uww+Ru 1dctJpWEuuXvRLwcjszndpFRsNrNUg5tTMFhMQ4Mjx6RksDIyR+QkLy4R9ELKTp1M4hW H1+BjVYu+Ko0gm4eUsOqhBnpy9nV6dX65ceQVcdc4C1vlImva4Yw9nRoKIJqqYjqJu9U fpJCvQMfcrw4Kh5RpDDFwWstzMWFMo/DhQ2g7yBEBUFJ5YVx60D7+0ei2TRufkv8YMeQ ve5zjCQIgRxbFfxtJ9lXlu98yvIRQsPrtmU/ciNBhWO//Lka+qmm2djiryWehMgxHBmm 8Acg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=IWQqTfpGJl5BBlGcqVTtk79kbffONd3n7C9C8I08tdU=; b=lyP0tTCWK/zTphbpC/UikVV56TO41blSSIp2FtCmj3xheIDBu2e2VnA18JGUFVJGs7 vC0AKozN2ZzD/QxMQj+ZQLbGdBXVBNxVjGfGe+CkCD0dLJ77t1czQQJ4daYLRq2Ipvnt kIFdsPh7MV5hUxMC1omO5udPUHnIfzBIdnl5HtQjYs+ukwHxmF+of3VVNrb6vug8vZ2R /JV9FtUk0knId+jLTN+/oM645znUi3juZ9soPctld6VuPzyNSh3hDNKaPNEid+oi/D3X UaJKWPfE46Bcl0OsUox9K6CQ3QlCjS8Sn8znvWWGUTCHf1qgLfxl9S0d/uB4D7k4H81l p9rA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d24si554823pgk.186.2019.06.18.09.21.42; Tue, 18 Jun 2019 09:21:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729927AbfFRQVG (ORCPT + 99 others); Tue, 18 Jun 2019 12:21:06 -0400 Received: from foss.arm.com ([217.140.110.172]:48818 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729295AbfFRQVF (ORCPT ); Tue, 18 Jun 2019 12:21:05 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9D0E0CFC; Tue, 18 Jun 2019 09:21:02 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B3A563F246; Tue, 18 Jun 2019 09:21:01 -0700 (PDT) Date: Tue, 18 Jun 2019 17:20:21 +0100 From: Will Deacon To: Arnd Bergmann Cc: Linux Kernel Mailing List , Dave Martin , Richard Henderson , Masahiro Yamada , Ard Biesheuvel Subject: Re: [PATCH] genksyms: Teach parser about 128-bit built-in types Message-ID: <20190618162021.GA4270@fuggles.cambridge.arm.com> References: <20190618131048.543-1-will.deacon@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On Tue, Jun 18, 2019 at 04:17:35PM +0200, Arnd Bergmann wrote: > On Tue, Jun 18, 2019 at 3:10 PM Will Deacon wrote: > > > > + { "__int128", BUILTIN_INT_KEYW }, > > + { "__int128_t", BUILTIN_INT_KEYW }, > > + { "__uint128_t", BUILTIN_INT_KEYW }, > > I wonder if it's safe to treat them as the same type, since > __int128_t and __uint128_t differ in signedness. > > If someone exports a symbol with one and changes it to the other, they > would appear to be the same type. My understanding is that the actual CRC generation for normal symbols is based purely on the string-representation of the function signature, and so the underlying type information isn't relevant to that. I can also confirm that the CRC for an exported symbol that returns a __uint128_t is not the same if you change it to return a __int128_t instead. Will