[Bug rtl-optimization/104198] New: [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[Bug rtl-optimization/104198] New: [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ro at gcc dot gnu.org]

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

            Bug ID: 104198
           Summary: [12 regression] ifcvf change breaks 64-bit SPARC
                    bootstrap
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: ebotcazou at gcc dot gnu.org, rdapp at gcc dot gnu.org
  Target Milestone: ---
            Target: sparcv9-sun-solaris2.11

Between 20220114 (89b4e316a02be9fda3b793a7be871f7c7913cd58) and 20220121
(6f45deb2aed804b185e7dabd2392bfbe14e9bb57)
64-bit Solaris/SPARC bootstrap got broken.  The issue can already be seen in
the
first C++ configure test for stage 2 libstdc++:

$ cat conftest.cpp
class Foo
{
public:
  Foo (void) { a = 0; }
private:
  int a;
};
$ ./xgcc -B./ -c conftest.cpp
../conftest.cpp:6:7: error: function definition does not declare parameters
    6 |   int a;
      |       ^
../conftest.cpp: In constructor ‘Foo::Foo()’:
../conftest.cpp:4:16: error: ‘a’ was not declared in this scope
    4 |   Foo (void) { a = 0; }
      |                ^

Looks like a miscompilation and completely breaks the libstdc++ build.

A reghunt identified this patch

commit aa8cfe785953a0e87d2472311e1260cd98c605c0
Author: Robin Dapp <rdapp@linux.ibm.com>
Date:   Wed Jan 19 17:36:36 2022 +0100

    ifcvt: Try re-using CC for conditional moves.

As the culprit.

32-bit Solaris/SPARC (sparc-sun-solaris2.11) is unaffected, however.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ro at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=104153

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does the patch in bug 104153 comment 3  help?

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> Does the patch in bug 104153 comment 3  help?

No: I'd tried that already to no avail.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-01-24
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Did you try to run the testsuite of the 32-bit compiler with -m64, for example
gcc.c-torture/execute, and see whether the miscompilation is visible there?

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Did you try to run the testsuite of the 32-bit compiler with -m64, for example
> gcc.c-torture/execute, and see whether the miscompilation is visible there?

I bootstrap the 32-bit compiler daily and run the testsuite for both
multilibs: no change there before and after Robin's patch.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
OK, too bad.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[rdapp at linux dot ibm.com]

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

rdapp at linux dot ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rdapp at linux dot ibm.com

--- Comment #6 from rdapp at linux dot ibm.com ---
I can take a look - would one of the compile farm SPARC machines be ok to
reproduce this? I'm currently trying on gcc64, but that's an OpenBSD.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #6 from rdapp at linux dot ibm.com ---
> I can take a look - would one of the compile farm SPARC machines be ok to
> reproduce this? I'm currently trying on gcc64, but that's an OpenBSD.

This doesn't look like an OS-specific issue to me, so any SPARC machine
should do.  However, gcc64 isn't even listed on

        https://cfarm.tetaneutral.net/machines/list/

and I believe OpenBSD has since deprecated SPARC support, which wasn't
particularly well maintained anyway.  I'd go for either a Solaris
(gcc211) or Linux (gcc202) system.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[rdapp at linux dot ibm.com]

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

--- Comment #8 from rdapp at linux dot ibm.com ---
One of the s390-"specific" execution testcases fails on SPARC using the wrong
order of operands.  I'm pretty sure this is the problem.  Going to investigate
further.
Seeing this, it might make sense to make the testcases target independent if
the testsuite was indeed clean after the ifcvt patches.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[rdapp at linux dot ibm.com]

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

--- Comment #9 from rdapp at linux dot ibm.com ---
I believe I know what's happening and it's indeed something that could also
happen on other targets.

I did not anticipate backends re-creating the initial condition for the case
when we pass it a cc comparison.  The SPARC backend does this, using a (now)
already overwritten value for comparison.  Other targets could also do this but
maybe do not currently but it would always lead to wrong code.

Not yet sure about a proper solution.  Since we go over the insns twice anyway
we could check the created sequences for overlap with the condition again and
mark them.  In the second iteration we would make sure to not overwrite the
condition unless there is no insn later that uses it.  Hope to come up with
something testable by today.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[rdapp at linux dot ibm.com]

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

--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 52297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52297&action=edit
Tentative patch

I now have something that successfully bootstraps on s390x, PowerPC and SPARC
but I'm not really happy with it.

The idea is basically to check if the newly introduced sequence (getting passed
a cc comparison) emits an instruction other than the movcc that reads a
register used in the comparison.  I'm not sure what backends are supposed to
emit for such a sequence but most likely everything is admissible. 
reg_overlap_mentioned_p does not handle every rtx_code so special handling is
necessary which needs to be exhaustive in order for reg_overlap_mentioned_p not
to ICE.

I feel like this is not the best way to achieve what we want and would
appreciate some insight.  I attached the current full diff to master (including
the fix for the problem triggered by the or1k backend.  It's pretty
raw/unpolished/ugly but the idea should come across.

A full testsuite run on gcc202 just finished, 83 FAILs, but I haven't yet done
a comparison run from before the ifcvt changes.

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from rdapp at linux dot ibm.com ---
> Created attachment 52297
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52297&action=edit
> Tentative patch
[...]
> A full testsuite run on gcc202 just finished, 83 FAILs, but I haven't yet done
> a comparison run from before the ifcvt changes.

I've now successfully completed a sparcv9-sun-solaris2.11 bootstrap
(sparc-sun-solaris2.11 for comparison with last night's bootstrap of an
unpatched tree still running), so we're mostly good again.  Thanks.

However, I see a couple of regressions compared to the last successful
bootstrap:

+FAIL: gfortran.dg/maxloc_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error:
Segmentation Fault)
+FAIL: gfortran.dg/maxloc_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
+UNRESOLVED: gfortran.dg/maxloc_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  compilation failed to produce
executable
+FAIL: gfortran.dg/minloc_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error:
Segmentation Fault)
+FAIL: gfortran.dg/minloc_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
+UNRESOLVED: gfortran.dg/minloc_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  compilation failed to produce
executable
+FAIL: gfortran.dg/minlocval_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error:
Segmentation Fault)
+FAIL: gfortran.dg/minlocval_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
+UNRESOLVED: gfortran.dg/minlocval_3.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  compilation failed to
produce executable
+FAIL: gfortran.dg/minlocval_3.f90   -O3 -g  (internal compiler error:
Segmentation Fault)
+FAIL: gfortran.dg/minlocval_3.f90   -O3 -g  (test for excess errors)
+UNRESOLVED: gfortran.dg/minlocval_3.f90   -O3 -g  compilation failed to
produce executable

