[Bug debug/52132] New: [4.7 Regression] ICE in loc_descriptor

[Bug debug/52132] New: [4.7 Regression] ICE in loc_descriptor

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

             Bug #: 52132
           Summary: [4.7 Regression] ICE in loc_descriptor
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: jakub@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
            Target: i686-linux


The following testcase ICEs with -m32 -g -O2 -std=c99 on x86_64-linux.
The bug is likely in regstack, which changes:
rh787518.i.216r.sched2:(debug_insn 20 58 21 2 (var_location:SI D#1 (subreg:SI
(reg:SF 8 st [orig:66 D.1248 ] [66]) 0)) rh787518.i:10 -1
to:
rh787518.i.218r.stack:(debug_insn 20 58 21 2 (var_location:SI D#1 (reg:SF 8
st)) rh787518.i:10 -1
(note the lost subreg).

The regression started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178597 though that likely just
made a latent bug into a reprduceable one.

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-02-06
      Known to work|                            |4.6.2
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1
      Known to fail|                            |4.7.0

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-06 08:34:22 UTC ---
int l;
void bar (void);

void
foo (int *x, float y)
{
  float b;
  union { float f; int i; } u = { .f = y };
  u.i += 127 << 23;
  u.f = ((-1.0f / 3) * u.f + 2) * u.f - 2.0f / 3;
  b = 0.5 * (u.f + l);
  if (b >= *x)
    bar ();
}

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-06 10:23:31 UTC ---
Created attachment 26581
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26581
gcc47-pr52132.patch

Untested fix.  What get_true_reg does might be reasonable for code where we
have quite strict requirements on what SUBREG can be applied or not, but it is
definitely wrong for arbitrary SUBREGs in DEBUG_INSNs.  In fact, I don't see
what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway
and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN.

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[p.finizio at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

Piero Finizio <p.finizio at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |p.finizio at gmail dot com

--- Comment #3 from Piero Finizio <p.finizio at gmail dot com> 2012-02-06 22:59:25 UTC ---
(In reply to comment #2)
> Created attachment 26581 [details]
> gcc47-pr52132.patch
> 
> Untested fix.  What get_true_reg does might be reasonable for code where we
> have quite strict requirements on what SUBREG can be applied or not, but it is
> definitely wrong for arbitrary SUBREGs in DEBUG_INSNs.  In fact, I don't see
> what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway
> and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN.

Fix tested with gcc-4.7.0-20120126 sources, this last extracted from
gcc-4.7.0-0.10.fc17.src.rpm.
Now gmake works with mesa from git repository.

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[p.finizio at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

--- Comment #4 from Piero Finizio <p.finizio at gmail dot com> 2012-02-06 23:01:56 UTC ---
(In reply to comment #2)
> Created attachment 26581 [details]
> gcc47-pr52132.patch
> 
> Untested fix.  What get_true_reg does might be reasonable for code where we
> have quite strict requirements on what SUBREG can be applied or not, but it is
> definitely wrong for arbitrary SUBREGs in DEBUG_INSNs.  In fact, I don't see
> what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway
> and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN.

Fix tested with gcc-4.7.0-20120126 sources, this last extracted from
gcc-4.7.0-0.10.fc17.src.rpm.
Now gmake works with mesa from git repository.

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-11 08:27:41 UTC ---
Author: jakub
Date: Sat Feb 11 08:27:30 2012
New Revision: 184126

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184126
Log:
    PR debug/52132
    * reg-stack.c (subst_stack_regs_in_debug_insn): Don't use
    get_true_reg.

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

Added:
    trunk/gcc/testsuite/gcc.dg/pr52132.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/reg-stack.c
    trunk/gcc/testsuite/ChangeLog

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52132

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-11 08:32:40 UTC ---
Fixed.