From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 61493385840D for ; Sat, 8 Jan 2022 15:27:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 61493385840D Received: by mail-wr1-x431.google.com with SMTP id r9so15449844wrg.0 for ; Sat, 08 Jan 2022 07:27:49 -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:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=m9eenu56pw665AVOSPfdzQvJUamK8m/waHimvXvV4Ik=; b=oBMOXw/qW/R1zXmsALT4/Oph9lA6LJe7eTvw85D0ijpNjc8y3ZYGrb/ybSr65+SXMr 8QyOwx2LZLzbmFUrrGRuVY/JSewJ8oR/AXX9NlzdrZWSRN2V+InCrjzPcnpomsxw8GxG HWzIJKBi0GtPBdYr/5KPysa/xzd1zIjw6P7WUNPjIBd4y+vWOrUjwcMTVMnKsbStRoC8 7CtOYD9DM/UXgfkrU+n4+ILFIMZs8hxKj4owVnyQ2FNeZLLgrCWeXz0e+UJc0R30HBZw IDLPtAWdnh+kLdq6nZUtYsY8gysN+aLZtGAKiqJiWclp72ln00iBfXu1Cc4/J222SgiE PGQA== X-Gm-Message-State: AOAM533/OeWXKQ8JCRD/UwRdrM39hOP95kvWdN8TEniaQaQOUJ9ZgAkE zIJV6+g1dgZ4tNXP+iVTOGU= X-Google-Smtp-Source: ABdhPJzvLJxpGoGyuUWrqQ8k1AMuBnhFCVf03iZs7xUbSXTHU6ptM/vCUd7Gqt5f5V7ai64EfjPPBw== X-Received: by 2002:a05:6000:144c:: with SMTP id v12mr59192095wrx.62.1641655668422; Sat, 08 Jan 2022 07:27:48 -0800 (PST) Received: from 2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at (2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at. [2a02:8388:e205:e880:569c:680a:c69b:a1ad]) by smtp.gmail.com with ESMTPSA id g8sm1649012wmh.17.2022.01.08.07.27.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Jan 2022 07:27:48 -0800 (PST) Message-ID: <2e1783a9e2a107dff24ecc4944bd43b1903746f1.camel@gmail.com> Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: Eric Botcazou Cc: Richard Biener , "gcc@gcc.gnu.org" Date: Sat, 08 Jan 2022 16:27:47 +0100 In-Reply-To: <5784303.lOV4Wx5bFT@fomalhaut> References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <5D6DA24A-954F-43C0-960F-54FE176D0607@gmail.com> <30b077c2231d31e0fb345584adef27ebe233c418.camel@gmail.com> <5784303.lOV4Wx5bFT@fomalhaut> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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, 08 Jan 2022 15:27:52 -0000 Am Samstag, den 08.01.2022, 15:41 +0100 schrieb Eric Botcazou: > > Yes, although I think potentially trapping ops > > are not moved before calls (as this would be > > incorrect). So do you think it would be feasable > > to prevent this for volatile too? > > Feasible probably, but why would this be desirable in C? It's not Java! It would allow us to still give at least some guarantees about the observable behavior of programs that later in their execution encounter UB (e.g. that an transaction with an external device is correctly completed). Considering the fact that it is virtually impossible to prove that any realistic C program is completely free of UB, this is would be very useful. As another example, there was recently the a proposal about adding a safe memory erasure function to the standard lib. It was pointed out that volatile stores would not be enough to be sure that the compiler safely erased some sensitive information, because an optimization based on later UB in the program could undo this. There is now also a proposal for C++ to introduce std::observable, which would require similar ordering constraints. But this would require the programmer to annotate the program correctly. Most C programmers would assume that volatile accesses already provides this guarantee, so actually doing so would be good. Or a more practical example: While debugging some embedded device, it would also be very annoying if the compilers reorders some trap before some debugging output. I could easily imagine loosing hours figuring out what happens. Martin