From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 674B0385841A for ; Mon, 13 Sep 2021 13:40:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 674B0385841A Received: by mail-pf1-x433.google.com with SMTP id 18so8839653pfh.9 for ; Mon, 13 Sep 2021 06:40:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aNi1uJuGv7HAcNAcD5jwd+HADVYHXy4RvFKCf0Ke3r8=; b=y4x0DzN2Eg5yABSRgBZIDXoh/k/hLjruq3ZPpQOLwOqV38JkU8un/dBmwL0b6gl6Yn RztD+keQaHRjkF1E0XZnx/8Co6Ghwziv0E0LeLi9p28UqfVqPr7CGMRnssO4M48rW/1L IJrRh1KzuFiNVoPuOoGkg4gbGsIWaQtF3W/VhRy37gDCawqgw6cniq3iSw/ohjOFC4sj s1iX4OtNRapeG/Lxvfje71+yopQJAflL/yqpTw+4jFTo6tzXih8fj4TS/fO1y3IA/iua vgr5MJOVUF8sJL+dimGZNIM+srm1PWnKapHOqmgBVHSeZrB6SpMEZi9itGUL6ZUXozZg JtMA== X-Gm-Message-State: AOAM532k0pJyKl9XyLCo3m8Jj/Z5tZRxcUQpVcE1QZILLopFrqZ8P0sR ClYOwCqBfo93LMNVjSKcCfQ= X-Google-Smtp-Source: ABdhPJyX0nYM/F1NhqQqEPFz1aMm5cBYERXyjEkCiAgc/MEv+/h/5b0tIIRpm4xK9o1JAccArZvEHw== X-Received: by 2002:a63:34c6:: with SMTP id b189mr11253602pga.122.1631540432350; Mon, 13 Sep 2021 06:40:32 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id m12sm7446981pjc.18.2021.09.13.06.40.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 06:40:32 -0700 (PDT) Subject: Re: Regression with recent change To: Aldy Hernandez Cc: gcc-patches , Richard Biener References: <889cbb03-3a02-65e4-7790-c903293bacf7@gmail.com> From: Jeff Law Message-ID: <3af2aac4-1b26-ff97-b73a-fa7c086b8dd6@gmail.com> Date: Mon, 13 Sep 2021 07:40:31 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 13:40:34 -0000 On 9/13/2021 7:29 AM, Aldy Hernandez wrote: > Jeff has pointed out that after my change adding global ranges to the > path solver, torture/pr55107.c is failing. Before I start digging > deep into the IL, I'd like to make sure this is not either expected or > a bogus test. > > Compiling this test on x86 with -Wall yields: > > $ gcc -c -O2 pr55107.c -Wall > pr55107.c: In function ‘f’: > pr55107.c:32:51: warning: the omitted middle operand in ‘?:’ will > always be ‘true’, suggest explicit middle operand [-Wparentheses] > 32 | ((a = d) ? b = 0 : (**p ? : 1) != (d != 1 ? : (a = 0))) > != (k ? a : 0) > | ^ > pr55107.c:33:11: warning: suggest parentheses around comparison in > operand of ‘!=’ [-Wparentheses] > 32 | ((a = d) ? b = 0 : (**p ? : 1) != (d != 1 ? : (a = 0))) > != (k ? a : 0) > | > ~~~~~~~~~~~ > 33 | < (a *= c = k) && (**p = 0); > | ^~~~~~~~~~~~~~ > pr55107.c:33:16: warning: operation on ‘a’ may be undefined [-Wsequence-point] > 33 | < (a *= c = k) && (**p = 0); > | ^~ > pr55107.c:33:16: warning: operation on ‘a’ may be undefined [-Wsequence-point] > pr55107.c:33:26: warning: value computed is not used [-Wunused-value] > 33 | < (a *= c = k) && (**p = 0); > | ^~ > pr55107.c:17:14: warning: ‘j’ is used uninitialized [-Wuninitialized] > 17 | for (; *j; j++) > | ^~ > > So it looks like there's some undefined behavior going on, even before > my patch. I'd like to get some feedback, because this is usually the > type of problems I see in the presence of a smarter threader... things > get shuffled around, problematic code gets isolated, and warning > passes have an easier time (or sometimes harder time) diagnosing > things. The original issue was PRE hanging, so I'd lean towards keeping the test as-is and instead twiddling any warning flags we can to make the diagnostics go away. jeff