From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16933 invoked by alias); 18 Mar 2012 00:29:26 -0000 Received: (qmail 16923 invoked by uid 22791); 18 Mar 2012 00:29:25 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta01.westchester.pa.mail.comcast.net (HELO qmta01.westchester.pa.mail.comcast.net) (76.96.62.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 18 Mar 2012 00:29:06 +0000 Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id mo591i0021YDfWL51oV65l; Sun, 18 Mar 2012 00:29:06 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta20.westchester.pa.mail.comcast.net with comcast id moV51i00H0BKwT43goV5UY; Sun, 18 Mar 2012 00:29:06 +0000 Subject: Re: remove wrong code in immed_double_const Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: <87obrvd6fh.fsf@talisman.home> Date: Sun, 18 Mar 2012 00:29:00 -0000 Cc: gcc-patches Patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FF5A724-3FE1-4E97-8124-542A0B8259FE@comcast.net> <87obrvd6fh.fsf@talisman.home> To: Richard Sandiford 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/msg01210.txt.bz2 On Mar 17, 2012, at 12:37 AM, Richard Sandiford wrote: > Mike Stump writes: >> This removes some wrong code. >>=20 >> Ok? >>=20 >> Index: gcc/emit-rtl.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- gcc/emit-rtl.c (revision 184563) >> +++ gcc/emit-rtl.c (working copy) >> @@ -540,8 +540,6 @@ immed_double_const (HOST_WIDE_INT i0, HO >>=20 >> if (GET_MODE_BITSIZE (mode) <=3D HOST_BITS_PER_WIDE_INT) >> return gen_int_mode (i0, mode); >> - >> - gcc_assert (GET_MODE_BITSIZE (mode) =3D=3D 2 * HOST_BITS_PER_WIDE= _INT); >> } >>=20 >> /* If this integer fits in one word, return a CONST_INT. */ >=20 > Is this because you have an integer mode between HOST_BITS_PER_WIDE_INT a= nd > 2 * HOST_BITS_PER_WIDE_INT? Yes, I have those, but, that wasn't the testcase I had in mind. > Or is this because you have an integer mode wider than > 2*OST_BITS_PER_WIDE_INT? Yes. > We currently only support constant integer > widths <=3D 2*HOST_BITS_PER_WIDE_INT, and the assert is correctly > triggering if we try to build a wider constant. Can you give me a concrete example of what will fail with the constant 0 ge= nerated by: return GEN_INT (i0); when the mode is 2*HOST_BITS_PER_WIDE_INT? When the mode is larger than th= is? If you cannot, can you refer me to documentation where this is discussed? = If not, how about code? What I am seeing is that it works and generates correct code without the as= sert. My contention is that any code that fails to work, is buggy, and sho= uld be fixed, and once fixed, then there is no code that doesn't work, and = hence the assert is wrong. If you want to argue that the code that fails, = isn't buggy, go ahead, I'd love to hear it. See, we already shorten the width of wide constants and expect that to work= . This is just another instance of shortening. Now, just to see what lurk= s in there, I when through 100% of the uses of CONST_DOUBLE in *.c to get a= feel for what might go wrong, the code is as benign as I expected, every i= nstance I saw, looked reasonably safe. It doesn't get any better than this. > Obviously it'd be nice Yes, but that is quite a lot of work. It also happens to be orthogonal to = the immediate issue at hand. > if we supported arbitrary widths, e.g. by replacing CONST_INT and > CONST_DOUBLE with a single n-HOST_WIDE_INT rtx (and immed_double_const > with some kind of nary builder, etc.). It won't be easy though. >=20 > Removing the assert seems like papering over the problem. Do you have an example of a failure? Hint, without a failure, there is no = bug, I cannot fix a bug, when there is no bug. > FWIW, here's another case where this came up: >=20 > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01220.html Yes, and surprisingly, or not it is the exact same case as I can into. Not= ice nowhere in that bug or thread, is _any_ detailed discussed as to why th= at would be a bad fix. So, I'm looking for approval, or a concrete reason why it is a bad idea.