From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id C84183858C2D for ; Fri, 2 Sep 2022 00:03:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C84183858C2D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x134.google.com with SMTP id g7so976610lfe.11 for ; Thu, 01 Sep 2022 17:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:from:to:cc:subject:date; bh=T4YiAFCBHRTcnP1RL5aOBCJPyRTSzbrMnomby0QJwYQ=; b=VFT9UKtQKWLIZSQsGmKlwm6Ov3Q0lhFTIZV26OZ+1JL7wgOcQVOhPo89ZkVtmKMCus W5cUJuSH2ZNT8fiWi5x3dPxYegVutQdYaPT+lCU4ihOS6syyQxXg/fnveVAyMn8nHp3Q qijVIbsvksZwlJboN5khlmhYrTYsK3gffXWg/a/ClENt9h3/9jqcm0HVeB2TBLFVP+xz 5ukEKUU1XvtKXIExIzrk+/CZywW0h804Qu4AdHgV4PKKOXVcja5kgAkhkeUVrod1gXwe VnTvtj1xrxKDcbMEmE1qtG6HsEsDYICAEZVbnl6HhF1r05EuiXVhqvvyWoLDS5M05MXE BgxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date; bh=T4YiAFCBHRTcnP1RL5aOBCJPyRTSzbrMnomby0QJwYQ=; b=X5eFsCJzaOCtrWZAN8FkSNTIg9G7KvI0e+7uvBAXZ5/98EIGntscpnfVJtVpSsH/8i ekaCqbGf86b2xMMcMGKZePyoQSA1f6ARDpzHHQSvogpKra6YdT4SrXI9b50l/kCce3TZ nUIaVygZb2tSta6rnp0KpstEw4HkqaRXm9OthAED7TsxMSh+g2BLAzR6FrgLbMFU+nSm DBF9uSf6Ll7VfzPsFS0ay8gKuWDm9OvF+hkpIrlfzP4Cw33OcyDS5B+3xntwEqs5SDNp 0bt6rqNxngCENgOXGqbAEocCTbMey0JQmEtpfzXtvKXu/ZbNIJEwj3a2UI46hsLY/4Fu /fhg== X-Gm-Message-State: ACgBeo2qvPi+ZUhszTEycPrk4UK4dRj3c5pdJPjmoPJHVZUlPwuEzrwj r4z3hICSmrpoaGMaRIlmigg= X-Google-Smtp-Source: AA6agR5xZ0yl8Y8vKvkGjLAgQhCiN7pFL4Io9NkrH+g0gTmJleLk6PDcGeVZUva0BTsHFfaZ3b6ncw== X-Received: by 2002:a05:6512:2528:b0:494:6ee8:a9b3 with SMTP id be40-20020a056512252800b004946ee8a9b3mr5720299lfb.148.1662076997747; Thu, 01 Sep 2022 17:03:17 -0700 (PDT) Received: from [192.168.0.14] (c83-254-134-90.bredband.tele2.se. [83.254.134.90]) by smtp.gmail.com with ESMTPSA id w10-20020a05651234ca00b00492c5ec6f84sm42293lfr.249.2022.09.01.17.03.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Sep 2022 17:03:16 -0700 (PDT) From: Krister Walfridsson X-Google-Original-From: Krister Walfridsson Date: Fri, 2 Sep 2022 00:03:11 +0000 (UTC) To: Richard Biener cc: Krister Walfridsson , Andrew MacLeod , GCC Development Subject: Re: GIMPLE undefined behavior In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.3 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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 1 Sep 2022, Richard Biener wrote: > It's generally poorly documented what is considered 'undefined behavior'. > We desparately need a section in the internals manual for this. > For the {L,R}SHIFT_EXPR case we assume the shift operand is > in range of [0, precision - 1], so in theory value-range propagation could > infer that b_8(D) < 32 after it "executed". But it seems that > range-on-exit doesn't do that yet. [...] > The problem with shifts is that there's not a "do it anway, but without > undefined behavior" operation to substitute. I read this as I should not report these as bugs for now. But I'll probably keep this as UB in my tool to get an idea of how often this happens... >> Calling f(-3, 0x75181005) makes slsr_9 overflow in the optimized code, >> even though the original did not overflow. My understanding is that signed >> overflow invokes undefined behavior in GIMPLE, so this is a bug in >> ifcombine. Is my understanding correct? > > Yes, the above would be a bug - again value-range propagation might be > leveraged to produce a wrong-code testcase. OK. I'll open bugs for the signed overflow issues the tool finds. >> I would appreciate some comments on which non-memory-related operations I >> should treat as invoking undefined behavior (memory operations are more >> complicated, and I'll be back with more concrete questions later...). > > The more "interesting" cases are uninitialized values (registers or memory). Yes, this is the next thing I was planning to implement. :) > In general what we should worry about most is introducing undefined > behavior that, when a later pass can assume it doesn't happen, causes > wrong code to be generated. Likewise when we have late instrumentation > that would flag such undefined behavior as a user error. Agreed. But that comes back to the issue of lacking documentation... :( /Krister