From patchwork Mon Jan 21 08:41:25 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 214047 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id C59AE2C009C for ; Mon, 21 Jan 2013 19:43:49 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1359362630; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version: Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=GlHJIs3smDI5fhR3A2uZO1SW77U=; b=uSOg88IF93FJl4t +HPdmM4JOgLBQzts6fQkdt5bOlNEiM/Qzz5n7jp489+9ZCFKWuQac3utg/l+Zp99 XEXYZEQcltihbXPwLeQkLfC4C9XBIOEWa5vm9OmMm6OQu7YmzzH1WZTD6f0CGe+b 8+KPjzXrG+NHcUoQ+tkAczwMmWm0= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=Dclegl6oyCzNPyXRSCtGD3pwDzmFkmTI/sRtD4qgHusdtUpeStwpPvpl0+EhHW 95RQAWmefmFIloGULMHhIWwqS+e/5vAe1YLfdNLELFyT2s7E2YEabZGfvtDb5k57 25+uh4CobomXCknIN0YvogJ5pcLPh2z8u728HcvAkytLc=; Received: (qmail 11054 invoked by alias); 21 Jan 2013 08:43:44 -0000 Received: (qmail 11043 invoked by uid 22791); 21 Jan 2013 08:43:43 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Jan 2013 08:43:37 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 41F6D29002E for ; Mon, 21 Jan 2013 09:43:46 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM0yuVzrJYMM for ; Mon, 21 Jan 2013 09:43:46 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 0F741290006 for ; Mon, 21 Jan 2013 09:43:46 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [patch] Fix wrong code with boolean negation Date: Mon, 21 Jan 2013 09:41:25 +0100 Message-ID: <10788105.o7paIdRnUj@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.16-desktop; KDE/4.7.2; x86_64; ; ) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi, this is a regression present in the Ada compiler since 4.5: the issue had been latent for ages, but an unrelated streamlining of the IR made it appear. When make_range_step is invoked on: (integer)!b < 0 where b is a boolean, it returns "always true" instead of "always false". The sequence is as follows: (integer)!b < 0 is_true_if not in [0:0] (integer)!b is_true_if not in [0;+inf[ !b is_true_if not in [0;255] b is_true_if in [0;255] The wrong step is the last one: when TRUTH_NOT_EXPR is seen in make_range_step the "in" value is unconditionally toggled. Of course that doesn't work in the general case, just if the range is the "boolean" range. As a matter of fact, this is explained just below for the comparison operators: /* We can only do something if the range is testing for zero and if the second operand is an integer constant. Note that saying something is "in" the range we make is done by complementing IN_P since it will set in the initial case of being not equal to zero; "out" is leaving it alone. */ so the fix is to use the zero range condition in the TRUTH_NOT_EXPR case. Tested on x86_64-suse-linux, OK for mainline? And for branch(es)? 2013-01-21 Eric Botcazou * fold-const.c (make_range_step) : Bail out if the range isn't testing for zero. 2013-01-21 Eric Botcazou * gnat.dg/opt26.adb: New test. Index: fold-const.c =================================================================== --- fold-const.c (revision 195310) +++ fold-const.c (working copy) @@ -3813,6 +3813,10 @@ make_range_step (location_t loc, enum tr switch (code) { case TRUTH_NOT_EXPR: + /* We can only do something if the range is testing for zero. */ + if (low == NULL_TREE || high == NULL_TREE + || ! integer_zerop (low) || ! integer_zerop (high)) + return NULL_TREE; *p_in_p = ! in_p; return arg0;