From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-19934-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17435 invoked by alias); 27 Jun 2002 22:56:03 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 17401 invoked by uid 71); 27 Jun 2002 22:56:02 -0000
Resent-Date: 27 Jun 2002 22:56:02 -0000
Resent-Message-ID: <20020627225602.17400.qmail@sources.redhat.com>
Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer)
Resent-To: nobody@gcc.gnu.org
Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
  kevin.hendricks@sympatico.ca
Resent-Reply-To: gcc-gnats@gcc.gnu.org, Franz.Sirl-kernel@lauterbach.com
Received: (qmail 16962 invoked by uid 61); 27 Jun 2002 22:55:16 -0000
Message-Id: <20020627225516.16958.qmail@sources.redhat.com>
Date: Thu, 27 Jun 2002 16:06:00 -0000
From: Franz.Sirl-kernel@lauterbach.com
Reply-To: Franz.Sirl-kernel@lauterbach.com
To: gcc-gnats@gcc.gnu.org
Cc: kevin.hendricks@sympatico.ca
X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31)
X-GNATS-Notify: kevin.hendricks@sympatico.ca
Subject: optimization/7147: ifcvt.c problem (regression)
X-SW-Source: 2002-06/txt/msg00675.txt.bz2
List-Id: <gcc-prs.sourceware.org>


>Number:         7147
>Category:       optimization
>Synopsis:       ifcvt.c problem (regression)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 27 15:56:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Franz.Sirl-kernel@lauterbach.com
>Release:        current gcc-3_1-branch
>Organization:
>Environment:
powerpc-linux-gnu
>Description:
This testcase is derived from a reported c++ mozilla miscompilation. It fails at -O and works fine with -O -fexpensive-optimizations.

My guess so far is that ifcvt.c is confused by the multiple SETs of pseudo 117 (from .rtl):

(insn 27 25 28 (set (reg/v:SI 117)
        (reg:SI 3 r3)) -1 (nil)
    (nil))

(insn 28 27 29 (set (reg:CC 120)
        (compare:CC (reg/v:SI 117)
            (const_int 0 [0x0]))) -1 (nil)
    (nil))

(insn 29 28 31 (set (reg/v:SI 117)
        (eq:SI (reg:CC 120)
            (const_int 0 [0x0]))) -1 (nil)
    (nil))

(jump_insn 31 29 32 (set (pc)
        (label_ref 34)) -1 (nil)
    (nil))

(barrier 32 31 33)

(note 33 32 34 0x30084680 NOTE_INSN_BLOCK_END)

(code_label 34 33 35 3 ("lab1") "" [0 uses])

(note 35 34 37 0x300846c0 NOTE_INSN_BLOCK_END)

(insn 37 35 38 (set (reg:CC 121)
        (compare:CC (reg/v:SI 117)
            (const_int 0 [0x0]))) -1 (nil)
    (nil))

(jump_insn 38 37 40 (set (pc)
        (if_then_else (eq (reg:CC 121)
                (const_int 0 [0x0]))
            (label_ref 48)
            (pc))) -1 (nil)
    (nil))


Somehow the inversion via insn 28 and 29 isn't accounted for.

This is a regression from gcc-2.95.4.
>How-To-Repeat:
Compile with -O on powerpc-linux-gnu:

extern void abort (void);
extern void exit (int);

int sub1 (int val)
{
  return val;
}

int testcond (int val)
{
  int flag1;

    {
      int t1 = val;
        {
          int t2 = t1;
            {
              flag1 = sub1 (t2) ==0;
              goto lab1;
            };
        }
      lab1: ;
    }

  if (flag1 != 0)
    return 0x4d0000;
  else
    return 0;
}

int main (void)
{
  if (testcond (1))
    abort ();
  exit (0);
}

>Fix:
hacking stmt.c like that fixes the bug:

int
preserve_subexpressions_p ()
{
  rtx insn;

  if (flag_expensive_optimizations)
    return 1;

  if (optimize == 0 || cfun == 0 || cfun->stmt == 0 || loop_stack == 0)
    return 0;
+  // make ifcvt happy
+  return 1;
+ 
  insn = get_last_insn_anywhere ();

  return (insn
          && (INSN_UID (insn) - INSN_UID (loop_stack->data.loop.start_label)
              < n_non_fixed_regs * 3));

}
>Release-Note:
>Audit-Trail:
>Unformatted: