From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <matz@suse.de>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29])
 by sourceware.org (Postfix) with ESMTPS id 0B2F1385800A
 for <gcc@gcc.gnu.org>; Thu, 13 Jan 2022 16:45:05 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B2F1385800A
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
 by smtp-out2.suse.de (Postfix) with ESMTP id C01251F387;
 Thu, 13 Jan 2022 16:45:03 +0000 (UTC)
Received: from wotan.suse.de (wotan.suse.de [10.160.0.1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by relay2.suse.de (Postfix) with ESMTPS id BA706A3B83;
 Thu, 13 Jan 2022 16:45:03 +0000 (UTC)
Received: by wotan.suse.de (Postfix, from userid 10510)
 id B02E264A8; Thu, 13 Jan 2022 16:45:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by wotan.suse.de (Postfix) with ESMTP id AEB3862DC;
 Thu, 13 Jan 2022 16:45:03 +0000 (UTC)
Date: Thu, 13 Jan 2022 16:45:03 +0000 (UTC)
From: Michael Matz <matz@suse.de>
To: Martin Uecker <ma.uecker@gmail.com>
cc: Richard Biener <richard.guenther@gmail.com>, 
 "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: reordering of trapping operations and volatile
In-Reply-To: <bacbe96676729ceafda1ec8077ec3206e4770d82.camel@gmail.com>
Message-ID: <alpine.LSU.2.20.2201131625270.4251@wotan.suse.de>
References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com>
 <CA+=Sn1ni3nAq3aGBJkV_=ie56EeeO2zXZK3gkq0nGM6f=-Jd_A@mail.gmail.com>
 <bc09552c7b4b6b0c7e9d9f5b3bbff1275dc412b1.camel@gmail.com>
 <CAFiYyc2f5yMT+Pm+2cC9USHZDq9W2h9VsMjerU+1ouNQ3FPFrg@mail.gmail.com>
 <40fd9a2f078cd6e87fedbc5f1e77baf8445a7356.camel@gmail.com>
 <CAFiYyc2Z-TzW0kUGVhF-OT=YyUd_frCO5ercNhTaq-XFBqYzLQ@mail.gmail.com>
 <02f4b13397f1d77db433ffc0c9401a6e66fb706d.camel@gmail.com>
 <CAFiYyc3e+cO-TzxFbTVc451-hJ=n2e2=0Jj0ABGVjYePBkVuDQ@mail.gmail.com>
 <bacbe96676729ceafda1ec8077ec3206e4770d82.camel@gmail.com>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2022 16:45:06 -0000

Hello,

On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote:

> >  Handling all volatile accesses in the
> > very same way would be possible but quite some work I don't
> > see much value in.
> 
> I see some value. 
> 
> But an alternative could be to remove volatile
> from the observable behavior in the standard
> or make it implementation-defined whether it
> is observable or not.

But you are actually arguing for making UB be observable (which then 
directly implies an ordering with respect to volatile accesses).  That's 
much different from making volatile not be observable anymore (which 
obviously would be a bad idea), and is also much harder to do, it's 
the nature of undefined behaviour to be hard to define :)

Well, what you _actually_ want is an implied dependency between some UB 
and volatile accesses (and _only_ those, not e.g. with other UB), and the 
difficulty now is to define "some" and to create the dependency without 
making that specific UB to be properly observable.  I think to define this 
all rigorously seems futile (you need a new category between observable 
and UB), so it comes down to compiler QoI on a case by case basis.


Ciao,
Michael.