[Bug rtl-optimization/32790] New: REG_N_SETS holds wrong value

[Bug rtl-optimization/32790] New: REG_N_SETS holds wrong value

[georgjohann at web dot de]

In ./gcc/regclass.c:reg_scan_mark_refs()

there is this source code:

    case SET:
      /* Count a set of the destination if it is a register.  */
      for (dest = SET_DEST (x);
           GET_CODE (dest) == SUBREG || GET_CODE (dest) == STRICT_LOW_PART
           || GET_CODE (dest) == ZERO_EXTEND;
           dest = XEXP (dest, 0))
        ;

This code counts the number of times a REG is changed (eventually used in
combine, reload, regrenumber, ...)

IMHO, the ZERO_EXTEND is a typo and should be a ZERO_EXTRACT, because (set
(zero_extract (reg foo bar)) are RTX that are actually generated in some
define_insn/define_expand insv (provided HAVE_insv) if the source deals with
bitfields.

As this code can already be seen in GCC 3.3.*, I guess this is not very
critical. But it leads to problems in a non-standard target (tricore) that uses
the information in REG_N_SETS().

Greets,

Georg-Johann Lay
georg.lay@hightec-rt.com


-- 
           Summary: REG_N_SETS holds wrong value
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: georgjohann at web dot de
 GCC build triplet: any
  GCC host triplet: any
GCC target triplet: any


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

[Bug rtl-optimization/32790] REG_N_SETS holds wrong value

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-07-17 10:22 -------
    56     kenner       /* Count a set of the destination if it is a register. 
*/
    56     kenner       for (dest = SET_DEST (x);
    56     kenner          GET_CODE (dest) == SUBREG || GET_CODE (dest) ==
STRICT_LOW_PART
    56     kenner          || GET_CODE (dest) == ZERO_EXTEND;
    56     kenner          dest = XEXP (dest, 0))
    56     kenner       ;

This comes from the begining of time :).
ZERO_EXTRACT has been there since the begining of time also:
    70     kenner /* Similar for unsigned bit-field.  */
    70     kenner DEF_RTL_EXPR(ZERO_EXTRACT, "zero_extract", "eee", 'b')


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |normal
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-17 10:22:51
               date|                            |
            Version|unknown                     |4.3.0


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

[Bug rtl-optimization/32790] REG_N_SETS holds wrong value

[georgjohann at web dot de]

------- Comment #2 from georgjohann at web dot de  2007-07-17 11:13 -------
(In reply to comment #1)
> 
> This comes from the begining of time :).
> ZERO_EXTRACT has been there since the begining of time also:
>     70     kenner DEF_RTL_EXPR(ZERO_EXTRACT, "zero_extract", "eee", 'b')
>

So what is the conclusion...?

At least the following backends implement "insv" as
  (define_*** "insv"
     [(set (zero_extract (match_operand 0 ...
with a predicate that allows registers:
i386, pa, sh, c4x, arm, vax, ia64, m68k, ip2k, ns32k, rs6000, h8300, mcore

Uses of REG_N_SETS(*) are spread all over the RTL passes and many of them rely
on REG_N_SETS(*) == 1 etc.

If such a condition holds but is incorrect because (set (zero_extract is
ignored that may lead to a bug in the output, e.g. due to a wrong replacement. 


-- 

georgjohann at web dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
            Version|4.3.0                       |unknown


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