From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <david.brown@hesbynett.no>
Received: from spam02.hesby.net (spam01.hesby.net [81.29.32.152])
 by sourceware.org (Postfix) with ESMTP id 79D3B3858D39
 for <gcc@gcc.gnu.org>; Tue, 11 Jan 2022 18:17:19 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79D3B3858D39
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=hesbynett.no
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hesbynett.no
Received: from [192.168.4.227] (247.92-221-34.customer.lyse.net
 [92.221.34.247]) by spam02.hesby.net (Halon) with ESMTPSA
 id b3575f84-730a-11ec-8d7a-506b8dfa0e58;
 Tue, 11 Jan 2022 19:17:16 +0100 (CET)
Subject: Re: reordering of trapping operations and volatile
To: Richard Biener <richard.guenther@gmail.com>,
 Martin Uecker <ma.uecker@gmail.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
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>
From: David Brown <david.brown@hesbynett.no>
Message-ID: <80181458-a864-57ea-47f0-adeedd2f7236@hesbynett.no>
Date: Tue, 11 Jan 2022 19:17:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAFiYyc2Z-TzW0kUGVhF-OT=YyUd_frCO5ercNhTaq-XFBqYzLQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3033.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 NICE_REPLY_A, 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: Tue, 11 Jan 2022 18:17:21 -0000

On 11/01/2022 08:11, Richard Biener via Gcc wrote:
> On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker <ma.uecker@gmail.com> wrote:
>>

<snip>

> 
> I realize that UB in a + b isn't (usually) observable but
> UB resulting in traps are.
> 
> So I'm still wondering why you think that 'volatile' makes
> a critical difference we ought to honor?  I don't remember
> 'volatile' being special in the definition of the abstract
> machine with regarding to observability (as opposed to
> sequence points).
> 
> 

Actually, volatile accesses /are/ critical to observable behaviour -
observable behaviour is program start and termination (normal
termination flushing file buffers, not crashes which are UB), input and
output via "interactive devices" (these are not defined by the
standard), and volatile accesses.  (See 5.1.2.3p6 in the standards if
you want the details.  Note that in C18, "volatile access" was expanded
to include all accesses through volatile-qualified lvalues.)


However, undefined behaviour is /not/ observable behaviour.  It can also
be viewed as not affecting anything else, and so moving it does not
affect volatile accesses.

So you can't re-order two volatile accesses with respect to each other.
 But you /can/ re-order UB with respect to anything else, including
volatile accesses.  (IMHO)

"Performing a trap" - such as some systems will do when dividing by 0,
for example - is not listed as observable behaviour.

<snip>