Re: [PATCH] PR middle-end/103059: reload: Also accept ASHIFT with indexed addressing

["Maciej W. Rozycki" <macro@embecosm.com>]

On Sun, 7 Nov 2021, Maciej W. Rozycki wrote:

>  For the record the change does fix numerous regressions in GCC 11 too, 
> e.g.:
> 
> 		=== gcc Summary ===
> 
> # of expected passes		122244
> # of unexpected failures	1852
> # of expected passes		122428
> # of unexpected failures	1484
> # of unexpected successes	5
> # of expected failures		721
> # of unresolved testcases	10

 Umm, that was supposed to be:

 		=== gcc Summary ===
 
-# of expected passes		122244
-# of unexpected failures	1852
+# of expected passes		122428
+# of unexpected failures	1484
 # of unexpected successes	5
 # of expected failures		721
 # of unresolved testcases	10

> So either this change, if deemed safe enough, will have to go into GCC 11, 
> or, if we're going to keep old reload yet for GCC 12, then the best course 
> of action for GCC 11 might be reverting commit c605a8bf9270, although at 
> the cost of regressing code quality a bit where it does build.

 Verification of the revert of commit c605a8bf9270 with GCC 11 shows a 
pair of regressions in libstdc++-v3 though:

-FAIL: 26_numerics/random/ranlux48.cc execution test
-FAIL: 26_numerics/random/ranlux48_base.cc execution test
+FAIL: 26_numerics/random/ranlux48.cc (test for excess errors)
+FAIL: 26_numerics/random/ranlux48_base.cc (test for excess errors)

and the excess errors are:

during RTL pass: postreload
.../libstdc++-v3/testsuite/26_numerics/random/ranlux48.cc: In function 'void test01()':
.../libstdc++-v3/testsuite/26_numerics/random/ranlux48.cc:36: internal compiler error: in cselib_invalidate_regno, at cselib.c:2422

and:

during RTL pass: postreload
.../libstdc++-v3/testsuite/26_numerics/random/ranlux48_base.cc: In function 'void test01()':
.../libstdc++-v3/testsuite/26_numerics/random/ranlux48_base.cc:36: internal compiler error: in cselib_invalidate_regno, at cselib.c:2422

respectively (we have a pair of test cases that fail anyway, but an ICE is 
I think an escalation of a failure in comparison to an execution failure; 
I haven't debugged what the causes of the respective execution failures 
are or what the exact cause of the ICEs is at this point).

 No changes elsewhere throughout all the testsuites.

  Maciej