From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id F0BD43858D20 for ; Tue, 15 Feb 2022 13:28:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F0BD43858D20 Received: by mail-ed1-x52b.google.com with SMTP id g7so15959549edb.5 for ; Tue, 15 Feb 2022 05:28:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dl2itAhvqZNm55VM/HIchzQqkaqjT2Biw5aVOcXEx5Q=; b=MEnCuVfrvt5lhp4VQs6+Y1c5Z5/AyK8RqtdV7TcE3dPBC63hs5xFcFZaHSat8VyUNs M+mDYtV0BHrqN1vH+gGvFLrk2mlVRvwMDkCHu3D9jQm+QYmjjmwxIGtVHxYGoZosq6pq oEHiPnwQ3AFNPtrGj+SmLRfkOq1Hbbku0aTMUZpIkIcI2uongAVsoEu/dKmT0XdG0Eu+ TRe8ncC4Gp8RVUjFOotDMkdFC8icq0fkBEBQfO5jMZbHpLNREcZuja5KONECSn6FLT0c CPcO/qSBv2GXpLROIk0shvLG9bEKKNuZIaY3v2J5YZPE/T07VH67Iu5EibMs19flBT8G hfAg== X-Gm-Message-State: AOAM531fFailuVERdATU2da1omuDNXhRYVrb7z3lA78XesnwIqlpJFGy 0UMG4kLFoP7+JizXVyznTx6+zsk3q+FavawQdiM= X-Google-Smtp-Source: ABdhPJycFG70MGRKHz2VLgipdURiKZoT0I6656q+DmCUGBHtedSR6drCeokL0/X77pspX//lRnfyrRpvxNl14RyFB1Q= X-Received: by 2002:a05:6402:17d1:: with SMTP id s17mr3940182edy.95.1644931695870; Tue, 15 Feb 2022 05:28:15 -0800 (PST) MIME-Version: 1.0 References: <20220214155757.861877-1-dmalcolm@redhat.com> <71de3204e639eed5052ca9e6416334aba6b2d1c7.camel@klomp.org> <3bfbfbf02e2d17d45b4a91e5ea5f855e0a62e5f5.camel@klomp.org> In-Reply-To: From: Richard Biener Date: Tue, 15 Feb 2022 14:28:04 +0100 Message-ID: Subject: Re: Uninit warnings due to optimizing short-circuit conditionals To: Julian Seward Cc: Mark Wielaard , David Malcolm , GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.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.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: Tue, 15 Feb 2022 13:28:18 -0000 On Tue, Feb 15, 2022 at 2:00 PM Julian Seward wrote: > > Sorry for the delayed response. I've been paging this all back in. > > I first saw this problem when memcheck-ing Firefox as compiled by Clang, some > years back. Not long after GCC was also at it. The transformation in > question is (at the C level): > > A && B ==> B && A if it can be proved that A > is always false whenever B is undefined > and (I assume) that B is provably exception-free > > where && means the standard lazy left-first C logical-AND. I believe this > might have become more prevalent due to ever-more aggressive inlining (at > least for Firefox), which presented the compilers with greater opportunities > to make the required proofs. Note GCC doesn't try to prove this, instead it reasons that when B is undefined it takes an indeterminate value and if A is _not_ always false then the program would have invoked undefined behavior, so we can disregard this possibility and assume B is not undefined. So either B is not undefined and everything is OK, or B is undefined but then A must be always false. Note that when A is always false we may have transformed a valid program (does not access B) into a program invoking undefined behavior (in C language terms). We don't treat undefined uses as "very" undefined behavior but I do remember we've shot ourselves in the foot with this transform - in this case we'd have to make the use of B determinate somehow, something we cannot yet do. So we'd want a transform like A && B ==> OK(B) && A where 'OK' sanitizes B in case it is undefined. The error we can run into is that two of the uninit Bs can be equated to two different values, breaking the B == B invariant (technically also OK, but not if it was us that introduced the undefinedness in the first place). Richard.