[Bug target/65321] New: ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[Bug target/65321] New: ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

            Bug ID: 65321
           Summary: ICE on valid code at -O2 and -O3 with -g enabled in
                    decompose, at rtl.h:2007
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 with -g enabled on x86_64-linux-gnu in both 32-bit and 64-bit
modes.

This is a regression from 4.9.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150304 (experimental) [trunk revision 221192] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-4.9.2 -O2 -g -c small.c
$ 
$ gcc-trunk -O2 -g -c small.c
small.c: In function ‘fn1’:
small.c:27:1: internal compiler error: in decompose, at rtl.h:2007
 }
 ^
0xae1a87 wi::int_traits<std::pair<rtx_def*, machine_mode> >::decompose(long*,
unsigned int, std::pair<rtx_def*, machine_mode> const&)
    ../../gcc-trunk/gcc/rtl.h:2005
0xae1a87 wide_int_ref_storage<false>::wide_int_ref_storage<std::pair<rtx_def*,
machine_mode> >(std::pair<rtx_def*, machine_mode> const&, unsigned int)
    ../../gcc-trunk/gcc/wide-int.h:957
0xae1a87 generic_wide_int<wide_int_ref_storage<false>
>::generic_wide_int<std::pair<rtx_def*, machine_mode> >(std::pair<rtx_def*,
machine_mode> const&, unsigned int)
    ../../gcc-trunk/gcc/wide-int.h:733
0xae1a87 wi::binary_traits<std::pair<rtx_def*, machine_mode>,
std::pair<rtx_def*, machine_mode>, wi::int_traits<std::pair<rtx_def*,
machine_mode> >::precision_type, wi::int_traits<std::pair<rtx_def*,
machine_mode> >::precision_type>::result_type wi::sub<std::pair<rtx_def*,
machine_mode>, std::pair<rtx_def*, machine_mode> >(std::pair<rtx_def*,
machine_mode> const&, std::pair<rtx_def*, machine_mode> const&)
    ../../gcc-trunk/gcc/wide-int.h:2357
0xae1a87 simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
    ../../gcc-trunk/gcc/simplify-rtx.c:3934
0xaded4f simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
    ../../gcc-trunk/gcc/simplify-rtx.c:1987
0x7791f3 cselib_expand_value_rtx_1
    ../../gcc-trunk/gcc/cselib.c:1843
0x77a38e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
    ../../gcc-trunk/gcc/cselib.c:1551
0xd88005 vt_expand_var_loc_chain
    ../../gcc-trunk/gcc/var-tracking.c:8310
0xd88005 vt_expand_loc_callback
    ../../gcc-trunk/gcc/var-tracking.c:8472
0x779102 cselib_expand_value_rtx_1
    ../../gcc-trunk/gcc/cselib.c:1704
0x77a38e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
    ../../gcc-trunk/gcc/cselib.c:1551
0xd88bb1 vt_expand_var_loc_chain
    ../../gcc-trunk/gcc/var-tracking.c:8310
0xd88bb1 vt_expand_1pvar
    ../../gcc-trunk/gcc/var-tracking.c:8585
0xd88bb1 emit_note_insn_var_location(variable_def**, emit_note_data_def*)
    ../../gcc-trunk/gcc/var-tracking.c:8640
0xd92403 void hash_table<variable_hasher, xcallocator,
false>::traverse_noresize<emit_note_data_def*,
&(emit_note_insn_var_location(variable_def**,
emit_note_data_def*))>(emit_note_data_def*)
    ../../gcc-trunk/gcc/hash-table.h:1057
0xd92403 void hash_table<variable_hasher, xcallocator,
false>::traverse<emit_note_data_def*,
&(emit_note_insn_var_location(variable_def**,
emit_note_data_def*))>(emit_note_data_def*)
    ../../gcc-trunk/gcc/hash-table.h:1079
0xd92403 emit_notes_for_changes
    ../../gcc-trunk/gcc/var-tracking.c:9000
