From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18669 invoked by alias); 17 Jul 2007 10:00:05 -0000 Received: (qmail 18500 invoked by uid 48); 17 Jul 2007 09:59:53 -0000 Date: Tue, 17 Jul 2007 10:00:00 -0000 Subject: [Bug rtl-optimization/32790] New: REG_N_SETS holds wrong value X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "georgjohann at web dot de" 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 X-SW-Source: 2007-07/txt/msg01835.txt.bz2 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