From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 440443853803 for ; Sat, 8 Jan 2022 16:42:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 440443853803 Received: by mail-wm1-x32a.google.com with SMTP id l12-20020a7bc34c000000b003467c58cbdfso6713107wmj.2 for ; Sat, 08 Jan 2022 08:42:38 -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:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=Tp0N2LX+jojsR6jdMvMSi5G1GNacH9vrGTTc6GJZ24s=; b=k3rzPqb2APX6/Tw3m+tsSH3Pp6I+IcbXDvDdp9QFASrdlHJ/VfJ03C1j+F7PApr54F RTr9zH2d3i4CaMlJrxcIDl0VgjgV+T5ENsV2b8RJFqfV3f2/meUg2TQViy+0TUo4cskF EzR1IBL/Q2m53Nq19AXWsOIszfc+RQYN4Om1bgIFfVUVHBzvCiqsP3Zyrzpu20J7G0VA vTlOUB2r9CXLteLDZ15ajXxDd2jGNGyNaWnNdYscrcpClE0yXbve4kfzX8hcElzbn1EH TIWKRwiCQoxy52rKXu14pnMY1NMxLy75oH1HiWPfL4LRgaEAHT7D9rnnRvvHcxyKlRf3 h1Kg== X-Gm-Message-State: AOAM530zg4IV27nVbTI2BlUJUR/0fO1aJzaehmk7sRRLeANm+ySferSu csQBpJXAUrnZJTeHGIfhWIE= X-Google-Smtp-Source: ABdhPJy4ucaKUP4z52IEkB0Z2noT1VIXHi/K72SunIbGsdHGmNzYiuNZ4ViA+Ce5HO9QIb4LBg9D4w== X-Received: by 2002:a05:600c:2304:: with SMTP id 4mr15193731wmo.71.1641660157314; Sat, 08 Jan 2022 08:42:37 -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 b13sm2057482wrf.64.2022.01.08.08.42.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Jan 2022 08:42:36 -0800 (PST) Message-ID: <58ba38d1f27052240b06e275b7ab09b202c0642e.camel@gmail.com> Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: David Brown , "gcc@gcc.gnu.org" Date: Sat, 08 Jan 2022 17:42:35 +0100 In-Reply-To: <8e4eea82-2e1a-9f8a-c0ef-54861db2563e@hesbynett.no> References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> <8e4eea82-2e1a-9f8a-c0ef-54861db2563e@hesbynett.no> 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 16:42:39 -0000 Am Samstag, den 08.01.2022, 16:03 +0100 schrieb David Brown: > On 08/01/2022 09:32, Martin Uecker via Gcc wrote: > > Hi Richard, > > > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial > > assumption (and hope) was that compilers take > > care to avoid creating traps that are incorrectly > > ordered relative to observable behavior. > > > > I had trouble finding examples, and my cursory > > glace at the code seemed to confirm that GCC > > carefully avoids this. But then someone showed > > me this example, where this can happen in GCC: > > > > > > volatile int x; > > > > int foo(int a, int b, _Bool store_to_x) > > { > > if (!store_to_x) > > return a / b; > > x = b; > > return a / b; > > } > > > > > > https://godbolt.org/z/vq3r8vjxr > > > > In this example a division is hoisted > > before the volatile store. (the division > > by zero which could trap is UB, of course). > > > > Doesn't this depend on whether the trap is considered "observable > behaviour", or "undefined behaviour" ? > > If (on the given target cpu and OS, and with any relevant compiler > flags) dividing by zero is guaranteed to give a trap with specific known > behaviour, then it is observable behaviour and thus should be ordered > carefully with respect to the volatile accesses. > > On the other hand, if division by 0 is considered undefined behaviour > (the C and C++ standards explicitly mark it as undefined, but a compiler > can of course define its behaviour) then the compiler can assume it does > not happen, or you don't care about the result of the program if it > happens. Undefined behaviour can be freely re-ordered around volatile > accesses, as far as I understand it - though that can come as a surprise > to some people. In C++ has wording that makes it clear that this reordering is allowed. In C, some people also see it this way. In my opinion, this is not clear and I always read the standard in a different way (i.e. run-time UB happens at a point in time but can not go backwards at change previous defined behavior). But in any case, I would find it much more useful if it is guaranteed to not affect previous observable behavior. This would make volatile more useful, which in my opinion is preferable to introducing another language feature to work around this issue. This of course assumes that this reodering around volatile accesses and I/O is not essential for optimization. Martin > > I don't know which of these views gcc takes - I think both are valid. > But it might be worth noting in the reference manual. > > David > > > > > As Martin Sebor pointed out this is done > > as part of redundancy elimination > > in tree-ssa-pre.c and that this might > > simply be an oversight (and could then be > > fixed with a small change). > > > > Could you clarify whether such reordering > > is intentional and could be exploited in > > general also in other optimizations or > > confirm that this is an oversight that > > affects only this specific case? > > > > If this is intentional, are there examples > > where this is important for optimization? > > > > > > Martin > > > > > > > > > > > > > >