From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFD0C13A27D for ; Wed, 5 Jun 2024 18:09:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717610944; cv=none; b=HvalfsA5evPaeR01mVxGgCC3OtAAzDJ/qMOfDD9Z8ylU3chLCXdG/nwXhGKI480x7dQEXXh++/ZkC/19Altbrx4riC/EVcbySbQ/OVm5nj4QucWucrlDJuaSxDKMn4Kjync8DMiEsfolewyga3OK5MooX7xs8IIVlbbSYQZaCf4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717610944; c=relaxed/simple; bh=EaAtez5Efr/Q9cWPJeQtwuO3Dd1/5zl4f/X492+tfGM=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nBFepWMGWYDO/orjv+oChdDVNYPatYha0+okkQAhvA3HyQm+reiLCYcMPSpWqTr6ZZ0jYIAAOxET1dbw2fgKM6F/+GDxWjcJtLnT/YkenpToa3/SMhnxpHtQNDx8t03A+z9w8q9N2jw3DtZbQnFKXUDFqtdMiZQOKW+vPMSHfWM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=h/8reT+5; arc=none smtp.client-ip=209.85.218.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="h/8reT+5" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a69607c6ccaso11049766b.2 for ; Wed, 05 Jun 2024 11:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1717610941; x=1718215741; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x0sdapZG/NhMB20a9AYoY0Ck+vFvnM8jdCx1nSzujEA=; b=h/8reT+5Jq6IR4OBzo2/MdNY2xjOiR3JPlWCWx321q2mQkfGwe4Bnu1L/1GVYLaUFr Rs0hFQfn/pHGjldwKYkvGdYIY5al2KyXkLl1g/bTM/0fnqfTSbHAe+9C+GEi4rQZTqSu xlSCK6uNEUwgKUmzp47XB0xCFjyhwP5pJ7yHA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717610941; x=1718215741; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x0sdapZG/NhMB20a9AYoY0Ck+vFvnM8jdCx1nSzujEA=; b=vUkRUonhZqGqT6JBncJ+wG7uiM3ho++lMEbmDlX7vR/MEa51FsXCTlvhiG3bBeohlh +SPP8+F2mKiwc1hxU5/0G8ifgJG3D1tWShgwv2KP7zAsIcMeIMWNflc5ye7V0ymIdnPO 2QMVtiyY237gujL26llBoUQp2zxa87HTLYuqUMCO/LA9hKTgIQ9stm09m7ae0kFufa3T E6sAyM5vWzYVhfr1UQJcbg0iHWpKlMhlKYt54LCnlivMX7TcMsknRUxdxMpPFrc8fJSa tE53uFv2frlhR+TH4hmyZzN40nkpKQS9j9wbK0kLFutu/szwbM715FaQACaY0qWgtm+0 wbuw== X-Gm-Message-State: AOJu0YwFPPB8UkAAoGgFB90V7Pnms6ozVHR6hUCyx9bHwk2Pbj6wrpiO W2uyG9y4ZrAMkfkGWEMBAXhjt51BdIodIZxyk0caNZCEz6H1qd0mf3laz6TgOXO63tHdKIJOcJ5 mMIimCkM4 X-Google-Smtp-Source: AGHT+IFkcaOqPcofHv/AwrdaDLjcpi5/eslhAZO+FrOUHLFvftiuYzzJ7Sit5gzouFHU38bpLngUKQ== X-Received: by 2002:a17:906:a2d0:b0:a69:20df:bb9f with SMTP id a640c23a62f3a-a699fcf3788mr207027266b.44.1717610940921; Wed, 05 Jun 2024 11:09:00 -0700 (PDT) Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com. [209.85.218.41]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a691bde21e2sm426655266b.104.2024.06.05.11.08.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jun 2024 11:08:58 -0700 (PDT) Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a68a4a9946cso15421166b.1 for ; Wed, 05 Jun 2024 11:08:58 -0700 (PDT) X-Received: by 2002:a17:906:50b:b0:a6c:6fac:f1ff with SMTP id a640c23a62f3a-a6c6fad1464mr108631166b.12.1717610938054; Wed, 05 Jun 2024 11:08:58 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <83f5e119-6e32-415a-a1c8-8e6b0bd11a75@paulmck-laptop> In-Reply-To: From: Linus Torvalds Date: Wed, 5 Jun 2024 11:08:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: A few proposals, this time from the C++ standards committee To: paulmck@kernel.org Cc: linux-toolchains@vger.kernel.org, peterz@infradead.org, hpa@zytor.com, rostedt@goodmis.org, gregkh@linuxfoundation.org, keescook@chromium.org Content-Type: text/plain; charset="UTF-8" On Wed, 5 Jun 2024 at 06:52, Paul E. McKenney wrote: > > n3243 A Memory model with Synchronization based type aliasing V1, > Eskil Steenberg Hald > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3243.pdf I love the part that admits that the type-based aliasing is broken. I don't think the "cast-based barriers" are a sufficient improvement. Note the "sufficient". I do think a cast-based barrier would have been a huge improvement *originally*, in that it would avoid two absolutely huge issues: - "char *" being special - the insane model of "use a union to tell the compiler type-base aliasing can happen" Both of the above things are disgusting and wrong, but they are mostly disgusting and wrong simply because type-based aliasing is entirely and utterly wrong to begin with. Saying "pointer casts are an aliasing barrier" is a much better and more logical model for the type-based thing. No question about that. They help make the insanity that is type-based aliasing much more manageable. However, I don't see that it would be sufficient for us to ever stop using the "-fno-strict-aliasing" thing. Because type-based aliasing continues to be insane, and even with pointer casting acting as a barrier, has real problems. The paper points out one such problem: the cast may have been done long long before the accesses are done. In fact, unions continue to be one very real case of such a situation, where the pointer cast basically comes from the type system itself. But even with explicit casts, those casts may very naturally be before the accesses (the examples in the paper are simplistic, but we have the "prepare casts" pattern in the kernel in places like this: static long do_fcntl(int fd, unsigned int cmd, unsigned long arg, struct file *filp) { void __user *argp = (void __user *)arg; int argi = (int)arg; ... which admittedly isn't about two pointers that can alias, but is very much an example of "it's more convenient to 'prep' the casts before use", when the 'arg' argument is then used in multiple different ways - sometimes as a pointer, sometimes as an integer, and sometimes as the original 'unsigned long'. I personally think that the whole type-based aliasing is fundamentally unfixable, and that the C standards committee should just admit that. It doesn't even *work*, because often the types are the same anyway, even when you really really want to say "these accesses can't alias". The whole type-based aliasing is literally designed for - and by - HPC people who (a) had no taste, (b) didn't understand language design and just hacked sh*t together and (c) were working with clearly distinct types because their workloads are trivial. The HPC people literally tried to solve the issue of "counters are integers, but our data is FP, and the two have obviously different types, so let's use that information for alias analysis". Anybody who doesn't understand how broken and hacky that is SHOULD NOT BE ON A LANGUAGE COMMITTEE. Seriously. I think it should be a fundamental filter for any C language committee member: "Do you think type-based aliasing makes sense?". If you get anything but an immediate "No!", you pull the lever that opens the trap-door to the crocodile-infested waters below. Or sharks. Sharks are good too. And no, "restrict" isn't great, but at least it's a better concept. I would suggest that people look at improving 'restrict' and making it more useful, and just admit that the type-based thing was a mistake. Linus