+FAIL: gfortran.dg/g77/19990826-3.f   -O  (internal compiler error:
Segmentation Fault)
+FAIL: gfortran.dg/g77/19990826-3.f   -O  (test for excess errors)

+FAIL: ext/special_functions/hyperg/check_nan.cc (test for excess errors)
+UNRESOLVED: ext/special_functions/hyperg/check_nan.cc compilation failed to
produce executable
+FAIL: ext/special_functions/hyperg/check_value.cc (test for excess errors)
+UNRESOLVED: ext/special_functions/hyperg/check_value.cc compilation failed to
produce executable
+FAIL: ext/special_functions/hyperg/compile.cc (test for excess errors)
+FAIL: tr1/5_numerical_facilities/special_functions/17_hyperg/check_nan.cc
(test for excess errors)
+UNRESOLVED:
tr1/5_numerical_facilities/special_functions/17_hyperg/check_nan.cc compilation
failed to produce executable
+FAIL: tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc
(test for excess errors)
+UNRESOLVED:
tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc
compilation failed to produce executable
+FAIL: tr1/5_numerical_facilities/special_functions/17_hyperg/compile.cc (test
for excess errors)
+FAIL: tr1/5_numerical_facilities/special_functions/17_hyperg/compile_2.cc
(test for excess errors)

for both 32 and 64-bit multilibs.

All of them are the same, it seems:

FAIL: gfortran.dg/maxloc_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
Excess errors:
during RTL pass: ce1
/vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/maxloc_2.f90:155:3:
internal compiler error: Segmentation Fault
0x100fed85b crash_signal
        /vol/gcc/src/hg/master/local/gcc/toplev.cc:322
0x100f5de28 copy_rtx(rtx_def*)
        /vol/gcc/src/hg/master/local/gcc/rtl.cc:290
0x101b0905b noce_convert_multiple_sets_1
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:3394
0x101b1027f noce_convert_multiple_sets
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:3281
0x101b12a9f noce_process_if_block
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:3731
0x101b12a9f noce_find_if_block
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:4485
0x101b12a9f find_if_header
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:4690
0x101b12a9f if_convert
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:5831
0x101b13ca7 rest_of_handle_if_conversion
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:5896
0x101b13ca7 execute
        /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:5936

