From patchwork Wed Jan 20 17:52:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew MacLeod X-Patchwork-Id: 1429374 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=m3e2GTTr; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DLY540Ht4z9sCD for ; Thu, 21 Jan 2021 04:52:22 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 822FE396EC4D; Wed, 20 Jan 2021 17:52:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 822FE396EC4D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1611165139; bh=VX+FSmquy/R2Hq1s9PTjRWZYRMwkJm+Jbq2RbVr6s3Y=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=m3e2GTTrtH6s+5w4Peki+h2nUn8aFtrXtHUKDU/drpPb94HCm8oQi8CeRIguobVZW 6iG71LsMjCfsa1NhJJBCiOxxwxkKjoYRz6lyMkeaci8rwC5jN3jAkoIxKdW6qrpxMt sK8iz6EZKHsOhNrEGALpIKrS6XR5P4Whc+HdMVGE= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id EFA86385782D for ; Wed, 20 Jan 2021 17:52:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EFA86385782D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-434-jm80FjY_Nxq7usdL-5x8CA-1; Wed, 20 Jan 2021 12:52:13 -0500 X-MC-Unique: jm80FjY_Nxq7usdL-5x8CA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1CEBC107ACE3; Wed, 20 Jan 2021 17:52:12 +0000 (UTC) Received: from [10.10.118.121] (ovpn-118-121.rdu2.redhat.com [10.10.118.121]) by smtp.corp.redhat.com (Postfix) with ESMTP id B159CE159; Wed, 20 Jan 2021 17:52:11 +0000 (UTC) To: gcc-patches Subject: trapv question Message-ID: <59cb3869-3edc-fc80-8b00-815d91e0ff1f@redhat.com> Date: Wed, 20 Jan 2021 12:52:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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-Patchwork-Original-From: Andrew MacLeod via Gcc-patches From: Andrew MacLeod Reply-To: Andrew MacLeod Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Im looking at the testcase gcc.dg/torture/ftrapv-2.c int i = 0x7fffffff; int main(void) {   pid_t child = fork ();   int status = 0;   if (child == 0)     {       volatile int x = i + 1 < i;       exit (0);     } THis is failing with the new relational work... and I'm looking to understand whether I should be doing something different, or whether its the testcase that is flawed. The IL produced is   i.0_1 = i;   _2 = i.0_1 + 1;   _4 = i.0_1 > _2;   _5 = (int) _4;   x ={v} _5;   exit (0); What happens is that since _2 and i.0_1 are signed, and an overflow would therefore trap,  we determines that   _2 = i.0_1 + 1; which implies that _2 > i.0_1 EVRP then visits the next statement,   _4 = i.0_1 > _2; and promptly determines that _4 can never be true, and replaces it with 0.  Which then makes the rest of the block dead, and it gets optimized to   x ={v} 0;   exit (0); And then the test case fails because it uses -ftrapv and expects there to be a trap and it was removed.... IT can all be disabled by not registering that relationship when flag_trapv is set... my question is whether that is the correct solution tho... It seems to me it might just be the testcase is assuming that the addition can not be removed and now that it can be, perhaps a modification to the test case is more appropriate?  something like simply incrementing i? Is that the right thing to do? THanks Andrew diff --git a/gcc/testsuite/gcc.dg/torture/ftrapv-2.c b/gcc/testsuite/gcc.dg/torture/ftrapv-2.c index 75e464fe557..5824c2fdbb7 100644 --- a/gcc/testsuite/gcc.dg/torture/ftrapv-2.c +++ b/gcc/testsuite/gcc.dg/torture/ftrapv-2.c @@ -20,7 +20,7 @@ int main(void)    int status = 0;    if (child == 0)      { -      volatile int x = i + 1 < i; +      i = i + 1;        exit (0);      }    else if (child == -1)