[Bug rtl-optimization/97092] New: [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Bug rtl-optimization/97092] New: [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[acoplan at gcc dot gnu.org]

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

            Bug ID: 97092
           Summary: [10/11 Regression] aarch64, SVE: ICE in ira-color.c
                    since r10-4752-g2d56600c
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following testcase:

void g(void);
long a;
signed char b(int c, int d) { return c + d; }
void e(void) {
  int f;
  for (; (long)e < 4;) {
    f = 0;
    for (; f < 10; f++);
    g();
    a = -4;
    for (; a; a = b(a, 1));
  }
}

AArch64 GCC ICEs in IRA when compiling with -O1 -ftree-vectorize
-march=armv8.2-a+sve:

$ aarch64-none-elf-gcc -O1 -ftree-vectorize -march=armv8.2-a+sve test.c -c -S
during RTL pass: ira
test.c: In function 'e':
test.c:13:1: internal compiler error: in paradoxical_subreg_p, at rtl.h:3170
   13 | }
      | ^
0xb56ebb paradoxical_subreg_p(machine_mode, machine_mode)
        /home/alecop01/toolchain/src/gcc/gcc/rtl.h:3170
0xb56ebb narrower_subreg_mode(machine_mode, machine_mode)
        /home/alecop01/toolchain/src/gcc/gcc/rtl.h:3200
0xb56ebb update_costs_from_allocno
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:1410
0xb574ed update_costs_from_copies
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:1478
0xb585b8 assign_hard_reg
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:1969
0xb61321 pop_allocnos_from_stack
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:2707
0xb61321 color_allocnos
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:3251
0xb61321 color_pass
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:3363
0xb4ad3f ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
        /home/alecop01/toolchain/src/gcc/gcc/ira-build.c:1778
0xb5d464 do_coloring
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:3514
0xb5d464 color
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:4885
0xb5d464 ira_color()
        /home/alecop01/toolchain/src/gcc/gcc/ira-color.c:5014
0xb4339f ira
        /home/alecop01/toolchain/src/gcc/gcc/ira.c:5368
0xb4339f execute
        /home/alecop01/toolchain/src/gcc/gcc/ira.c:5668
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

While this does seem to have been introduced before GCC 11, I haven't been able
to reproduce this on 10.x builds. More investigation needed here.

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.3

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[akrl at gcc dot gnu.org]

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

--- Comment #1 from akrl at gcc dot gnu.org ---
Hi all,

I can't reproduce this on current master (76a1719f0ff), I guess has been 
fixed in the meanwhile?

  Andrea

Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Andrea Corallo]

"akrl at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #1 from akrl at gcc dot gnu.org ---
> Hi all,
>
> I can't reproduce this on current master (76a1719f0ff), I guess has been 
> fixed in the meanwhile?

As not said I swapped two reproducers.  I *can* reproduce the issue on
current master.

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com]

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

--- Comment #2 from Andrea Corallo <andrea.corallo at arm dot com> ---
"akrl at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #1 from akrl at gcc dot gnu.org ---
> Hi all,
>
> I can't reproduce this on current master (76a1719f0ff), I guess has been 
> fixed in the meanwhile?

As not said I swapped two reproducers.  I *can* reproduce the issue on
current master.

  Andrea

Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Andrea Corallo]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

What is going on is that in 'update_costs_from_allocno' we try to
identify the smallest mode using narrower_subreg_mode to then update the
costs.

The two modes involved here are E_DImode and E_VNx2QImode, cause these
are not ordered we ICE in 'paradoxical_subreg_p'.

Now I don't know if the strategy we want is:

- In 'update_costs_from_allocno' when modes are not ordered instead of
  calling 'narrower_subreg_mode' just keep the current one.

- Always select the cheapest mode in terms of cost.

The attached I'm testing implements the second.

  Andrea