gdb shows

gdb) run /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/maxloc_2.f90
-quiet -mcpu=v9 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-o maxloc_2.s
Starting program:
/var/gcc/regression/master/11.4-gcc-64/build/gcc/testsuite/gfortran/f951
/vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/maxloc_2.f90 -quiet
-mcpu=v9 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -o
maxloc_2.s
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
copy_rtx (orig=0x0) at /vol/gcc/src/hg/master/local/gcc/rtl.cc:290
290       code = GET_CODE (orig);
(gdb) bt
#0  copy_rtx (orig=0x0) at /vol/gcc/src/hg/master/local/gcc/rtl.cc:290
#1  0x0000000101b0905c in noce_convert_multiple_sets_1
(if_info=0xffffffff7fffdbc8, need_no_cmov=0xffffffff7fffdbe0,
rewired_src=0xffffffff7fffdc10, targets=0xffffffff7fffdbc0,
temporaries=0xffffffff7fffdbc8, unmodified_insns=0xffffffff7fffdbd0,
last_needs_comparison=0xffffffff7fffdbb4) at
/vol/gcc/src/hg/master/local/gcc/ifcvt.cc:3394
#2  0x0000000101b10280 in noce_convert_multiple_sets (if_info=<optimized out>)
at /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:3280
#3  0x0000000101b12aa0 in noce_process_if_block (if_info=0xffffffff7fffde08) at
/vol/gcc/src/hg/master/local/gcc/ifcvt.cc:3731
#4  noce_find_if_block (pass=2, else_edge=<edge 0xffffffff7ae77a70 (198 ->
202)>, then_edge=<edge 0xffffffff7ae77b60 (198 -> 201)>, test_bb=<basic_block
0xffffffff7af92e38 (198)>) at /vol/gcc/src/hg/master/local/gcc/ifcvt.cc:4485
#5  find_if_header (pass=2, test_bb=<basic_block 0xffffffff7af92e38 (198)>) at
/vol/gcc/src/hg/master/local/gcc/ifcvt.cc:4690
#6  if_convert (after_combine=<optimized out>) at
/vol/gcc/src/hg/master/local/gcc/ifcvt.cc:5831
#7  0x0000000101b13ca8 in rest_of_handle_if_conversion () at
/vol/gcc/src/hg/master/local/gcc/ifcvt.cc:5896
#8  (anonymous namespace)::pass_rtl_ifcvt::execute (this=0x0) at
/vol/gcc/src/hg/master/local/gcc/ifcvt.cc:5936
#9  0x0000000100ebb0c4 in execute_one_pass (pass=<opt_pass* 0x1023bd000
"ce1"(271)>) at /vol/gcc/src/hg/master/local/gcc/passes.cc:2637
#10 0x0000000100ebbd38 in execute_pass_list_1 (pass=<opt_pass* 0x1023bd000
"ce1"(271)>) at /vol/gcc/src/hg/master/local/gcc/passes.cc:2737
#11 0x0000000100ebbd58 in execute_pass_list_1 (pass=<opt_pass* 0x1023bc9e0
"*rest_of_compilation"(-1)>) at /vol/gcc/src/hg/master/local/gcc/passes.cc:2738
#12 0x0000000100ebbdc0 in execute_pass_list (fn=0xffffffff7acac0b8,
pass=<opt_pass* 0x1023b7c00 "fixup_cfg"(98)>) at
/vol/gcc/src/hg/master/local/gcc/passes.cc:2748
#13 0x00000001009ad934 in cgraph_node::expand (this=<cgraph_node * const
0xffffffff7ad76110 "main"/1>) at /vol/gcc/src/hg/master/local/gcc/context.h:48
#14 cgraph_node::expand (this=<cgraph_node * const 0xffffffff7ad76110
"main"/1>) at /vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:1787
#15 0x00000001009afb78 in expand_all_functions () at
/vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:1998
#16 symbol_table::compile (this=0xffffffff7ac10000) at
/vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2348
#17 0x00000001009b42c0 in symbol_table::compile (this=0xffffffff7ac10000) at
/vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2261
#18 symbol_table::finalize_compilation_unit (this=0xffffffff7ac10000) at
/vol/gcc/src/hg/master/local/gcc/cgraphunit.cc:2529
#19 0x0000000100fedbf0 in compile_file () at
/vol/gcc/src/hg/master/local/gcc/toplev.cc:479
#20 0x0000000100ff2200 in do_compile (no_backend=false) at
/vol/gcc/src/hg/master/local/gcc/toplev.cc:2158
#21 toplev::main (this=<optimized out>, argc=<optimized out>, argv=<optimized
out>) at /vol/gcc/src/hg/master/local/gcc/toplev.cc:2310
#22 0x0000000101cf90a8 in main (argc=<optimized out>, argv=0xffffffff7fffe7d8)
at /vol/gcc/src/hg/master/local/gcc/main.cc:39

