From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16188 invoked by alias); 22 Mar 2012 13:16:07 -0000 Received: (qmail 16180 invoked by uid 22791); 22 Mar 2012 13:16:06 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Mar 2012 13:15:53 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id E548D90B49; Thu, 22 Mar 2012 14:15:51 +0100 (CET) Date: Thu, 22 Mar 2012 13:16:00 -0000 From: Michael Matz To: Mike Stump Cc: Richard Sandiford , Richard Guenther , gcc-patches Patches Subject: Re: remove wrong code in immed_double_const In-Reply-To: <5F4F06D3-C6F0-47F2-AEB3-1760EC4D2EAE@comcast.net> Message-ID: References: <5FF5A724-3FE1-4E97-8124-542A0B8259FE@comcast.net> <87obrvd6fh.fsf@talisman.home> <87haxmgqoo.fsf@talisman.home> <7C6A7462-C1D3-4765-83FF-3B3C726D92E5@comcast.net> <8762e09sgc.fsf@talisman.home> <0A5CBD0C-FC94-4637-B230-1A83372DE91A@comcast.net> <7E568BC6-FD8F-4FD5-8ABF-43FD253D3E8F@comcast.net> <5F4F06D3-C6F0-47F2-AEB3-1760EC4D2EAE@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg01503.txt.bz2 Hi, On Wed, 21 Mar 2012, Mike Stump wrote: > > If the high bit of i1 is set then currently you will get a negative > > number produced no matter the absolute value of it. > > Ok, in the new patch, I'm pushing to change the spec so that the value > is sign extended and fixing all the code that doesn't conform to that > spec. That certainly is strictly better than any of the other possibilities, I just didn't get the impression from your second mail to this thread that you were even considering doing that. Good I was wrong. If I notice anything I'll answer directly to the patch. > > This positive/negative inconsistency doesn't make sense to allow, and > > the assert ensures that it isn't allowed. > > Don't need the assert when there is no inconsistency, I believe that > resolving any inconsistencies should remove the need for the assert. Correct. > :-) Only the point I wanted to make; that 0 is safe. As such, it > proves that the spec, as you might call it, is wrong. I would call it too strict, not wrong. Because there are (or were after your fixes get it) values where there was a problem. Of course that's again just splitting hair about terminology :) Ciao, Michael.