[-- Attachment #2: PR97092.patch --]
[-- Type: text/plain, Size: 2347 bytes --]

>From 03da7bb5c7ad8ab6c25631de5ee1f7b70ea46229 Mon Sep 17 00:00:00 2001
From: Andrea Corallo <andrea.corallo@arm.com>
Date: Tue, 8 Dec 2020 23:17:26 +0100
Subject: [PATCH] Fix ICE in ira-color

2020-12-08  Andrea Corallo  <andrea.corallo@arm.com>

	* ira-color.c (update_costs_from_allocno): Pick the cheapest mode
	instead of the smaller one.
---
 gcc/ira-color.c | 34 ++++++++++++++++++++++------------
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index d3f8e23faff..13a3548018a 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -1400,19 +1400,29 @@ update_costs_from_allocno (ira_allocno_t allocno, int hard_regno,
 	      || ALLOCNO_ASSIGNED_P (another_allocno))
 	    continue;
 
-	  /* If we have different modes use the smallest one.  It is
-	     a sub-register move.  It is hard to predict what LRA
-	     will reload (the pseudo or its sub-register) but LRA
-	     will try to minimize the data movement.  Also for some
-	     register classes bigger modes might be invalid,
-	     e.g. DImode for AREG on x86.  For such cases the
-	     register move cost will be maximal.  */
-	  mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
+	  /* If we have different modes use the cheapest one.  It is a
+	     sub-register move.  It is hard to predict what LRA will
+	     reload (the pseudo or its sub-register) but LRA will try
+	     to minimize the data movement.  Also for some register
+	     classes bigger modes might be invalid, e.g. DImode for
+	     AREG on x86.  For such cases the register move cost will
+	     be maximal.  */
+	  machine_mode mode2 = ALLOCNO_MODE (cp->second);
 	  ira_init_register_move_cost_if_necessary (mode);
-	  
-	  cost = (cp->second == allocno
-		  ? ira_register_move_cost[mode][rclass][aclass]
-		  : ira_register_move_cost[mode][aclass][rclass]);
+	  ira_init_register_move_cost_if_necessary (mode2);
+	  int cost1, cost2;
+	  if (cp->second == allocno)
+	    {
+	      cost1 = ira_register_move_cost[mode][rclass][aclass];
+	      cost2 = ira_register_move_cost[mode2][rclass][aclass];
+	    }
+	  else
+	    {
+	      cost1 = ira_register_move_cost[mode][aclass][rclass];
+	      cost2 = ira_register_move_cost[mode2][aclass][rclass];
+	    }
+	  cost = MIN (cost1, cost2);
+
 	  if (decr_p)
 	    cost = -cost;
 
-- 
2.20.1

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com]

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

--- Comment #3 from Andrea Corallo <andrea.corallo at arm dot com> ---
What is going on is that in 'update_costs_from_allocno' we try to
identify the smallest mode using narrower_subreg_mode to then update the
costs.

The two modes involved here are E_DImode and E_VNx2QImode, cause these
are not ordered we ICE in 'paradoxical_subreg_p'.

Now I don't know if the strategy we want is:

- In 'update_costs_from_allocno' when modes are not ordered instead of
  calling 'narrower_subreg_mode' just keep the current one.

- Always select the cheapest mode in terms of cost.

The attached I'm testing implements the second.

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Andrea Corallo from comment #3)
> Created attachment 49710 [details]
> PR97092.patch
> 
> What is going on is that in 'update_costs_from_allocno' we try to
> identify the smallest mode using narrower_subreg_mode to then update the
> costs.
> 
> The two modes involved here are E_DImode and E_VNx2QImode, cause these
> are not ordered we ICE in 'paradoxical_subreg_p'.
> 
> Now I don't know if the strategy we want is:
> 
> - In 'update_costs_from_allocno' when modes are not ordered instead of
>   calling 'narrower_subreg_mode' just keep the current one.
> 
> - Always select the cheapest mode in terms of cost.
> 
> The attached I'm testing implements the second.
I think instead we should consider recomputing “mode” in each
iteration of the loop, rather than carry over the result of
previous iterations.  I.e. use:

    mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
                                 ALLOCNO_MODE (cp->second));

instead of:

    mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));

Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
was a loop invariant, so it made sense to set it outside
the loop.  I think the intention of that patch was to use
the smaller of the two modes involved in the copy, and carrying
the result over to future copies might have been unintentional.

The difficulty with carrying the mode over to later copies
is that the costs then become dependent on the order of
the copies, whereas I'm not sure the order of the copies
is significant.

Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Andrea Corallo]

"rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to Andrea Corallo from comment #3)
>> Created attachment 49710 [details]
>> PR97092.patch
>> 
>> What is going on is that in 'update_costs_from_allocno' we try to
>> identify the smallest mode using narrower_subreg_mode to then update the
>> costs.
>> 
>> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> are not ordered we ICE in 'paradoxical_subreg_p'.
>> 
>> Now I don't know if the strategy we want is:
>> 
>> - In 'update_costs_from_allocno' when modes are not ordered instead of
>>   calling 'narrower_subreg_mode' just keep the current one.
>> 
>> - Always select the cheapest mode in terms of cost.
>> 
>> The attached I'm testing implements the second.

Hi Richard,

thanks for commenting.

> I think instead we should consider recomputing “mode” in each
> iteration of the loop, rather than carry over the result of
> previous iterations.  I.e. use:
>
>     mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>                                  ALLOCNO_MODE (cp->second));

Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
(cp->second) always satisfying 'ordered_p'?  In case not I think we
can't use 'narrower_subreg_mode'.

I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.