[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
[...]
> I've now successfully completed a sparcv9-sun-solaris2.11 bootstrap
> (sparc-sun-solaris2.11 for comparison with last night's bootstrap of an
> unpatched tree still running), so we're mostly good again.  Thanks.

The sparc-sun-solaris2.11 bootstrap has completed now and shows the same
regressions compared to the unmodified tree.

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

[rdapp at linux dot ibm.com]

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

--- Comment #13 from rdapp at linux dot ibm.com ---
I was away for some days, going to look into this again today.

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

[rdapp at linux dot ibm.com]

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

--- Comment #14 from rdapp at linux dot ibm.com ---
Ok, this is triggered by the copy_rtx I introduced for the or1k failure:

+  rtx rev_cc_cmp = copy_rtx (cond_exec_get_condition (jump, /* get_reversed */
true));

because copy_rtx is called with NULL_RTX here.

I'm now testing with

--- a/gcc/ifcvt.cc
+++ b/gcc/ifcvt.cc
@@ -3390,8 +3390,12 @@ noce_convert_multiple_sets_1 (struct noce_if_info
*if_info,
   /* Decompose the condition attached to the jump.  */
   rtx cond = noce_get_condition (jump, &cond_earliest, false);

-  rtx cc_cmp = copy_rtx (cond_exec_get_condition (jump));
-  rtx rev_cc_cmp = copy_rtx (cond_exec_get_condition (jump, /* get_reversed */
true));
+  rtx cc_cmp = cond_exec_get_condition (jump);
+  if (cc_cmp)
+    cc_cmp = copy_rtx (cc_cmp);
+  rtx rev_cc_cmp = cond_exec_get_condition (jump, /* get_reversed */ true);
+  if (rev_cc_cmp)
+    rev_cc_cmp = copy_rtx (rev_cc_cmp);

but the reg_overlap_mentioned_p part still needs to be improved
(independently).

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

[rdapp at linux dot ibm.com]

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

--- Comment #15 from rdapp at linux dot ibm.com ---
Testsuite is same as before the original patch now.  Going to post a patch to
the mailing list later.

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

https://gcc.gnu.org/g:d0d4601ccde3c4849f6e7244035f1a899d608cb7

commit r12-7114-gd0d4601ccde3c4849f6e7244035f1a899d608cb7
Author: Robin Dapp <rdapp@linux.ibm.com>
Date:   Tue Feb 8 16:11:20 2022 +0100

    ifcvt: Fix PR104153 and PR104198.

    This is a bugfix for r12-6747-gaa8cfe785953a0 which caused an ICE
    on or1k (PR104153) and broke SPARC bootstrap (PR104198).

    cond_exec_get_condition () returns the jump condition directly and we
    now pass it to the backend.  The or1k backend modified the condition
    in-place (other backends do that as well) but this modification is not
    reverted when the sequence in question is discarded.  Therefore we copy
    the RTX instead of using it directly.

    The SPARC problem is due to the SPARC backend recreating the initial
    condition when being passed a CC comparison.  This causes the sequence
    to read from an already overwritten condition operand.  Generally, this
    could also happen on other targets.  The workaround is to always first
    emit to a temporary.  In a second run of noce_convert_multiple_sets_1
    we know which sequences actually require the comparison and will use no
    temporaries if all sequences after the current one do not require it.

            PR rtl-optimization/104198
            PR rtl-optimization/104153

    gcc/ChangeLog:

            * ifcvt.cc (noce_convert_multiple_sets_1): Copy rtx instead of
            using it directly.  Rework comparison handling and always
            perform a second pass.

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr104198.c: New test.

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Is this fixed now?

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Is this fixed now?

It is: SPARCv9 bootstrap is back to normal.

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
.