0xd94140 emit_notes_in_bb
    ../../gcc-trunk/gcc/var-tracking.c:9432
0xd94140 vt_emit_notes
    ../../gcc-trunk/gcc/var-tracking.c:9495
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-------------------------------------


int a, b, c, d, e;

int
fn1 ()
{
  int h;
  char i;
  for (; c > 0;)
    {
      for (d = 0; d < 2; d++)
    {
      i = 1 << d;
      if (i - a)
        {
          e = b = 0;
          for (; c; c--)
        d = 127;
        }
    }
      h = ~d;
      if (h > c)
    for (;;)
      ;
      return 0;
    }
  return 0;
}
>From gcc-bugs-return-479417-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 05 06:40:00 2015
Return-Path: <gcc-bugs-return-479417-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 86731 invoked by alias); 5 Mar 2015 06:40:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 86641 invoked by uid 48); 5 Mar 2015 06:39:57 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/65067] regression on accessing volatile bit field
Date: Thu, 05 Mar 2015 06:40: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: missed-optimization
X-Bugzilla-Severity: major
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65067-4-ZD7VI3MWiL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65067-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65067-4@http.gcc.gnu.org/bugzilla/>
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/msg00561.txt.bz2
Content-length: 820

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide067

--- Comment #10 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Tony Liu from comment #9)
> (In reply to Bernd Edlinger from comment #8)
> > Created attachment 34955 [details]
> > Proposed Fix
> >
> > Well, I noticed that the first version of this patch caused
> > a small but measurable decrease of code quality on x86_64,
> > so I moved the patch to the if (strict_volatile_bitfield_p block,
> > and used some code transformations to simplify the resulting code
> > a bit.
> >
> > I will post this new version for review, after a full boot-strap
> > and successful regression-test on my ARM target.
>
> I've tested for target Cortex-M3, no regression.

Oh, thanks.  This was really speedy!

Then I am clear to post the patch in a moment.

[Bug target/65321] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-05
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed, started with r212352.

[Bug debug/65321] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
          Component|target                      |debug

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, i?86-*-*
             Status|NEW                         |ASSIGNED
          Component|debug                       |rtl-optimization
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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 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.

Richard?

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

--- Comment #4 from rsandifo at gcc dot gnu.org <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.  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.

> 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.

Thanks,
Richard

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
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 <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).

>  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).

So we need to either saturate (for !SHIFT_COUNT_TRUNCATED) or
truncate (for SHIFT_COUNT_TRUNCATED).

> > 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.  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).

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

--- Comment #6 from rsandifo at gcc dot gnu.org <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 <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

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
Richard S. is correct.  SHIFT_COUNT_TRUNCATED means that the target internally
truncates the shift count to the number of bits needed to represent the size of
the object being shift (which is actually more crisply defined than I
remember).

For a !SHIFT_COUNT_TRUNCATED target, the count is still constrained by the mode
of the shift count and it *may* still be internally truncated by the target. 
The x86 and m68k are good examples of this.  They truncate shifts, but not
things like variable bit test instructions.  But since they don't truncate
both, we do not define SHIFT_COUNT_TRUNCATED.

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34987&action=edit
gcc5-pr65321.patch

>From what I've seen, backends generally ensure that the shift amount mode is
not wider than the shift mode, so it is just the debug insns where this wasn't
enforced.  Fixed thusly (untested so far), does this look reasonable?

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|rguenth at gcc dot gnu.org         |jakub at gcc dot gnu.org

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
looks reasonable

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

--- Comment #10 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Thanks, looks good to me too FWIW.

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Mar 10 06:36:50 2015
New Revision: 221298

URL: https://gcc.gnu.org/viewcvs?rev=221298&root=gcc&view=rev
Log:
    PR rtl-optimization/65321
    * cfgexpand.c (expand_debug_expr): Ensure shift amount isn't wider
    than shift mode.
    * var-tracking.c (use_narrower_mode): Likewise.

    * gcc.dg/pr65321.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr65321.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/var-tracking.c

[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.