From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2283 invoked by alias); 20 Mar 2012 19:41:51 -0000 Received: (qmail 2274 invoked by uid 22791); 20 Mar 2012 19:41:50 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BR,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta15.westchester.pa.mail.comcast.net (HELO qmta15.westchester.pa.mail.comcast.net) (76.96.59.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Mar 2012 19:41:36 +0000 Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id ntvq1i0091swQuc5Fvhbp2; Tue, 20 Mar 2012 19:41:35 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta15.westchester.pa.mail.comcast.net with comcast id nvha1i00v0BKwT43bvhbtv; Tue, 20 Mar 2012 19:41:35 +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: Date: Tue, 20 Mar 2012 19:41:00 -0000 Cc: Richard Guenther , gcc-patches Patches Content-Transfer-Encoding: quoted-printable Message-Id: <30DD0C87-07A8-4657-A1D6-A4D4A40BD243@comcast.net> 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> 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/msg01384.txt.bz2 On Mar 20, 2012, at 5:26 AM, Richard Sandiford wrote: > So what I was trying to say was that if we remove the assert > altogether, and allow CONST_DOUBLEs to be wider than 2 HWIs, > we need to define what the "implicit" high-order HWIs of a > CONST_DOUBLE are, just like we already do for CONST_INT. The problem with your position is you are wrong. Let me give you an concre= te example: typedef __attribute__((mode(OI))) signed int256_t; int256_t foo() { return (int256_t)0x7000000000000000 << 10; } This fails your assert you want to move down. This is _wrong_, wrong, wron= g wrong. This is getting tiring. This is perfectly well defined, with no change in any definition. Would yo= u like to try again? > If we remove the assert altogether, it very much matters what is done by = that last "*vp" line. > If Mike or anyone is up to doing that, then great. I categorically object to moving it down, it is wrong, for all the same rea= sons the original is wrong. > But if instead it's just a case of handling zero correctly, moving rather= than > removing the assert seems safer. Sure, that fixes 1 testcase, and is monotonically better. The problem, it = fixes less than 1% of the values for which we assert currently which are wr= ong. What is the point of bug pushing? Bug pushing is wrong. > I'm obviously not explaining this well :-) No, you are explaining your position well, it is just that your position is= wrong. Your position is you want to bug push, that position is wrong. Yo= u can't win with me by having that position. The only solution is to chang= e your position. You've done it once now, and you are moving in the right = direction. You are now willing to remove the assert for 0, which you didn'= t want to do before. Your next stop, will be to remove the assert for (in= t256_t)0x7000000000000000 << 10. I will keep pushing until you relent on t= hat point. Once you do, your position will have changed twice, mine, unch= anged. I will not relent after that step, merely, I will select the next v= alue and make you agree to it, then the next, and the next and the next, un= til I succeed in moving you to my original position. Now, you might be thinking that this check will protect wrong code generati= on in the rest of the compiler, and that may be somewhat true. A counter p= oint would be: (int256_t)1 << 254 which would have been my next interesting value to get you to agree with me= on, but, the assert you point at, doesn't prevent great badness from happe= ning with this case. Other parts of the compiler just suck, because people= didn't care enough. This I can change, but will take time. In my first p= atch, it will not be complete nor perfect. If you want to reject all the p= atches until every single last test case works, well, that isn't usually wh= at we do. We usually approve each one as long as it is monotonically bette= r, that's the standard by which to judge patches. Is your position, the rest of the compiler isn't perfect, so, no progress c= an be made in fixing it until the rest of it is perfect? If so, this is a = very bad position to take. I have time now to fix and submit work to make = things better. After I have things working perfectly, I may have 0 time wi= th which to do this. I'll give you a concrete example which exactly parall= els this work. There was a time when gcc didn't work on 64-bit targets. I= did the first 64-bit port. It was done as a series of patches, one at a ti= me, that pushed the compiler kicking and screaming in the right direction. = That work is the basis for all the 64-bit ports today; they are now less r= are than they were when I first started. gcc is reasonably good at support= ing 64-bit ports. What is different today, absolutely nothing, just N. In= stead of 64, it is 256, life goes on. All I can say, if you have this mist= aken notion that work to make OI work should be blocked because OI doesn't = work, is you are wrong. So, my question is, do you have this position?