> instead of:
>
>     mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
>
> Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
> was a loop invariant, so it made sense to set it outside
> the loop.  I think the intention of that patch was to use
> the smaller of the two modes involved in the copy, and carrying
> the result over to future copies might have been unintentional.
>
> The difficulty with carrying the mode over to later copies
> is that the costs then become dependent on the order of
> the copies, whereas I'm not sure the order of the copies
> is significant.

I see

Thanks!

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com]

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

--- Comment #5 from Andrea Corallo <andrea.corallo at arm dot com> ---
"rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to Andrea Corallo from comment #3)
>> Created attachment 49710 [details]
>> PR97092.patch
>> 
>> What is going on is that in 'update_costs_from_allocno' we try to
>> identify the smallest mode using narrower_subreg_mode to then update the
>> costs.
>> 
>> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> are not ordered we ICE in 'paradoxical_subreg_p'.
>> 
>> Now I don't know if the strategy we want is:
>> 
>> - In 'update_costs_from_allocno' when modes are not ordered instead of
>>   calling 'narrower_subreg_mode' just keep the current one.
>> 
>> - Always select the cheapest mode in terms of cost.
>> 
>> The attached I'm testing implements the second.

Hi Richard,

thanks for commenting.

> I think instead we should consider recomputing “mode” in each
> iteration of the loop, rather than carry over the result of
> previous iterations.  I.e. use:
>
>     mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>                                  ALLOCNO_MODE (cp->second));

Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
(cp->second) always satisfying 'ordered_p'?  In case not I think we
can't use 'narrower_subreg_mode'.

I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.

> instead of:
>
>     mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
>
> Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
> was a loop invariant, so it made sense to set it outside
> the loop.  I think the intention of that patch was to use
> the smaller of the two modes involved in the copy, and carrying
> the result over to future copies might have been unintentional.
>
> The difficulty with carrying the mode over to later copies
> is that the costs then become dependent on the order of
> the copies, whereas I'm not sure the order of the copies
> is significant.

I see

Thanks!

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Andrea Corallo from comment #5)
> "rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
> writes:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
> >
> > --- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> > (In reply to Andrea Corallo from comment #3)
> >> Created attachment 49710 [details]
> >> PR97092.patch
> >> 
> >> What is going on is that in 'update_costs_from_allocno' we try to
> >> identify the smallest mode using narrower_subreg_mode to then update the
> >> costs.
> >> 
> >> The two modes involved here are E_DImode and E_VNx2QImode, cause these
> >> are not ordered we ICE in 'paradoxical_subreg_p'.
> >> 
> >> Now I don't know if the strategy we want is:
> >> 
> >> - In 'update_costs_from_allocno' when modes are not ordered instead of
> >>   calling 'narrower_subreg_mode' just keep the current one.
> >> 
> >> - Always select the cheapest mode in terms of cost.
> >> 
> >> The attached I'm testing implements the second.
> 
> Hi Richard,
> 
> thanks for commenting.
> 
> > I think instead we should consider recomputing “mode” in each
> > iteration of the loop, rather than carry over the result of
> > previous iterations.  I.e. use:
> >
> >     mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
> >                                  ALLOCNO_MODE (cp->second));
> 
> Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
> (cp->second) always satisfying 'ordered_p'?
Yeah, I think so.  If the modes aren't ordered then we shouldn't
create a copy between them.

> I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.
I think the difficulty is that for the x86 situation described in
the comment, the cost for the wider mode might not be meaningful.
It might be dangerous to rely on it having a larger value than
the narrower (meaningful) mode.

Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Andrea Corallo]

"rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to Andrea Corallo from comment #5)
>> "rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
>> writes:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>> >
>> > --- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
>> > (In reply to Andrea Corallo from comment #3)
>> >> Created attachment 49710 [details]
>> >> PR97092.patch
>> >> 
>> >> What is going on is that in 'update_costs_from_allocno' we try to
>> >> identify the smallest mode using narrower_subreg_mode to then update the
>> >> costs.
>> >> 
>> >> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> >> are not ordered we ICE in 'paradoxical_subreg_p'.
>> >> 
>> >> Now I don't know if the strategy we want is:
>> >> 
>> >> - In 'update_costs_from_allocno' when modes are not ordered instead of
>> >>   calling 'narrower_subreg_mode' just keep the current one.
>> >> 
>> >> - Always select the cheapest mode in terms of cost.
>> >> 
>> >> The attached I'm testing implements the second.
>> 
>> Hi Richard,
>> 
>> thanks for commenting.
>> 
>> > I think instead we should consider recomputing “mode” in each
>> > iteration of the loop, rather than carry over the result of
>> > previous iterations.  I.e. use:
>> >
>> >     mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>> >                                  ALLOCNO_MODE (cp->second));
>> 
>> Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
>> (cp->second) always satisfying 'ordered_p'?
> Yeah, I think so.  If the modes aren't ordered then we shouldn't
> create a copy between them.

