From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 4BDDC3858D35 for ; Sat, 15 Jan 2022 21:28:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BDDC3858D35 Received: by mail-il1-x133.google.com with SMTP id a18so5009491ilq.6 for ; Sat, 15 Jan 2022 13:28:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:cc:references:content-language:in-reply-to :content-transfer-encoding; bh=DneAapNJKl+8ByjF9VC1SSwtKBri7EHzxDTsoHK/Td8=; b=8EV/2nKIYfEi3ZbOHcYQn6FMmfX7SFi2hAtZfF+xIN4kKa5rIz3SV+FPoyZavwISpO 8HNsdddXPZhNPKR2nhZ1FX5PH4Alfv3LAIZSSUvAmpWJAeT6vW/6KwEyHPJRm6HiXW/P 6xxIdFRcgX+qz1Jigptn+cQQReXC4b4QcXu/AK9l/jfc1/rodG0gNh8e//35vHqZ/pPD U32snURPtpWcP98UdwKiETW0iHetXPv19i8VdAtuqjOMJXmgsxJyGRaJP4KF2llakoMP pKJL2/pAmPjRbPRvUV6ktayh1Ove/KdHKUq8xc1KQJd7JIrJCllPWukKOsM9QTGe/mSc X7YQ== X-Gm-Message-State: AOAM530svIAuWROI1XwzH9lqfoqyYrtPSqDrVr6qmZjMs/zM70M0iuZ6 XYyDt1hWcrVAUmPYWEBxYT0= X-Google-Smtp-Source: ABdhPJwpTZKNpBI8Bvbcx35vvPZbgqaLeehYpP28ab+N8136QAiyNhMi9h8mUWZ0y2jLpGdIfo+nAA== X-Received: by 2002:a92:940e:: with SMTP id c14mr6446492ili.216.1642282101458; Sat, 15 Jan 2022 13:28:21 -0800 (PST) Received: from [192.168.0.41] (97-118-100-142.hlrn.qwest.net. [97.118.100.142]) by smtp.gmail.com with ESMTPSA id m14sm6815174iow.54.2022.01.15.13.28.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Jan 2022 13:28:21 -0800 (PST) Message-ID: Date: Sat, 15 Jan 2022 14:28:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 From: Martin Sebor Subject: Re: reordering of trapping operations and volatile To: Paul Koning , Michael Matz Cc: GCC Development , Martin Uecker References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <40fd9a2f078cd6e87fedbc5f1e77baf8445a7356.camel@gmail.com> <02f4b13397f1d77db433ffc0c9401a6e66fb706d.camel@gmail.com> <09C9C641-02B2-4B83-B2C1-423DC573090B@comcast.net> Content-Language: en-US In-Reply-To: <09C9C641-02B2-4B83-B2C1-423DC573090B@comcast.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2022 21:28:26 -0000 On 1/14/22 07:58, Paul Koning via Gcc wrote: > > >> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote: >> >> Hello, >> >> On Thu, 13 Jan 2022, Martin Uecker 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 >>> >>> No, I am arguing for UB not to have the power >>> to go back in time and change previous defined >>> observable behavior. >> >> But right now that's equivalent to making it observable, >> because we don't have any other terms than observable or >> undefined. As aluded to later you would have to >> introduce a new concept, something pseudo-observable, >> which you then started doing. So, see below. > > I find it really hard to view this notion of doing work for UB with any favor. The way I see it is that a program having UB is synonymous with "defective program" and for the compiler to do extra work for these doesn't make much sense to me. This is also the official position of the C committee on record, but it's one that's now being challenged. > > If the issue is specifically the handling of overflow traps, perhaps a better answer would be to argue for language changes that manage such events explicitly rather than having them be undefined behavior. Another (similar) option might be to choose a language in which this is done. (Is Ada such a language? I don't remember.) A change to the language standard is only feasible if it doesn't overly constrain existing implementations. The impetus for Martin's question here is to try to understand the impact on GCC. Of course, GCC is just one of many C implementations, and WG14 has only a very limited visibility into existing compilers. As a result, even if GCC were not to be impacted by a change here, imposing requirements that might have an adverse effect on other implementations isn't likely to gain enough support. Martin