From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24525 invoked by alias); 7 Mar 2015 10:32:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 24488 invoked by uid 48); 7 Mar 2015 10:32:31 -0000 From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007 Date: Sat, 07 Mar 2015 10:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg00777.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to rguenther@suse.de from comment #5) > On Thu, 5 Mar 2015, rsandifo at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321 > > > > --- Comment #4 from rsandifo at gcc dot gnu.org --- > > (In reply to Richard Biener from comment #3) > > > (gdb) p debug_rtx (x.first) > > > (const_int 128 [0x80]) > > > (gdb) p x.second > > > $2 = QImode > > > (gdb) p precision > > > $3 = 8 > > > > > > the CONST_INT is not properly sign-extended. This is from > > > > > > #6 0x0000000000d55381 in simplify_const_binary_operation (code=ASHIFT, > > > mode=QImode, op0=0x7ffff68d3490, op1=0x7ffff69e8b00) > > > at /space/rguenther/src/svn/trunk2/gcc/simplify-rtx.c:4001 > > > ... > > > 3997 case LSHIFTRT: > > > 3998 case ASHIFTRT: > > > 3999 case ASHIFT: > > > 4000 { > > > 4001 wide_int wop1 = pop1; > > > 4002 if (SHIFT_COUNT_TRUNCATED) > > > 4003 wop1 = wi::umod_trunc (wop1, width); > > > > > > but of course the shift amount need not be QImode as well. 128 is quite > > > large, > > > but well... > > > > > > Fact is that we don't know the mode of op1 here. From the fact that the > > > const_int is not sign-extended we can conclude its mode is larger than > > > QImode. > > > And we will truncate it anyway (or return NULL_RTX) if it is too large, so > > > it doesn't even matter. > > > > I take your point, but at the same time, is it really worth supporting shifts > > whose shift amount is wider than the shifted value? ISTM that no .md pattern > > would want such a thing, so in practice this would only ever happen with debug > > exprs. > > Well, simplifying such shift may occur in regular code as well. We > simply drop the extra bits (or fail to simplify), but that's done > with wide-int stuff so we need to be able to convert the RTX to a > wide-int first... (chicken and egg issue). But shifts in regular code are going to be more sensible, since they're ultimately constrained by .md patterns. And when given a sensible shift mode, the simplify-rtx.c routines should only produce sensible shift modes. The problem case is coming from simplification routines local to var-tracking.c. > > I think the safest fix would be to make use_narrower_mode{,_test} > > narrow the shift amount if it is wider than the target mode. Just tried that > > locally and it seems to fix the test case. > > No, that doesn't work. It will change behavior for say > a shift of a QImode value by 0x101 because you'd obtain one for the > shift value and thus the path taken will be different. ISTR that > the difference with respect to implementations is whether a > shift by 0x101 will result in a shift by 1 (SHIFT_COUNT_TRUNCATED) > or whether it will result in zero (shift by too large value). No, !SHIFT_COUNT_TRUNCATED doesn't mean that the shifts are infinite precision, it just means that they have a target-specific precision. The result can be 0, 1 or even something else. The target-independent code simply doesn't know, which is why simplify-rtx.c bails out if the shift amount is out of range on a !SHIFT_COUNT_TRUNCATED target. AIUI this leeway isn't there for language-level behaviour. It's there so that if the target wants to split more complicated operations into sequences involving shifts, it can take the behaviour of the shift instructions into account without worrying about the target-independent code misoptimising the result. E.g. if you're implementing doubleword 64-bit shifts using 32-bit word shifts, you can save an instruction if the 32-bit shift honours the low 6 bits of the shift amount. 32-bit ARM is an example of this. It's !SHIFT_COUNT_TRUNCATED, but pass a shift amount of 0x101 to an ARM shift instruction and the result would be the same as a shift of 1, just as it is for SHIFT_COUNT_TRUNCATED. So !SHIFT_COUNT_TRUNCATED shifts are only "implementation-defined" for shifts that the target could actually do. If the shift has no corresponding instruction, the behaviour is undefined rather than implementation-defined. > > > I think we can simply use > > > > > > wide_int wop1 = std::make_pair (op1, MAX_MODE_INT); > > > > > > here (or SImode maybe). Or have a "don't care" way to make a wide-int > > > from a CONST_INT directly. > > > > Certainly SImode would be dangerous, since there's nothing to stop the same bug > > reappearing with DImode. MAX_MODE_INT is a problem because it can be wider > > than MAX_BITSIZE_MODE_ANY_INT on targets like x86_64 that explicitly override > > the wide_int size. And I'd be reluctant to relax the general CONST_INT > > semantics for such an oddball case. > > Well, the real fix is to pass down the mode - which may be not available, > of course. The real fix is to add modes to CONST_INT :-) Have I complained before about how many problems modeless CONST_INTs cause? > Or simply declare that the shift amount has to be the same > mode as the shifted value and properly create the RTL in the first place > (honoring SHIFT_COUNT_TRUNCATED in the correct way). I don't think we want to force targets to have wider than necessary shift amounts. E.g. x86 uses QImode shift amounts for SImode. The point of my use_narrower_mode suggestion was to declare that the shift amount has to be no wider than the shifted value. No target should be affected by that. Thanks, Richard