From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 9BECC3857C67 for ; Sat, 8 Jan 2022 21:07:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BECC3857C67 Received: by mail-wr1-x42d.google.com with SMTP id l25so7645483wrb.13 for ; Sat, 08 Jan 2022 13:07:59 -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=6Pol7TeTB6RCTcxBtOc8QsL2qxg870u4vrvbgKyB0y4=; b=1j7svKqxMNTtr75WbObhRBLBX0DZeb3h474sWfEcFbwBGClG5mZucE7QSMSSIlgafg lt8HILzpoiXX04woYHXQ+M9JjNY+kdDy0RtUubJYYlk0alrgeRdYQKwzPlbXumDA2p/x QQGrFvh2PhLBzPYFob4ZscVvabqnRWXmGbp7ouTdDw+iHnNIdLYnk4llafiovOnAeZ/p /2Q1BdhZ7ejqj7g9SAWRvMXqT1hA7SpB+Y+YohqKRjqY7UropqlfLkweUWyJ4pX62fEF Bw2wyqEnAp3SmUvAy6OHiggxKRXh3H4v18lEkmAKRVOi8BK7EiDwpsPMCXNmhGGNCNjz 0w7A== X-Gm-Message-State: AOAM530maApXV12Nnn4IAaV68FIiiEuS8DeWMdf4vhRp1kyZepi9kQRk D+RAXp0An419DTERuYHnugM= X-Google-Smtp-Source: ABdhPJzZ6TF1OMC3zZjx5cT5uZPwqUn89ZBDDsTEMagsYNcyVCYUyVX+QmrOjFePY98PJF/zxPdKIA== X-Received: by 2002:a05:6000:1c08:: with SMTP id ba8mr9322517wrb.0.1641676078568; Sat, 08 Jan 2022 13:07:58 -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 r62sm2361940wmr.35.2022.01.08.13.07.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Jan 2022 13:07:58 -0800 (PST) Message-ID: Subject: Re: reordering of trapping operations and volatile From: Martin Uecker To: Andrew Pinski Cc: "gcc@gcc.gnu.org" Date: Sat, 08 Jan 2022 22:07:57 +0100 In-Reply-To: References: <832b1b3957a0243ca37378a774effe537642eed3.camel@gmail.com> 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 21:08:01 -0000 Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > On Sat, Jan 8, 2022 at 12:33 AM 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 > > The question becomes what is a trapping instruction vs an undefined > instruction? > For floating point types, it is well defined what is a trapping > instruction while for integer types it is not well defined. > On some (many?) targets dividing by 0 is just undefined and does not > trap (powerpc, aarch64, arm and many others; MIPS it depends on the > options passed to GCC if the conditional trap should be inserted or > not). > The other side is if there is undefined code on the path, should > observable results happen first (stores to volatile/atomics, etc.)? I think for volatile stores and I/O, I think it would be nice of we could guarantee that those happen before the UB ruins the day. (I am not sure about atomics, those are not directly obsevable) For I/O this is probably already the case (?). For volatile, it seems this would need some tweaks. I am trying to figure out whether this is feasible. > GCC assumes by default that divide is trappable but stores not are not > observable. This is where -fnon-call-exceptions come into play. Ok, thanks! I will look at this! > In the second case, GCC assumes reducing trappable instructions are > fine. -fnon-call-exceptions would treat trapping instructions as defined (and trapping) instead of UB? This is then probably even stronger than the requirement above. > Note I thought -fno-delete-dead-exceptions would fix the sink > but it didn't. Martin