[Bug middle-end/48043] New: pr47201: var-tracking loc_order_check fails for type punning examples

[Bug middle-end/48043] New: pr47201: var-tracking loc_order_check fails for type punning examples

[krebbel at gcc dot gnu.org]

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

           Summary: pr47201: var-tracking loc_order_check fails for type
                    punning examples
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: krebbel@gcc.gnu.org


Created attachment 23593
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23593
pr47201.i.214r.vartrack

The pr47201 testcase contains a union of an int and a float value.
The way these values are accessed seems to confuse the
canonicalize_loc_order_check done during var-tracking.

/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c: In function ‘foo’:
/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:18:1: internal compiler error:
in loc_cmp, at var-tracking.c:2753
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


pr47201.i.212r.alignments:

(insn 29 10 11 2 (set (reg:SI 1 %r1)
        (mem/u/c:SI (plus:SI (reg:SI 12 %r12)
                (const:SI (unspec:SI [
                            (symbol_ref:SI ("u")  <var_decl 0x779eb060 u>)
                        ] 111))) [0 S4 A8]))
            /build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 67 {*movsi_esa}
     (nil))

(insn 11 29 30 2 (set (reg:SF 16 %f0 [orig:53 u.d ] [53])
        (mem/s/j/c:SF (reg:SI 1 %r1) [0 u.d+0 S4 A32]))
    /build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 87 {movsf}
     (expr_list:REG_DEAD (reg:SI 1 %r1)
        (expr_list:REG_EQUIV (mem/s/j/c:SF (mem/u/c:SI (plus:SI (reg:SI 12
%r12)
                        (const:SI (unspec:SI [
                                    (symbol_ref:SI ("u")  <var_decl 0x779eb060
u>)
                                ] 111))) [0 S4 A8]) [0 u.d+0 S4 A32])
            (nil))))

(insn 30 11 12 2 (set (reg:SF 17 %f2)
        (mem/u/c:SF (plus:SI (reg:SI 12 %r12)
                (const:SI (unspec:SI [
                            (symbol_ref:SI ("u")  <var_decl 0x779eb060 u>)
                        ] 111))) [0 S4 A8]))
            /build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 87 {movsf}
     (expr_list:REG_DEAD (reg:SI 12 %r12)
        (nil)))

(insn 12 30 13 2 (set (reg:CCZ 33 %cc)
        (compare:CCZ (reg:SF 16 %f0 [orig:53 u.d ] [53])
            (reg:SF 17 %f2)))
        /build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 49 {*cmpsf_ccs}
     (expr_list:REG_DEAD (reg:SF 17 %f2)
        (expr_list:REG_DEAD (reg:SF 16 %f0 [orig:53 u.d ] [53])
            (nil))))


log_cmp complains about the mode differences of:

(reg:SF 17 %f2)
(reg:SI 1 %r1)

both holding: (symbol_ref:SI ("u")  <var_decl 0x779eb060 u>)

from:

(value/u:SI 12:5945 @0xe15b28/0xe27910)
 locs:
  from insn 30 (reg:SF 17 %f2)
  from insn 29 (reg:SI 1 %r1)
  from insn 29 (symbol_ref:SI ("u")  <var_decl 0x779eb060 u>)
 addr list:
  (value/u:SF 14:14 @0xe15b58/0xe27950)

[Bug middle-end/48043] pr47201: var-tracking loc_order_check fails for type punning examples

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-03-09 12:04:32 UTC ---
Created attachment 23594
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23594
pr47201.i.212r.alignments

[Bug middle-end/48043] pr47201: var-tracking loc_order_check fails for type punning examples

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.03.09 12:39:00
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-09 12:39:00 UTC ---
We should either prune non-compatible locations from the list (they are
only bitwise identical, the values as interpreted in the locations mode
differ) or simply accept these locations.

[Bug middle-end/48043] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-09 19:34:58 UTC ---
bb 2 op 19 insn 30 MO_VAL_SET (concat/u:SF (value/u:SI 12:5945
@0x243ae38/0x2445870)
        (reg:SF 17 %f2))
Either we should SUBREG this to the VALUE's mode, or allow different modes.  If
we do the latter, then we'll need to SUBREG it at vt_expand_loc_callback time.

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |debug
   Target Milestone|---                         |4.6.0
            Summary|pr47201: var-tracking       |[4.6 Regression] pr47201:
                   |loc_order_check fails for   |var-tracking
                   |type punning examples       |loc_order_check fails for
                   |                            |type punning examples

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-09 20:40:29 UTC ---
Actually, this is a s390 variant of PR43972, not a var-tracking bug.

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-09 20:43:29 UTC ---
Created attachment 23608
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23608
gcc46-pr48043.patch

Fix (tested just with cross on the pr47201.c testcase).  Could you please
bootstrap/regtestit, it might take a while for me to test it on s390x.

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-03-10 14:27:19 UTC ---
(In reply to comment #5)
> Created attachment 23608 [details]
> gcc46-pr48043.patch
> 
> Fix (tested just with cross on the pr47201.c testcase).  Could you please
> bootstrap/regtestit, it might take a while for me to test it on s390x.

Done. Bootstraps fine on s390 and s390x. No regression. The testcase is fixed
with this.

But your fix only applies if the mode mismatch comes from an address. Wouldn't
it be possible to trigger this situation with a normal value not going through
delegitimize_address?

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-10 14:37:39 UTC ---
If there isn't a mode mismatch in the instruction stream, then no.
The problem is that because of the delegitimizate address bug adjust_insn
in var-tracking (temporarily) changed the insn into
(set (reg:SF ...) (symbol_ref:SI ...))
(SET_SRC coming from delegitimizing a (mem:SF ...)) and var-tracking not
expecting mode mismatches.
If there is (set (reg:SF ...) (subreg:SF (reg:SI ...))) or something similar,
var-tracking ought to handle it correctly, sorry for the false alarm in #c3, I
wrote it without looking carefully into it.

Thanks for testing the patch, I'll post it to gcc-patches momentarily.

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-10 18:10:19 UTC ---
Author: jakub
Date: Thu Mar 10 18:10:14 2011
New Revision: 170851

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170851
Log:
    PR debug/48043
    * config/s390/s390.c (s390_delegitimize_address): Make sure the             
    result mode matches original rtl mode.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/s390/s390.c

[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-10 18:16:33 UTC ---
Fixed.