Great, I'm going to test the suggested then.

Thanks

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com]

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

--- Comment #7 from Andrea Corallo <andrea.corallo at arm dot com> ---
"rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to Andrea Corallo from comment #5)
>> "rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
>> writes:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>> >
>> > --- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
>> > (In reply to Andrea Corallo from comment #3)
>> >> Created attachment 49710 [details]
>> >> PR97092.patch
>> >> 
>> >> What is going on is that in 'update_costs_from_allocno' we try to
>> >> identify the smallest mode using narrower_subreg_mode to then update the
>> >> costs.
>> >> 
>> >> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> >> are not ordered we ICE in 'paradoxical_subreg_p'.
>> >> 
>> >> Now I don't know if the strategy we want is:
>> >> 
>> >> - In 'update_costs_from_allocno' when modes are not ordered instead of
>> >>   calling 'narrower_subreg_mode' just keep the current one.
>> >> 
>> >> - Always select the cheapest mode in terms of cost.
>> >> 
>> >> The attached I'm testing implements the second.
>> 
>> Hi Richard,
>> 
>> thanks for commenting.
>> 
>> > I think instead we should consider recomputing “mode” in each
>> > iteration of the loop, rather than carry over the result of
>> > previous iterations.  I.e. use:
>> >
>> >     mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>> >                                  ALLOCNO_MODE (cp->second));
>> 
>> Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
>> (cp->second) always satisfying 'ordered_p'?
> Yeah, I think so.  If the modes aren't ordered then we shouldn't
> create a copy between them.

Great, I'm going to test the suggested then.

Thanks

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrea Corallo <akrl@gcc.gnu.org>:

https://gcc.gnu.org/g:499651e43854ea65303eb55324263c25256c9735

commit r11-5926-g499651e43854ea65303eb55324263c25256c9735
Author: Andrea Corallo <andrea.corallo@arm.com>
Date:   Wed Dec 9 17:59:12 2020 +0100

    ira.c: Fix ICE in ira-color [PR97092]

    gcc/ChangeLog

    2020-12-10  Andrea Corallo  <andrea.corallo@arm.com>

            PR rtl-optimization/97092
            * ira-color.c (update_costs_from_allocno): Do not carry over mode
            between subsequent iterations.

    gcc/testsuite/ChangeLog

    2020-12-10  Andrea Corallo  <andrea.corallo@arm.com>

            * gcc.target/aarch64/sve/pr97092.c: New test.

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[acoplan at gcc dot gnu.org]

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

--- Comment #9 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Thanks for fixing this Andrea! FWIW I can reproduce the ICE with the same
testcase and options on the head of the GCC 10 branch (contrary to my first
message).

Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[Andrea Corallo]

"acoplan at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #9 from Alex Coplan <acoplan at gcc dot gnu.org> ---
> Thanks for fixing this Andrea! FWIW I can reproduce the ICE with the same
> testcase and options on the head of the GCC 10 branch (contrary to my first
> message).

Hi Alex,

I'll test the patch also on gcc-10 then so we can have it there too (it
should apply).

Thanks for checking!

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com]

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

--- Comment #10 from Andrea Corallo <andrea.corallo at arm dot com> ---
"acoplan at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #9 from Alex Coplan <acoplan at gcc dot gnu.org> ---
> Thanks for fixing this Andrea! FWIW I can reproduce the ICE with the same
> testcase and options on the head of the GCC 10 branch (contrary to my first
> message).

Hi Alex,

I'll test the patch also on gcc-10 then so we can have it there too (it
should apply).

Thanks for checking!

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Andrea Corallo
<akrl@gcc.gnu.org>:

https://gcc.gnu.org/g:41a2a54476cba88376c4b30ca8b94b4a088a66ce

commit r10-9153-g41a2a54476cba88376c4b30ca8b94b4a088a66ce
Author: Andrea Corallo <andrea.corallo@arm.com>
Date:   Wed Dec 9 17:59:12 2020 +0100

    ira.c: Fix ICE in ira-color [PR97092]

    2020-12-10  Andrea Corallo  <andrea.corallo@arm.com>

    gcc/ChangeLog

    2020-12-10  Andrea Corallo  <andrea.corallo@arm.com>

            PR rtl-optimization/97092
            * ira-color.c (update_costs_from_allocno): Do not carry over mode
            between subsequent iterations.

    gcc/testsuite/ChangeLog

    2020-12-10  Andrea Corallo  <andrea.corallo@arm.com>

            * gcc.target/aarch64/sve/pr97092.c: New test.

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

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

--- Comment #12 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Fixed.