From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id D54A03858401 for ; Sat, 8 Jan 2022 12:41:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D54A03858401 Received: by mail-wr1-x432.google.com with SMTP id h10so6373244wrb.1 for ; Sat, 08 Jan 2022 04:41:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:user-agent:in-reply-to :references:message-id:mime-version:content-transfer-encoding; bh=P4uhM88btCPdeVdsJKxP4kirvKPRqIJ2wm6hvW5hn4Q=; b=ulNoMeFRD4bbdPFH+86+ti4z2H1wRKnc8YJf27rNWEH80scREpc4mGwIcLT9Bt6U2e syl2hioudNKj5nVzWMOz7a5ydbsz+9+PcsWfWq2cIDx2A2xTcVtu+p96VD7QRtD2SNeN ZfcX2GMLgiGdWfiujlbO+yRNQxyIgyErxZshFRBQedRYz4qsTDZDwSy/g+Uj1k4NF/aC LNPoq+NkkNczhdtXZ7G9aCUAgx+djY2OB5SIBDNJ0QWdZUzIlPhMG8FZUn0qUrGCG7Su FpzI3zIq5ucYrnjQVGEU3L+9JxxHnv2XH5S9XZzNQFpjpLbOfWvhiyaAO2ZsesWw3Vn9 wa+Q== X-Gm-Message-State: AOAM531OoymqiyHz83I1NU5jJeISpkF0HmAiYPr/+sz5VRWIDuZohmGT jXL3FgdvcsCM1rmiJJeFz24= X-Google-Smtp-Source: ABdhPJwBIQ3tMGXB4HigXY1OmtNLZFUmzeHqxicuS/JXzF+DSzaFtGNCmdVljmcW6H/rOS9cdCJTYg== X-Received: by 2002:adf:efc6:: with SMTP id i6mr56304516wrp.428.1641645716846; Sat, 08 Jan 2022 04:41:56 -0800 (PST) Received: from [127.0.0.1] (dynamic-095-114-104-056.95.114.pool.telefonica.de. [95.114.104.56]) by smtp.gmail.com with ESMTPSA id ay39sm1348974wmb.29.2022.01.08.04.41.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jan 2022 04:41:56 -0800 (PST) Date: Sat, 08 Jan 2022 13:41:55 +0100 From: Richard Biener To: Martin Uecker , "gcc@gcc.gnu.org" Subject: Re: reordering of trapping operations and volatile User-Agent: K-9 Mail for Android In-Reply-To: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> Message-ID: <5D6DA24A-954F-43C0-960F-54FE176D0607@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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 12:41:59 -0000 On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker wrote: > >Hi Richard, > >I have a question regarding reodering of volatile >accesses and trapping operations=2E My initial >assumption (and hope) was that compilers take >care to avoid creating traps that are incorrectly >ordered relative to observable behavior=2E > >I had trouble finding examples, and my cursory >glace at the code seemed to confirm that GCC >carefully avoids this=2E 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 =3D b; > return a / b; >} > > >https://godbolt=2Eorg/z/vq3r8vjxr > >In this example a division is hoisted=20 >before the volatile store=2E (the division >by zero which could trap is UB, of course)=2E > >As Martin Sebor pointed out this is done >as part of redundancy elimination=20 >in tree-ssa-pre=2Ec and that this might >simply be an oversight (and could then be >fixed with a small change)=2E > >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? In general there is no data flow information that prevents traps from bein= g reordered with respect to volatile accesses=2E The specific case could be= easily mitigated in PRE=2E Another case would be A =3D c / d; X =3D 1; If (use_a) Bar (a); Where we'd sink a across x into the guarded Bb I suspect=2E=20 (sorry for the odd formatting, writing this on a mobile device)=2E=20 Richard=2E=20 > >Martin > > > > > >