From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 70E7D3858D1E for ; Fri, 2 Sep 2022 06:20:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70E7D3858D1E 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-ej1-x636.google.com with SMTP id fy31so1835267ejc.6 for ; Thu, 01 Sep 2022 23:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=RGUH6fpvn3pCmTNScA65M9/P8TwKlPDsxXaiFBTu3t8=; b=aTfQmX8M9zPs6Tg2qIQzGI0mfYR9jfsHl0/P4Oe6XAT75xzIkA8FLRSzpVmCRzRwNW mOFnQlL6acKnZ5YGYzQL2asMC+tDwE0DWICdlFu6FE9CiMTioEh8EVQwV76fju7wjPzv IuE5wIq+JMXANUx/0lymC0LO/CJqgDB5e/+oWlwui+qklWZbJ/2hmFBatN5pbxD1GLxe l6huBCwdLZfu/kxxQyheXs/YicAE+yqD4VIhXKta6R3zRAtX10gvPlzrP6XVRWlPv60I GRgA/6aleREsAT28Lm2oBnfF9CHgMfuTXZEy8p7F5WY6gxUMHJVnOW1Vhpgb5VdoZtcC yxaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=RGUH6fpvn3pCmTNScA65M9/P8TwKlPDsxXaiFBTu3t8=; b=czCD3DZnS3AbR2zdN9jpsE/9++ovjKZjnC8Mcc7ntsFI1nAUsMymlK5GI/KZvApZka QLby4MkheXmZvXkEuC/c9YKNlUpvYHG/jc0+Mb2jJW6NgDwZ4n4t/W5i7XxJiBDQ14zS ZkAFDod7RDiKv+Dh1JTZl+c3s3BVdbVKqUSuMSH+ni9AHefujzVc0H77/LiQ6UIzu8C6 pdb77+XtnJH5aGbXhqq892C3ba57tkVrAiBzcxm28NWc8Odzanv+wN3gDCV/Oyyi6x2s bw8C6YRIpOyMEpj4v/EIGAVM4CfsD7NCEWmwQ/SLfpCdrqVqf4uFljn4H8aOLX3Kvb5E tUGw== X-Gm-Message-State: ACgBeo0SRFsu7n2IKjGbbq3EdWowDHczOvdt54i/OOzI2P0EEutGDGg1 QL+kVlfRKKB76M9mRy7kB9A7MHvP+fNFCb97n54= X-Google-Smtp-Source: AA6agR72R0DY+dY7iqwLsWxH/8NkzT+ro4WTg1tT6Gonw+8eRLo8KDK9Y0RJ1KlVzXsA1ia13Fwmrmdy7plZ6X5ZitY= X-Received: by 2002:a17:906:8a68:b0:741:56b2:af42 with SMTP id hy8-20020a1709068a6800b0074156b2af42mr18883199ejc.488.1662099599333; Thu, 01 Sep 2022 23:19:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 2 Sep 2022 08:19:47 +0200 Message-ID: Subject: Re: GIMPLE undefined behavior To: Krister Walfridsson Cc: Andrew MacLeod , GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 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 Fri, Sep 2, 2022 at 2:03 AM Krister Walfridsson wrote: > > 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... Can you report a single case as kind-of meta-bug for this particular issue? That would be nice. > > >> 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. Thanks. > >> 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... :( Yes. There's some "unknowns" in what GIMPLE treats as undefined given the lack of a strict specification but there's also implementation facts for which cases optimization passes already exploit undefined behavior (but even that subset is not documented). Richard. > /Krister