[Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[Bug tree-optimization/62631] New: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

            Bug ID: 62631
           Summary: gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
              Host: sparc*-sun-solaris2.*
            Target: sparc*-sun-solaris2.*
             Build: sparc*-sun-solaris2.*

The new gcc.dg/tree-ssa/ivopts-lt-2.c test FAILs on 64-bit SPARC (only; 32-bit
is
ok):

FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI" 1
FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "p_[0-9]* <" 1

I'm attaching the ivopts dump.

  Rainer

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33427&action=edit
ivopts dump

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33428&action=edit
slp dump

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 33429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33429&action=edit
bb-slp-26.c.120t.slp1 dump

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker.cheng at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #4 from bin.cheng <amker.cheng at gmail dot com> ---
Hi Rainer,
This is caused by abnormal huge cost of function call `shiftadd_cost (true,
DImode, 2)'.  It returns 100+ cost, resulting in huge cost when representing
use 1 with cand 4:

use 1
  compare
  in statement if (i_12 <= 99)

  at position 
  type unsigned int
  base i_4(D) + 1
  step 1
  is a biv
  related candidates 

  i_4(D) is invariant (2), eliminable
  p_8 is invariant (1), eliminable

candidate 4 (important)
  original biv
  type int *
  base p_8
  step 4
  base object (void *) p_8

Use 1:
  cand    cost    compl.    depends on
  0    4    0     inv_expr:0
  1    4    0    
  4    23    0     inv_expr:1   <------huge cost.
  5    0    0
  6    0    0    
  8    4    1    

I worked out a patch fixing this from ivopt.  Because I am not firmiliar with
sparc ISA, could you please help me confirm that below fixed assembly is better
than the original version?

The orignal assembly:
f1:
    sllx    %o1, 2, %g1
    add    %o0, %g1, %o0
.LL2:
    st    %g0, [%o0]
    add    %o1, 1, %g1
    add    %o0, 4, %o0
    cmp    %g1, 99
    bleu,pt    %icc, .LL2
     srl    %g1, 0, %o1
    jmp    %o7+8
     nop
    .size    f1, .-f1

The fixed version assembly:
f1:
    .register    %g2, #scratch
    sllx    %o1, 2, %g1
    mov    99, %g2
    add    %o0, %g1, %o0
    sub    %g2, %o1, %o1
    srl    %o1, 0, %g1
    add    %g1, 1, %g1
    sllx    %g1, 2, %g1
    add    %o0, %g1, %g1
    st    %g0, [%o0]
.LL5:
    add    %o0, 4, %o0
    cmp    %o0, %g1
    blu,a,pt %xcc, .LL5
     st    %g0, [%o0]
    jmp    %o7+8
     nop
    .size    f1, .-f1

Though it has larger loop setup code, the loop itself is simplified.

If yes, I will send out the patch for review.

Thanks,
bin

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #5 from John David Anglin <danglin at gcc dot gnu.org> ---
Also seen on 32-bit hppa*-*-*.  64-bit is OK.

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

amker at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker at gcc dot gnu.org

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #0)
> The new gcc.dg/tree-ssa/ivopts-lt-2.c test FAILs on 64-bit SPARC (only;
> 32-bit is
> ok):
> 
> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI" 1
> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "p_[0-9]* <"
> 1
> 
> I'm attaching the ivopts dump.
> 
>   Rainer

Hi,
According to https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00345.html, could
you have a look whether the huge cost returned on sparc64 is as expected?

Thanks very much.

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #6 from amker at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #0)
>> The new gcc.dg/tree-ssa/ivopts-lt-2.c test FAILs on 64-bit SPARC (only;
>> 32-bit is
>> ok):
>> 
>> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI" 1
>> FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "p_[0-9]* <"
>> 1
>> 
>> I'm attaching the ivopts dump.
[...]
> According to https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00345.html, could
> you have a look whether the huge cost returned on sparc64 is as expected?

I think that's easiest for Eric to say.

    Rainer

[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
>> I think that's easiest for Eric to say.
>
> Not really, I guess you want to debug the function and replay the computation
> since the cost is synthetized and doesn't come directly from the back-end.

I've found what's going on:

* In expmed.c (init_expmed_one_mode), l.194

  set_shiftadd_cost (speed, mode, m, set_src_cost (all->shift_add, speed));

  with all->shift_add something like

(plus:QI (mult:QI (reg:QI 109 [0])
        (const_int 8 [0x8]))
    (reg:QI 109 [0]))

* For the mult part, rtx_code calls sparc_rtx_cost, which has

    case MULT:
      if (float_mode_p)
    *total = sparc_costs->float_mul;
      else if (! TARGET_HARD_MUL)
    *total = COSTS_N_INSNS (25);

  On SPARCv9/-m64, TARGET_HARD_MUL is false, so we get the 25*4 = 100 part,
  unlike v8, which explains why the test only fails for 64-bit.

    Rainer

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|ebotcazou at gcc dot gnu.org       |unassigned at gcc dot gnu.org

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I'm about to install a patch that changes the costs on SPARC 64-bit to:

Use 1:
  cand  cost    compl.  depends on
  0     4       0        inv_expr:0
  1     8       0       
  4     6       0        inv_expr:1
  5     0       0       
  6     0       0

but this doesn't change the outcome of the test. :-(

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Tue Feb  3 09:56:45 2015
New Revision: 220369

URL: https://gcc.gnu.org/viewcvs?rev=220369&root=gcc&view=rev
Log:
    PR target/62631
    * config/sparc/sparc.h (TARGET_HARD_MUL): Remove TARGET_V8PLUS.
    (TARGET_HARD_MUL32): Rewrite based on TARGET_HARD_MUL.
    * config/sparc/sparc.c (sparc_rtx_costs) <MULT>: Return costs based on
    int_mulX for integers in 64-bit mode if TARGET_HARD_MUL is not set.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sparc/sparc.c
    trunk/gcc/config/sparc/sparc.h

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #12)
> I'm about to install a patch that changes the costs on SPARC 64-bit to:
> 
> Use 1:
>   cand  cost    compl.  depends on
>   0     4       0        inv_expr:0
>   1     8       0       
>   4     6       0        inv_expr:1
>   5     0       0       
>   6     0       0
> 
> but this doesn't change the outcome of the test. :-(

I will have a look why it fails with refined cost.

Thanks,
bin

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #15 from amker at gcc dot gnu.org ---
(In reply to amker from comment #14)
> (In reply to Eric Botcazou from comment #12)
> > I'm about to install a patch that changes the costs on SPARC 64-bit to:
> > 
> > Use 1:
> >   cand  cost    compl.  depends on
> >   0     4       0        inv_expr:0
> >   1     8       0       
> >   4     6       0        inv_expr:1
> >   5     0       0       
> >   6     0       0
> > 
> > but this doesn't change the outcome of the test. :-(
> 
> I will have a look why it fails with refined cost.
> 
> Thanks,
> bin

The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4"  computed using
normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is computed
as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by
get_shiftadd_cost.

>From the assembly code, it seems the computation is expensive on sparc64, I may
skip the test for these architectures if no other solutions.

Thanks.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4"  computed
> using normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is
> computed as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by
> get_shiftadd_cost.

How do you get the first number exactly?  Note that the costs of shiftadd is
completely skewed (by a factor of 3) because expmed.c computes it as a multadd
instead of a shiftadd:

Breakpoint 2, init_expmed_one_mode (all=0x7fffffffd540, mode=QImode, speed=1)
    at /home/eric/svn/gcc/gcc/expmed.c:219
219           set_shiftadd_cost (speed, mode, m, set_src_cost (all->shift_add,
speed));
(gdb) p debug_rtx(all->shift_add)
(plus:QI (mult:QI (reg:QI 109 [0])
        (const_int 2 [0x2]))
    (reg:QI 109 [0]))

but this should ensure that the costs are roughly the same for the expressions.

> From the assembly code, it seems the computation is expensive on sparc64, I
> may skip the test for these architectures if no other solutions.

The hitch is that the code generated for 32-bit SPARC (where the test passes)
is the optimal one and is also valid for 64-bit SPARC.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This looks a generic problem in get_shiftadd_cost to me, it ought to mimic the
algorithms in expmed.c, something like:

@@ -3597,22 +3597,26 @@ get_shiftadd_cost (tree expr, machine_mo
   tree multop = TREE_OPERAND (mult, 0);
   int m = exact_log2 (int_cst_value (cst));
   int maxm = MIN (BITS_PER_WORD, GET_MODE_BITSIZE (mode));
-  int sa_cost;
-  bool equal_p = false;
+  int as_cost, sa_cost;
+  bool mult_in_op1;

   if (!(m >= 0 && m < maxm))
     return false;

-  if (operand_equal_p (op1, mult, 0))
-    equal_p = true;
+  mult_in_op1 = operand_equal_p (op1, mult, 0);

+  as_cost = add_cost (speed, mode) + shift_cost (speed, mode, m);
+
+  /* If the target has a cheap shift-and-add or shift-and-sub instruction,
+     use that in preference to a shift insn followed by an add insn.  */
   sa_cost = (TREE_CODE (expr) != MINUS_EXPR
              ? shiftadd_cost (speed, mode, m)
-             : (equal_p
+             : (mult_in_op1
                 ? shiftsub1_cost (speed, mode, m)
                 : shiftsub0_cost (speed, mode, m)));
-  res = new_cost (sa_cost, 0);
-  res = add_costs (res, equal_p ? cost0 : cost1);
+
+  res = new_cost (MIN (as_cost, sa_cost), 0);
+  res = add_costs (res, mult_in_op1 ? cost0 : cost1);

   STRIP_NOPS (multop);
   if (!is_gimple_val (multop))

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #18 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #16)
> > The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4"  computed
> > using normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is
> > computed as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by
> > get_shiftadd_cost.
> 
> How do you get the first number exactly?  Note that the costs of shiftadd is
In force_expr_to_var_cost, it calculates the cost in normal way before
returning get_shiftadd_cost.

> completely skewed (by a factor of 3) because expmed.c computes it as a
> multadd instead of a shiftadd:
> 
> Breakpoint 2, init_expmed_one_mode (all=0x7fffffffd540, mode=QImode, speed=1)
>     at /home/eric/svn/gcc/gcc/expmed.c:219
> 219           set_shiftadd_cost (speed, mode, m, set_src_cost
> (all->shift_add, speed));
> (gdb) p debug_rtx(all->shift_add)
> (plus:QI (mult:QI (reg:QI 109 [0])
>         (const_int 2 [0x2]))
>     (reg:QI 109 [0]))
> 
> but this should ensure that the costs are roughly the same for the
> expressions.
> 
> > From the assembly code, it seems the computation is expensive on sparc64, I
> > may skip the test for these architectures if no other solutions.
> 
> The hitch is that the code generated for 32-bit SPARC (where the test
> passes) is the optimal one and is also valid for 64-bit SPARC.

The assembly is as below on sparc64:
f1:
    .register    %g2, #scratch
    sllx    %o1, 2, %g1
    mov    99, %g2
    add    %o0, %g1, %o0
    sub    %g2, %o1, %o1
    srl    %o1, 0, %g1
    add    %g1, 1, %g1
    sllx    %g1, 2, %g1
    add    %o0, %g1, %g1
    st    %g0, [%o0]
.LL5:
    add    %o0, 4, %o0
    cmp    %o0, %g1
    blu,a,pt %xcc, .LL5
     st    %g0, [%o0]
    jmp    %o7+8
     nop

While more efficient on sparc32, as below:

f1:
    sll    %o1, 2, %g1
    sub    %g0, %o1, %o1
    add    %o0, %g1, %o0
    sll    %o1, 2, %o1
    add    %o1, 400, %g1
    add    %o0, %g1, %g1
    st    %g0, [%o0]
.LL5:
    add    %o0, 4, %o0
    cmp    %o0, %g1
    blu,a    .LL5
     st    %g0, [%o0]
    jmp    %o7+8
     nop

The bloated pre-header happens on all 64 bits platforms.  At least I can
confrim that on aarch64 it is much worse than arm.  The difference is, it is
fixed in later compilation passes on aarch64 (I didn't investigate why or how).

I think the cause is, on 64bits platforms, expression
  "p + ((sizetype)(99 - i_6(D)) + 1) * 4" != "p + ((sizetype)(100-i_6(D)) * 4"
like on 32 platforms because sizetype has larger precision.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The assembly is as below on sparc64:
> f1:
> 	.register	%g2, #scratch
> 	sllx	%o1, 2, %g1
> 	mov	99, %g2
> 	add	%o0, %g1, %o0
> 	sub	%g2, %o1, %o1
> 	srl	%o1, 0, %g1
> 	add	%g1, 1, %g1
> 	sllx	%g1, 2, %g1
> 	add	%o0, %g1, %g1
> 	st	%g0, [%o0]
> .LL5:
> 	add	%o0, 4, %o0
> 	cmp	%o0, %g1
> 	blu,a,pt %xcc, .LL5
> 	 st	%g0, [%o0]
> 	jmp	%o7+8
> 	 nop

How did you configure the compiler?  We're talking about 64-bit SPARC/Solaris
and here's the code actually generated for the time being:

        .type   f1, #function
        .proc   020
f1:
        sllx    %o1, 2, %g1
        add     %o0, %g1, %o0
.LL2:
        st      %g0, [%o0]
        add     %o1, 1, %g1
        add     %o0, 4, %o0
        cmp     %g1, 99
        bleu,pt %icc, .LL2
         srl    %g1, 0, %o1
        jmp     %o7+8
         nop

so it is still suboptimal, hence my generic fix.
>From gcc-bugs-return-476212-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 06 07:22:17 2015
Return-Path: <gcc-bugs-return-476212-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6786 invoked by alias); 6 Feb 2015 07:22:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6728 invoked by uid 48); 6 Feb 2015 07:22:13 -0000
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
Date: Fri, 06 Feb 2015 07:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62631-4-eNx22NbpSz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62631-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62631-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00545.txt.bz2
Content-length: 1251

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #20 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #19)
> > The assembly is as below on sparc64:
> > f1:
> > 	.register	%g2, #scratch
> > 	sllx	%o1, 2, %g1
> > 	mov	99, %g2
> > 	add	%o0, %g1, %o0
> > 	sub	%g2, %o1, %o1
> > 	srl	%o1, 0, %g1
> > 	add	%g1, 1, %g1
> > 	sllx	%g1, 2, %g1
> > 	add	%o0, %g1, %g1
> > 	st	%g0, [%o0]
> > .LL5:
> > 	add	%o0, 4, %o0
> > 	cmp	%o0, %g1
> > 	blu,a,pt %xcc, .LL5
> > 	 st	%g0, [%o0]
> > 	jmp	%o7+8
> > 	 nop
> 
> How did you configure the compiler?  We're talking about 64-bit
> SPARC/Solaris and here's the code actually generated for the time being:
> 
>         .type   f1, #function
>         .proc   020
> f1:
>         sllx    %o1, 2, %g1
>         add     %o0, %g1, %o0
> .LL2:
>         st      %g0, [%o0]
>         add     %o1, 1, %g1
>         add     %o0, 4, %o0
>         cmp     %g1, 99
>         bleu,pt %icc, .LL2
>          srl    %g1, 0, %o1
>         jmp     %o7+8
>          nop
> 
> so it is still suboptimal, hence my generic fix.
Ouch, my bad.  That code is generated because I forced gcc to do the iv
replacement by decreasing the cost.  The trunk generates assembly just like
yours.

Thanks.
>From gcc-bugs-return-476213-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 06 08:12:06 2015
Return-Path: <gcc-bugs-return-476213-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3760 invoked by alias); 6 Feb 2015 08:12:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3693 invoked by uid 48); 6 Feb 2015 08:12:02 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/17982] stop calling assemble_external before final assembly output time
Date: Fri, 06 Feb 2015 08:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.0.0
X-Bugzilla-Keywords: FIXME
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-17982-4-Y9dzeBGGnv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-17982-4@http.gcc.gnu.org/bugzilla/>
References: <bug-17982-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00546.txt.bz2
Content-length: 507

https://gcc.gnu.org/bugzilla/show_bug.cgi?id\x17982

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |FIXED

--- Comment #36 from Jeffrey A. Law <law at redhat dot com> ---
This was fixed in 2012.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Fri Feb  6 11:17:46 2015
New Revision: 220473

URL: https://gcc.gnu.org/viewcvs?rev=220473&root=gcc&view=rev
Log:
    PR target/62631
    * tree-ssa-loop-ivopts.c (get_shiftadd_cost): Use the mininum of costs
    of shift-add and (add + shift) operations.  Rename local variable.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-ivopts.c

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #22 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
OK, this is fixed on the SPARC, but not on the PA where we still have 2 IVs.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #23 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> OK, this is fixed on the SPARC, but not on the PA where we still have 2 IVs.

Correction: we have only one IV on the PA, but it's 'i' and not 'p'.

Dave, is the generated code optimimal on the PA or should the compiler use 'p'?

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #24 from dave.anglin at bell dot net ---
On 2015-02-06 6:33 AM, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
>
> --- Comment #23 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
>> OK, this is fixed on the SPARC, but not on the PA where we still have 2 IVs.
> Correction: we have only one IV on the PA, but it's 'i' and not 'p'.
>
> Dave, is the generated code optimimal on the PA or should the compiler use 'p'?
>
I'll take a look on the weekend.

Dave

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #25 from dave.anglin at bell dot net ---
On 2015-02-06, at 6:33 AM, ebotcazou at gcc dot gnu.org wrote:

> Correction: we have only one IV on the PA, but it's 'i' and not 'p'.
> 
> Dave, is the generated code optimimal on the PA or should the compiler use 'p'?

The generated code on PA looks optimal to me:

        zdep %r25,29,30,%r28
        b .L2
        ldi 99,%r19
.L6:
        zdep %r25,29,30,%r28
.L2:
        addl %r26,%r28,%r28
        ldo 1(%r25),%r25
        comb,>>= %r19,%r25,.L6
        stw %r0,0(%r28)
        bv,n %r0(%r2)

Dave
--
John David Anglin    dave.anglin@bell.net

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The generated code on PA looks optimal to me:
> 
>         zdep %r25,29,30,%r28
>         b .L2
>         ldi 99,%r19
> .L6:
>         zdep %r25,29,30,%r28
> .L2:
>         addl %r26,%r28,%r28
>         ldo 1(%r25),%r25
>         comb,>>= %r19,%r25,.L6
>         stw %r0,0(%r28)
>         bv,n %r0(%r2)

For most other architectures the BIV (%r25) is eliminated to the GIV (%r28) so
you only have one additive operation in the loop.  This happens for 64-bit PA:

.L5:
        ldo 4(%r26),%r26
        cmpb,*>>,n %r28,%r26,.L5
        stw %r0,0(%r26)
        bve,n (%r2)

Why couldn't such a code be generated for 32-bit PA too?

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #27 from dave.anglin at bell dot net ---
On 2015-02-07, at 5:24 PM, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631
> 
> --- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
>> The generated code on PA looks optimal to me:
>> 
>>        zdep %r25,29,30,%r28
>>        b .L2
>>        ldi 99,%r19
>> .L6:
>>        zdep %r25,29,30,%r28
>> .L2:
>>        addl %r26,%r28,%r28
>>        ldo 1(%r25),%r25
>>        comb,>>= %r19,%r25,.L6
>>        stw %r0,0(%r28)
>>        bv,n %r0(%r2)
> 
> For most other architectures the BIV (%r25) is eliminated to the GIV (%r28) so
> you only have one additive operation in the loop.  This happens for 64-bit PA:
> 
> .L5:
>        ldo 4(%r26),%r26
>        cmpb,*>>,n %r28,%r26,.L5
>        stw %r0,0(%r26)
>        bve,n (%r2)
> 
> Why couldn't such a code be generated for 32-bit PA too?


There is no reason that I can see.

Dave
--
John David Anglin    dave.anglin@bell.net

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #28 from amker at gcc dot gnu.org ---
On hppa 32, the two iv uses are:
use 0
  address
  in statement *p_1 = 0;

  at position *p_1
  type int *
  base p_7
  step 4
  base object (void *) p_7
  related candidates 
use 1
  compare
  in statement if (i_11 <= 99)

  at position 
  type unsigned int
  base i_4(D) + 1
  step 1
  is a biv
  related candidates 
And the BIV/GIV candidates are:
candidate 3 (important)
  original biv
  type int *
  base p_7
  step 4
  base object (void *) p_7
candidate 4 (important)
  ...
candidate 5 (important)
  original biv
  type unsigned int
  base i_4(D)
  step 1

The costs table are:

Candidate costs:
  cand    cost
  0    5
  1    5
  2    5
  3    4
  4    5
  5    4
  6    5
  7    5
Use 0:
  cand    cost    compl.    depends on
  0    1    2    1
  1    1    0    
  2    1    1    1
  3    1    0    
  4    3    2     inv_expr:0
  5    3    2     inv_expr:0
  6    1    1    
  7    19    3     inv_expr:1

Use 1:
  cand    cost    compl.    depends on
  0    4    0     inv_expr:2
  3    3    0     inv_expr:3
  4    0    0    
  5    0    0    
  7    4    1    

It seems cand3 and cand5 have same level cost, but GCC chooses candidate 5 as
below:
Initial set of candidates:
  cost: 9 (complexity 2)
  cand_cost: 4
  cand_use_cost: 3 (complexity 2)
  candidates: 5
   use:0 --> iv_cand:5, cost=(3,2)
   use:1 --> iv_cand:5, cost=(0,0)

While on other targets, cand 3 is selected.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #29 from amker at gcc dot gnu.org ---
(In reply to amker from comment #28)
> On hppa 32, the two iv uses are:
> use 0
>   address
>   in statement *p_1 = 0;
> 
>   at position *p_1
>   type int *
>   base p_7
>   step 4
>   base object (void *) p_7
>   related candidates 
> use 1
>   compare
>   in statement if (i_11 <= 99)
> 
>   at position 
>   type unsigned int
>   base i_4(D) + 1
>   step 1
>   is a biv
>   related candidates 
> And the BIV/GIV candidates are:
> candidate 3 (important)
>   original biv
>   type int *
>   base p_7
>   step 4
>   base object (void *) p_7
> candidate 4 (important)
>   ...
> candidate 5 (important)
>   original biv
>   type unsigned int
>   base i_4(D)
>   step 1
> 
> The costs table are:
> 
> Candidate costs:
>   cand	cost
>   0	5
>   1	5
>   2	5
>   3	4
>   4	5
>   5	4
>   6	5
>   7	5
> Use 0:
>   cand	cost	compl.	depends on
>   0	1	2	1
>   1	1	0	
>   2	1	1	1
>   3	1	0	
>   4	3	2	 inv_expr:0
>   5	3	2	 inv_expr:0
>   6	1	1	
>   7	19	3	 inv_expr:1
> 
> Use 1:
>   cand	cost	compl.	depends on
>   0	4	0	 inv_expr:2
>   3	3	0	 inv_expr:3
>   4	0	0	
>   5	0	0	
>   7	4	1	
> 
> It seems cand3 and cand5 have same level cost, but GCC chooses candidate 5

Ah, candidate 5 is considered cheaper according to the cost table.

> as below:
> Initial set of candidates:
>   cost: 9 (complexity 2)
>   cand_cost: 4
>   cand_use_cost: 3 (complexity 2)
>   candidates: 5
>    use:0 --> iv_cand:5, cost=(3,2)
>    use:1 --> iv_cand:5, cost=(0,0)
> 
> While on other targets, cand 3 is selected.
>From gcc-bugs-return-476361-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 08 14:11:50 2015
Return-Path: <gcc-bugs-return-476361-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25400 invoked by alias); 8 Feb 2015 14:11:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25346 invoked by uid 48); 8 Feb 2015 14:11:46 -0000
From: "hp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
Date: Sun, 08 Feb 2015 14:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hp at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64467-4-Jf8QWgqXKb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64467-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64467-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00694.txt.bz2
Content-length: 472

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd467

--- Comment #9 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
To wit, at r220506  still see:
assertion "!t.isctype('\n', t.lookup_classname(blank,
blank+sizeof(blank)/sizeof(blank[0])-1))" failed: file
"/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc",
line 61, function: void test01()
program stopped with signal 6 (Aborted).

Maybe the newlib preprocessor symbol isn't universal?

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #30 from dave.anglin at bell dot net ---
On 2015-02-08, at 9:09 AM, amker at gcc dot gnu.org wrote:

> Ah, candidate 5 is considered cheaper according to the cost table.

Is this a problem with insn costs, or a problem in the estimation of the total
cost
for each candidate?

Dave
--
John David Anglin    dave.anglin@bell.net

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #31 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The test also fails on PowerPC, the 2 IVs are kept by ivopts.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #32 from amker at gcc dot gnu.org ---
(In reply to dave.anglin from comment #30)
> On 2015-02-08, at 9:09 AM, amker at gcc dot gnu.org wrote:
> 
> > Ah, candidate 5 is considered cheaper according to the cost table.
> 
> Is this a problem with insn costs, or a problem in the estimation of the
> total cost
> for each candidate?
The total cost I think.  Cost in IVOPT is tricky and inaccurate since 1) it
needs to estimate cost of RTL on gimple IR; 2) The rtx expression cost is
computed together with address expression cost, which doesn't happen in other
part of GCC.  
I can try to make the case less vulnerable for now.  Should we consider this as
a missed optimization since GCC never did the optimization for the case before
(and still not for mentioned targets)?

Thanks,
bin
> 
> Dave
> --
> John David Anglin	dave.anglin@bell.net
>From gcc-bugs-return-476419-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 05:31:18 2015
Return-Path: <gcc-bugs-return-476419-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15224 invoked by alias); 9 Feb 2015 05:31:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15166 invoked by uid 48); 9 Feb 2015 05:31:14 -0000
From: "hp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c
Date: Mon, 09 Feb 2015 05:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hp at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61548-4-MnY9GUXadS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61548-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00752.txt.bz2
Content-length: 283

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida548

--- Comment #28 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #27)
> Does the following patch fix the problem?

Yes! Full regtest is underway but this particular FAIL is fixed.  Thanks.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

--- Comment #33 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #31)
> The test also fails on PowerPC, the 2 IVs are kept by ivopts.

On targets like ARM, the biv(i) is eliminated with biv(p).  PowerPC is
different, it only supports pre-increment addressing mode, so GIV(p-4) is
selected for the array reference.  GCC now is conservative in iv elimination by
only considering original BIV and nowrapping IVs.  Related code is in function
iv_elimination_compare_lt as below:

  /* We need to know that the candidate induction variable does not overflow.
     While more complex analysis may be used to prove this, for now just
     check that the variable appears in the original program and that it
     is computed in a type that guarantees no overflows.  */
  cand_type = TREE_TYPE (cand->iv->base);
  if (cand->pos != IP_ORIGINAL || !nowrap_type_p (cand_type))
    return false;

Another place we can improve.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.5                         |---