[Bug target/55212] New: [SH] Switch from IRA to LRA

[Bug target/55212] New: [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

             Bug #: 55212
           Summary: [SH] Switch from IRA to LRA
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: olegendo@gcc.gnu.org
            Target: sh*-*-*


Since a new register allocator (LRA) has been added in 4.8 it might be worth
trying it out for SH.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sun Aug  3 09:47:15 2014
New Revision: 213524

URL: https://gcc.gnu.org/viewcvs?rev=213524&root=gcc&view=rev
Log:
PR target/55212
Create branch.

Added:
    branches/sh-lra/
      - copied from r213515, trunk/

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-10
     Ever confirmed|0                           |1

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I've committed a small change as r215140.  In my case building libgcc failed in
the function __divsc3 and the change in sh_secondary_reload made it go away. 
I've briefly compared the resulting code against non-LRA and it looked OK. 
However, building __divsc3 still fails for -m2 -mb, now with the following:

beh 0 0 0
(insn 1159 1008 1120 27 (set (reg:QI 625)
        (mem/c:QI (plus:SI (reg/f:SI 153 sfp)
                (const_int 19 [0x13])) [2 %sfp+-1 S1 A8])) sh_tmp.cpp:45 -1
     (nil))

sh_tmp.cpp: In function '__divsc3':
sh_tmp.cpp:57:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:947
 }
 ^
0x8524c29 lra_set_insn_recog_data(rtx_def*)
    ../../gcc-sh-lra/gcc/lra.c:947
0x85258cb lra_get_insn_recog_data
    ../../gcc-sh-lra/gcc/lra-int.h:468
0x85258cb lra_update_insn_regno_info
    ../../gcc-sh-lra/gcc/lra.c:1607
0x85258cb lra_update_insn_regno_info
    ../../gcc-sh-lra/gcc/lra.c:1598
0x8525b1b lra_push_insn_1
    ../../gcc-sh-lra/gcc/lra.c:1660
0x8525b1b lra_push_insn(rtx_def*)
    ../../gcc-sh-lra/gcc/lra.c:1668
0x8525d12 push_insns
    ../../gcc-sh-lra/gcc/lra.c:1711
0x852618f lra_process_new_insns(rtx_def*, rtx_def*, rtx_def*, char const*)
    ../../gcc-sh-lra/gcc/lra.c:1756
0x8533758 simplify_operand_subreg
    ../../gcc-sh-lra/gcc/lra-constraints.c:1523
0x8533758 curr_insn_transform
    ../../gcc-sh-lra/gcc/lra-constraints.c:3258
0x8535e2d lra_constraints(bool)
    ../../gcc-sh-lra/gcc/lra-constraints.c:4212
0x8526af8 lra(_IO_FILE*)
    ../../gcc-sh-lra/gcc/lra.c:2198
0x84e6823 do_reload
    ../../gcc-sh-lra/gcc/ira.c:5306
0x84e6823 execute
    ../../gcc-sh-lra/gcc/ira.c:5465

The generated insn 1159 isn't recognized, because the displacement value is out
of range.

It seems that LRA doesn't try to transform the out of range displacement QImode
move into something else so that the <disp04> constraint is satisfied.

Maybe this is due to the way I did the QI/HImode displacement patterns.  AFAIR,
reload uses the macro LEGITIMIZE_RELOAD_ADDRESS (sh_legitimize_reload_address)
to handle such cases.  LRA can decompose addresses.  However, it looks like
it's not done in some cases?

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 33465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33465&action=edit
problematic libgcc divsc3 function

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #2)
> However, building __divsc3 still fails for -m2 -mb, now with the
> following:
> 
> beh 0 0 0
> (insn 1159 1008 1120 27 (set (reg:QI 625)
>         (mem/c:QI (plus:SI (reg/f:SI 153 sfp)
>                 (const_int 19 [0x13])) [2 %sfp+-1 S1 A8])) sh_tmp.cpp:45 -1
>      (nil))
> 
> sh_tmp.cpp: In function '__divsc3':
> sh_tmp.cpp:57:1: internal compiler error: in lra_set_insn_recog_data, at
> lra.c:947
>  }
>  ^
> 0x8524c29 lra_set_insn_recog_data(rtx_def*)
> 	../../gcc-sh-lra/gcc/lra.c:947
> 0x85258cb lra_get_insn_recog_data
> 	../../gcc-sh-lra/gcc/lra-int.h:468
> 0x85258cb lra_update_insn_regno_info
> 	../../gcc-sh-lra/gcc/lra.c:1607
> 0x85258cb lra_update_insn_regno_info
> 	../../gcc-sh-lra/gcc/lra.c:1598
> 0x8525b1b lra_push_insn_1
> 	../../gcc-sh-lra/gcc/lra.c:1660
> 0x8525b1b lra_push_insn(rtx_def*)
> 	../../gcc-sh-lra/gcc/lra.c:1668
> 0x8525d12 push_insns
> 	../../gcc-sh-lra/gcc/lra.c:1711
> 0x852618f lra_process_new_insns(rtx_def*, rtx_def*, rtx_def*, char const*)
> 	../../gcc-sh-lra/gcc/lra.c:1756
> 0x8533758 simplify_operand_subreg
> 	../../gcc-sh-lra/gcc/lra-constraints.c:1523
> 0x8533758 curr_insn_transform
> 	../../gcc-sh-lra/gcc/lra-constraints.c:3258
> 0x8535e2d lra_constraints(bool)
> 	../../gcc-sh-lra/gcc/lra-constraints.c:4212
> 0x8526af8 lra(_IO_FILE*)
> 	../../gcc-sh-lra/gcc/lra.c:2198
> 0x84e6823 do_reload
> 	../../gcc-sh-lra/gcc/ira.c:5306
> 0x84e6823 execute
> 	../../gcc-sh-lra/gcc/ira.c:5465
> 
> The generated insn 1159 isn't recognized, because the displacement value is
> out of range.

When compiling for -m2a-nofpu -mb the problem goes away because SH2A can handle
the displacement.  However, there are no QImode accesses in the resulting code
after LRA.
>From gcc-bugs-return-461750-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 13 14:57:53 2014
Return-Path: <gcc-bugs-return-461750-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9946 invoked by alias); 13 Sep 2014 14:57:52 -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 9893 invoked by uid 48); 13 Sep 2014 14:57:49 -0000
From: "danglin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61853] [4.9/5 Regression] ICE: SIGSEGV in store_field
Date: Sat, 13 Sep 2014 14:57: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.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: danglin 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: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61853-4-3KNVRgrCWt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61853-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61853-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: 2014-09/txt/msg01584.txt.bz2
Content-length: 717

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

--- Comment #9 from John David Anglin <danglin at gcc dot gnu.org> ---
Introduced in r202592:

    * tree-into-ssa.c (gate_into_ssa): New.
    (pass_data_build_ssa): Use it.
    * cgraph.h (expand_thunk): Update prototype.
    * cgraphunit.c (analyze_function): Expand thunks early.
    (expand_thunk): Fix DECL_CONTEXT of reust_decl;
    build proper cgraph; set in_ssa_p; clear bogus TREE_ASM_WRITTEN;
    set lowered flag; do not add new function.
    (assemble_thunks_and_aliases): Update.
    * tree-ssa.c (gate_init_datastructures): New gate.
    (pass_data_init_datastructures): Use it.

PA bug fix in r202594 needs to be backported to r202592 to see this.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Compiling the gcc.dg/atomic/c11-atomic-exec-4.c test case with '-O2 -m4 -ml
-matomic-model=soft-gusa' results in the following:

beh
(insn 207 206 208 6 (set (reg/f:SI 14 r14 [275])
        (plus:SI (reg/f:SI 15 r15)
            (const_int 36 [0x24]))) 76 {*addsi3_compact}
     (expr_list:REG_EQUIV (plus:SI (reg/f:SI 153 sfp)
            (const_int -4 [0xfffffffffffffffc]))
        (nil)))

internal compiler error: in check_rtl, at lra.c:1936
 TEST_FUNCS (complex_float_add, _Complex float, , += 1, 0, 20000)
 ^
0x85416bf check_rtl
    ../../gcc-sh-lra/gcc/lra.c:1936
0x8544a9a lra(_IO_FILE*)
    ../../gcc-sh-lra/gcc/lra.c:2327
0x8500e43 do_reload
    ../../gcc-sh-lra/gcc/ira.c:5312
0x8500e43 execute
    ../../gcc-sh-lra/gcc/ira.c:5471


the addsi3_compact insn should have been split into two insns: 1x reg-reg-move
+ 1x add-insn.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Sep 13 16:23:55 2014
New Revision: 215240

URL: https://gcc.gnu.org/viewcvs?rev=215240&root=gcc&view=rev
Log:
PR target/55212
* lra.c: fix comments.  print insn before lra_assert.

Modified:
    branches/sh-lra/gcc/lra.c

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo <olegendo at gcc dot gnu.org> ---
An issue similar to that in c#5 has been reported here: 
https://gcc.gnu.org/ml/gcc/2014-04/msg00273.html

I've tried applying that patch, but it doesn't fix the issue in c#2 nor c#5.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Sep 13 18:53:54 2014
New Revision: 215241

URL: https://gcc.gnu.org/viewcvs?rev=215241&root=gcc&view=rev
Log:
PR target/55212
* predicates.md (general_movsrc_operand,  general_movdst_operand):
  Don't legitimate QI/HImode  mem displacement while LRA is running.

Modified:
    branches/sh-lra/gcc/config/sh/predicates.md

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #9 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #8)
> Author: olegendo
> Date: Sat Sep 13 18:53:54 2014
> New Revision: 215241
> 
> URL: https://gcc.gnu.org/viewcvs?rev=215241&root=gcc&view=rev
> Log:
> PR target/55212
> * predicates.md (general_movsrc_operand,  general_movdst_operand):
>   Don't legitimate QI/HImode  mem displacement while LRA is running.
> 
> Modified:
>     branches/sh-lra/gcc/config/sh/predicates.md

libgcc now seems to compile for all default multilibs defined for sh-elf.

The next failure is:

gcc-sh-lra-build-sh-elf/sh-elf/libstdc++-v3/include/bits/locale_facets_nonio.h:1564:66:
internal compiler error: in set_address_disp, at rtlanal.c:5790
       { return this->do_put(__s, __intl, __io, __fill, __units); }
                                                                  ^
0x8830497 set_address_disp
    ../../gcc-sh-lra/gcc/rtlanal.c:5790
0x8830497 set_address_disp
    ../../gcc-sh-lra/gcc/rtlanal.c:6080
0x8830497 decompose_normal_address
    ../../gcc-sh-lra/gcc/rtlanal.c:5912
0x8830497 decompose_address
    ../../gcc-sh-lra/gcc/rtlanal.c:5997
0x88305b1 decompose_mem_address(address_info*, rtx_def*)
    ../../gcc-sh-lra/gcc/rtlanal.c:6017
0x8745d7b process_address_1
    ../../gcc-sh-lra/gcc/lra-constraints.c:2783
0x874aed9 process_address
    ../../gcc-sh-lra/gcc/lra-constraints.c:2990
0x874aed9 curr_insn_transform
    ../../gcc-sh-lra/gcc/lra-constraints.c:3274
0x874d905 lra_constraints(bool)
    ../../gcc-sh-lra/gcc/lra-constraints.c:4215
0x873ce6c lra(_IO_FILE*)
    ../../gcc-sh-lra/gcc/lra.c:2206
0x86f99a3 do_reload
    ../../gcc-sh-lra/gcc/ira.c:5312
0x86f99a3 execute
    ../../gcc-sh-lra/gcc/ira.c:5471

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #9)
>  
> The next failure is:
> 
> gcc-sh-lra-build-sh-elf/sh-elf/libstdc++-v3/include/bits/locale_facets_nonio.
> h:1564:66: internal compiler error: in set_address_disp, at rtlanal.c:5790
>        { return this->do_put(__s, __intl, __io, __fill, __units); }
>                                                                   ^
> 0x8830497 set_address_disp
> 	../../gcc-sh-lra/gcc/rtlanal.c:5790
> 0x8830497 set_address_disp
> 	../../gcc-sh-lra/gcc/rtlanal.c:6080
> 0x8830497 decompose_normal_address
> 	../../gcc-sh-lra/gcc/rtlanal.c:5912
> 0x8830497 decompose_address
> 	../../gcc-sh-lra/gcc/rtlanal.c:5997
> 0x88305b1 decompose_mem_address(address_info*, rtx_def*)
> 	../../gcc-sh-lra/gcc/rtlanal.c:6017
> 0x8745d7b process_address_1
> 	../../gcc-sh-lra/gcc/lra-constraints.c:2783
> 0x874aed9 process_address
> 	../../gcc-sh-lra/gcc/lra-constraints.c:2990
> 0x874aed9 curr_insn_transform
> 	../../gcc-sh-lra/gcc/lra-constraints.c:3274
> 0x874d905 lra_constraints(bool)
> 	../../gcc-sh-lra/gcc/lra-constraints.c:4215
> 0x873ce6c lra(_IO_FILE*)
> 	../../gcc-sh-lra/gcc/lra.c:2206
> 0x86f99a3 do_reload
> 	../../gcc-sh-lra/gcc/ira.c:5312
> 0x86f99a3 execute
> 	../../gcc-sh-lra/gcc/ira.c:5471


This is due to the following invalid mem that ends up in the
"*extend<mode>si2_compact_snd" pattern:

(insn 8 5 10 2 (set (reg/v:SI 171 [ __fill ])
        (sign_extend:SI (mem/c:QI (plus:SI (plus:SI (reg/f:SI 145 ap)
                        (const_int 12 [0xc]))
                    (const_int 4 [0x4])) [0 __fill+0 S1 A32])))
locale_facets_nonio.h:1562 241 {*extendqisi2_compact_snd}
     (expr_list:REG_EQUIV (mem:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 4 [0x4])) [0  S4 A32])
        (nil)))


in function "decompose_address":
inner = (plus:SI (plus:SI (reg/f:SI 145 ap)
        (const_int 12 [0xc]))
    (const_int 4 [0x4]))
>From gcc-bugs-return-461770-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 13 20:21:37 2014
Return-Path: <gcc-bugs-return-461770-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18411 invoked by alias); 13 Sep 2014 20:21:37 -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 18361 invoked by uid 55); 13 Sep 2014 20:21:33 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/55212] [SH] Switch from IRA to LRA
Date: Sat, 13 Sep 2014 20:21: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo 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: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55212-4-aLPz2EOWgx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55212-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55212-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: 2014-09/txt/msg01604.txt.bz2
Content-length: 442

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

--- Comment #11 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Sep 13 20:21:00 2014
New Revision: 215243

URL: https://gcc.gnu.org/viewcvs?rev!5243&root=gcc&view=rev
Log:
PR target/55212
* predicates.md (general_movsrc_operand,  general_movdst_operand):
  Allow only valid plus address expressions.

Modified:
    branches/sh-lra/gcc/config/sh/predicates.md

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #12 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #11)
> Author: olegendo
> Date: Sat Sep 13 20:21:00 2014
> New Revision: 215243
> 
> URL: https://gcc.gnu.org/viewcvs?rev=215243&root=gcc&view=rev
> Log:
> PR target/55212
> * predicates.md (general_movsrc_operand,  general_movdst_operand):
>   Allow only valid plus address expressions.
> 
> Modified:
>     branches/sh-lra/gcc/config/sh/predicates.md

After that, we're back to:

beh
(insn 189 188 1583 22 (set (reg/f:SI 14 r14 [561])
        (plus:SI (reg/f:SI 15 r15)
            (const_int 28 [0x1c]))) locale_facets_nonio.h:1195 76
{*addsi3_compact}
     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
            (const_int -36 [0xffffffffffffffdc]))
        (nil)))

locale_facets_nonio.tcc:125:5: internal compiler error: in check_rtl, at
lra.c:1935

0x873a21f check_rtl
    ../../gcc-sh-lra/gcc/lra.c:1935
0x873d5fa lra(_IO_FILE*)
    ../../gcc-sh-lra/gcc/lra.c:2326
0x86f99a3 do_reload
    ../../gcc-sh-lra/gcc/ira.c:5312
0x86f99a3 execute
    ../../gcc-sh-lra/gcc/ira.c:5471

... which seems to be the same issue as in c#5

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #13 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Sep 13 20:40:21 2014
New Revision: 215244

URL: https://gcc.gnu.org/viewcvs?rev=215244&root=gcc&view=rev
Log:
PR target/55212
* Remove LEGITIMIZE_RELOAD_ADDRESS and sh_legitimize_reload_address.
  They are not used by LRA.

Modified:
    branches/sh-lra/gcc/config/sh/sh-protos.h
    branches/sh-lra/gcc/config/sh/sh.c
    branches/sh-lra/gcc/config/sh/sh.h

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Sep 13 21:32:27 2014
New Revision: 215246

URL: https://gcc.gnu.org/viewcvs?rev=215246&root=gcc&view=rev
Log:
PR target/55212
* Apply patch from https://gcc.gnu.org/ml/gcc/2014-04/msg00273.html

Modified:
    branches/sh-lra/gcc/lra-constraints.c

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #15 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #14)
> Author: olegendo
> Date: Sat Sep 13 21:32:27 2014
> New Revision: 215246
> 
> URL: https://gcc.gnu.org/viewcvs?rev=215246&root=gcc&view=rev
> Log:
> PR target/55212
> * Apply patch from https://gcc.gnu.org/ml/gcc/2014-04/msg00273.html
> 
> Modified:
>     branches/sh-lra/gcc/lra-constraints.c

Now the build 'make all' for sh-elf c,c++ completes without errors.

New problem:
Compiling newlib 1.20.0 with '-O2 -m2e':

./../../../../../newlib-1.20.0/newlib/libm/math/er_lgamma.c: In function
'__ieee754_lgamma_r':
../../../../../../newlib-1.20.0/newlib/libm/math/er_lgamma.c:309:1: internal
compiler error: Max. number of generated reload insns per insn is achieved (90)

 }
 ^
0x85551c5 lra_constraints(bool)
    ../../gcc-sh-lra/gcc/lra-constraints.c:4145
0x85442bc lra(_IO_FILE*)
    ../../gcc-sh-lra/gcc/lra.c:2206
0x8500df3 do_reload
    ../../gcc-sh-lra/gcc/ira.c:5312
0x8500df3 execute
    ../../gcc-sh-lra/gcc/ira.c:5471
Please submit a full bug report,

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #16 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #5)
> Compiling the gcc.dg/atomic/c11-atomic-exec-4.c test case with '-O2 -m4 -ml
> -matomic-model=soft-gusa' results in the following:
> 

This problem seems to be gone now, too.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #17 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Sep 13 22:13:56 2014
New Revision: 215247

URL: https://gcc.gnu.org/viewcvs?rev=215247&root=gcc&view=rev
Log:
PR target/55212
* lra-constraints.c: Print insn when hitting MAX_RELOAD_INSNS_NUMBER.

Modified:
    branches/sh-lra/gcc/lra-constraints.c

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #18 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 33489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33489&action=edit
Reduced case for MAX_RELOAD_INSNS_NUMBER

This fails when compiling with -O2 -m2e -m{l|b} with:

curr_insn = (insn 713 115 712 16 (parallel [
            (set (reg/v:SF 804 [orig:333 x ] [333])
                (reg/v:SF 714 [orig:333 x ] [333]))
            (use (reg/v:PSI 151 ))
            (clobber (scratch:SI))
        ]) er_lgamma.c:85 296 {movsf_ie}
     (nil))

In file included from sh_tmp.cpp:4:0:
er_lgamma.c: In function '__ieee754_lgamma_r':
er_lgamma.c:151:1: internal compiler error: Max. number of generated reload
insns per insn is achieved (90)

 }
 ^
0x8555215 lra_constraints(bool)
    ../../gcc-sh-lra/gcc/lra-constraints.c:4149
0x85442bc lra(_IO_FILE*)
    ../../gcc-sh-lra/gcc/lra.c:2206
0x8500df3 do_reload
    ../../gcc-sh-lra/gcc/ira.c:5312
0x8500df3 execute
    ../../gcc-sh-lra/gcc/ira.c:5471

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #19 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #18)
> Created attachment 33489 [details]
> Reduced case for MAX_RELOAD_INSNS_NUMBER
> 
> This fails when compiling with -O2 -m2e -m{l|b} with:
> 
> curr_insn = (insn 713 115 712 16 (parallel [
>             (set (reg/v:SF 804 [orig:333 x ] [333])
>                 (reg/v:SF 714 [orig:333 x ] [333]))
>             (use (reg/v:PSI 151 ))
>             (clobber (scratch:SI))
>         ]) er_lgamma.c:85 296 {movsf_ie}
>      (nil))

It's a reload loop and is maybe similar to PR 57032.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #20 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Vlad, do you have any idea/suggestion what could be going wrong in this case?
Also, could you please have a look at the patch applied to the sh-lra branch as
r215246  and see whether it makes sense to commit it to trunk?

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #21 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I've run check-gcc for sh-lra branch on sh4-unknown-linux-gnu
and got
                === gcc Summary ===

# of expected passes            83035
# of unexpected failures        169
# of unexpected successes       1
# of expected failures          119
# of unresolved testcases       45
# of unsupported tests          1514

It looks that 3 new kind of ICEs except the ICE in #c18 which
causes ~100 failures.  ~50 failures are

internal compiler error: in assign_by_spills, at lra-assigns.c:1335

which may be similar with mips's PR61610.  The typical example is
c-c++-common/torture/complex-sign-add.c -O2.
There are some unrecognizable insn errors for the rtl like

(insn 11 10 12 2 (set (reg/f:SI 166)
        (mem/f/j:SI (plus:SI (subreg:SI (reg/v:DI 162 [ s1 ]) 0)
                (const_int 4 [0x4])) [0 _5->m+0 S4 A32]))

It seems that the patch in #c11 should take account of subregs.
The example of another type of new failures is 

gcc.c-torture/execute/20040703-1.c:127:1: error: could not split insn
(insn 118 112 119 (parallel [
            (set (reg:SI 9 r9 [orig:253 D.1616 ] [253])
                (xor:SI (zero_extend:SI (reg:QI 147 t))
                    (const_int 1 [0x1])))
            (clobber (reg:SI 1 r1 [287]))
            (clobber (reg:SI 147 t))
        ]) gcc.c-torture/execute/20040703-1.c:54 401 {*movrt_negc}

It looks that LRA substitutes
  (zero_extend:SI (subreg:QI (reg:SI 147 t) 0))
with
  (zero_extend:SI (reg:QI 147 t))
in this case.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #22 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33505&action=edit
A possible patch

These last two errors could be fixed with the attached patch:

    * config/sh/predicates.md (general_movsrc_operand): Take
    subregs into account for plus address expression.
    (general_movdst_operand): Likewise.
    (t_reg_operand): Allow (zero_extend (reg t)).

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #23 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #22)
> Created attachment 33505 [details]
> A possible patch
> 
> These last two errors could be fixed with the attached patch:
> 
> 	* config/sh/predicates.md (general_movsrc_operand): Take
> 	subregs into account for plus address expression.
> 	(general_movdst_operand): Likewise.
> 	(t_reg_operand): Allow (zero_extend (reg t)).

Makes sense.
>From gcc-bugs-return-461917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 17 10:45:17 2014
Return-Path: <gcc-bugs-return-461917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9268 invoked by alias); 17 Sep 2014 10:45: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 9229 invoked by uid 48); 17 Sep 2014 10:45:11 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/63285] New: [4.9/5 Regression] -fcompare-debug scheduler related failure
Date: Wed, 17 Sep 2014 10:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-63285-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: 2014-09/txt/msg01751.txt.bz2
Content-length: 1163

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

            Bug ID: 63285
           Summary: [4.9/5 Regression] -fcompare-debug scheduler related
                    failure
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: vmakarov at gcc dot gnu.org

The following testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -fcompare-debug" } */

struct S { int a; };
struct T { int b, c; } a;
long b;
int c, d;
void bar (int, int);
void baz (void *, int);

void
foo (struct S *x, int y, int z, void *f, int *p, struct T *e)
{
  while (x)
    {
      baz (f, &d > p);
      if (z & 1)
        bar (f > (void *) &f, z);
    }
  if (c)
    {
      asm ("" : "+m" (a) : "i" (0));
      y--;
    }
  if (e->b == e->c)
    c = y;
  y--;
}

fails with -fcompare-debug on the trunk and 4.9 branch since the PR61923 fix
(i.e. r213675 on the trunk and r213674 on the 4.9 branch), one insn has :TI in
just one of the dumps and not the other one.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #24 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Wed Sep 17 23:24:40 2014
New Revision: 215341

URL: https://gcc.gnu.org/viewcvs?rev=215341&root=gcc&view=rev
Log:
PR target/55212
* config/sh/predicates.md (general_movsrc_operand): Take
  subregs into account for plus address expression.
  (general_movdst_operand): Likewise.
  (t_reg_operand): Allow (zero_extend (reg t)).


Modified:
    branches/sh-lra/gcc/config/sh/predicates.md

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #26 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33525&action=edit
.reload dump file

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #27 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33526&action=edit
A trial patch

It disables equiv substitution when the equiv includes some reg
assigned to a small register class.  I hope that it makes the issue
a bit clearer, even if it doesn't the right thing.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #28 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33527&action=edit
Another reduced test case (with "-m4 -ml -O2 -std=gnu99")

Here is a test case for the ICE in assign_by_spill which looks
caused by another reason.
.reload dump says that the problematic insn is something like

  107: {r166:SF=[r942:SI+r943:SI];use :PSI;clobber r784:SI;}

and

      Creating newreg=942 from oldreg=374, assigning class R0_REGS to address
r942
      Creating newreg=943, assigning class GENERAL_REGS to base + disp r943
       Change to class R0_REGS for r943

which means that R0_REGS is assigned to both r942 and r943.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #29 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33528&action=edit
A trial patch

The patch is to refrain from changing to class R0_REGS for r943.

With the above 2 patches, the remained test case failing with the ICE
in assign_by_spill is gcc.dg/pr38338.c which uses extra-ordinary
__builtin_apply_args and __builtin_apply builtins.  I can't get
what is going on that case yet.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org,
                   |                            |vmakarov at redhat dot com

--- Comment #30 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I thought I've CC'ed Vlad, but somehow I haven't.  Trying again.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #31 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33556&action=edit
A bit reduced test case of pr38338.c (-O0 -m4 -ml)

That case has only one basic block which looks like

    (prologue)
    (Save r4-r7,fr4-fr11,...)
  ;; Save argument
    mov.b    r0,@(8,r1)    ! 4    *movqi_store_mem_disp04/1
  ;; insns don't use r0
    ...
  ;; untyped_call
    mov.l    .L3,r1
    jsr    @r1
    nop    ! 97    calli
    mov.l    r0,@(56,r9)    ! 98    movsi_ie/9
    flds    fr0,fpul    ! 197    movsi_ie/22
    sts    fpul,r1    ! 198    movsi_ie/20
    mov.l    r1,@(60,r8)    ! 99    movsi_ie/9
  ;;
    ...

if RA was done.
It seems that LRA thought that r0 in insn 4 conflicts r0 in insn 98 and
fails at reloading *movqi_store_mem_disp04 which permits only r0 as
the source operand when reg+offset addressing mode is used.  LRA looks
right, because RA doesn't know that r0 is the function return value
register set by function call.
Target could notify it with clobbering function value registers before
call.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #32 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33557&action=edit
Patch for SH untyped_call

    * config/sh/sh.md (untyped_call): Clobber function value
    registers before call.

[Bug target/55212] [SH] Switch from IRA to LRA

[hp at gcc dot gnu.org]

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

--- Comment #33 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #32)
> Patch for SH untyped_call
> config/sh/sh.md (untyped_call): Clobber function value registers before
> call.

(Sorry for butting in; I'm CC'ed with the purpose of observing issues likely to
pop up for my own ports.)

Will clobbering function-value registers before the call not cause problems on
SH5, where function-value registers and parameters registers overlap (IIUC)?

For reference, i386.md emits a blockage (i.e. *using* and clobbering all
registers).

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #34 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #33)
> Will clobbering function-value registers before the call not cause problems
> on SH5, where function-value registers and parameters registers overlap
> (IIUC)?

Yes.  I've forgot about SH5.  Thanks for pointing it out.  The patch
should be conditionalized for SH5 on which this issue won't happen.

> For reference, i386.md emits a blockage (i.e. *using* and clobbering all
> registers).

It looks all ports including SH emit a blockage after storing
the function return values to a memory block, not before the call.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #35 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #32)
> Created attachment 33557 [details]
> Patch for SH untyped_call
> 
> 	* config/sh/sh.md (untyped_call): Clobber function value
> 	registers before call.

I'm just wondering ... how did/does that work without LRA (i.e. with IRA)?
>From gcc-bugs-return-462530-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 25 09:40:37 2014
Return-Path: <gcc-bugs-return-462530-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15714 invoked by alias); 25 Sep 2014 09:40:36 -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 15674 invoked by uid 48); 25 Sep 2014 09:40:30 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
Date: Thu, 25 Sep 2014 09:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63368-4-9sjtK5E2gs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63368-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63368-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: 2014-09/txt/msg02364.txt.bz2
Content-length: 241

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
ppc32 doesn't have a 64-bit CAS instruction, so this would need to be done with
a global lock, not an atomic instruction.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #36 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #35)
> I'm just wondering ... how did/does that work without LRA (i.e. with IRA)?

I'm not sure about the old reload.  LRA makes only 3 uses of r0 and it's
relatively easy to see what is going on there with .reload comments.
The old reload makes many uses of r0 and it looks not easy to see how
does that work.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #37 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #36)
> I'm not sure about the old reload.  LRA makes only 3 uses of r0 and it's
> relatively easy to see what is going on there with .reload comments.
> The old reload makes many uses of r0 and it looks not easy to see how
> does that work.

Hm, there's still this open PR 23868 ... maybe it's somehow related or even
fixed with LRA + attachment 33557 ...

[Bug target/55212] [SH] Switch from IRA to LRA

[hp at gcc dot gnu.org]

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

--- Comment #38 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #34)
> For reference,
> i386.md emits a blockage (i.e. *using* and clobbering all
> registers).

> It
> looks all ports including SH emit a blockage after storing
the function
> return values to a memory block, not before the call.

Hm, you're right, but to me that indicates the patch covering-up a bug
elsewhere than in the sh port.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #39 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #38)
> Hm, you're right, but to me that indicates the patch covering-up a bug
> elsewhere than in the sh port.

Would it be better to file an independent PR for this?
It looks a latent problem of untyped_call implementations on some
targets, though I guess that it's hard to hit because untyped_call
is fairly exotic and the RA issue before that call can be happened
only on arches with non-orthogonal instruction set like SH which
heavily depends on R0.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #40 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I've tried to see what is going on with reload loop on movsf_ie
for gcc.c-torture/compile/20050113-1.c -O1 -m4 -ml.
It looks that the problem starts at reloading

(insn 15 10 18 2 (parallel [
            (set (subreg:SF (reg:SI 173 [ a ]) 0)
                (minus:SF (reg:SF 160 [ D.1385 ])
                    (reg:SF 160 [ D.1385 ])))
            (use (reg/v:PSI 151 ))
        ]) yyy.i:10 443 {subsf3_i}
     (expr_list:REG_DEAD (reg:SF 160 [ D.1385 ])
        (expr_list:REG_DEAD (reg/v:PSI 151 )
            (nil))))

RA inserts

   43: {r179:SF=r160:SF;use :PSI;clobber scratch;}

before that insn and

   44: {r173:SI#0=r179:SF;use :PSI;clobber scratch;}

after that where #0 means subreg:SF 0.
RA assigns register class FP_REGS to r179 here and tries to
reload insn 44 which matches movsf_ie.
SH has no direct move instruction from floating point reg to
general reg and RA chooses the alt 1 in movesf_ie of which operands
are (0) r  (1) r  (2) c  (3) X.  Then RA creates new reg r180
with assigning class GENERAL_REGS to r180 and inserts

   45: {r180:SF=r179:SF;use :PSI;clobber scratch;}

before insn 44 which is now

   44: {r173:SI#0=r180:SF;use :PSI;clobber scratch;}

RA tries to reload insn 45 which is in the same situation with
the original 44, i.e. move from FP_REGS to GENERAL_REGS.
Thus things are looping.

It looks that the problematic cases are corresponding to the cases
which were handled by the secondary reloads in the old reload.
In the above example, if RA choosed the alt 13 in movsf_ie of
which operands are (0) fr  (1) rf  (2) c  (3) y, it didn't loop.
It looks RA doesn't choose it because it requires more numbers
of registers than the alt 1.  The current movsf_ie uses

   (clobber (match_scratch:SI 3
"=X,X,Bsc,Bsc,&z,X,X,X,X,X,X,X,X,y,X,X,X,X,X"))]

and this pattern might be not good for lra.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #41 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33601&action=edit
A trial patch for reload-loop problem

My first trial is to define a special movsf_ie insn_and_split used
when lra makes new reload insns.
Here is the check-gcc result with the patch + c#29 + patch c#32:

                === gcc Summary ===

# of expected passes            83153
# of unexpected failures        21
# of unexpected successes       1
# of expected failures          119
# of unresolved testcases       3
# of unsupported tests          1514
/home/ldroot/dodes/xsh-gcc-lra/gcc/xgcc  version 5.0.0 20140913 (experimental)
(GCC) 

No "Max. number of generated reload insns per insn is achieved" errors.
I'm backing out the patch in c#27 for this test because there are
many execution errors with it.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #42 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #41)
> Created attachment 33601 [details]
> A trial patch for reload-loop problem
> 
> My first trial is to define a special movsf_ie insn_and_split used
> when lra makes new reload insns.

That also fixes the case in comment #18.

PR 54699 comes into my mind when seeing the movsf_ie patterns ... having
another movsf_ie pattern is discomforting.  But if it makes it work, so be it. 
Maybe we can try to combine the two movsf_ie insns later.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #43 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #42)
> PR 54699 comes into my mind when seeing the movsf_ie patterns ... having
> another movsf_ie pattern is discomforting.  But if it makes it work, so be
> it.  Maybe we can try to combine the two movsf_ie insns later.

Sure.  It's an experiment to clear the issue further.  I'll
apply it and the revised untyped_call patch on sh-lra branch.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #44 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Mon Sep 29 01:24:33 2014
New Revision: 215676

URL: https://gcc.gnu.org/viewcvs?rev=215676&root=gcc&view=rev
Log:
PR target/55212
* config/sh/sh-protos.h (sh_movsf_ie_ra_split_p): New prototype.
* config/sh/sh.c (sh_movsf_ie_ra_split_p): New function.
* config/sh/sh.md (movsi_ie): Use constraint "mr" instead of "m".
  (movsf_ie_ra): New insn_and_split.
  (movsf): Use movsf_ie_ra when lra_in_progress is set.


Modified:
    branches/sh-lra/gcc/config/sh/sh-protos.h
    branches/sh-lra/gcc/config/sh/sh.c
    branches/sh-lra/gcc/config/sh/sh.md

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #45 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Author: kkojima
Date: Mon Sep 29 01:27:03 2014
New Revision: 215677

URL: https://gcc.gnu.org/viewcvs?rev=215677&root=gcc&view=rev
Log:
PR target/55212
* config/sh/sh.md (untyped_call): Clobber the function value registers
  before the call.


Modified:
    branches/sh-lra/gcc/config/sh/sh.md

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #46 from Oleg Endo <olegendo at gcc dot gnu.org> ---
newlib 1.2.0 now builds without errors here.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #47 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 33615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33615&action=edit
reduced CSiBE /libpng-1.2.5 test

I've tried compiling CSiBE (-m4 -ml).  This is a stripped down pngrutil.c which
crashes in lra-spills.c (remove_pseudos).
It's a bit strange, because if the function 'test' (top of the file) is
compiled before the actual problematic function 'png_handle_cHRM', there's a
segfault.  If 'test' is left out, it ends in:

internal compiler error: in copy_rtx, at rtl.c:356

0x862e4d2 copy_rtx(rtx_def*)
    ../../gcc-sh-lra/gcc/rtl.c:356

In the segfault case, the insn is:

insn = 
(call_insn 617 775 618 42 (parallel [
            (call (mem:SI (reg/f:SI 701) [0 png_set_cHRM S4 A32])
                (const_int 0 [0]))
            (use (reg:PSI 151 ))
            (clobber (reg:SI 146 pr))
        ]) sh_tmp.cpp:395 316 {calli}
     (expr_list:REG_DEAD (reg:SI 69 fr5)
        (expr_list:REG_DEAD (reg:SI 75 fr11)
            (expr_list:REG_DEAD (reg:SI 71 fr7)
                (expr_list:REG_DEAD (reg:SI 73 fr9)
                    (expr_list:REG_DEAD (reg/f:SI 701)
                        (expr_list:REG_DEAD (reg:SI 5 r5)
                            (expr_list:REG_DEAD (reg:SI 4 r4)
                                (expr_list:REG_DEAD (reg:DF 74 fr10)
                                    (expr_list:REG_DEAD (reg:DF 72 fr8)
                                        (expr_list:REG_DEAD (reg:DF 70 fr6)
                                            (expr_list:REG_DEAD (reg:DF 68 fr4)
                                                (expr_list:REG_CALL_DECL
(symbol_ref:SI ("png_set_cHRM") [flags 0x41]  <function_decl 0xb7407c80
png_set_cHRM>)
                                                    (nil)))))))))))))
    (expr_list:SI (use (reg:SI 4 r4))
        (expr_list:SI (use (reg:SI 5 r5))
            (expr_list:DF (use (reg:DF 68 fr4))
                (expr_list:DF (use (reg:DF 70 fr6))
                    (expr_list:DF (use (reg:DF 72 fr8))
                        (expr_list:DF (use (reg:DF 74 fr10))
                            (expr_list:DF (use (mem:DF (reg/f:SI 15 r15) [0  S8
A32]))
                                (expr_list:DF (use (mem:DF (reg/f:SI 699) [0 
S8 A32]))
                                    (expr_list:DF (use (mem:DF (reg/f:SI 696)
[0  S8 A32]))
                                        (expr_list:DF (use (mem:DF (reg/f:SI
693) [0  S8 A32]))
                                            (nil))))))))))))

and the crash is caused by
loc = (reg/f:SI 699)

In the non-segfault case the input arg 'orig' in copy_rtx prints "(UnKnown
Unknown)"

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #48 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #47)
> Created attachment 33615 [details]
> reduced CSiBE /libpng-1.2.5 test
> 
> I've tried compiling CSiBE (-m4 -ml).  This is a stripped down pngrutil.c
> which crashes in lra-spills.c (remove_pseudos).
> It's a bit strange, because if the function 'test' (top of the file) is
> compiled before the actual problematic function 'png_handle_cHRM', there's a
> segfault. 

The segfault happens because of this lookup (remove_pseudos):

if ((hard_reg = spill_hard_reg[i]) != NULL_RTX)

The array at i = 699 doesn't seem to contain anything valid.

Function 'assign_spill_hard_regs' sets those values:

      spill_hard_reg[regno]
    = gen_raw_REG (PSEUDO_REGNO_MODE (regno), hard_regno);

However, in this case it never gets to it because of this:

  if (! lra_reg_spill_p)
    return n;

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #49 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #48)
> The array at i = 699 doesn't seem to contain anything valid.

It looks that
  (expr_list:DF (use (mem:DF (reg/f:SI 699) [0  S8 A32]))
which shows an argument of call_insn 617 via memory, was missed
by LRA as a usage of pseudo 699.  Here is my trial:

--- gcc/lra.c.orig    2014-09-14 09:09:57.223724308 +0900
+++ gcc/lra.c    2014-09-30 17:15:21.709508021 +0900
@@ -1615,6 +1615,20 @@ lra_update_insn_regno_info (rtx_insn *in
   if ((code = GET_CODE (PATTERN (insn))) == CLOBBER || code == USE)
     add_regs_to_insn_regno_info (data, XEXP (PATTERN (insn), 0), uid,
                  code == USE ? OP_IN : OP_OUT, false);
+  if (CALL_P (insn))
+    {
+      rtx link;
+
+      /* Take account of arguments via memory which could be implicit
+     usage of pseudo regs.  */
+      for (link = CALL_INSN_FUNCTION_USAGE (insn);
+       link != NULL_RTX;
+       link = XEXP (link, 1))
+    if (GET_CODE (XEXP (link, 0)) == USE
+        && MEM_P (XEXP (XEXP (link, 0), 0)))
+      add_regs_to_insn_regno_info (data, XEXP (XEXP (link, 0), 0), uid,
+                       OP_IN, false);
+    }
   if (NONDEBUG_INSN_P (insn))
     setup_insn_reg_info (data, freq);
 }

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #50 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Tue Sep 30 22:12:42 2014
New Revision: 215744

URL: https://gcc.gnu.org/viewcvs?rev=215744&root=gcc&view=rev
Log:
PR target/55212
* lra.c (lra_update_insn_regno_info): Handle mem args in calls.

Modified:
    branches/sh-lra/gcc/lra.c

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #51 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #50)
> Author: olegendo
> Date: Tue Sep 30 22:12:42 2014
> New Revision: 215744
> 
> URL: https://gcc.gnu.org/viewcvs?rev=215744&root=gcc&view=rev
> Log:
> PR target/55212
> * lra.c (lra_update_insn_regno_info): Handle mem args in calls.
> 
> Modified:
>     branches/sh-lra/gcc/lra.c

This fixes the issue with attachment 33615.

[Bug target/55212] [SH] Switch from IRA to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #52 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 33632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33632&action=edit
Reduced case of error: in assign_by_spills, at lra-assigns.c:1335

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #54 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33657&action=edit
A possible workaround

The patch is trying to fix the result of decompose_mem_address
so as not to assign INDEX_REG_CLASS to both base and index regs
when INDEX_REG_CLASS has one register only.

[Bug target/55212] [SH] Switch from IRA to LRA

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33657|0                           |1
        is obsolete|                            |

--- Comment #55 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33662&action=edit
revised patch

The last patch should check if base rtx and index rtx of the address are
registers.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #56 from Oleg Endo <olegendo at gcc dot gnu.org> ---
There are some LRA changes coming ...
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00948.html

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33526|0                           |1
        is obsolete|                            |

--- Comment #57 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33686&action=edit
revised patch for the problem in c#25

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #58 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #57)
> revised patch for the problem in c#25

I've looked into the remained ICEs for usual sh4-unknown-linux-gnu
test and got that they are similar to the ICE in c#25.
The original insn is a move insn from/to a memory with base+index
addressing which requires r0 for index reg on SH.  The other operand
of that insn has an equivalence with a memory of which load/store
uses r0 for some reason.  The tipical example is a memory of which
addressing is base+index and base+a_small_display_constant which
can fit to mov.[bwl] r0,@(disp,rm)/@(disp,rm),r0 instructions.
The patch introduces a new tergetm fuction and hides equivalences
for such cases.  The default tergetm fuction simply do nothing and
shouldn't impact the other targets.
The patch might be a bit overkill for SH.  We need to see the code
quality.

With c#29 + c#55 + c#57 patches, all ICEs went away on sh4-linux.
compare_tests against trunk rev.215912 says

--
New tests that FAIL:

g++.dg/cpp1y/feat-cxx14.C  -std=gnu++1y (test for excess errors)
gcc.target/sh/pr50749-sf-postinc-1.c scan-assembler-times
fmov.s\\t@r[0-9]+\\\\+,fr[0-9]+ 1
gcc.target/sh/pr50749-sf-postinc-3.c scan-assembler-times
fmov.s\\t@r[0-9]+\\\\+,fr[0-9]+ 1

Old tests that failed, that have disappeared: (Eeek!)

gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (internal compiler error)
gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (test for excess errors)
libgomp.fortran/udr14.f90   -O3 -g  (internal compiler error)
libgomp.fortran/udr14.f90   -O3 -g  (test for excess errors)
--

The first new FAIL looks a test glitch and it turned out that
pr50749-sf-postinc-1.c FAILs can be easily fixed.

It looks that the LRA change suggested in c#56 is related about
the optimization based with equivalences.  I'd like to try it
on sh-lra.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #59 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33688&action=edit
reduced CSiBE teem-1.6.0 test (-O2 sh4-linux)

Yet another lra-assigns.c:1335 ICE when compiling nrrd/kernel.c of CSiBE/
teem-1.6.0 test.  It looks that RA fails for FPUL_REGS class.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #60 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #59)
> Yet another lra-assigns.c:1335 ICE when compiling nrrd/kernel.c of CSiBE/
> teem-1.6.0 test.  It looks that RA fails for FPUL_REGS class.

It seems that the scenario starts at insn 58 in .reload.

   58: {r199:DF=float_extend(r190:SF);use :PSI;}

LRA inserts a reload insn 138 before it.

  138: {r261:SF=r190:SF;use :PSI;clobber scratch;0;}
   58: {r199:DF=float_extend(r261:SF);use :PSI;}

During inheritance/split process, LRA inserts a move insn 151
after 138 to save r190.

    Add save<-reg after:
  151: r280:SI=r190:SF#0

where LRA assigns the hard reg fr8 to r190 and #0 means subreg:SI
here.  We need fpul to save the SFmode value on fr8 to SImode
object and insn 58 is actually fcnvds instruction of which destination
is fpul.  This causes the ICE.
LRA chooses SImode at insn 151 because fr8 is a caller save register
and HARD_REGNO_CALLER_SAVE_MODE returns SImode for fr8 even with
SFmode.  SH doesn't define its specific HARD_REGNO_CALLER_SAVE_MODE
and uses the default choose_hard_reg_mode (regno, nregs, false)
implementation.  choose_hard_reg_mode chooses mode based on
HARD_REGNO_MODE_OK and returns ?Imode for float registers when
sh_hard_regno_mode_ok permits integer modes on them. 
I guess that HARD_REGNO_CALLER_SAVE_MODE should return SFmode in
this case.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #61 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33692&action=edit
a possible patch

I'm testing a patch to define a SH specific HARD_REGNO_CALLER_SAVE_MODE macro.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #62 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Just a note... I've briefly checked whether PR 54429 gets any better with LRA. 
It doesn't seem to be the case.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #63 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33705&action=edit
CSiBE result-size.cvs sh-lra+c#29+c#55+c#57+c#61

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #64 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33706&action=edit
CSiBE result-size.cvs trunk rev.215912

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #65 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
We can see ~2% code size regression on average with CSiBE.
There are some cases which register elimination doesn't
work well.  An example is

int foo (int x)
{
  int y[100];

  bar (&y[4], x);
  return y[4];
}

which is compiled to a lengthy code:

foo:
        sts.l   pr,@-r15
        mov.w   .L6,r1
        mov     r4,r5
        mov.w   .L3,r2
        sub     r1,r15
        mov.l   .L4,r0
        mov     r15,r3
        mov.w   .L5,r1
        add     #4,r3
        add     r3,r2
        add     r2,r1
        mov.l   r1,@r15
        mov     r1,r4
        jsr     @r0
        add     #16,r4
        mov.l   @r15,r1
        mov.l   @(16,r1),r0
        mov.w   .L6,r7
        add     r7,r15
        lds.l   @r15+,pr
        rts
        nop
        .align 1
.L6:
        .short  404
.L3:
        .short  400
.L5:
        .short  -400

with -O2.  It seems that SH's very limited addsi3 insn doesn't
match with the LRA's register elimination.  The canonical insn
like (set reg_a (plus reg_b const_int)) are scaned at register
elimination phase.
On SH, it's expanded to the 2 insns (set reg_a const_int) and
(set reg_a (plus reg_a reg_b)) when const_int doesn't fit in 8-bit.
This makes the elimination process unhappy.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #66 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33707&action=edit
a possible patch

With it, foo is compiled to

foo:
        sts.l   pr,@-r15
        mov.w   .L4,r1
        mov     r4,r5
        mov.l   .L3,r0
        mov     #16,r4
        sub     r1,r15
        jsr     @r0
        add     r15,r4
        mov.l   @(16,r15),r0
        mov.w   .L4,r7
        add     r7, r15
        lds.l   @r15+,pr
        rts
        nop
        .align 1
.L4:
        .short  400

and the code size regression for CSiBE is reduced to 0.74%.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #67 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33708&action=edit
CSiBE result-runtime.cvs sh-lra+c#29+c#55+c#57+c#61+c#66

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #68 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33709&action=edit
CSiBE result-runtime.cvs trunk rev.215912

0.54% runtime regression.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #69 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
The patch in c#57 disables memory equiv substitution for the memory
with base+index and base+display addressing.

static bool
sh_cannot_substitute_equiv_p (rtx subst)
{
  if (TARGET_SHMEDIA)
    return false;

  if (GET_CODE (subst) == SUBREG)
    subst = SUBREG_REG (subst);
  if (MEM_P (subst) && GET_CODE (XEXP (subst, 0)) == PLUS)
    return true;

  return false;
}

A bit surprisingly, disabling all memory equiv substitution wins
CSiBE tests.  With

static bool
sh_cannot_substitute_equiv_p (rtx subst)
{
  if (TARGET_SHMEDIA)
    return false;

  return true;
}

the code size regression for CSiBE from non LRA is reduced to 0.59%.
Looking at the improved cases, the extra save/restore insns to/from
stack disappear.  I guess that SH has not enough numbers of the hard
registers to make the equiv substitution win in the size and the speed
on average working sets.  It looks the pseudos produced to hold
the equiv values can't get hard registers for bad cases and end up
memory save/restore insns which make the code worse.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #70 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I'd like to apply the revised patches below to sh-lra branch for
looking at the problems easily.  Oleg, is it OK for you?

c#55: Fixup the result of decompose_mem_address when INDEX_REG_CLASS
  is a single register class.
c#59: Introduce target hook which disables the substitution of pseudos
  with equivalent memory values.
c#61: Define SH specific HARD_REGNO_CALLER_SAVE_MODE target macro.
c#66: Make *addsi3_compact insn_and_split and add an alternative
  which will split to (set a c) and (set (plus a b)) after reload.

I omit c#29 patch which touches lra-constraints.c and may impact on
other targets.  That patch would make it hard to compare with other
targets.  c#55 and c#59 also touch lra-constraints.c but those changes
unlikely impact on other targets.  Fortunately the test case c#28
doesn't ICE anymore without c#29.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #71 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #69)
> the code size regression for CSiBE from non LRA is reduced to 0.59%.
> Looking at the improved cases, the extra save/restore insns to/from
> stack disappear.  I guess that SH has not enough numbers of the hard
> registers to make the equiv substitution win in the size and the speed
> on average working sets.  It looks the pseudos produced to hold
> the equiv values can't get hard registers for bad cases and end up
> memory save/restore insns which make the code worse.

I don't know the details and maybe I'm totally off here ... LRA is being used
for ARM and there are almost the same amount of GP registers available on ARM
than on SH.  So either on ARM nobody has checked for such regressions, or
there's something else going wrong or missing on SH?  Or is it maybe really
that SH R0-ness thing that makes everything work (or not work) totally
different?

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #72 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #70)
> I'd like to apply the revised patches below to sh-lra branch for
> looking at the problems easily.  Oleg, is it OK for you?

Sure.  However, maybe it's better to do a merge from trunk first.  I know there
might be some conflicts w.r.t. my recent changes on trunk, in particular for PR
53513.  On the other hand, I've seen some LRA changes/fixes on trunk recently.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #73 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #71)
> I don't know the details and maybe I'm totally off here ... LRA is being
> used for ARM and there are almost the same amount of GP registers available
> on ARM than on SH.  So either on ARM nobody has checked for such
> regressions, or there's something else going wrong or missing on SH?  Or is
> it maybe really that SH R0-ness thing that makes everything work (or not
> work) totally different?

I'm not sure about ARM.  The problematic cases I've looked at are
high R0 pressure cases and IRA decided to allocate equiv value
registers to memory as most profitable ones.
It looks that the remained code size inflation came from R0-ness,
very limited base+display addressing, only one index register and
so on.  I'll attach the test cases for them to this PR after merge
from trunk and commit current patches.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #74 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #73)
> I'm not sure about ARM.  The problematic cases I've looked at are
> high R0 pressure cases and IRA decided to allocate equiv value
> registers to memory as most profitable ones.
> It looks that the remained code size inflation came from R0-ness,
> very limited base+display addressing, only one index register and
> so on.

OK, makes sense.

> I'll attach the test cases for them to this PR after merge
> from trunk and commit current patches.

Thanks!

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #75 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
FYI, merge from trunk revision 216447 as r216529.
I've fixed c#55, c#59, c#61 and c#66 so to match this merge and committed
them on sh-lra as r216532, r216533, r216533 and r216535, respectively.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #76 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33787&action=edit
a reduced test case of SCiBE compiler/vam test

compiler/vam is a test which is an example of code size regression
from non LRA compiler.  With -O2, non LRA compiler generates code like

    mov.l    r0,@(56,r15)
    mov    #64,r1
    add    #2,r0
    mov    r13,r2
    add    r15,r1
    mov.l    r0,@(60,r15)
    add    #18,r2
    mov    r13,r14
    add    #2,r0
    mov.l    r2,@(0,r1)
    mov.l    r0,@(4,r1)
    add    #2,r2
    add    #2,r0
    mov.l    r2,@(8,r1)
    mov.l    r0,@(12,r1)

and the corresponding code generated by sh-lra compiler looks like

    mov.l    r1,@(56,r15)
    mov    #17,r1
    add    r2,r1
    mov.l    r1,@(60,r15)
    mov    #2,r14
    mov    #16,r10
    mov    #18,r1
    add    r2,r1
    add    r2,r14
    add    r2,r10
    mov    #64,r2
    add    r15,r2
    mov.l    r1,@r2
    mov    #19,r1
    mov    #68,r2
    add    r13,r1
    add    r15,r2
    mov.l    r1,@r2
    mov    #20,r1
    mov    #72,r2
    add    r13,r1
    add    r15,r2
    mov.l    r1,@r2
    mov    #21,r1
    mov    #76,r2
    add    r13,r1
    add    r15,r2
    mov.l    r1,@r2

which shows that base+disp addressing mode wasn't used for the insn
(set reg (mem (plus sp N))) when N >= 64.
It looks that non LRA compiler uses targetm.legitimize_address to
handle that case and splits it to (set new_reg (plus sp M)) and
(set reg (mem (plus new_reg N-M))) so as to N-M is a legitimate
display constant for base+disp addressing.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #77 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33788&action=edit
another reduced test case of compiler/vam

This is an another test case got from compiler/vam test.
The generated code for the second foo call with non LRA compiler at
-O2 looks like

    mov.b    @(7,r8),r0
    extu.b    r0,r7
    mov.b    @(6,r8),r0
    extu.b    r0,r6
    mov.b    @(5,r8),r0
    extu.b    r0,r5
    mov.b    @(4,r8),r0
    jsr    @r9
    extu.b    r0,r4

and the corresponding code with sh-lra is here

    mov.b    @(7,r8),r0
    mov.b    r0,@(1,r15)
    mov.b    @(6,r8),r0
    mov.b    r0,@(2,r15)
    mov.b    @(5,r8),r0
    mov.b    r0,@(3,r15)
    mov.b    @(4,r8),r0
    mov.b    r0,@r15
    mov.b    @(1,r15),r0
    extu.b    r0,r7
    mov.b    @(2,r15),r0
    extu.b    r0,r6
    mov.b    @(3,r15),r0
    extu.b    r0,r5
    mov.b    @r15,r0
    jsr    @r9
    extu.b    r0,r4

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #79 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #78)
> Created attachment 33813 [details]
> a trial patch for the issue c#76
> 
> With it, the generated code for c#76 test case looks similar with
> the one with non LRA compiler. The total code size regression for
> CSiBE is reduced to 0.43%.
> The patch introduces a new targetm function legitimize_address_display.

Hm, maybe it's better to name this "legitimize_address_displacement" or
"legitimize_address_offset"?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #80 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #79)
> Hm, maybe it's better to name this "legitimize_address_displacement" or
> "legitimize_address_offset"?

Sure.  I'm not sure whether that targetm function is a good idea
or not in the first place, though.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #81 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #80)
> (In reply to Oleg Endo from comment #79)
> > Hm, maybe it's better to name this "legitimize_address_displacement" or
> > "legitimize_address_offset"?
> 
> Sure.  I'm not sure whether that targetm function is a good idea
> or not in the first place, though.

I haven't studied the LRA code, but I guess there must be some logic that
replaces the target hook function sh_legitimize_reload_address.  Either it's
using sh_legitimize_address and interpreting/expecting something different from
what it gets, or it's doing it's own "guessing" of how to legitimize the
address.  My opinion is that it's better to have an explicit transformation in
the back end (i.e. something like legitimize_address_offset) rather than
guess-and-check-if-valid.  But that's just my personal opinion.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #82 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #77)
> Created attachment 33788 [details]
> another reduced test case of compiler/vam

It seems that unsigned char memory accesses make this bad code
with LRA.
We have no (zero_extend:SI (reg) (mem)) instruction for QI/HImode.
When displacement addressing is used, (set rA (mem (plus rX disp)))
and a zero extension between registers are generated for it.
The combine phase may combine that extension and another move insn
and deletes the original extension:

      (set rA (mem (plus rX disp)))        (set rA (mem (plus rX disp)))
      (zero_extend:SI rB rA)        deleted insn
      ...                 =>  
      (set rC rB)                (zero_extend:SI rC rA)

RA will assign r0 to rA for QI/HImode and make a long live range
for R0 unfortunately.  This may cause anomalous register spills in
some case with LRA.  I guess that the old reload has something
to handle such exceptional case.  I think that the long live R0 is
problematic in the first place, though.
The above combine doesn't happen if rA is a hard reg of which reg
class is likely spilled to avoid such problem.  We can split
(set rA (mem (plus rX disp))) to two move insns via r0 which is
a likely spilled register.  It will make some codes worse but it
wins on average.
CSiBE shows 0.036% total code size improvement when the above split
is done in prepare_move_operands for load only and 0.049% when
done for both load and store.  I'll attach the patch for it.  With
it, the generated code for the 2nd call of the test case looks like

    mov.b    @(7,r8),r0
    mov    r0,r7
    mov.b    @(6,r8),r0
    extu.b    r7,r7
    mov    r0,r6
    mov.b    @(5,r8),r0
    extu.b    r6,r6
    mov    r0,r5
    mov.b    @(4,r8),r0
    extu.b    r5,r5
    jsr    @r9
    extu.b    r0,r4

Spills to memory went away, though it's still worse than non LRA case.
Before that patch, I've tried several splitters for zero_extend of
which operands are register and memory with displacement addressing.
They gave similar codes against the test case but can't win CSiBE on
average.  Even with some peepholes to fix regressions, the total code
size of CSiBE increases 0.05-0.1%.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #83 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 33992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33992&action=edit
a patch for the issue c#77

Interestingly, this reduces the total text size of CSiBE test ~0.04%
at -O2 even for the trunk i.e. with the old reload.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #84 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
FYI, merge from trunk revision 217978 as sh-lra revision 217980 to
apply the lra remat changes on trunk.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #85 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 34135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34135&action=edit
patch to add -mlra option

I'd like to apply the patch to add a transitional option -mlra
like ARM and the revised patches in c#78 and c#83 on sh-lra branch
after merge from trunk.  It helps me a lot when building, comparing
and testing sh-lra compilers.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #85 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 34135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34135&action=edit
patch to add -mlra option

I'd like to apply the patch to add a transitional option -mlra
like ARM and the revised patches in c#78 and c#83 on sh-lra branch
after merge from trunk.  It helps me a lot when building, comparing
and testing sh-lra compilers.

--- Comment #86 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #85)
> Created attachment 34135 [details]
> patch to add -mlra option
> 
> I'd like to apply the patch to add a transitional option -mlra
> like ARM and the revised patches in c#78 and c#83 on sh-lra branch
> after merge from trunk.  It helps me a lot when building, comparing
> and testing sh-lra compilers.

Sure, makes sense to me.  It's probably better to revert my commit r215244 to
reinstate reload on the sh-lra branch.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #87 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #86)
> (In reply to Kazumoto Kojima from comment #85)
> > Created attachment 34135 [details]
> > patch to add -mlra option
> > 
> > I'd like to apply the patch to add a transitional option -mlra
> > like ARM and the revised patches in c#78 and c#83 on sh-lra branch
> > after merge from trunk.  It helps me a lot when building, comparing
> > and testing sh-lra compilers.
> 
> Sure, makes sense to me.  It's probably better to revert my commit r215244
> to reinstate reload on the sh-lra branch.

Sorry, your patch in attachment 34135 does that already of course.

We could also  try to merge the sh-lra branch into trunk for the gcc 5 release.
 If all the LRA changes are conditional and the code paths are not changed if
-mlra is not specified, it should be OK to do it.

Some of the changes could probably also be applied unconditionally, such as
r215241 and r215243.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #88 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
For the record, here is the sh-lra revisions.
218191: Merge from trunk revision 218173.
218192: Add legitimize_address_displacement target macto.
218193: Split QI/HImode displacement addressing load/store via R0.
        Use std::swap in the sh-lra change.
218194: Add -mlra option.

BTW, there are new ICEs with
  internal compiler error: in split_reg, at lra-constraints.c:4909
It looks that DCmode move causes them on sh-lra.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #89 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 34159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34159&action=edit
a reduced c++ test case (-O2 -std=gnu++11)

Here is related lines of lra-constraints.c:

4906      save = emit_spill_move (true, new_reg, original_reg);
4907      if (NEXT_INSN (save) != NULL_RTX)
4908        {
4909          lra_assert (! call_save_p);

where

(gdb) p call_save_p
$2 = true
(gdb) call debug_rtx(new_reg)    
(reg:DC 270)
(gdb) call debug_rtx(original_reg)
(reg:DC 220 [+8 ])

and emit_spill_move emits 3 instructions

(insn 106 0 107 (clobber (reg:DC 270)) -1
     (nil))

(insn 107 106 108 (parallel [
            (set (subreg:DF (reg:DC 270) 0)
                (subreg:DF (reg:DC 220 [+8 ]) 0))
            (use (reg:SI 154 fpscr0))
            (clobber (scratch:SI))
        ]) -1
     (nil))

(insn 108 107 0 (parallel [
            (set (subreg:DF (reg:DC 270) 8)
                (subreg:DF (reg:DC 220 [+8 ]) 8))
            (use (reg:SI 154 fpscr0))
            (clobber (scratch:SI))
        ]) -1
     (nil))

with emit_move_complex function in expr.c.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #90 from Oleg Endo <olegendo at gcc dot gnu.org> ---
For the record, the patches to enable LRA on SH have been committed.  The last
revision of the committed patch series is r218892.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #91 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Re: [RFC PATCH 9/9] [SH] Split QI/HImode load/store via r0

(In reply to Kazumoto Kojima from comment #83)
> Created attachment 33992 [details]
> a patch for the issue c#77
> 
> Interestingly, this reduces the total text size of CSiBE test ~0.04%
> at -O2 even for the trunk i.e. with the old reload.

I've checked this change to prepare_move_operands without LRA with trunk
r218988, to see whether it should be enabled for non-LRA.

I can confirm the -1140 bytes / -0.04% on the CSiBE set.  However, as mentioned
in comment #82, it results in unnecessary zero extensions before other
logic/arithmetic because combine doesn't (want to) see through the R0 hardreg.  

Unnecessary sign/zero extensions are actually a separate topic (e.g. PR 53987).
 If there was a good sign/zero extension elimination in place, this wouldn't be
an issue here.

I've tried disabling the prepare_move_operands change and instead adding the
following splitters, which are done after combine and before RA:

(define_split
  [(set (match_operand:SI 0 "arith_reg_dest")
    (sign_extend:SI (match_operand:QIHI 1 "displacement_mem_operand")))]
  "TARGET_SH1 && can_create_pseudo_p ()
   && !refers_to_regno_p (R0_REG, R0_REG + 1, operands[1], NULL)"
  [(set (match_dup 2) (reg:SI R0_REG))
   (set (reg:SI R0_REG) (sign_extend:SI (match_dup 1)))
   (set (match_dup 0) (reg:SI R0_REG))
   (set (reg:SI R0_REG) (match_dup 2))]
{
  operands[2] = gen_reg_rtx (SImode);
})

(define_split
  [(set (match_operand:QIHI 0 "arith_reg_dest")
    (match_operand:QIHI 1 "displacement_mem_operand"))]
  "TARGET_SH1 && can_create_pseudo_p ()
   && !refers_to_regno_p (R0_REG, R0_REG + 1, operands[1], NULL)"
  [(set (match_dup 2) (reg:SI R0_REG))
   (set (reg:QIHI R0_REG) (match_dup 1))
   (set (match_dup 0) (reg:QIHI R0_REG))
   (set (reg:SI R0_REG) (match_dup 2))]
{
  operands[2] = gen_reg_rtx (SImode);
})

With these two splitters for mem loads I get exactly the same -1140 bytes /
-0.04% on the CSiBE set.

The simple test case

int test_tst (unsigned char* x, int y, int z)
{
  return x[4] ? y : z;
}

does not contain the extu.b insn anymore, but instead we get this:
        mov.b    @(4,r4),r0
        mov    r0,r1
        tst    r1,r1        << should be: tst r0,r0
        bf    .L4
    mov    r6,r5
.L4:
    rts
    mov    r5,r0


Other cases of new unnessecary zero-extension insns are in e.g. in
jpeg-6b/jdcoefct.s.

In linux-2.4.23-pre3-testplatform/arch/testplatform/kernel/signal.s some mov
reg,reg insns end up as:
    extu.b    r0,r0
    mov.b    r0,@(1,r8)
    mov    r9,r0
    shlr16    r0
    extu.b    r0,r0
    mov.b    r0,@(2,r8)
    mov    r9,r0
    shlr16    r0
    shlr8    r0
    mov.b    r0,@(3,r8)
    extu.b    r1,r0
    mov.b    r0,@(4,r8)
    mov    r1,r0
        ....
those can be wallpapered with peepholes though.

I've also tried using the splitters instead of the prepare_move_operands hunk
with LRA.  But then I get spill errors on QI/HImode stores with displacement
addressing.

I've also tried removing the prepare_move_operands hunk with LRA.  Compared
with trunk no-lra I get:
sum:  3368431 -> 3378515    +10084 / +0.299368 %

And LRA + prepare_move_operands hunk vs. trunk no-lra is:
sum:  3368431 -> 3376507    +8076 / +0.239756 %

Doing this kind of pre-RA R0 pre-allocation seems to result in better RA
choices w.r.t. commutative insns such as addition.

After all, maybe it's worth trying out an SH specific R0 pre-alloc pass that
offloads some of the RA choices.  Of course it will not be able to solve issues
that arise when spilling code is generated that uses QI/HImode mem accesses
during the RA/spilling process.

R0 is the most difficult candidate, but I've also seen reports about FPU code
ICEing due FR0 spill failures when there are lots of (interdependent?) FMAC
insns at -O3 (e.g. FP matrix multiplication).  Another register (class), of
which there is only one on SH, would be the MACH/MACL pair.  Currently
MACH/MACL are fixed hardregs.  Early experiments to allow MACH/MACL to be used
by RA and adding the MAC insn showed some problems (see PR 53949 #c3).

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #92 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sun Dec 21 23:37:42 2014
New Revision: 218999

URL: https://gcc.gnu.org/viewcvs?rev=218999&root=gcc&view=rev
Log:
gcc/
    PR target/55212
    * config/sh/sh.md (*addsi3_compact): Add parentheses around &&
    condition.  Add comments.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/sh.md

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #94 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Kaz, do you think we can enable LRA by default for GCC 6?

Some early results from the AMS optimization show new R0 spill failures.  For
example, AMS uses @(R0,Rn) address modes more often.  Although I still would
like to try this R0 prealloc pass, I don't know when I will have time for that.
 Enabling LRA might be easier.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #95 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #94)
> Kaz, do you think we can enable LRA by default for GCC 6?

I think that it's OK to make LRA default on trunk, even if it's
better with your R0 pre-allocating pass.
The last time I tested -mlra, there are some regressions, though.
I'd like to test it again.  Could you see any serious problems on
sh-elf with -mlra?

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #96 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #95)
> 
> I think that it's OK to make LRA default on trunk, even if it's
> better with your R0 pre-allocating pass.

The R0 pre-alloc pass could be a further improvement, even with LRA.

> The last time I tested -mlra, there are some regressions, though.
> I'd like to test it again.  Could you see any serious problems on
> sh-elf with -mlra?

I haven't tried yet.  I will do a full toolchain rebuild and test with -mlra
enabled by default.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #97 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #96)
> 
> I haven't tried yet.  I will do a full toolchain rebuild and test with -mlra
> enabled by default.

I've compared the results of r227512 without LRA and r227682 with LRA.  Below
are the new failures.


Running target sh-sim/-m2/-mb
FAIL: gcc.c-torture/execute/20040709-2.c   -Os  execution test
FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36

Running target sh-sim/-m2/-ml
FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36

Running target sh-sim/-m2a/-mb
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36

Running target sh-sim/-m4/-mb
FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2
AIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36

Running target sh-sim/-m4/-ml
FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36

Running target sh-sim/-m4a/-mb
FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36

Running target sh-sim/-m4a/-ml
FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28
FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #98 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #97)
> I've compared the results of r227512 without LRA and r227682 with LRA. 
> Below are the new failures.

A typical example of pr64661-x.c regressions is:
[LRA]
test_37_1:
        stc     gbr,r3  ! 22    store_gbr       [length = 2]
        mova    1f,r0   ! 6     atomic_add_fetchqi_soft_tcb     [length = 20]
        mov     #(0f-1f),r1
        .align 2
        mov.l   r0,@(128,gbr)
0:      mov.b   @(4,r3),r0
        ...

[no-LRA]
test_37_1:
        mova    1f,r0   ! 6     atomic_add_fetchqi_soft_tcb     [length = 20]
        mov     #(0f-1f),r1
        .align 2
        mov.l   r0,@(128,gbr)
0:      mov.b   @(4,gbr),r0
        ...

where

(define_insn_and_split "atomic_fetch_<fetchop_name><mode>_soft_tcb"
  [(set (match_operand:QIHISI 0 "arith_reg_dest" "=&r")
        (match_operand:QIHISI 1 "atomic_mem_operand_1" "=SraSdd"))
   ...
   (clobber (reg:SI R0_REG))
   (clobber (reg:SI R1_REG))]
  "TARGET_ATOMIC_SOFT_TCB"
{
  return "\r    mova    1f,r0"                  "\n"
         "      .align 2"                       "\n"
         "      mov     #(0f-1f),r1"            "\n"
         "      mov.l   r0,@(%O3,gbr)"          "\n"
         "0:    mov.<bwl>       %1,r0"          "\n"
         ...

The .ira dump shows

(insn 6 5 7 2 (parallel [
            (set (reg:QI 167)
                (plus:QI (mem/v:QI (plus:SI (reg:SI 144 gbr)
                            (const_int 4 [0x4])) [-1  S1 A8])
                    (const_int 1 [0x1])))
            (set (mem/v:QI (plus:SI (reg:SI 144 gbr)
                        (const_int 4 [0x4])) [-1  S1 A8])
                (unspec:QI [
                        (plus:QI (mem/v:QI (plus:SI (reg:SI 144 gbr)
                                    (const_int 4 [0x4])) [-1  S1 A8])
                            (const_int 1 [0x1]))
                    ] UNSPEC_ATOMIC))
...

which looks the code generated with the old RA.  It seems that
old RA passes gbr+4 addressing as is but LRA spills gbr with r3
according to the constraint SraSdd.  Perhaps LRA is more strict
in this regard.
I guess that these pr64661-x.c regressions are not so problem, though.
I'm not sure whether hiconst.c regression is serious or not.
The serious one would be

Running target sh-sim/-m2/-mb
FAIL: gcc.c-torture/execute/20040709-2.c   -Os  execution test

My sh4-unknown-linux-gnu test also shows another execution
errors for libstdc++-v3.

New tests that FAIL:

22_locale/money_get/get/wchar_t/14.cc execution test
22_locale/money_get/get/wchar_t/19.cc execution test
22_locale/money_get/get/wchar_t/22131.cc execution test
22_locale/money_get/get/wchar_t/38399.cc execution test
22_locale/money_get/get/wchar_t/39168.cc execution test
22_locale/money_get/get/wchar_t/6.cc execution test
22_locale/money_get/get/wchar_t/8.cc execution test
22_locale/money_get/get/wchar_t/9.cc execution test
22_locale/money_put/put/wchar_t/39168.cc execution test
22_locale/money_put/put/wchar_t/5.cc execution test
22_locale/money_put/put/wchar_t/6.cc execution test

These tests compiled with -mlra don't fail with libstdc++-v3
library compiled with -mno-lra, i.e. libstdc++-v3 is miscompiled
with -mlra.  These wrong code problems should be resolved before
witch to LRA.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #99 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #98)
> I guess that these pr64661-x.c regressions are not so problem, though.

I agree.

> I'm not sure whether hiconst.c regression is serious or not.

I think we can ignore this for now.  It's about loading/sharing constants. 
There are more constant related inefficiencies which can be addressed later.

> The serious one would be
> 
> Running target sh-sim/-m2/-mb
> FAIL: gcc.c-torture/execute/20040709-2.c   -Os  execution test

I will have a look at it.


> My sh4-unknown-linux-gnu test also shows another execution
> errors for libstdc++-v3.
> 
> New tests that FAIL:
> 
> 22_locale/money_get/get/wchar_t/14.cc execution test
> 22_locale/money_get/get/wchar_t/19.cc execution test
> 22_locale/money_get/get/wchar_t/22131.cc execution test
> 22_locale/money_get/get/wchar_t/38399.cc execution test
> 22_locale/money_get/get/wchar_t/39168.cc execution test
> 22_locale/money_get/get/wchar_t/6.cc execution test
> 22_locale/money_get/get/wchar_t/8.cc execution test
> 22_locale/money_get/get/wchar_t/9.cc execution test
> 22_locale/money_put/put/wchar_t/39168.cc execution test
> 22_locale/money_put/put/wchar_t/5.cc execution test
> 22_locale/money_put/put/wchar_t/6.cc execution test
> 
> These tests compiled with -mlra don't fail with libstdc++-v3
> library compiled with -mno-lra, i.e. libstdc++-v3 is miscompiled
> with -mlra.  These wrong code problems should be resolved before
> witch to LRA.

Hm .. those don't fail on sh-elf ... maybe something related to the atomics? 
Atomics are off by default for sh-elf, but on for sh-linux.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #100 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #99)
> Hm .. those don't fail on sh-elf ... maybe something related to the atomics?
> Atomics are off by default for sh-elf, but on for sh-linux.

Maybe.  It could be something atomic related.
For 14.cc case, replacing locale.o and cxx11-shim_facets.o with
ones from non-LRA build fixes the failure.
For example, std::locale::locale(std::locale const&) is compiled
very differently in LRA/non-LRA builds.  Strangely, the problem
can't be reproduced with recompiling these objects with -mlra in
non-LRA builds.  The above constructor is compiled to

[LRA build]
   0:   c6 2f           mov.l   r12,@-r15
   2:   0b c7           mova    30 <_ZNSt6localeC1ERKS_+0x30>,r0
   4:   0a dc           mov.l   30 <_ZNSt6localeC1ERKS_+0x30>,r12       ! 0
<_ZNSt6localeC1ERKS_>
   6:   0c 3c           add     r0,r12
   8:   52 62           mov.l   @r5,r2
   a:   0a d0           mov.l   34 <_ZNSt6localeC1ERKS_+0x34>,r0        ! 0
<_ZNSt6localeC1ERKS_>
   c:   ce 01           mov.l   @(r0,r12),r1
   e:   18 21           tst     r1,r1
  10:   09 8d           bt.s    26 <_ZNSt6localeC1ERKS_+0x26>
  12:   22 24           mov.l   r2,@r4
  14:   02 c7           mova    20 <_ZNSt6localeC1ERKS_+0x20>,r0
  16:   f3 61           mov     r15,r1
  18:   fa ef           mov     #-6,r15
  1a:   22 63           mov.l   @r2,r3
  1c:   01 73           add     #1,r3
  1e:   32 22           mov.l   r3,@r2
  20:   13 6f           mov     r1,r15
  22:   0b 00           rts     
  24:   f6 6c           mov.l   @r15+,r12
  26:   22 61           mov.l   @r2,r1
  28:   01 71           add     #1,r1
  2a:   12 22           mov.l   r1,@r2
  2c:   0b 00           rts     
  2e:   f6 6c           mov.l   @r15+,r12
        ...
                        30: R_SH_GOTPC  _GLOBAL_OFFSET_TABLE_
                        34: R_SH_GOT32  __pthread_key_create
[non-LRA build]
   0:   c6 2f           mov.l   r12,@-r15
   2:   0b c7           mova    30 <_ZNSt6localeC1ERKS_+0x30>,r0
   4:   0a dc           mov.l   30 <_ZNSt6localeC1ERKS_+0x30>,r12       ! 0
<_ZNSt6localeC1ERKS_>
   6:   22 4f           sts.l   pr,@-r15
   8:   0c 3c           add     r0,r12
   a:   52 61           mov.l   @r5,r1
   c:   09 d0           mov.l   34 <_ZNSt6localeC1ERKS_+0x34>,r0        ! 0
<_ZNSt6localeC1ERKS_>
   e:   ce 02           mov.l   @(r0,r12),r2
  10:   28 22           tst     r2,r2
  12:   07 8d           bt.s    24 <_ZNSt6localeC1ERKS_+0x24>
  14:   12 24           mov.l   r1,@r4
  16:   13 64           mov     r1,r4
  18:   07 d1           mov.l   38 <_ZNSt6localeC1ERKS_+0x38>,r1        ! 1a
  1a:   03 01           bsrf    r1
  1c:   01 e5           mov     #1,r5
  1e:   26 4f           lds.l   @r15+,pr
  20:   0b 00           rts     
  22:   f6 6c           mov.l   @r15+,r12
  24:   12 62           mov.l   @r1,r2
  26:   01 72           add     #1,r2
  28:   22 21           mov.l   r2,@r1
  2a:   26 4f           lds.l   @r15+,pr
  2c:   0b 00           rts     
  2e:   f6 6c           mov.l   @r15+,r12
        ...
                        30: R_SH_GOTPC  _GLOBAL_OFFSET_TABLE_
                        34: R_SH_GOT32  __pthread_key_create
  38:   1a 00           sts     macl,r0
                        38: R_SH_PLT32  _ZN9__gnu_cxx12__atomic_addEPVii
        ...

Perhaps the both codes are ok, though something odd happens
on atomic things anyway.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #101 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
> Perhaps the both codes are ok, though something odd happens
> on atomic things anyway.

I've forgotten that some atomic builtins fail with spill_failure
in class 'R0_REGS' for old RA.  So libstdc++-v3 was configured
so to undefine _GLIBCXX_ATOMIC_BUILTINS for old RA and we see
the above difference.  I've tried to disable it on LRA build
and rebuild libstdc++-v3 libs.  14.exe still fails and it looks
very sensitive with code/option changes.  Weird.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #102 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #101)
> 
> I've forgotten that some atomic builtins fail with spill_failure
> in class 'R0_REGS' for old RA.  So libstdc++-v3 was configured
> so to undefine _GLIBCXX_ATOMIC_BUILTINS for old RA and we see
> the above difference.

Ah!  I always wondered why those failures disappeared from your nightly tests. 
Did you do this locally in your setup, or has this been committed at some time?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #103 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #102)
> Ah!  I always wondered why those failures disappeared from your nightly
> tests.  Did you do this locally in your setup, or has this been committed at
> some time?

I did nothing.  Looks simply fragile like as other reload ICEs.
libstdc++-v3 conftest catches it, (un)fortunately.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #104 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #103)
> I did nothing.  Looks simply fragile like as other reload ICEs.
> libstdc++-v3 conftest catches it, (un)fortunately.

Ah, I understand.  Thanks.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #105 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 36328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36328&action=edit
20040709-2.s without LRA (PASS)

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #106 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 36329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36329&action=edit
20040709-2.s with LRA (FAIL)

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #107 from Oleg Endo <olegendo at gcc dot gnu.org> ---
> > The serious one would be
> > 
> > Running target sh-sim/-m2/-mb
> > FAIL: gcc.c-torture/execute/20040709-2.c   -Os  execution test
> 

I have tried compiling that test case outside of the testsuite with -m2 -mb -Os
with and without LRA.  There are lots of differences in the asm output, but the
LRA version executable runs fine and doesn't abort.

Running the test inside the testsuite fails reliably.  I could reduce it to the 

testZ ();

subtest.

It passes with with
make -k check RUNTESTFLAGS="execute.exp=20040709-2.c
--target_board=sh-sim\{-m2/-mb/-save-temps/-mno-lra}"

It fails with (-mlra enabled by default)
make -k check RUNTESTFLAGS="execute.exp=20040709-2.c
--target_board=sh-sim\{-m2/-mb/-save-temps}"

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #108 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #107)

The problem is the define_split at sh.md line 893 (the part at 945).  Or
actually, it's sh_find_set_of_reg.  Adding this

diff --git a/gcc/config/sh/sh-protos.h b/gcc/config/sh/sh-protos.h
index 3e4211b..b4866c1 100644
--- a/gcc/config/sh/sh-protos.h
+++ b/gcc/config/sh/sh-protos.h
@@ -199,8 +199,13 @@ sh_find_set_of_reg (rtx reg, rtx_insn* insn, F stepfunc,
     {
       if (BARRIER_P (result.insn))
        break;
+
+      if (CALL_P (result.insn))
+       break;
+
       if (!NONJUMP_INSN_P (result.insn))
        continue;
+
       if (reg_set_p (reg, result.insn))
        {
          result.set_rtx = set_of (reg, result.insn);

Fixes the test case for me.  It seems I should really fix PR 67061, which looks
like the same issue (and the other issue with sh_find_set_of_reg which was
fixed with a modified_between_p).

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #109 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #108)
> 
> It seems I should really fix PR 67061, which
> looks like the same issue (and the other issue with sh_find_set_of_reg which
> was fixed with a modified_between_p).

I have posted a patch for PR 67061 attachment 36331
With that patch

make -k check RUNTESTFLAGS="execute.exp=20040709-2.c
--target_board=sh-sim\{-m2/-mb/-mlra}"

passes the tests.  Maybe it also fixes the std::locale issues.  Kaz, could you
please have a look?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #110 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #109)
> Maybe it also fixes the std::locale issues.  Kaz, could
> you please have a look?

It doesn't fix those failures.  I'll try to bisect that issue.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
Bug 55212 depends on bug 67573, which changed state.

Bug 67573 Summary: [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573

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

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #112 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I had a quick look at the gcc.target/sh/hiconst.c test case:

int rab (char *pt, int *pti)
{
  pt[2] = 0;
  pti[3] = 0;

  return 0;
}

without LRA:
        mov     #0,r0
        mov.b   r0,@(2,r4)
        rts     
        mov.l   r0,@(12,r5)


with LRA:
        mov     #0,r0
        mov.b   r0,@(2,r4)
        mov     #0,r1
        mov.l   r1,@(12,r5)
        rts     
        mov     #0,r0

Without LRA it seems some of the constant loads are CSE'ed, but the return
value constant load remains and reload-something figures it out.  With LRA it
seems that for the SImode store it wants to use R1, but for the QImode store it
needs to use R0.  It then rematerializes the constant load.  Increasing the
costs of constants:

@@ -3574,7 +3574,7 @@
          return true;
        }
       if (CONST_OK_FOR_I08 (INTVAL (x)))
-        *total = 0;
+        *total = 4;
       else if ((outer_code == AND || outer_code == IOR || outer_code == XOR)
               && CONST_OK_FOR_K08 (INTVAL (x)))
         *total = 1;

results in:
        mov     #0,r1
        mov     r1,r0
        mov.b   r0,@(2,r4)
        mov.l   r1,@(12,r5)
        rts     
        mov     r1,r0

That would make the hiconst test pass again of course, but is not much better. 
Probably a combination of constant optimization (PR 65069, PR 63390, PR 51708,
PR 54682) and an R0 pre-alloc would give optimal results.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #113 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 36363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36363&action=edit
CSiBE I08 const cost = 0 vs. cost = 1, no LRA

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #114 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 36364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36364&action=edit
CSiBE I08 const cost = 0 vs. cost = 1, LRA

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #115 from Oleg Endo <olegendo at gcc dot gnu.org> ---
It seems that it's already enough to set the cost for I08 from 0 to 1:

Index: gcc/config/sh/sh.c
===================================================================
--- gcc/config/sh/sh.c  (revision 227958)
+++ gcc/config/sh/sh.c  (working copy)
@@ -3574,7 +3574,7 @@
          return true;
        }
       if (CONST_OK_FOR_I08 (INTVAL (x)))
-        *total = 0;
+        *total = 1;
       else if ((outer_code == AND || outer_code == IOR || outer_code == XOR)
               && CONST_OK_FOR_K08 (INTVAL (x)))
         *total = 1;

This will reduce the rematerializations and thus increase reg live ranges in
other places.

attachment 36363 and attachment 36364 are CSiBE comparistions with and without
LRA.

Without LRA: sum:  3347407 -> 3345667    -1740 / -0.051981 %
With LRA:    sum:  3348933 -> 3347433    -1500 / -0.044790 %

Although there are quite some increases, overall it seems beneficial...

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #116 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #91)
> 
> I can confirm the -1140 bytes / -0.04% on the CSiBE set.

Since r228176 this is no longer true.  Now the gap of no-LRA and LRA is a bit
wider:

3345527 -> 3334351    -11176 / -0.334058 %

See also PR 67732.

I think now the difference is too big to enable LRA by default for GCC 6.  We
should wait until the number gets better again.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #117 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #94)
> Kaz, do you think we can enable LRA by default for GCC 6?
> 
> Some early results from the AMS optimization show new R0 spill failures. 
> For example, AMS uses @(R0,Rn) address modes more often.  Although I still
> would like to try this R0 prealloc pass, I don't know when I will have time
> for that.  Enabling LRA might be easier.

So I've tried compiling the CSiBE set with AMS and LRA.  The AMS branch still
has some problems, but without LRA CSiBE at least compiles without errors. 
With LRA I get a lot of:

ll_rw_blk.i: In function 'generic_plug_device':
ll_rw_blk.i:8464:1: error: unable to find a register to spill
 }
 ^
ll_rw_blk.i:8464:1: error: this is the insn:
(insn 32 74 61 5 (set (mem/j:QI (plus:SI (reg/v/f:SI 170 [ q ])
                (reg:SI 283 [272])) [0 q_2(D)->plugged+0 S1 A32])
        (reg:QI 0 r0)) ll_rw_blk.i:8462 276 {*movqi}
     (expr_list:REG_DEAD (reg:SI 283 [272])
        (expr_list:REG_DEAD (reg:QI 0 r0)
            (nil))))
ll_rw_blk.i:8464:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1431

It seems it has trouble rearranging this:

       mov.b  r0,@(Rm,Rn)

into
       mov.b  Rx,@(R0,Rn)

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #126 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I'm retesting a native build with LRA enabled by default now and report back.

If that works, I will try to build and boot a kernel.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #127 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #126)
> I'm retesting a native build with LRA enabled by default now and report back.
> 
> If that works, I will try to build and boot a kernel.

OK, that fails with:

../../../src/libgcc/libgcc2.c: In function '__addvsi3':
../../../src/libgcc/libgcc2.c:84:1: error: unable to generate reloads for:
   84 | }
      | ^
(call_insn 29 28 30 4 (parallel [
            (call (mem:SI (symbol_ref:SI ("abort") [flags 0x41] <function_decl
0x3f800580 abort>) [0 __builtin_abort S4 A32])
                (const_int 0 [0]))
            (use (reg:SI 154 fpscr0))
            (use (reg:SI 12 r12))
            (clobber (reg:SI 146 pr))
            (clobber (reg:SI 176))
        ]) "../../../src/libgcc/libgcc2.c":81:5 228 {call_pcrel}
     (expr_list:REG_DEAD (reg:SI 154 fpscr0)
        (expr_list:REG_CALL_DECL (symbol_ref:SI ("abort") [flags 0x41]
<function_decl 0x3f800580 abort>)
            (expr_list:REG_NORETURN (const_int 0 [0])
                (expr_list:REG_EH_REGION (const_int 0 [0])
                    (nil)))))
    (nil))
during RTL pass: reload

Attaching the full build log which also contains the intermediate source.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #128 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 57498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57498&action=edit
Build log including preprocessed source for building gcc-14 (20240221) natively
with LRA

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #129 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
A reduced 2-line testcase for -O2 -fpic -mlra:

extern void bar (void) __attribute__ ((__noreturn__));
void foo (void) {  bar (); }

Looks LRA reveals again pcrel call insn_and_splits scratch register allocation
problem.  Maybe the similar issue with sibcall_vallue_pcrel which is commented
by Oleg at the just before that insn_and_split.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #130 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58831&action=edit
a trial patch for c#129

A quick fix may be:

* config/sh/sh.md
(call_pcrel, call_value_pcrel, sibcall_pcrel): Use a fixed call clobberd
register
for the address.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #131 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58832&action=edit
a patch to fix broken_move for -mlra

BTW, I fould an oversite when adding movsf_ie_ra insn_and_split too.
There is an ICE for __powisf2 with -O2 -mlra durring libgcc build. With -mlra,
movsf expander might generate constant load with registers instead of
scratches.
broken_move assumed a scratch only when handles fldi0/1.

* config/sh/sh.cc
(broken_move): Take movsf_ie_ra into account for fldi cases.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #132 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58833&action=edit
a patch to fix a reload issue in movsf with LRA

Another ICEs with LRA can be found for some conner cases. The first one has a
one-liner testcase. It makes never ending reload sequence which ends up with an
ICE with -O2 -mlra.

float foo (float a) { return (__builtin_isinf  (a)) ? __builtin_huge_valf () :
a; }

A trial is:

* config/sh/sh.md
(movsf): Use movsf_ie instead of movsf_ie_ra for simple reg-reg move.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #133 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58834&action=edit
a testcase for r0-starvation issue with -mlra

The second one I've found has a bit lengthy testcases for -O2 -mlra.
It seems that LRA fails with r0-starvation for the pseudo code sequence like

  98: r361:SI=sign_extend([r332:SI+0x2])
  607: r178:SI=r361:SI
  101: r360:HI=r178:SI
  606: [r336:SI+r359:SI]=r360:HI

for example, which tries to use R0_REGS for both r361 and r359.
If I remember correctly, a similar issue for mov<mode> was already known to be
problematic with LRA and was handled specifically in
sh.cc:prepare_move_operands.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #134 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58835&action=edit
another testcase for c#133

Another testcase.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #135 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58836&action=edit
a trial patch for c#133

Simlar changes for extend<mode>si2 and mov<mode> which define new
insn_and_split to force hardware r0 reg for the problematic cases so as to
shorten r0 live range.

* config/sh/sh.md (extend<mode>si2_short_mem_disp_z,
mov<mode>_store_mem_index): New insn_and_split patterns.
(extend<mode>si2, mov<mode>): Use them for LRA.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #136 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Hope these observations help for clarifying issues.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #137 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #136)
> Hope these observations help for clarifying issues.

Kaz, thanks so much for chiming in and looking at these after such a long time!
 It's really appreciated!

My concern is that, LRA was supposed to make things _better_ than old reload. 
But now  we have to add even more hacks....

Perhaps some of the fixes should go into LRA itself -- in particular the one
for R0 in comment #135. 

We already have the R0 constraint:

(define_insn "*extend<mode>si2_compact_mem_disp"
  [(set (match_operand:SI 0 "arith_reg_dest" "=z,r")
                                              ^^^ 

.. your patch to add an explicit R0 clobber seems a good workaround, but also
shows that something in LRA land is not working properly, I think.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #138 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #137)
> (In reply to Kazumoto Kojima from comment #136)
> > Hope these observations help for clarifying issues.
> 
> Kaz, thanks so much for chiming in and looking at these after such a long
> time!  It's really appreciated!

I agree. It was very pleasant this morning to hear from Kaz again. Welcome
back!

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #139 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 58859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58859&action=edit
testcase for attachment 58836 with -mno-lra

(In reply to Kazumoto Kojima from comment #135)
> Created attachment 58836 [details]
> a trial patch for c#133
> 
> Simlar changes for extend<mode>si2 and mov<mode> which define new
> insn_and_split to force hardware r0 reg for the problematic cases so as to
> shorten r0 live range.
> 
> * config/sh/sh.md (extend<mode>si2_short_mem_disp_z,
> mov<mode>_store_mem_index): New insn_and_split patterns.
> (extend<mode>si2, mov<mode>): Use them for LRA.

The attached reproducer triggers R0 spill failures after applying attachment
58836 when compiling with -O2 -m4-single -mno-lra.

It seems to compile OK with -mlra though (with or without the patch).
The code generated with LRA seems worse (more instructions).


If we decide to go down the path of adding the R0 clobbers to all those
R0-problematic insns, then it is going to become incompatible with the old
reload framework it seems.  I'm not sure what's the overall plan there --
whether old reload and -mno-lra will be kept around for a while or whether it
will be removed completely at once.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #140 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Created attachment 58860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58860&action=edit
testcase for attachment  58831,  58832,  58833,  58836

The attached test case, when compiled with 'sh-elf-gcc -O2 -m4-single -mlra' on
current development branch (GCC 15) fails with the following ICE:

during RTL pass: mach
genmenu.cpp: In member function 'void
MyMenu::preparePopulate(std::filesystem::__cxx11::path, bool, bool)':
genmenu.cpp:277:1: internal compiler error: in sh_reorg, at
config/sh/sh.cc:6235
  277 |     };
      | ^
0x1f17d0e internal_error(char const*, ...)
        ../../gcc/gcc/diagnostic-global-context.cc:491
0x96a34f fancy_abort(char const*, int, char const*)
        ../../gcc/gcc/diagnostic.cc:1772
0x8ace30 sh_reorg
        ../../gcc/gcc/config/sh/sh.cc:6235
0x11e8579 execute
        ../../gcc/gcc/reorg.cc:3932


The issue goes away after applying attachment 58831, 58832, 58836.

(Sorry, it's c++ code that uses the std lib. I gave up trying to reduce it)

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #141 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #140)
> Created attachment 58860 [details]
> testcase for attachment  58831 [details],  58832,  58833,  58836
> (...)
> The issue goes away after applying attachment 58831 [details], 58832, 58836.

I wonder whether these patches are already enough to allow for a full bootstrap
with LRA enabled by default.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #142 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #141)
> (In reply to Oleg Endo from comment #140)
> > Created attachment 58860 [details]
> > testcase for attachment  58831 [details],  58832,  58833,  58836
> > (...)
> > The issue goes away after applying attachment 58831 [details], 58832, 58836.
> 
> I wonder whether these patches are already enough to allow for a full
> bootstrap with LRA enabled by default.

I have applied all three patches now and enabled LRA by default using the
change from comment #121.

Build log here:
https://people.debian.org/~glaubitz/gcc-14_with_lra_58832_58833_58836.log.gz

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #143 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
The most common failure seems to be "error: unable to generate reloads for" and
it occurs often in routine for integer arithmetic.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #144 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
It seems that all ICEs in the log in c#142 are the pcrel call issues described
in c#129 which could be avoided with the patch 58831.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #145 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #144)
> It seems that all ICEs in the log in c#142 are the pcrel call issues
> described in c#129 which could be avoided with the patch 58831.

OK, the failure is different now. It fails while building libgomp for stage2:

checking for dlfcn.h... mv -f .deps/oacc-mem.Tpo .deps/oacc-mem.Plo
yes
checking for objdir... .libs
checking if /<<PKGBUILDDIR>>/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/build/./gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem
/usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem
/<<PKGBUILDDIR>>/build/sys-include   -fno-checking supports -fno-rtti
-fno-exceptions... make[7]: *** [Makefile:806: affinity-fmt.lo] Error 1
make[7]: *** Waiting for unfinished jobs....
no

There is no real error message coming from the compiler itself though. Maybe
the patches don't fully work with gcc-14?

Full log:
http://people.debian.org/~glaubitz/gcc-14_with_lra_58831_58832_58833_58836.log.gz

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #146 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #145)
> There is no real error message coming from the compiler itself though. Maybe
> the patches don't fully work with gcc-14?

Same problem with gcc-15.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #147 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #145)

Looks that some error occured durring configuring target libgomp. Unfortunately
we can't see what is going on from that log.  If
/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libgomp/config.log exists, it might have
more details.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #148 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58882&action=edit
a testcase for c++ problem with the patch 58831 both for -mlra and -mno-lra

sh.cc:sh_output_mi_thunk generates the insn

(parallel [
            (call (mem:SI (symbol_ref:SI ("*.LTHUNK8") [flags 0x3]
<function_decl 0x7df4cdb83c00 *.LTHUNK8>) [0  S4 A32])
                (const_int 0 [0]))
            (use (reg:SI 154 fpscr0))
            (clobber (reg:SI 3 r3))
            (return)
        ])

for thunk. The patch 58831 made it unrecognizable.   A fix will be to use R3
instead of R1 as the scratch in the sibcall_pcrel pattern.
Clearly it will break -fcall_saved-reg or -ffixed-reg cases commented in
sh_output_mi_thunk() a bit.  I guess that it's too rare to be considered.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #149 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58883
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58883&action=edit
a revised patch for c#129 and c#148

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #150 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Now target libgcc and libstdc++v3 are built successfully with -O2
-mlra/-mno-lra.  Next I'd like to look into c#140 after ongoing sh-elf binutils
and gcc builds are done.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #151 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #147)
> (In reply to John Paul Adrian Glaubitz from comment #145)
> 
> Looks that some error occured durring configuring target libgomp.
> Unfortunately we can't see what is going on from that log.  If
> /<<PKGBUILDDIR>>/build/sh4-linux-gnu/libgomp/config.log exists, it might
> have more details.

OK, thanks for the suggestion. I will try another build but keep the buildroot
after the failure and then inspect the various configuration files. I will
report back later today or tomorrow.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #152 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #140)
> Created attachment 58860 [details]
> testcase for attachment  58831 [details],  58832,  58833,  58836
> 
> The attached test case, when compiled with 'sh-elf-gcc -O2 -m4-single -mlra'
> on current development branch (GCC 15) fails with the following ICE:

I have yet to reproduce the failure.

/home/kkojima/Take3/shelf-gcc/gcc/g++-cross -B/home/kkojima/Take3/shelf-gcc/gcc
-c -O2 -mlra -m4-single  genmenu.ii

genmenu.cpp:57660:2: error: expected '}' at end of input
genmenu.cpp:40566:1: note: to match this '{'

Maybe something is wrong with my sh-elf gcc build or some file truncation
problem.
FYI, it compiles successfully when adding '}' at the end of genmenu.ii.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #153 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58886
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58886&action=edit
a revised patch for c#135 and c#139

(In reply to Oleg Endo from comment #139)

If we try to keep the old behavior with -mno-lra as possible, it means that
when we define new patterns with R0-clobber, they should be guarded with
sh_lra_p() rigidly and the old patterns should be kept.
The patch adds these guards to the new patterns in c#135 and fixes the testcase
58859.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #154 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #151)
> (In reply to Kazumoto Kojima from comment #147)
> > (In reply to John Paul Adrian Glaubitz from comment #145)
> > 
> > Looks that some error occured durring configuring target libgomp.
> > Unfortunately we can't see what is going on from that log.  If
> > /<<PKGBUILDDIR>>/build/sh4-linux-gnu/libgomp/config.log exists, it might
> > have more details.
> 
> OK, thanks for the suggestion. I will try another build but keep the
> buildroot after the failure and then inspect the various configuration
> files. I will report back later today or tomorrow.

Managed to reproduce the error with an error message:

(unstable-sh4-sbuild)glaubitz@acrux:/build/gcc-14-7reYr0/gcc-14-14.2.0/build/sh4-linux-gnu/libgomp$
/build/gcc-14-7reYr0/gcc-14-14.2.0/build/./gcc/xgcc
-B/build/gcc-14-7reYr0/gcc-14-14.2.0/build/./gcc/ -B/usr/sh4-linux-gnu/bin/
-B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include -isystem
/usr/sh4-linux-gnu/sys-include -isystem
/build/gcc-14-7reYr0/gcc-14-14.2.0/build/sys-include -fno-checking
-DHAVE_CONFIG_H -I. -I../../../src/libgomp -I../../../src/libgomp/config/posix
-I../../../src/libgomp -I../../../src/libgomp/../include -Wall
-ftls-model=initial-exec -pthread -DUSING_INITIAL_EXEC_TLS -g -O2 -MT
affinity-fmt.lo -MD -MP -MF .deps/affinity-fmt.Tpo -c
../../../src/libgomp/affinity-fmt.c -o affinity-fmt.o
../../../src/libgomp/affinity-fmt.c: In function 'gomp_display_affinity':
../../../src/libgomp/affinity-fmt.c:437:1: error: unable to find a register to
spill
  437 | }
      | ^
../../../src/libgomp/affinity-fmt.c:437:1: error: this is the insn:
(insn 1939 564 567 70 (set (reg:SI 537 [orig:214 _146 ] [214])
        (reg:SI 214 [ _146 ])) "../../../src/libgomp/affinity-fmt.c":203:13 191
{movsi_ie}
     (nil))
../../../src/libgomp/affinity-fmt.c:437: confused by earlier errors, bailing
out
(unstable-sh4-sbuild)glaubitz@acrux:/build/gcc-14-7reYr0/gcc-14-14.2.0/build/sh4-linux-gnu/libgomp$

The error message is not visible during boot due to ">/dev/null 2>&1" at the
end of the command line.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #155 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #154)
> Managed to reproduce the error with an error message:
> 
> (unstable-sh4-sbuild)glaubitz@acrux:/build/gcc-14-7reYr0/gcc-14-14.2.0/build/
> sh4-linux-gnu/libgomp$ /build/gcc-14-7reYr0/gcc-14-14.2.0/build/./gcc/xgcc
> -B/build/gcc-14-7reYr0/gcc-14-14.2.0/build/./gcc/ -B/usr/sh4-linux-gnu/bin/
> -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include -isystem
> /usr/sh4-linux-gnu/sys-include -isystem
> /build/gcc-14-7reYr0/gcc-14-14.2.0/build/sys-include -fno-checking
> -DHAVE_CONFIG_H -I. -I../../../src/libgomp
> -I../../../src/libgomp/config/posix -I../../../src/libgomp
> -I../../../src/libgomp/../include -Wall -ftls-model=initial-exec -pthread
> -DUSING_INITIAL_EXEC_TLS -g -O2 -MT affinity-fmt.lo -MD -MP -MF
> .deps/affinity-fmt.Tpo -c ../../../src/libgomp/affinity-fmt.c -o
> affinity-fmt.o
> ../../../src/libgomp/affinity-fmt.c: In function 'gomp_display_affinity':
> ../../../src/libgomp/affinity-fmt.c:437:1: error: unable to find a register
> to spill
>   437 | }
>       | ^
> ../../../src/libgomp/affinity-fmt.c:437:1: error: this is the insn:
> (insn 1939 564 567 70 (set (reg:SI 537 [orig:214 _146 ] [214])
>         (reg:SI 214 [ _146 ])) "../../../src/libgomp/affinity-fmt.c":203:13
> 191 {movsi_ie}
>      (nil))
> ../../../src/libgomp/affinity-fmt.c:437: confused by earlier errors, bailing
> out
> (unstable-sh4-sbuild)glaubitz@acrux:/build/gcc-14-7reYr0/gcc-14-14.2.0/build/
> sh4-linux-gnu/libgomp$

This goes away with "-fno-inline-functions -fno-thread-jumps
-fno-rerun-cse-after-loop".

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #156 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58904&action=edit
a reduced testcase for c#154

New insn_and_split mov<mode>_store_mem_index added with my patch is generated
with an LRA routine, unexpectedly.  Its generation should be guarded with
!lra_in progress intead of !reload_in_progress.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #157 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58905&action=edit
a revised patch for c#135, c#139 and c#154

[Bug target/55212] [SH] Switch to LRA

[sjames at gcc dot gnu.org]

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

--- Comment #158 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #154)
>
> The error message is not visible during boot due to ">/dev/null 2>&1" at the
> end of the command line.

This stupid behaviour is a libtool feature which I plan on asking upstream to
drop (https://bugs.gentoo.org/135865).

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #159 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #157)
> Created attachment 58905 [details]
> a revised patch for c#135, c#139 and c#154

This now fails when compiling libstdc++-v3 with:

libtool: compile:  /<<PKGBUILDDIR>>/build/./gcc/xgcc -shared-libgcc
-B/<<PKGBUILDDIR>>/build/./gcc -nostdinc++
-L/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libstdc++-v3/src
-L/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libstdc++-v3/src/.libs
-L/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem
/usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem
/<<PKGBUILDDIR>>/build/sys-include -fno-checking
-I/<<PKGBUILDDIR>>/src/libstdc++-v3/../libgcc
-I/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libstdc++-v3/include/sh4-linux-gnu
-I/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libstdc++-v3/include
-I/<<PKGBUILDDIR>>/src/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=c++locale.lo -g -O2 -D_GNU_SOURCE -fimplicit-templates -c
c++locale.cc  -fPIC -DPIC -D_GLIBCXX_SHARED -o c++locale.o
../../../../../src/libstdc++-v3/src/c++98/strstream.cc: In member function
'virtual void std::strstream::_ZTv0_n12_NSt9strstreamD1Ev()':
../../../../../src/libstdc++-v3/src/c++98/strstream.cc:417:1: error:
unrecognizable insn:
  417 | } // namespace
      | ^
(call_insn/j 6 5 7 (parallel [
            (call (mem:SI (symbol_ref:SI ("*.LTHUNK4") [flags 0x3]
<function_decl 0x2c89c680 *.LTHUNK4>) [0  S4 A32])
                (const_int 0 [0]))
            (use (reg:SI 154 fpscr0))
            (clobber (reg:SI 3 r3))
            (return)
        ])
"/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libstdc++-v3/include/backward/strstream":217:13
-1
     (nil)
    (expr_list (use (reg:SI 4 r4))
        (nil)))
../../../../../src/libstdc++-v3/src/c++98/strstream.cc:417:1: internal compiler
error: in insn_min_length, at config/sh/sh.md:4190
0x17cf86f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ../../src/gcc/rtl-error.cc:108
0x17cf8d9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../src/gcc/rtl-error.cc:116
0x23ac109 insn_min_length(rtx_insn*)
        ../../src/gcc/config/sh/sh.md:4190
0x12b3d5f shorten_branches(rtx_insn*)
        ../../src/gcc/final.cc:1089
0x1d33865 sh_reorg
        ../../src/gcc/config/sh/sh.cc:6113
0x1d46f39 sh_output_mi_thunk
        ../../src/gcc/config/sh/sh.cc:10947
0x1114f9d expand_thunk(cgraph_node*, bool, bool)
        ../../src/gcc/symtab-thunks.cc:388
0x1131b1d cgraph_node::assemble_thunks_and_aliases()
        ../../src/gcc/cgraphunit.cc:1767
0x1131c0d cgraph_node::assemble_thunks_and_aliases()
        ../../src/gcc/cgraphunit.cc:1789
0x1132101 cgraph_node::expand()
        ../../src/gcc/cgraphunit.cc:1918
0x11325bf expand_all_functions
        ../../src/gcc/cgraphunit.cc:2028
0x113323f symbol_table::compile()
        ../../src/gcc/cgraphunit.cc:2404
0x11337ab symbol_table::finalize_compilation_unit()
        ../../src/gcc/cgraphunit.cc:2589
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-14/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccHVpWhQ.out file, please attach this to
your bugreport.

Will attach the preprocessed source from /tmp/ccHVpWhQ.out as well.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #160 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 58910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58910&action=edit
Preprocessed source from from comment #159

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #161 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #159)

It looks the issue described in c#148.  Could you confirm that patch 58883 in
c#149 has been applied?  The testcase in c#160 is compiled successfully with it
here.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #162 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #153)
> Created attachment 58886 [details]
> a revised patch for c#135 and c#139
> 
> (In reply to Oleg Endo from comment #139)
> 
> If we try to keep the old behavior with -mno-lra as possible, it means that
> when we define new patterns with R0-clobber, they should be guarded with
> sh_lra_p() rigidly and the old patterns should be kept.
> The patch adds these guards to the new patterns in c#135 and fixes the
> testcase 58859.

I'm not in favor of the R0-clobber approach, to be honest.  I think we would
need to add it to the other R0-restricted insns as well.  I'm also afraid of
code quality getting worse if we add all those R0-clobbers everywhere.  With
LRA we are already getting worse code quality than before, so this will just
make it even worse.  

Then there is the maintenance overhead.  So if we use this approach, it's
probably best to make it LRA-only.

Obviously, the spill failure issues are a problem of LRA.  I hope that they can
be addressed adequately by LRA maintainers in time, before forcing everybody to
switch to LRA.

If this doesn't happen, we could also hide R0 from register allocation and fix
it up using an SH specific RTL post-register-allocation pass to "optimize the
R0 usage".  I think this idea has been around for a while, it's just again
quite a bit of work.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #163 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #130)
> Created attachment 58831 [details]
> a trial patch for c#129
> 
> A quick fix may be:
> 
> * config/sh/sh.md
> (call_pcrel, call_value_pcrel, sibcall_pcrel): Use a fixed call clobberd
> register
> for the address.

I don't understand why the 'call_pcrel' insn splits out the constant load of
the call address only after reload?!  I think it could do that before register
allocation, when expanding the define_expand "call" pattern.  Or am I missing
something?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #164 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #162)
> (In reply to Kazumoto Kojima from comment #153)
> > Created attachment 58886 [details]
> > a revised patch for c#135 and c#139
> > 
> > (In reply to Oleg Endo from comment #139)
> > 
> > If we try to keep the old behavior with -mno-lra as possible, it means that
> > when we define new patterns with R0-clobber, they should be guarded with
> > sh_lra_p() rigidly and the old patterns should be kept.
> > The patch adds these guards to the new patterns in c#135 and fixes the
> > testcase 58859.
> 
> I'm not in favor of the R0-clobber approach, to be honest.  I think we would
> need to add it to the other R0-restricted insns as well.  I'm also afraid of
> code quality getting worse if we add all those R0-clobbers everywhere.  With
> LRA we are already getting worse code quality than before, so this will just
> make it even worse.  
> 
> Then there is the maintenance overhead.  So if we use this approach, it's
> probably best to make it LRA-only.
> 
> Obviously, the spill failure issues are a problem of LRA.  I hope that they
> can be addressed adequately by LRA maintainers in time, before forcing
> everybody to switch to LRA.
> 
> If this doesn't happen, we could also hide R0 from register allocation and
> fix it up using an SH specific RTL post-register-allocation pass to
> "optimize the R0 usage".  I think this idea has been around for a while,
> it's just again quite a bit of work.

Agreed.

R0 specific pass would be "the Right Thing".  It is hard to do right away,
though.
I've seen the recent argument for an LRA patch which passed the tests on
mainstream processors but is causing wrong code on aarch64 and riscv.
I guess that RA tends to be "one line change makes the failure on some arch"
thing which was warned so for the old reload.
Yes, the R0-clobber approach is only workaround for LRA.  It should be LRA-only
as you pointed out.
I don't expect the LRA to improve the code on SH.  Only I can try to help -mlra
get it into a usable state somehow.  And the time I can help may not be not so
long.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #165 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #163)
> (In reply to Kazumoto Kojima from comment #130)
> > Created attachment 58831 [details]
> > a trial patch for c#129
> > 
> > A quick fix may be:
> > 
> > * config/sh/sh.md
> > (call_pcrel, call_value_pcrel, sibcall_pcrel): Use a fixed call clobberd
> > register
> > for the address.
> 
> I don't understand why the 'call_pcrel' insn splits out the constant load of
> the call address only after reload?!  I think it could do that before
> register allocation, when expanding the define_expand "call" pattern.  Or am
> I missing something?

I also don't understand why these insn_and_split patterns are needed.  Maybe
some issue with sh_expand_sym_label2reg before reload_completed?

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #166 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #164)
> 
> R0 specific pass would be "the Right Thing".  It is hard to do right away,
> though.

I know.  It's not a quick-fix, needs more time to implement.

> I've seen the recent argument for an LRA patch which passed the tests on
> mainstream processors but is causing wrong code on aarch64 and riscv.
> I guess that RA tends to be "one line change makes the failure on some arch"
> thing which was warned so for the old reload.

It feels like running in circles after all.  The only thing that it proves is,
it's difficult to have one ultimate RA approach/implementation that works well
and is stable for all architectures.  After all, the RA implementation itself
becomes so difficult and riddled with corner cases, that only very few people
can do anything about it.  I think this is the case we're having now
unfortunately.

> Yes, the R0-clobber approach is only workaround for LRA.  It should be
> LRA-only as you pointed out.
> I don't expect the LRA to improve the code on SH.  Only I can try to help
> -mlra get it into a usable state somehow.  And the time I can help may not
> be not so long.

Totally understandable.  Any help from you is highly appreciated!

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #167 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #165)
> (In reply to Oleg Endo from comment #163)
> > (In reply to Kazumoto Kojima from comment #130)
> > > Created attachment 58831 [details]
> > > a trial patch for c#129
> > > 
> > > A quick fix may be:
> > > 
> > > * config/sh/sh.md
> > > (call_pcrel, call_value_pcrel, sibcall_pcrel): Use a fixed call clobberd
> > > register
> > > for the address.
> > 
> > I don't understand why the 'call_pcrel' insn splits out the constant load of
> > the call address only after reload?!  I think it could do that before
> > register allocation, when expanding the define_expand "call" pattern.  Or am
> > I missing something?
> 
> I also don't understand why these insn_and_split patterns are needed.  Maybe
> some issue with sh_expand_sym_label2reg before reload_completed?

If the constant load is exposed earlier, it could also be hoisted out of loops,
which would be better.

The call_pcrel and related patterns were added in 2000 ... maybe it was because
of SH5 support?  Not sure.  Perhaps the 'call_pcrel' expansion should be
somehow merged into the 'call' expansion.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #168 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I am getting a segmentation fault when building libgcc2.c now:

/<<PKGBUILDDIR>>/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/build/./gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem
/usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem
/<<PKGBUILDDIR>>/build/sys-include   -fno-checking -g -O2 -O2  -g -O2 -DIN_GCC 
 -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fpic
-DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -I. -I.
-I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/.
-I../../../src/libgcc/../gcc -I../../../src/libgcc/../include  -DHAVE_CC_TLS  
-o __gcc_bcmp.o -MT __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c
../../../src/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: evrp
../../../src/libgcc/libgcc2.c: In function '__clrsbsi2':
../../../src/libgcc/libgcc2.c:760:1: internal compiler error: Segmentation
fault
  760 | }
      | ^
Unhandled trap: 0x180
pc=0x2b7e4c40 sr=0x00000001 pr=0x2b7e4c32 fpscr=0x00080004
spc=0x00000000 ssr=0x00000000 gbr=0x2b2f3c20 vbr=0x00000000
sgr=0x00000000 dbr=0x00000000 delayed_pc=0x2b7e4c32 fpul=0x00000064
r0=0x00000004 r1=0x2b9410c8 r2=0x00000005 r3=0x00000000
r4=0x001fdb3e r5=0x001fdb3e r6=0x00000006 r7=0x0000011c
r8=0x2b9410bc r9=0x00000468 r10=0x2b2f3760 r11=0x01480400
r12=0x2b940c60 r13=0x2b2a5c8c r14=0x2b2a5ccc r15=0x2b2a5634
r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000
r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000
make[5]: *** [Makefile:508: _clrsbsi2.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory '/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libgcc'
make[4]: *** [Makefile:18852: all-stage2-target-libgcc] Error 2
make[4]: Leaving directory '/<<PKGBUILDDIR>>/build'
make[3]: *** [Makefile:24459: stage2-bubble] Error 2
make[3]: Leaving directory '/<<PKGBUILDDIR>>/build'
make[2]: *** [Makefile:24663: bootstrap] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build'

This is with the following patches applied on top of gcc-14:

- 58832
- 58833
- 58883
- 58905

I also had to disable Ada for the time being which failed with:

/<<PKGBUILDDIR>>/build/./prev-gcc/xgcc -B/<<PKGBUILDDIR>>/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/
-isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include
-isystem /<<PKGBUILDDIR>>/build/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg  -W -Wall -fno-PIE -nostdinc -I- -I. -Iada/gen
erated -Iada -I../../src/gcc/ada -Iada/libgnat -I../../src/gcc/ada/libgnat
-Iada/gcc-interface -I../../src/gcc/ada/gcc-interface
../../src/gcc/ada/libgnat/s-except.adb -o ada/libgnat/s-except.o
mkdir -p ada/libgnat/
/<<PKGBUILDDIR>>/build/./prev-gcc/xgcc -B/<<PKGBUILDDIR>>/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/
-isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include
-isystem /<<PKGBUILDDIR>>/build/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg  -W -Wall -fno-PIE -nostdinc -I- -I. -Iada/gen
erated -Iada -I../../src/gcc/ada -Iada/libgnat -I../../src/gcc/ada/libgnat
-Iada/gcc-interface -I../../src/gcc/ada/gcc-interface ada/libgnat/s-excmac.adb
-o ada/libgnat/s-excmac.o
mkdir -p ada/libgnat/
/<<PKGBUILDDIR>>/build/./prev-gcc/xgcc -B/<<PKGBUILDDIR>>/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/
-isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include
-isystem /<<PKGBUILDDIR>>/build/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg  -W -Wall -fno-PIE -nostdinc -I- -I. -Iada/gen
erated -Iada -I../../src/gcc/ada -Iada/libgnat -I../../src/gcc/ada/libgnat
-Iada/gcc-interface -I../../src/gcc/ada/gcc-interface
../../src/gcc/ada/libgnat/s-exctab.adb -o ada/libgnat/s-exctab.o
during RTL pass: subreg1
+===========================GNAT BUG DETECTED==============================+
| 14.2.0 (sh4-linux-gnu) GCC error:                                        |
| in decompose_multiword_subregs, at lower-subreg.cc:1728                  |
| Error detected around ../../src/gcc/ada/libgnat/a-exexda.adb:312:8       |
| Compiling ../../src/gcc/ada/libgnat/a-except.adb                         |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

../../src/gcc/ada/gcc-interface/system.ads
../../src/gcc/ada/libgnat/a-except.adb
../../src/gcc/ada/libgnat/a-except.ads
../../src/gcc/ada/libgnat/ada.ads
../../src/gcc/ada/libgnat/s-parame.ads
../../src/gcc/ada/libgnat/s-stalib.ads
../../src/gcc/ada/libgnat/a-unccon.ads
../../src/gcc/ada/libgnat/s-traent.ads
../../src/gcc/ada/libgnat/s-except.ads
../../src/gcc/ada/libgnat/s-excdeb.ads
../../src/gcc/ada/libgnat/s-soflin.ads
../../src/gcc/ada/libgnat/s-secsta.ads
../../src/gcc/ada/libgnat/s-stoele.ads
../../src/gcc/ada/libgnat/s-stache.ads
../../src/gcc/ada/libgnat/s-wchcon.ads
../../src/gcc/ada/libgnat/s-wchstw.ads
../../src/gcc/ada/libgnat/s-traceb.ads
../../src/gcc/ada/libgnat/s-trasym.ads
../../src/gcc/ada/libgnat/s-exctab.ads
../../src/gcc/ada/libgnat/a-excach.adb
../../src/gcc/ada/libgnat/a-exexda.adb
../../src/gcc/ada/libgnat/a-exexpr.adb
../../src/gcc/ada/libgnat/a-uncdea.ads
ada/libgnat/s-excmac.ads
../../src/gcc/ada/libgnat/a-exextr.adb
../../src/gcc/ada/libgnat/a-elchha.ads
../../src/gcc/ada/libgnat/s-imgint.ads
../../src/gcc/ada/libgnat/s-imagei.ads
../../src/gcc/ada/libgnat/s-vaispe.ads
../../src/gcc/ada/libgnat/s-vauspe.ads
../../src/gcc/ada/libgnat/s-valspe.ads
../../src/gcc/ada/libgnat/s-unstyp.ads
../../src/gcc/ada/libgnat/s-vs_int.ads
../../src/gcc/ada/libgnat/s-vs_uns.ads
../../src/gcc/ada/libgnat/a-exstat.adb


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:412
mkdir -p ada/libgnat/
make[5]: *** [../../src/gcc/ada/gcc-interface/Make-lang.in:1174:
ada/libgnat/a-except.o] Error 1
make[5]: *** Waiting for unfinished jobs....
/<<PKGBUILDDIR>>/build/./prev-gcc/xgcc -B/<<PKGBUILDDIR>>/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/
-isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include
-isystem /<<PKGBUILDDIR>>/build/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg  -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../src/gcc/ada -Iada/libgnat
-I../../src/gcc/ada/libgnat -Iada/gcc-interface
-I../../src/gcc/ada/gcc-interface ../../src/gcc/ada/libgnat/s-htable.adb -o
ada/libgnat/s-htable.o
../../src/gcc/ada/uintp.adb: In function 'Uintp.Ui_Mul':
../../src/gcc/ada/uintp.adb:2030:27: warning: '(*l_vec.461_50)[1]{lb: 1 sz: 4}'
may be used uninitialized [-Wmaybe-uninitialized]
../../src/gcc/ada/sem_res.adb: In function
'Sem_Res.Resolve_Selected_Component':
../../src/gcc/ada/sem_res.adb:11254:10: warning: 'it1.typ' may be used
uninitialized [-Wmaybe-uninitialized]
../../src/gcc/ada/sem_res.adb:11144:7: note: 'it1.typ' was declared here
rm gcc.pod gfortran.pod lto-dump.pod
make[5]: Leaving directory '/<<PKGBUILDDIR>>/build/gcc'
make[4]: *** [Makefile:5093: all-stage2-gcc] Error 2
make[4]: Leaving directory '/<<PKGBUILDDIR>>/build'
make[3]: *** [Makefile:25185: stage2-bubble] Error 2
make[3]: Leaving directory '/<<PKGBUILDDIR>>/build'
make[2]: *** [Makefile:25389: bootstrap] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build'

Trying with gcc-15 now.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #169 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #168)
> I am getting a segmentation fault when building libgcc2.c now:
> 
> /<<PKGBUILDDIR>>/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/build/./gcc/
> -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem
> /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem
> /<<PKGBUILDDIR>>/build/sys-include   -fno-checking -g -O2 -O2  -g -O2
> -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
> ./include  -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
> -fbuilding-libgcc -fno-stack-protector  -fpic -DNO_FPSCR_VALUES -w
> -Wno-sync-nand -I. -I. -I../.././gcc -I../../../src/libgcc
> -I../../../src/libgcc/. -I../../../src/libgcc/../gcc
> -I../../../src/libgcc/../include  -DHAVE_CC_TLS   -o __gcc_bcmp.o -MT
> __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c
> ../../../src/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
> during GIMPLE pass: evrp
> ../../../src/libgcc/libgcc2.c: In function '__clrsbsi2':
> ../../../src/libgcc/libgcc2.c:760:1: internal compiler error: Segmentation
> fault
>   760 | }
>       | ^
>...
> make[5]: *** [Makefile:508: _clrsbsi2.o] Error 1
> make[5]: *** Waiting for unfinished jobs....
> make[5]: Leaving directory '/<<PKGBUILDDIR>>/build/sh4-linux-gnu/libgcc'
> make[4]: *** [Makefile:18852: all-stage2-target-libgcc] Error 2
> make[4]: Leaving directory '/<<PKGBUILDDIR>>/build'
> make[3]: *** [Makefile:24459: stage2-bubble] Error 2
> make[3]: Leaving directory '/<<PKGBUILDDIR>>/build'
> make[2]: *** [Makefile:24663: bootstrap] Error 2
> make[2]: Leaving directory '/<<PKGBUILDDIR>>/build'

It seems that the stage2 compiler segfaults when building stage2 libgcc. There
is some wrong code issue with the stage1 compiler. I can't look into it
directly with the cross compiler.
I'll try running gcc testsuite with the sh-elf cross compiler on old sh-sim. 
There may not be much chance, but it might catch the wrong code bug.

Of course, you can investigate that segfault directly or run gcc testsuite
natively with the stage1 compiler to find the wrong code.

> Trying with gcc-15 now.

Hope it gives us more information.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #170 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #168)
> I am getting a segmentation fault when building libgcc2.c now:
> (...) 
> Trying with gcc-15 now.

gcc-15 from July segfaults the same way when building libgcc2.c. Will try a
gcc-15 snapshot from 7 August now.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #171 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #170)
> (In reply to John Paul Adrian Glaubitz from comment #168)
> > I am getting a segmentation fault when building libgcc2.c now:
> > (...) 
> > Trying with gcc-15 now.
> 
> gcc-15 from July segfaults the same way when building libgcc2.c. Will try a
> gcc-15 snapshot from 7 August now.

I'm going to try to obtain a backtrace now. This may take a little while
though.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #172 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Interesting, it's showing an illegal instruction now:

root@tirpitz:..sh4-linux-gnu/libgcc>
/srv/gcc-snapshot-3YBWb3/gcc-snapshot-20240715/build/./gcc/xgcc
-B/srv/gcc-snapshot-3YBWb3/gcc-snapshot-20240715/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fno-checking -g -O2 -O2  -g
-O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -DNO_FPSCR_VALUES -w
-Wno-sync-nand -I. -I. -I../.././gcc -I../../../src/libgcc
-I../../../src/libgcc/. -I../../../src/libgcc/../gcc
-I../../../src/libgcc/../include  -DHAVE_CC_TLS   -o _muldi3.o -MT _muldi3.o
-MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../src/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: waccess
../../../src/libgcc/libgcc2.c: In function '__muldi3':
../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Segmentation
fault
  538 | }
      | ^

../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
instruction
root@tirpitz:..sh4-linux-gnu/libgcc>

Could this be just an issue of the compiler generating invalid code?

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #173 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Here's what I got from gdb:

(gdb) bt
#0  0x0109fee4 in wi::add_large(long long*, long long const*, unsigned int,
long long const*, unsigned int, unsigned int, signop, wi::overflow_type*) ()
#1  0x00bdbc10 in
access_ref::add_offset(generic_wide_int<fixed_wide_int_storage<128> > const&,
generic_wide_int<fixed_wide_int_storage<128> > const&) ()
#2  0x00bdd0e8 in compute_objsize_r(tree_node*, gimple*, bool, int,
access_ref*, ssa_name_limit_t&, pointer_query*) ()
#3  0x00000000 in ?? ()
(gdb) display/i $pc
1: x/i $pc
=> 0x109fee4 <_ZN2wi9add_largeEPxPKxjS2_jj6signopPNS_13overflow_typeE+84>:     
mov.l   @r2,r3
(gdb) x/wx $r2
0x7c07eaa0:     Cannot access memory at address 0x7c07eaa0
(gdb)

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #174 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #169)
> I'll try running gcc testsuite with the sh-elf cross compiler on old sh-sim.
> There may not be much chance, but it might catch the wrong code bug.

The results w/wo -mlra are exactly the same on the patched compiler. For
example,

make check-gcc RUNTESTFLAGS="execute.exp --target_board=sh-sim/-m4"
make check-gcc RUNTESTFLAGS="execute.exp --target_board=sh-sim/-m4/-mlra"

                === gcc Summary ===

# of expected passes            23910
# of unexpected failures        96

The result for the unpatched trunk compiler with -m4 is same,  but with  -m4
for  the vanilla compiler 14.0.1 20240222 shows 

# of unexpected failures        93

and 3 new failures on the current master compilers are

> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2  execution test
> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O3 -g  execution test
> FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution test

It doesn't look that this issue is the cause of the segfault.  This is a bad
sign, though.
Can the unpatched trunk gcc15 bootstrap with reverting enable -mlra by default
patch in c#121 in the first place?  I assume that gcc14 can bootstrap
successfully with -mno-lra.

I'll look the above execution errors into more closely.

BTW, the patched (58832, 58833,58883,58905) gcc 14.0.1 20240222 has no above 3
FAILs for gcc.c-torture/execute/struct-ret-1.c and moreover -mlra fixes one
more case

PASS: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

which was failed even with unpatched 14.0.1.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #175 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #172)
> ../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
> instruction
> root@tirpitz:..sh4-linux-gnu/libgcc>
> 
> Could this be just an issue of the compiler generating invalid code?

I assume.  A wrong code can make a bad register value which will be used as an
instruction address.  If that address is in a data object, for example, it can
cause an illegal instruction error.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #176 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I am trying a full bootstrap with the patches applied now but with LRA disabled
by default.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #177 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #175)
> (In reply to John Paul Adrian Glaubitz from comment #172)
> > ../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
> > instruction
> > root@tirpitz:..sh4-linux-gnu/libgcc>
> > 
> > Could this be just an issue of the compiler generating invalid code?
> 
> I assume.  A wrong code can make a bad register value which will be used as
> an instruction address.  If that address is in a data object, for example,
> it can cause an illegal instruction error.

It could also be a latent bug exposed, like ..

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

(just two I could of think right now, perhaps there more of course)

As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
compiler on a regular basis, see also
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660457.html

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #178 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #177)
> As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
> compiler on a regular basis, see also
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660457.html

I assume he is doing cross-compiled bootstraps which is why he is never running
the miscompiled code, is he?

Also, did he try with LRA enabled?

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #179 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #178)
> (In reply to Oleg Endo from comment #177)
> > As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
> > compiler on a regular basis, see also
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660457.html
> 
> I assume he is doing cross-compiled bootstraps which is why he is never
> running the miscompiled code, is he?

I don't know.  He's not ever disclosed the details of his test setup for all
the various targets...


> 
> Also, did he try with LRA enabled?

No, LRA is not enabled in the vanilla version as of yet.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #180 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #174)
> > FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2  execution test
> > FAIL: gcc.c-torture/execute/struct-ret-1.c   -O3 -g  execution test
> > FAIL: gcc.c-torture/execute/struct-ret-1.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution test
...
> I'll look the above execution errors into more closely.

It turned out that these FAILs don't show the real compiler issue but rather a
problem with my newlib build.  Sorry for the noise.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #181 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Just as a heads-up: I am currently performing extensive testing to be able to
generate anything useful from testsuite results to a usable backtrace. For
that, I am building GCC natively with various options on sh4.

Will report back as soon as I have something.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #182 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #181)
> Just as a heads-up: I am currently performing extensive testing to be able
> to generate anything useful from testsuite results to a usable backtrace.
> For that, I am building GCC natively with various options on sh4.
> 
> Will report back as soon as I have something.

With the following patches applied

- 58832
- 58833
- 58883
- 58905

and LRA enabled by default, I am seeing the same segfault on git master with:

"../configure --disable-multilib --enable-multiarch --enable-bootstrap
--enable-languages=c,c++"

but not with

./configure --disable-multilib --enable-multiarch --disable-bootstrap
--enable-languages=c,c++

I wonder whether this is related to "[committed] Fix m68k bootstrap segfault
with late-combine" for m68k. I will revert the late combine change and see if
that helps.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #183 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I'm trying with late-combine disabled now:

diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 280588268ae..dca27893536 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -1047,6 +1047,9 @@ sh_override_options_after_change (void)
          str_align_functions = r;
        }
     }
+
+    if (!OPTION_SET_P (flag_late_combine_instructions))
+      flag_late_combine_instructions = 0;
 }
 ^L
 /* Print the operand address in x to the stream.  */

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #184 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #183)
> I'm trying with late-combine disabled now:
> 
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index 280588268ae..dca27893536 100644
> --- a/gcc/config/sh/sh.cc
> +++ b/gcc/config/sh/sh.cc
> @@ -1047,6 +1047,9 @@ sh_override_options_after_change (void)
>           str_align_functions = r;
>         }
>      }
> +
> +    if (!OPTION_SET_P (flag_late_combine_instructions))
> +      flag_late_combine_instructions = 0;
>  }
>  ^L
>  /* Print the operand address in x to the stream.  */

Segfault is still present.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #185 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Unfortunately, nothing new showed up in running gcc/g++ testsuite for
sh-elf+sim with -mlra.

OTOH, the segfault can be reproduced on qemu with the patched stage2 compiler
built with -g -O2 -mlra -m4.  gdb says that it occurs in the function call

wide-int.cc:top_bit_of (a=0x407ff620, len=65792, prec=128)

at the statement

  unsigned HOST_WIDE_INT val = a[len - 1];

which ends up "mov @r2, r3" as in c#173.  Looks len=65792 is a wrong value.
It seems that at least gcc/pointer-query.cc is miscompiled by the patched
stage2 compiler built with -O2 -mlra -m4.  Compiling pointer-query.cc with -O0
-mlra instead of -O2 -mlra, __muldi3 is compiled successfully.  This compiler
segfaults for another files of libgcc, i.e. there are another gcc objects
miscompiled with -O2 -mlra.
It is not at all clear what is causing the wrong value or code, though.  We are
still at the starting point of the bugfix.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #186 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #185)
> It is not at all clear what is causing the wrong value or code, though.  We
> are still at the starting point of the bugfix.

That's still great progress in any case. Thanks a lot!

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #187 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58989&action=edit
a testcase for wrong code which is pre-processed gcc/gimple-fold.cc

One other segfault is seen when compiling libgcc/libgcov-driver.c. 
It seems that gcc/gimple-fold.cc: fold_const_aggregate_ref_1(tree_node*,
tree_node* (*)(tree_node*)) is miscompiled with -O2 -mlra.  The asm code
sequences in question are

[-O2 -mno-lra]
        ...
        mov.l   .L13907,r1      ! 2387  [c=10 l=2]  movsi_ie/0
        mov     #0,r6   ! 2383  [c=4 l=2]  movsi_ie/2
        mov.l   r3,@(4,r0)      ! 542   [c=4 l=2]  movsi_ie/8
        mov.l   r5,@(8,r0)      ! 546   [c=4 l=2]  movsi_ie/8
        mov     #96,r0  ! 2385  [c=4 l=2]  movsi_ie/2
        mov.l   r3,@(8,r15)     ! 556   [c=4 l=2]  movsi_ie/8
        mov.l   r5,@(4,r15)     ! 558   [c=4 l=2]  movsi_ie/8
        mov.l   r3,@r15 ! 560   [c=4 l=2]  movsi_ie/8
        mov.l   r6,@(16,r15)    ! 552   [c=4 l=2]  movsi_ie/8
        mov.l   r6,@(12,r15)    ! 554   [c=4 l=2]  movsi_ie/8
        mov.l   @(r0,r15),r6    ! 563   [c=3 l=2]  movsi_ie/5
        mov.l   @(56,r15),r5    ! 564   [c=1 l=2]  movsi_ie/5
        jsr     @r1     ! 566   [c=5 l=2]  call_valuei
        mov.l   @(60,r15),r4    ! 565   [c=1 l=2]  movsi_ie/5
        mov.l   @(60,r15),r10   ! 2388  [c=1 l=2]  movsi_ie/5
        mov     r0,r7   ! 1828  [c=4 l=2]  movsi_ie/1
        mov.l   @(56,r15),r4    ! 576   [c=1 l=2]  movsi_ie/5
        mov.l   r0,@(16,r10)    ! 570   [c=4 l=2]  movsi_ie/8
        mov     r10,r5  ! 577   [c=4 l=2]  movsi_ie/1
        mov.l   .L13908,r10     ! 2389  [c=10 l=2]  movsi_ie/0
        jsr     @r10    ! 579   [c=1 l=2]  block_lump_real_i4/0
        mov     #1,r6   ! 578   [c=4 l=2]  movsi_ie/2

[-O2 -mlra]
        ...
        mov.l   .L13994,r14     ! 2172  [c=10 l=2]  movsi_ie/0
        mov.l   r0,@(16,r10)    ! 524   [c=4 l=2]  movsi_ie/8
        mov     #1,r6   ! 532   [c=4 l=2]  movsi_ie/2
        mov.l   r0,@(56,r15)    ! 2562  [c=4 l=2]  movsi_ie/8
        jsr     @r14    ! 533   [c=1 l=2]  block_lump_real_i4/0
        mov     r10,r5  ! 531   [c=4 l=2]  movsi_ie/1
        mov.l   @(40,r15),r7    ! 2173  [c=1 l=2]  movsi_ie/5
        mov     #0,r3   ! 2694  [c=4 l=2]  movsi_ie/2
        mov     #8,r2   ! 2693  [c=4 l=2]  movsi_ie/2
        mov.w   .L13995,r1      ! 2561  [c=10 l=2]  *movhi/0
        mov.l   r2,@(44,r7)     ! 2695  [c=4 l=2]  movsi_ie/8
        mov     r4,r5   ! 567   [c=4 l=2]  movsi_ie/1
        mov.l   r3,@(48,r7)     ! 2696  [c=4 l=2]  movsi_ie/8
        mov     r10,r4  ! 568   [c=4 l=2]  movsi_ie/1
        mov.l   @(60,r15),r7    ! 2419  [c=1 l=2]  movsi_ie/5
        mov.l   .L13996,r2      ! 2566  [c=10 l=2]  movsi_ie/0
        mov.l   r7,@r13 ! 541   [c=4 l=2]  movsi_ie/8
        mov.l   r1,@(8,r13)     ! 549   [c=4 l=2]  movsi_ie/8
        mov.l   r12,@(4,r13)    ! 2176  [c=4 l=2]  movsi_ie/8
        mov.l   @(56,r15),r6    ! 566   [c=1 l=2]  movsi_ie/5
        mov.l   r1,@(4,r15)     ! 561   [c=4 l=2]  movsi_ie/8
        mov.l   r11,@(16,r15)   ! 2179  [c=4 l=2]  movsi_ie/8
        mov.l   r11,@(12,r15)   ! 2180  [c=4 l=2]  movsi_ie/8
        mov.l   r12,@(8,r15)    ! 2181  [c=4 l=2]  movsi_ie/8
        jsr     @r2     ! 569   [c=5 l=2]  call_valuei
        mov.l   r12,@r15        ! 2183  [c=4 l=2]  movsi_ie/8
        mov     #1,r6   ! 581   [c=4 l=2]  movsi_ie/2
        mov.l   r0,@(16,r10)    ! 573   [c=4 l=2]  movsi_ie/8
        mov     r0,r7   ! 1839  [c=4 l=2]  movsi_ie/1
        jsr     @r14    ! 582   [c=1 l=2]  block_lump_real_i4/0
        mov     r10,r5  ! 580   [c=4 l=2]  movsi_ie/1

In the latter case,  the last jsr @r14 that is calling __movstr_i4_odd libgcc
asm function of which arguments are r4, r5, r6.  We can't see any explicit insn
to set r4 after jsr@r2 that is calling wi::mul_internal c++ function which may
clobber r4.  We can find mov.l   @(56,r15),r4 before jsr @r10 which is
__movstr_i4_odd call in the former -mno-lra case.

In the -mlra case, r4 is 0x1 when  __movstr_i4_odd is called.  Looks a wrong
code.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #188 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #187)

Looking at the RTL dumps in -mlra case, there is an instruction to set r4 in
the postreload dump:

(insn 579 573 580 49 (set (reg:SI 4 r4)
        (reg/f:SI 11 r11 [1021])) "/git/gcc/gcc/wide-int.h":822:94 191
{movsi_ie}
     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
            (const_int -88 [0xffffffffffffffa8]))
        (nil)))
(insn 580 579 581 49 (set (reg:SI 5 r5)
        (reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
{movsi_ie}
     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
            (const_int -60 [0xffffffffffffffc4]))
        (nil)))
(insn 581 580 2186 49 (set (reg:SI 6 r6)
        (const_int 1 [0x1])) "/git/gcc/gcc/wide-int.h":822:94 191 {movsi_ie}
     (nil))
(note 2186 581 582 49 NOTE_INSN_DELETED)
(insn 582 2186 2187 49 (parallel [
            (set (mem:BLK (reg:SI 4 r4) [0  A8])
                (mem:BLK (reg:SI 5 r5) [0  A8]))
            (use (reg:SI 14 r14 [1193]))
            (use (const_int 0 [0]))
            (use (reg:SI 6 r6))
            (clobber (reg:SI 146 pr))
            (clobber (reg:SI 147 t))
            (clobber (reg:SI 4 r4))
            (clobber (reg:SI 5 r5))
            (clobber (reg:SI 6 r6))
            (clobber (reg:SI 0 r0))
            (clobber (reg:SI 1 r1))
            (clobber (reg:SI 2 r2))
            (clobber (reg:SI 3 r3))
        ]) "/git/gcc/gcc/wide-int.h":822:94 326 {block_lump_real_i4}
     (nil))

but the insn 579 is dissapeared in late_combine2 dump:

(insn 573 1839 580 49 (set (mem/c:SI (plus:SI (reg/f:SI 10 r10 [1023])
                (const_int 16 [0x10])) [6 MEM[(struct fixed_wide_int_storage
*)_301].len+0 S4 A32])
        (reg:SI 7 r7 [1042])) "/git/gcc/gcc/wide-int.h":1435:7 191 {movsi_ie}
     (nil))
(insn 580 573 581 49 (set (reg:SI 5 r5)
        (reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
{movsi_ie}
     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
            (const_int -60 [0xffffffffffffffc4]))
        (nil)))

I confirmed that -fno-late-combine-instructions fixes this issue.  I'm not sure
what is going on, though.
As pointed out in c#184, -fno-late-combine-instructions doesn't help __muldi3
case.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #189 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
There is another segfault during compiling libgcc/fp-bit.c.
In that case, the 2nd visit to tree-ssa-sccvn.cc:3567 in vn_reference_lookup_3

      FOR_EACH_VEC_ELT (rhs, j, vro)
        vr->operands[i + 1 + j] = *vro;

shows a bad *vro in the 2nd iteration of this FOR_EACH_VEC_ELT:

(gdb) p *vro
$13 = {opcode = 0x17, clique = 0x0, base = 0x19, reverse = 0x0, align = 0x0, 
  off = {coeffs = {0x1a0000001b}}, type = 0x1c, op0 = 0x1e, op1 = 0x20, 
  op2 = 0x21}

where the type and op[0-2] fields are pointers with wrong value.
The fault is avoided with compiling tree-ssa-sccvn.cc and tree-ssa-alias.cc
with -O0 -mlra.  This issue may be hard to investigate because the function
vn_reference_lookup_3 is huge and complex.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #190 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Another two segfaults are observed when building libstdc++v3.

Compiling                               Segfault in
libsupc++/dyncast.cc                    tree-ssa-reassoc.cc
src/c++11/locale-inst.cc                tree-ssa-strlen.cc

I have not looked into these in detail yet.
Anyway, the target libgcc & libstdc++v3 can be built successfuly when the files

gimple-fold.cc
pointer-query.cc
tree-ssa-sccvn.cc tree-ssa-alias.cc
tree-ssa-reassoc.cc
tree-ssa-strlen.cc

were compiled with -O0 -mlra.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #191 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #188)
> (In reply to Kazumoto Kojima from comment #187)
> 
> Looking at the RTL dumps in -mlra case, there is an instruction to set r4 in
> the postreload dump:
> 
> (insn 579 573 580 49 (set (reg:SI 4 r4)
>         (reg/f:SI 11 r11 [1021])) "/git/gcc/gcc/wide-int.h":822:94 191
> {movsi_ie}
>      (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
>             (const_int -88 [0xffffffffffffffa8]))
>         (nil)))
> (insn 580 579 581 49 (set (reg:SI 5 r5)
>         (reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
> {movsi_ie}
>      (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
>             (const_int -60 [0xffffffffffffffc4]))
>         (nil)))
> (insn 581 580 2186 49 (set (reg:SI 6 r6)
>         (const_int 1 [0x1])) "/git/gcc/gcc/wide-int.h":822:94 191 {movsi_ie}
>      (nil))
> (note 2186 581 582 49 NOTE_INSN_DELETED)
> (insn 582 2186 2187 49 (parallel [
>             (set (mem:BLK (reg:SI 4 r4) [0  A8])
>                 (mem:BLK (reg:SI 5 r5) [0  A8]))
>             (use (reg:SI 14 r14 [1193]))
>             (use (const_int 0 [0]))
>             (use (reg:SI 6 r6))
>             (clobber (reg:SI 146 pr))
>             (clobber (reg:SI 147 t))
>             (clobber (reg:SI 4 r4))
>             (clobber (reg:SI 5 r5))
>             (clobber (reg:SI 6 r6))
>             (clobber (reg:SI 0 r0))
>             (clobber (reg:SI 1 r1))
>             (clobber (reg:SI 2 r2))
>             (clobber (reg:SI 3 r3))
>         ]) "/git/gcc/gcc/wide-int.h":822:94 326 {block_lump_real_i4}
>      (nil))
> 
> but the insn 579 is dissapeared in late_combine2 dump:
> 
> (insn 573 1839 580 49 (set (mem/c:SI (plus:SI (reg/f:SI 10 r10 [1023])
>                 (const_int 16 [0x10])) [6 MEM[(struct fixed_wide_int_storage
> *)_301].len+0 S4 A32])
>         (reg:SI 7 r7 [1042])) "/git/gcc/gcc/wide-int.h":1435:7 191 {movsi_ie}
>      (nil))
> (insn 580 573 581 49 (set (reg:SI 5 r5)
>         (reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
> {movsi_ie}
>      (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
>             (const_int -60 [0xffffffffffffffc4]))
>         (nil)))
> 
> I confirmed that -fno-late-combine-instructions fixes this issue.  I'm not
> sure what is going on, though.
> As pointed out in c#184, -fno-late-combine-instructions doesn't help
> __muldi3 case.

Maybe Richard Sandiford can help with this, since he's the original author of
the late-combine, from what I remember.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #192 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58994&action=edit
a testcase for a wrong code issue which is preprocessed gcc/pointer-query.cc

I identified a wrong code with -O2 -mlra for gcc/prointer-query.cc which causes
the segfault reported in c#172 and c#185.

On the lines below 

static bool
handle_component_ref (tree cref, gimple *stmt, bool addr, int ostype,
                      access_ref *pref, ssa_name_limit_t &snlim,
                      pointer_query *qry)
{
  gcc_assert (TREE_CODE (cref) == COMPONENT_REF);

  const tree base = TREE_OPERAND (cref, 0);
  const tree field = TREE_OPERAND (cref, 1);
  access_ref base_ref = *pref;

  /* Unconditionally determine the size of the base object (it could
     be smaller than the referenced member when the object is stored
     in a buffer with an insufficient size).  */
  if (!compute_objsize_r (base, stmt, addr, 0, &base_ref, snlim, qry))
    return false;

the last lines are compiled to

.L4909:
        mov.l   .L5394,r7       ! 6818  [c=10 l=2]  movsi_ie/0
        mov     #16,r6  ! 1751  [c=4 l=2]  movsi_ie/2
        mov.w   .L5395,r4       ! 7790  [c=10 l=2]  *movhi/0
        mov     r8,r5   ! 1750  [c=4 l=2]  movsi_ie/1
        mov.l   @(24,r9),r12    ! 1745  [c=1 l=2]  movsi_ie/5
        add     r15,r4  ! 7791  [c=4 l=2]  *addsi3_compact_lra/0
        jsr     @r7     ! 1752  [c=1 l=2]  block_lump_real_i4/0
        mov.l   r4,@(36,r15)    ! 7176  [c=4 l=2]  movsi_ie/8
        mov.l   .L5396,r0       ! 6435  [c=10 l=2]  movsi_ie/0
        mov     #0,r7   ! 1758  [c=4 l=2]  movsi_ie/2
        mov.l   r14,@(4,r15)    ! 1754  [c=4 l=2]  movsi_ie/8
        mov     r13,r6  ! 1759  [c=4 l=2]  movsi_ie/1
        mov.l   r4,@r15 ! 1756  [c=4 l=2]  movsi_ie/8
        mov.l   @(32,r15),r5    ! 1760  [c=1 l=2]  movsi_ie/5
        mov.l   @(40,r15),r4    ! 1761  [c=1 l=2]  movsi_ie/5
        jsr     @r0     ! 1762  [c=5 l=2]  call_valuei
        mov.l   r10,@(8,r15)    ! 1753  [c=4 l=2]  movsi_ie/8
        tst     r0,r0   ! 1766  [c=4 l=2]  cmpeqsi_t/0
        bf/s    .L5907          ! 1767  [c=17 l=2]  *cbranch_t

where .L5394 points __movmem_i4_even and .L5396 points compute_objsize_r.
Before calling __movmem_i4_even which gives a block move base_ref = *pref, the
codes set r4 = &base_ref and r5 = pref.  This r4 is copied on stack @(36,r15)
too.  After calling __movmem_i4_even, the value of r4 is clobbered.
But the above code set this clobbered value to the 5th argument @r15 of
compute_objsize_r which should be &base_ref.
When I pushed "mov.l @(36,r15),r4" just before "mov r13,r6" as an experiment
and used the assembled object as pointer-querry.o in the stage2 cc1, the
segfault during compiling __muldi3 went away.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #193 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #192)

Related parts of RTL dumps.

[.ira dump]

(insn 1747 1745 1748 125 (set (reg/f:SI 2854)
        (plus:SI (reg/f:SI 153 sfp)
            (const_int -136 [0xffffffffffffff78])))
"/git/gcc/gcc/pointer-query.
cc":1906:14 48 {*addsi3_compact_lra}
     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
            (const_int -136 [0xffffffffffffff78]))
        (nil)))
(insn 1748 1747 1749 125 (set (reg/f:SI 2847)
        (symbol_ref:SI ("__movmem_i4_even") [flags 0x1]))
"/git/gcc/gcc/pointer-
query.cc":1906:14 191 {movsi_ie}
     (expr_list:REG_EQUIV (symbol_ref:SI ("__movmem_i4_even") [flags 0x1])
        (nil)))
(insn 1749 1748 1750 125 (set (reg:SI 4 r4)
        (reg/f:SI 2854)) "/git/gcc/gcc/pointer-query.cc":1906:14 191 {movsi_ie}
     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
            (const_int -136 [0xffffffffffffff78]))
        (nil)))
(insn 1750 1749 1751 125 (set (reg:SI 5 r5)
        (reg/v/f:SI 724 [ pref ])) "/git/gcc/gcc/pointer-query.cc":1906:14 191
{movsi_ie}
     (nil))
(insn 1751 1750 1752 125 (set (reg:SI 6 r6)
        (const_int 16 [0x10])) "/git/gcc/gcc/pointer-query.cc":1906:14 191
{movsi_ie}
     (nil))
(insn 1752 1751 1753 125 (parallel [
            (set (mem:BLK (reg:SI 4 r4) [0  A8])
                (mem:BLK (reg:SI 5 r5) [0  A8]))
            (use (reg/f:SI 2847))
            (use (const_int 0 [0]))
            (use (reg:SI 6 r6))
            (clobber (reg:SI 146 pr))
            (clobber (reg:SI 147 t))
            (clobber (reg:SI 4 r4))
            (clobber (reg:SI 5 r5))
            (clobber (reg:SI 6 r6))
            (clobber (reg:SI 0 r0))
            (clobber (reg:SI 1 r1))
            (clobber (reg:SI 2 r2))
            (clobber (reg:SI 3 r3))
        ]) "/git/gcc/gcc/pointer-query.cc":1906:14 326 {block_lump_real_i4}
     (expr_list:REG_DEAD (reg:SI 6 r6)
        (expr_list:REG_DEAD (reg:SI 5 r5)
            (expr_list:REG_DEAD (reg:SI 4 r4)
                (expr_list:REG_UNUSED (reg:SI 147 t)
                    (expr_list:REG_UNUSED (reg:SI 146 pr)
                        (expr_list:REG_UNUSED (reg:SI 6 r6)
                            (expr_list:REG_UNUSED (reg:SI 5 r5)
                                (expr_list:REG_UNUSED (reg:SI 4 r4)
                                    (expr_list:REG_UNUSED (reg:SI 3 r3)
                                        (expr_list:REG_UNUSED (reg:SI 2 r2)
                                            (expr_list:REG_UNUSED (reg:SI 1 r1)
                                                (expr_list:REG_UNUSED (reg:SI 0
r0)
                                                    (nil))))))))))))))
(insn 1753 1752 1754 125 (set (mem:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 8 [0x8])) [0  S4 A32])
        (reg/v/f:SI 726 [ qry ])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (expr_list:REG_DEAD (reg/v/f:SI 726 [ qry ])
        (nil)))
(insn 1754 1753 1756 125 (set (mem:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 4 [0x4])) [0  S4 A32])
        (reg/v/f:SI 725 [ snlim ])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (expr_list:REG_DEAD (reg/v/f:SI 725 [ snlim ])
        (nil)))
(insn 1756 1754 1758 125 (set (mem:SI (reg/f:SI 15 r15) [0  S4 A32])
        (reg/f:SI 2854)) "/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (nil))
(insn 1758 1756 1759 125 (set (reg:SI 7 r7)
        (const_int 0 [0])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (nil))
(insn 1759 1758 1760 125 (set (reg:SI 6 r6)
        (reg:SI 2905)) "/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (nil))
(insn 1760 1759 1761 125 (set (reg:SI 5 r5)
        (reg:SI 2904)) "/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (expr_list:REG_DEAD (reg:SI 2904)
        (nil)))
(insn 1761 1760 6435 125 (set (reg:SI 4 r4)
        (reg/v/f:SI 484 [ base ])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (nil))
(insn 6435 1761 1762 125 (set (reg/f:SI 1448)
        (symbol_ref:SI
("_ZL17compute_objsize_rP9tree_nodeP6gimplebiP10access_refR16ssa_name_limit_tP13pointer_query")
[flags 0x3]  <function_decl 0x7ca377e5ff00 compute_objsize_r>))
"/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (expr_list:REG_EQUIV (symbol_ref:SI
("_ZL17compute_objsize_rP9tree_nodeP6gimplebiP10access_refR16ssa_name_limit_tP13pointer_query")
[flags 0x3]  <function_decl 0x7ca377e5ff00 compute_objsize_r>)
        (nil)))
(call_insn 1762 6435 5898 125 (parallel [
            (set (reg:SI 0 r0)
                (call (mem:SI (reg/f:SI 1448) [0 compute_objsize_r S4 A32])
                    (const_int 12 [0xc])))
            (use (reg:SI 154 fpscr0))
            (clobber (reg:SI 146 pr))
        ]) "/git/gcc/gcc/pointer-query.cc":1911:26 233 {call_valuei}
     (expr_list:REG_DEAD (reg/f:SI 1448)
        (expr_list:REG_DEAD (reg:SI 7 r7)
            (expr_list:REG_DEAD (reg:SI 6 r6)
                (expr_list:REG_DEAD (reg:SI 5 r5)
                    (expr_list:REG_DEAD (reg:SI 4 r4)
                        (expr_list:REG_CALL_DECL (symbol_ref:SI
("_ZL17compute_objsize_rP9tree_nodeP6gimplebiP10access_refR16ssa_name_limit_tP13pointer_query")
[flags 0x3]  <function_decl 0x7ca377e5ff00 compute_objsize_r>)
                            (expr_list:REG_EH_REGION (const_int 0 [0])
                                (nil))))))))
    (expr_list:SI (use (reg:SI 4 r4))
        (expr_list:SI (use (reg:SI 5 r5))
            (expr_list:SI (use (reg:SI 6 r6))
                (expr_list:SI (use (reg:SI 7 r7))
                    (expr_list:SI (use (mem/f:SI (reg/f:SI 15 r15) [0  S4
A32]))
                        (expr_list:SI (use (mem/f:SI (plus:SI (reg/f:SI 15 r15)
                                        (const_int 4 [0x4])) [0  S4 A32]))
                            (expr_list:SI (use (mem/f:SI (plus:SI (reg/f:SI 15
r15)
                                            (const_int 8 [0x8])) [0  S4 A32]))
                                (nil)))))))))
(insn 5898 1762 1763 125 (set (reg:SI 2942)
        (reg:SI 0 r0)) "/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (expr_list:REG_DEAD (reg:SI 0 r0)
        (nil)))

[.reload dump]

(insn 1747 1745 7176 126 (set (reg/f:SI 4 r4 [2854])
        (plus:SI (reg/f:SI 15 r15)
            (const_int 212 [0xd4]))) "/git/gcc/gcc/pointer-query.cc":1906:14 48 
{*addsi3_compact_lra}
     (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
            (const_int -136 [0xffffffffffffff78]))
        (nil)))
(insn 7176 1747 1748 126 (set (mem/c:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 36 [0x24])) [506 %sfp+-312 S4 A32])
        (reg/f:SI 4 r4 [2854])) "/git/gcc/gcc/pointer-query.cc":1906:14 191
{movsi_ie}
     (nil))
(note 1748 7176 1750 126 NOTE_INSN_DELETED)
(insn 1750 1748 1751 126 (set (reg:SI 5 r5)
        (reg/v/f:SI 8 r8 [orig:724 pref ] [724]))
"/git/gcc/gcc/pointer-query.cc":1906:14 191 {movsi_ie}
     (nil))
(insn 1751 1750 6818 126 (set (reg:SI 6 r6)
        (const_int 16 [0x10])) "/git/gcc/gcc/pointer-query.cc":1906:14 191
{movsi_ie}
     (nil))
(insn 6818 1751 1752 126 (set (reg:SI 7 r7 [3270])
        (symbol_ref:SI ("__movmem_i4_even") [flags 0x1]))
"/git/gcc/gcc/pointer-query.cc":1906:14 191 {movsi_ie}
     (nil))
(insn 1752 6818 1753 126 (parallel [
            (set (mem:BLK (reg:SI 4 r4) [0  A8])
                (mem:BLK (reg:SI 5 r5) [0  A8]))
            (use (reg:SI 7 r7 [3270]))
            (use (const_int 0 [0]))
            (use (reg:SI 6 r6))
            (clobber (reg:SI 146 pr))
            (clobber (reg:SI 147 t))
            (clobber (reg:SI 4 r4))
            (clobber (reg:SI 5 r5))
            (clobber (reg:SI 6 r6))
            (clobber (reg:SI 0 r0))
            (clobber (reg:SI 1 r1))
            (clobber (reg:SI 2 r2))
            (clobber (reg:SI 3 r3))
        ]) "/git/gcc/gcc/pointer-query.cc":1906:14 326 {block_lump_real_i4}
     (nil))
(insn 1753 1752 6819 126 (set (mem:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 8 [0x8])) [0  S4 A32])
        (reg/v/f:SI 10 r10 [orig:726 qry ] [726]))
"/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (nil))
(insn 6819 1753 1754 126 (set (reg/v/f:SI 1 r1 [orig:725 snlim ] [725])
        (reg/v/f:SI 14 r14 [orig:725 snlim ] [725]))
"/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (nil))
(insn 1754 6819 1756 126 (set (mem:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 4 [0x4])) [0  S4 A32])
        (reg/v/f:SI 1 r1 [orig:725 snlim ] [725]))
"/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (nil))
(insn 1756 1754 1758 126 (set (mem:SI (reg/f:SI 15 r15) [0  S4 A32])
        (reg/f:SI 4 r4 [2854])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (nil))
(insn 1758 1756 1759 126 (set (reg:SI 7 r7)
        (const_int 0 [0])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (nil))
(insn 1759 1758 1760 126 (set (reg:SI 6 r6)
        (reg:SI 13 r13 [2905])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (nil))
(insn 1760 1759 1761 126 (set (reg:SI 5 r5)
        (mem/c:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 32 [0x20])) [506 %sfp+-316 S4 A32]))
"/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (nil))
(insn 1761 1760 6435 126 (set (reg:SI 4 r4)
        (mem/c:SI (plus:SI (reg/f:SI 15 r15)
                (const_int 40 [0x28])) [506 %sfp+-308 S4 A32]))
"/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (nil))
(insn 6435 1761 1762 126 (set (reg/f:SI 0 r0 [1448])
        (symbol_ref:SI
("_ZL17compute_objsize_rP9tree_nodeP6gimplebiP10access_refR16ssa_name_limit_tP13pointer_query")
[flags 0x3]  <function_decl 0x7ca377e5ff00 compute_objsize_r>))
"/git/gcc/gcc/pointer-query.cc":1911:26 191 {movsi_ie}
     (expr_list:REG_EQUIV (symbol_ref:SI
("_ZL17compute_objsize_rP9tree_nodeP6gimplebiP10access_refR16ssa_name_limit_tP13pointer_query")
[flags 0x3]  <function_decl 0x7ca377e5ff00 compute_objsize_r>)
        (nil)))
(call_insn 1762 6435 1763 126 (parallel [
            (set (reg:SI 0 r0)
                (call (mem:SI (reg/f:SI 0 r0 [1448]) [0 compute_objsize_r S4
A32])
                    (const_int 12 [0xc])))
            (use (reg:SI 154 fpscr0))
            (clobber (reg:SI 146 pr))
        ]) "/git/gcc/gcc/pointer-query.cc":1911:26 233 {call_valuei}
     (expr_list:REG_CALL_DECL (symbol_ref:SI
("_ZL17compute_objsize_rP9tree_nodeP6gimplebiP10access_refR16ssa_name_limit_tP13pointer_query")
[flags 0x3]  <function_decl 0x7ca377e5ff00 compute_objsize_r>)
        (expr_list:REG_EH_REGION (const_int 0 [0])
            (nil)))
    (expr_list:SI (use (reg:SI 4 r4))
        (expr_list:SI (use (reg:SI 5 r5))
            (expr_list:SI (use (reg:SI 6 r6))
                (expr_list:SI (use (reg:SI 7 r7))
                    (expr_list:SI (use (mem/f:SI (reg/f:SI 15 r15) [0  S4
A32]))
                        (expr_list:SI (use (mem/f:SI (plus:SI (reg/f:SI 15 r15)
                                        (const_int 4 [0x4])) [0  S4 A32]))
                            (expr_list:SI (use (mem/f:SI (plus:SI (reg/f:SI 15
r15)
                                            (const_int 8 [0x8])) [0  S4 A32]))
                                (nil)))))))))
(insn 1763 1762 7174 126 (set (reg:SI 1 r1 [orig:718 <retval> ] [718])
        (reg:SI 0 r0 [2942])) "/git/gcc/gcc/pointer-query.cc":1911:26 191
{movsi_ie}
     (nil))

It looks that LRA allocates r4 to the psuedo register r2854 and assumes that
it's preserved beyond the insn 1752 block_lump_real_i4.
Can the SH's sfunc pattern like block_lump_real_i4 confuse RA?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #194 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 58995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58995&action=edit
simply a trial patch, not a real fix

With this explicit emit_clobber, all the segfaults I reported are gone.  I'm a
bit confused.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #195 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #193)

Great results!

> 
> It looks that LRA allocates r4 to the psuedo register r2854 and assumes that
> it's preserved beyond the insn 1752 block_lump_real_i4.
> Can the SH's sfunc pattern like block_lump_real_i4 confuse RA?

Are any other backends defining the patterns like that?  Maybe something in
RA/LRA doesn't pay attention to the clobber in the parallel .... 

It looks a bit strange ...

(define_insn "block_lump_real_i4"
  [(parallel [(set (mem:BLK (reg:SI R4_REG))
                   (mem:BLK (reg:SI R5_REG)))
              (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
              (use (match_operand 1 "" "Z,Ccl"))
              (use (reg:SI R6_REG))
              (clobber (reg:SI PR_REG))
              (clobber (reg:SI T_REG))
              (clobber (reg:SI R4_REG))
              (clobber (reg:SI R5_REG))
              (clobber (reg:SI R6_REG))
              (clobber (reg:SI R0_REG))
              (clobber (reg:SI R1_REG))
              (clobber (reg:SI R2_REG))
              (clobber (reg:SI R3_REG))])]

Why is this not written like other patterns 

(define_insn "block_lump_real_i4"
  [(set (mem:BLK (reg:SI R4_REG))
        (mem:BLK (reg:SI R5_REG)))
   (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
   (use (match_operand 1 "" "Z,Ccl"))
   (use (reg:SI R6_REG))
   (clobber (reg:SI PR_REG))
   (clobber (reg:SI T_REG))
   (clobber (reg:SI R4_REG))
   (clobber (reg:SI R5_REG))
   (clobber (reg:SI R6_REG))
   (clobber (reg:SI R0_REG))
   (clobber (reg:SI R1_REG))
   (clobber (reg:SI R2_REG))
   (clobber (reg:SI R3_REG))
 ... 

???

[Bug target/55212] [SH] Switch to LRA

[schwab@linux-m68k.org]

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

--- Comment #196 from Andreas Schwab <schwab@linux-m68k.org> ---
Both forms are completely equivalent (a multi element template is implicitly
surrounded by parallel).

[Bug target/55212] [SH] Switch to LRA

[pinskia at gcc dot gnu.org]

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

--- Comment #197 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #196)
> Both forms are completely equivalent (a multi element template is implicitly
> surrounded by parallel).

Yes and I just fixed a bug dealing with that and genemit and adding the
clobbers back too.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #198 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #194)
> Created attachment 58995 [details]
> simply a trial patch, not a real fix
> 
> With this explicit emit_clobber, all the segfaults I reported are gone.  I'm
> a bit confused.

This fixes the segmentation fault for me as well, I'm just left with a single
bootstrap comparison failure:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/gimple-lower-bitint.o differs
make[2]: *** [Makefile:24837: compare] Error 1
make[2]: Leaving directory '/srv/glaubitz/gcc/build'
make[1]: *** [Makefile:24817: stage3-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc/build'
make: *** [Makefile:1101: all] Error 2

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #199 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59000&action=edit
a patch for an experiment

I added explicit register clobbers after all s-function calls as an experiment,
although it is not the right way to fix the issue.

I'll run gcc testsuite w/wo -mlra on qemu.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #200 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #199)
> Created attachment 59000 [details]
> a patch for an experiment
> 
> I added explicit register clobbers after all s-function calls as an
> experiment, although it is not the right way to fix the issue.

OK, I'll add that patch and retest.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #201 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 59006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59006&action=edit
Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c

(In reply to John Paul Adrian Glaubitz from comment #200)
> (In reply to Kazumoto Kojima from comment #199)
> > Created attachment 59000 [details]
> > a patch for an experiment
> > 
> > I added explicit register clobbers after all s-function calls as an
> > experiment, although it is not the right way to fix the issue.
> 
> OK, I'll add that patch and retest.

Comparison failure is still present with 59000 applied instead of 58995.

Attaching the disassembled diff for gcc/gimple-lower-bitint.c.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #202 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Adding "gcc/gimple-lower-bitint*" to "compare_exclusions" in configure.ac makes
the build pass the bootstrap comparison and completely succeed with LRA enabled
with the following patches applied:

- 58832
- 58833
- 58883
- 58905
- 59000

This is with late-combine disabled which I will enable now for the next test
build.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #203 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #201)
> Created attachment 59006 [details]
> Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c

I tried to build the stage3 gcc on qemu with the stage2 gcc which was built
with the cross comiler.   Interestingly, stage2 gcc/gimple-lower-bitint.o and
stage3 gcc/gimple-lower-bitint.o were exactly the same.  Perhaps the problem
cannot be reproduced because my qemu environment is not the real sh4-linux and
my build process of the stage3 compiler was not the same with the true
bootstrapping.

FYI, your stage2 gcc/gimple-lower-bitint.o already seems to be slightly
different from my stage2 gcc/gimple-lower-bitint.o. It may be due to the
difference in codebase.  I'm using gcc master commit
7f65c38ac1b18773d55c08d6ba920a798462b871 (origin/master, master).

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #204 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #203)
> (In reply to John Paul Adrian Glaubitz from comment #201)
> > Created attachment 59006 [details]
> > Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c
> 
> I tried to build the stage3 gcc on qemu with the stage2 gcc which was built
> with the cross comiler.   Interestingly, stage2 gcc/gimple-lower-bitint.o
> and stage3 gcc/gimple-lower-bitint.o were exactly the same.  Perhaps the
> problem cannot be reproduced because my qemu environment is not the real
> sh4-linux and my build process of the stage3 compiler was not the same with
> the true bootstrapping.

It actually seems that the bootstrap comparison failure that I have run into
was a result of disabling late combine. I am retesting this now just to make
sure.

> FYI, your stage2 gcc/gimple-lower-bitint.o already seems to be slightly
> different from my stage2 gcc/gimple-lower-bitint.o. It may be due to the
> difference in codebase.  I'm using gcc master commit
> 7f65c38ac1b18773d55c08d6ba920a798462b871 (origin/master, master).

Yeah, I'm pretty sure that's because I disabled late combine as one of the
measures trying to mitigate the segfault.

I am testing now with the following patches applied:

- 58832
- 58833
- 58883
- 58905
- 59000

as well as LRA enabled by default and late combine enabled as well.

Will report back as soon as the build finishes.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #205 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #204)
> Yeah, I'm pretty sure that's because I disabled late combine as one of the
> measures trying to mitigate the segfault.
> 
> I am testing now with the following patches applied:
> 
> - 58832
> - 58833
> - 58883
> - 58905
> - 59000
> 
> as well as LRA enabled by default and late combine enabled as well.
> 
> Will report back as soon as the build finishes.

Confirmed. The above configuration builds fine for me with a full bootstrap
with C and C++ as the enabled languages.

Will now try with patch 58995 instead of patch 59000.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #206 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #205)
> Confirmed. The above configuration builds fine for me with a full bootstrap
> with C and C++ as the enabled languages.
> 
> Will now try with patch 58995 instead of patch 59000.

Even with patch 58995 instead of patch 59000, a full bootstrap builds fine.

Next I'm going to test with Ada enabled which had some issues in previous
tests.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #207 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #206)
> Next I'm going to test with Ada enabled which had some issues in previous
> tests.

Enabling Ada fails with:

/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-except.adb -o ada/libgnat/s-except.o
mkdir -p ada/libgnat/
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface ada/libgnat/s-excmac.adb -o
ada/libgnat/s-excmac.o
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-exctab.adb -o ada/libgnat/s-exctab.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-htable.adb -o ada/libgnat/s-htable.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad32.ads -o ada/libgnat/s-imad32.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad64.ads -o ada/libgnat/s-imad64.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imgint.adb -o ada/libgnat/s-imgint.o
mkdir -p ada/libgnat/
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-mastop.adb -o ada/libgnat/s-mastop.o
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-memory.adb -o ada/libgnat/s-memory.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-os_lib.adb -o ada/libgnat/s-os_lib.o
during RTL pass: subreg1
+===========================GNAT BUG DETECTED==============================+
| 15.0.0 20240818 (experimental) (sh4-unknown-linux-gnu) GCC error:        |
| in decompose_multiword_subregs, at lower-subreg.cc:1728                  |
| Error detected around ../../gcc/ada/libgnat/a-exexda.adb:312:8           |
| Compiling ../../gcc/ada/libgnat/a-except.adb                             |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

../../gcc/ada/gcc-interface/system.ads
../../gcc/ada/libgnat/a-except.adb
../../gcc/ada/libgnat/a-except.ads
../../gcc/ada/libgnat/ada.ads
../../gcc/ada/libgnat/s-parame.ads
../../gcc/ada/libgnat/s-stalib.ads
../../gcc/ada/libgnat/a-unccon.ads
../../gcc/ada/libgnat/s-traent.ads
../../gcc/ada/libgnat/s-except.ads
../../gcc/ada/libgnat/s-excdeb.ads
../../gcc/ada/libgnat/s-soflin.ads
../../gcc/ada/libgnat/s-secsta.ads
../../gcc/ada/libgnat/s-stoele.ads
../../gcc/ada/libgnat/s-stache.ads
../../gcc/ada/libgnat/s-wchcon.ads
../../gcc/ada/libgnat/s-wchstw.ads
../../gcc/ada/libgnat/s-traceb.ads
../../gcc/ada/libgnat/s-trasym.ads
../../gcc/ada/libgnat/s-exctab.ads
../../gcc/ada/libgnat/a-excach.adb
../../gcc/ada/libgnat/a-exexda.adb
../../gcc/ada/libgnat/a-exexpr.adb
../../gcc/ada/libgnat/a-uncdea.ads
ada/libgnat/s-excmac.ads
../../gcc/ada/libgnat/a-exextr.adb
../../gcc/ada/libgnat/a-elchha.ads
../../gcc/ada/libgnat/s-imgint.ads
../../gcc/ada/libgnat/s-imagei.ads
../../gcc/ada/libgnat/s-vaispe.ads
../../gcc/ada/libgnat/s-vauspe.ads
../../gcc/ada/libgnat/s-valspe.ads
../../gcc/ada/libgnat/s-unstyp.ads
../../gcc/ada/libgnat/s-vs_int.ads
../../gcc/ada/libgnat/s-vs_uns.ads
../../gcc/ada/libgnat/a-exstat.adb


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:412
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:1175:
ada/libgnat/a-except.o] Error 1
make[3]: *** Waiting for unfinished jobs....
../../gcc/ada/uintp.adb: In function 'Uintp.Ui_Mul':
../../gcc/ada/uintp.adb:2030:27: warning: '(*l_vec.447_422)[1]{lb: 1 sz: 4}'
may be used uninitialized [-Wmaybe-uninitialized]
../../gcc/ada/uintp.adb:2030:27: warning: '(*l_vec.447_50)[1]{lb: 1 sz: 4}' may
be used uninitialized [-Wmaybe-uninitialized]
../../gcc/ada/uintp.adb:2030:27: warning: '(*l_vec.447_235)[1]{lb: 1 sz: 4}'
may be used uninitialized [-Wmaybe-uninitialized]
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[3]: Leaving directory '/srv/glaubitz/gcc/build/gcc'
make[2]: *** [Makefile:5095: all-stage2-gcc] Error 2
make[2]: Leaving directory '/srv/glaubitz/gcc/build'
make[1]: *** [Makefile:25394: stage2-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc/build'
make: *** [Makefile:1101: all] Error 2

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #208 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Building with Go enabled, fails with:

during RTL pass: subreg3
../../../libgo/go/unicode/utf16/utf16.go: In function 'unicode/utf16.Encode':
../../../libgo/go/unicode/utf16/utf16.go:56:1: internal compiler error: in
decompose_multiword_subregs, at lower-subreg.cc:1728
   56 | func Encode(s []rune) []uint16 {
      | ^
libtool: compile:  /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=internal/itoa ../../../libgo/go/internal/itoa/itoa.go -o
internal/itoa.o >/dev/null 2>&1
libtool: compile:  /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=sync/atomic ../../../libgo/go/sync/atomic/doc.go
../../../libgo/go/sync/atomic/unaligned.go
../../../libgo/go/sync/atomic/value.go -o sync/atomic.o >/dev/null 2>&1
libtool: compile:  /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=container/ring ../../../libgo/go/container/ring/ring.go -o
container/ring.o >/dev/null 2>&1
0x1872ddb internal_error(char const*, ...)
        ../../gcc/diagnostic-global-context.cc:491
0x67aca7 fancy_abort(char const*, int, char const*)
        ../../gcc/diagnostic.cc:1772
0x173af73 decompose_multiword_subregs
        ../../gcc/lower-subreg.cc:1728
0x173b8bf execute
        ../../gcc/lower-subreg.cc:1849
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Not sure whether this is an old bug though.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #209 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
OK, I can confirm that the Ada problem is a regression due to the LRA switch.

Not sure about the Go problem yet.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #210 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
It seems that go build fails in the subreg3 optimization and ada build fails in
the subreg1 optimization.  Since the subreg1 optimization is done before
IRA/LRA, it could mean that there is another wrong code problem with -mlra.  It
could be a latent problem even with the old RA, though.
Unfortunately, it's difficult to investigate in my environment.

BTW, I'm running g++ testsuite on qemu with -mlra, but it'll take another 2
days to complete.   I have not found any new wrong code issues yet.  All
unexpected FAILs are also seen with the vanilla cross gcc /-mno-lra, ATM.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #211 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #209)
> OK, I can confirm that the Ada problem is a regression due to the LRA switch.
> 
> Not sure about the Go problem yet.

Confirmed that Go has regressed due to LRA as well.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #212 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #210)
> Unfortunately, it's difficult to investigate in my environment.

We could maybe ask one of the Ada or Go developers. If you have any other idea
how I can help here, please let me know.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #213 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I have no experience debugging gcc go or ada compilers and don't know how to
make a handy testcase like .i files in c/c++ cases.  It seems that the GNAT BUG
message in c#207 says about something about that.  If your build directories
are kept, you can run the failing commands

/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-os_lib.adb -o ada/libgnat/s-os_lib.o

and

/srv/glaubitz/gcc/build/./gcc/gccgo -B/srv/glaubitz/gcc/build/./gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/
-isystem /usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=container/ring ../../../libgo/go/container/ring/ring.go -o
container/ring.o

by hand with --verbose to see the raw compiling commands.  Those raw
compilations could be debugged with gdb to see why they end up in ICE with
"decompose_multiword_subregs, at lower-subreg.cc:1728" which might be  the
assert statement

                      i = apply_change_group ();
                      gcc_assert (i);

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #214 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #213)

Sorry I missed the use of -jN in your build.  Perhaps the failed go compilation
command would be

/srv/glaubitz/gcc/build/./gcc/gccgo -B/srv/glaubitz/gcc/build/./gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/
-isystem /usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=unicode/utf16 ../../../libgo/go/unicode/utf16/utf16.go -o
unicode/utf16.o

Fortunately, I can reproduce the ICE with the cross go compiler.  I'll look
into what is going on.

$ /home/kkojima/Take3/sh4-linux-gcc/gcc/go1
/git/gcc/libgo/go/unicode/utf16/utf16.go -quiet -dumpbase xxx.go -dumpbase-ext
.go -m4 -mlra -g -O2 -version -fchecking=1 -fgo-pkgpath=unicode/utf16 -fPIC -o
xxx.s
GNU Go (GCC) version 15.0.0 20240825 (experimental) (sh4-unknown-linux-gnu)
        compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
during RTL pass: subreg3
/git/gcc/libgo/go/unicode/utf16/utf16.go: In function 'unicode/utf16.Encode':
/git/gcc/libgo/go/unicode/utf16/utf16.go:56:1: internal compiler error: in
decompose_multiword_subregs, at lower-subreg.cc:1731
   56 | func Encode(s []rune) []uint16 {
      | ^
0x1c7f765 internal_error(char const*, ...)
        /git/gcc/gcc/diagnostic-global-context.cc:491
0x89b2be fancy_abort(char const*, int, char const*)
        /git/gcc/gcc/diagnostic.cc:1772
0x87b099 decompose_multiword_subregs
        /git/gcc/gcc/lower-subreg.cc:1731
0x1b10aa1 execute
        /git/gcc/gcc/lower-subreg.cc:1852

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #215 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
OK, thanks a lot for looking at the Go problem. In the meantime, I will try to
get a more usable backtrace from Ada.

On a sidenote, gccgo doesn't work 100% properly on qemu-user while it works
perfectly fine on real hardware. But the crash above is not related to
qemu-user.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #216 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59034&action=edit
a patch augments 58905

In the problematic case c#214, the subreg pass requires to recognize the insn

(insn 224 223 131 17 (set (mem:HI (plus:SI (reg/f:SI 167 [ _13 ])
                (reg:SI 0 r0)) [0  S2 A16])
        (subreg:HI (reg:SI 236) 0)) "utf16-nopic.go":75:9 -1
     (nil))

but it can't be recognized with the new patterns in the 58905.  The patch adds
it.

This patch is assumed to be applied to the top of  58832, 58833, 58883, 58905
and 59000, though it could be reconstructed as the revised 58905.

It's tested only with the target libgcc/libstdc++v3/libgo builds and check-gcc
excecute.exp on the cross compilers. I plan to do more tests.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #217 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #216)
> Created attachment 59034 [details]
> a patch augments 58905
> 
> In the problematic case c#214, the subreg pass requires to recognize the insn
> 
> (insn 224 223 131 17 (set (mem:HI (plus:SI (reg/f:SI 167 [ _13 ])
>                 (reg:SI 0 r0)) [0  S2 A16])
>         (subreg:HI (reg:SI 236) 0)) "utf16-nopic.go":75:9 -1
>      (nil))
> 
> but it can't be recognized with the new patterns in the 58905.  The patch
> adds it.
> 
> This patch is assumed to be applied to the top of  58832, 58833, 58883,
> 58905 and 59000, though it could be reconstructed as the revised 58905.
> 
> It's tested only with the target libgcc/libstdc++v3/libgo builds and
> check-gcc excecute.exp on the cross compilers. I plan to do more tests.

Kaz, can you please create a branch devel/sh-lra and add the patches there?  I
think it would make it easier to manage the patches.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #218 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #216)
> This patch is assumed to be applied to the top of  58832, 58833, 58883,
> 58905 and 59000, though it could be reconstructed as the revised 58905.
> 
> It's tested only with the target libgcc/libstdc++v3/libgo builds and
> check-gcc excecute.exp on the cross compilers. I plan to do more tests.

Testing this now and see if that fixes the issue with gccgo.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #219 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #217)
> (In reply to Kazumoto Kojima from comment #216)

> Kaz, can you please create a branch devel/sh-lra and add the patches there? 
> I think it would make it easier to manage the patches.

I am currently losing SSH access to gcc.gnu.org.  I have chosen not to update
it so as not to add one more dormant account when an update is requested.
Sorry for the inconvenience.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #220 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #219)
> (In reply to Oleg Endo from comment #217)
> > (In reply to Kazumoto Kojima from comment #216)
> 
> > Kaz, can you please create a branch devel/sh-lra and add the patches there? 
> > I think it would make it easier to manage the patches.
> 
> I am currently losing SSH access to gcc.gnu.org.  I have chosen not to
> update it so as not to add one more dormant account when an update is
> requested.
> Sorry for the inconvenience.

Ah, OK, understandable.  No problem.  How about github instead?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #221 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #220)

> Ah, OK, understandable.  No problem.  How about github instead?

I forked https://github.com/gcc-mirror/gcc and have just added the sh-lra
branch to https://github.com/kazkojima/gcc.git.  Hope it helps.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #222 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #221)
> (In reply to Oleg Endo from comment #220)
> 
> > Ah, OK, understandable.  No problem.  How about github instead?
> 
> I forked https://github.com/gcc-mirror/gcc and have just added the sh-lra
> branch to https://github.com/kazkojima/gcc.git.  Hope it helps.

Thanks so much!

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #223 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #218)
> (In reply to Kazumoto Kojima from comment #216)
> > This patch is assumed to be applied to the top of  58832, 58833, 58883,
> > 58905 and 59000, though it could be reconstructed as the revised 58905.
> > 
> > It's tested only with the target libgcc/libstdc++v3/libgo builds and
> > check-gcc excecute.exp on the cross compilers. I plan to do more tests.
> 
> Testing this now and see if that fixes the issue with gccgo.

I had run into some issues with my build environment, so my results are a
little delayed. Apologies.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #224 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #223)
> 
> I had run into some issues with my build environment, so my results are a
> little delayed. Apologies.

No problem.

After further testing, it appears that there may be some wrong code issue.  Not
sure if this is due to the patch 59034 or not, but I'm looking into it.  So
there is no hurry to do the bootstrap test in your environment.  I will report
back once the problem is clear.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #225 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #224)
> (In reply to John Paul Adrian Glaubitz from comment #223)
> > 
> > I had run into some issues with my build environment, so my results are a
> > little delayed. Apologies.
> 
> No problem.
> 
> After further testing, it appears that there may be some wrong code issue. 
> Not sure if this is due to the patch 59034 or not, but I'm looking into it. 
> So there is no hurry to do the bootstrap test in your environment.  I will
> report back once the problem is clear.

It seems that I have run into this issue after 59034 as well since the compiler
segfaults for me with the patch applied:

/srv/glaubitz/gcc/build/./gcc/xgcc -B/srv/glaubitz/gcc/build/./gcc/
-fno-checking -xc -nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
0x2b7a0f9f __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x2b7a1083 __libc_start_main_impl
        ./csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #226 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59044&action=edit
a patch to fix patch 59034

Looks the use of the raw R0 pattern in 59034 confuses the def-use analysis and
RA.
I guess it could be the cause of the segfault in c#225.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #227 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #226)
> Created attachment 59044 [details]
> a patch to fix patch 59034
> 
> Looks the use of the raw R0 pattern in 59034 confuses the def-use analysis
> and RA.
> I guess it could be the cause of the segfault in c#225.

Thanks, I'll add that patch and try again.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #228 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #227)
> (In reply to Kazumoto Kojima from comment #226)
> > Created attachment 59044 [details]
> > a patch to fix patch 59034
> > 
> > Looks the use of the raw R0 pattern in 59034 confuses the def-use analysis
> > and RA.
> > I guess it could be the cause of the segfault in c#225.
> 
> Thanks, I'll add that patch and try again.

I can confirm that the patch 59044 fixes the patch 59034 and both patches
together fix gccgo. I'll have a go at Ada now.

Great to see that we're making so much progress!

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #229 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #228)
> I'll have a go at Ada now.

Ada still fails in subreg1:

mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-except.adb -o ada/libgnat/s-except.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface ada/libgnat/s-excmac.adb -o
ada/libgnat/s-excmac.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-exctab.adb -o ada/libgnat/s-exctab.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-htable.adb -o ada/libgnat/s-htable.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad32.ads -o ada/libgnat/s-imad32.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad64.ads -o ada/libgnat/s-imad64.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imgint.adb -o ada/libgnat/s-imgint.o
during RTL pass: subreg1
+===========================GNAT BUG DETECTED==============================+
| 15.0.0 20240818 (experimental) (sh4-unknown-linux-gnu) GCC error:        |
| in decompose_multiword_subregs, at lower-subreg.cc:1728                  |
| Error detected around ../../gcc/ada/libgnat/a-exexda.adb:312:8           |
| Compiling ../../gcc/ada/libgnat/a-except.adb                             |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

../../gcc/ada/gcc-interface/system.ads
../../gcc/ada/libgnat/a-except.adb
../../gcc/ada/libgnat/a-except.ads
../../gcc/ada/libgnat/ada.ads
../../gcc/ada/libgnat/s-parame.ads
../../gcc/ada/libgnat/s-stalib.ads
../../gcc/ada/libgnat/a-unccon.ads
../../gcc/ada/libgnat/s-traent.ads
../../gcc/ada/libgnat/s-except.ads
../../gcc/ada/libgnat/s-excdeb.ads
../../gcc/ada/libgnat/s-soflin.ads
../../gcc/ada/libgnat/s-secsta.ads
../../gcc/ada/libgnat/s-stoele.ads
../../gcc/ada/libgnat/s-stache.ads
../../gcc/ada/libgnat/s-wchcon.ads
../../gcc/ada/libgnat/s-wchstw.ads
../../gcc/ada/libgnat/s-traceb.ads
../../gcc/ada/libgnat/s-trasym.ads
../../gcc/ada/libgnat/s-exctab.ads
../../gcc/ada/libgnat/a-excach.adb
../../gcc/ada/libgnat/a-exexda.adb
../../gcc/ada/libgnat/a-exexpr.adb
../../gcc/ada/libgnat/a-uncdea.ads
ada/libgnat/s-excmac.ads
../../gcc/ada/libgnat/a-exextr.adb
../../gcc/ada/libgnat/a-elchha.ads
../../gcc/ada/libgnat/s-imgint.ads
../../gcc/ada/libgnat/s-imagei.ads
../../gcc/ada/libgnat/s-vaispe.ads
../../gcc/ada/libgnat/s-vauspe.ads
../../gcc/ada/libgnat/s-valspe.ads
../../gcc/ada/libgnat/s-unstyp.ads
../../gcc/ada/libgnat/s-vs_int.ads
../../gcc/ada/libgnat/s-vs_uns.ads
../../gcc/ada/libgnat/a-exstat.adb


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:412
mkdir -p ada/libgnat/
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:1175:
ada/libgnat/a-except.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-mastop.adb -o ada/libgnat/s-mastop.o
../../gcc/ada/uintp.adb: In function 'Uintp.Ui_Mul':
../../gcc/ada/uintp.adb:2030:27: warning: '(*l_vec.447_422)[1]{lb: 1 sz: 4}'
may be used uninitialized [-Wmaybe-uninitialized]
../../gcc/ada/uintp.adb:2030:27: warning: '(*l_vec.447_50)[1]{lb: 1 sz: 4}' may
be used uninitialized [-Wmaybe-uninitialized]
../../gcc/ada/uintp.adb:2030:27: warning: '(*l_vec.447_235)[1]{lb: 1 sz: 4}'
may be used uninitialized [-Wmaybe-uninitialized]
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[3]: Leaving directory '/srv/glaubitz/gcc/build/gcc'
make[2]: *** [Makefile:5095: all-stage2-gcc] Error 2
make[2]: Leaving directory '/srv/glaubitz/gcc/build'
make[1]: *** [Makefile:25394: stage2-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc/build'
make: *** [Makefile:1101: all] Error 2

Will try other languages now.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #230 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #229)
> Will try other languages now.

Building with Fortran, Objective-C and Objective-C++ enabled works fine.

Will test D and M2 now.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #231 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #230)
> (In reply to John Paul Adrian Glaubitz from comment #229)
> > Will try other languages now.
> 
> Building with Fortran, Objective-C and Objective-C++ enabled works fine.
> 
> Will test D and M2 now.

Couldn't test D yet due to limitations of the frontend, but I tried JIT and M2
and both built fine although I had to fix a minor unrelated bug in the JIT code
to get the build to finish. Will post the patch on gcc-patches.

Will try to build D now.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #232 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59061&action=edit
a trial patch to fix ICE in c#229

I could get multiple ICEs with the cross libada build.
The first one looks like the same ICE in c#229 and is caused by the insn

(set (mem/j:QI (plus:SI (reg:SI 175)
            (subreg:SI (reg/v:DI 172 [ info ]) 0)) [9
MEM[(character[D.4371:iftmp.54] *)_5][ptr.57_6]{lb: _2 sz: 1}+0 S1 A8])
    (subreg/s/u:QI (reg/v:SI 170 [ c ]) 0))

which is unrecognizable with -mlra.  This is an oversite when adding the new
split_and_insns for QIHI move.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #233 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59062&action=edit
a patch to fix other ICEs during libada build

The second one is the ICE in split2 pass during building libada with the
unrecognizable insn:

(insn 1695 103 1694 12 (set (reg:SF 150 fpul)
        (reg:SF 150 fpul)) "s-valrea.adb":157:13 -1
     (nil))

which looks to be generated with

(define_split
  [(set (match_operand:SF 0 "register_operand" "")
        (match_operand:SF 1 "register_operand" ""))
   (use (reg:SI FPSCR_MODES_REG))
   (clobber (reg:SI FPUL_REG))]
  "TARGET_SH1"
  [(parallel [(set (reg:SF FPUL_REG) (match_dup 1))
              (use (reg:SI FPSCR_MODES_REG))
              (clobber (scratch:SI))])
   (parallel [(set (match_dup 0) (reg:SF FPUL_REG))
              (use (reg:SI FPSCR_MODES_REG))
              (clobber (scratch:SI))])]
  "")

when operand 1 is FPUL itself.  movsf_ie_ra could make that pattern which was
never generated with the old RA.  It went away with adding guards so not to
permit this splitting when fpul is given as the operand 0/1.

There is another ICE for the unrecognizable insn:

(insn 5 307 288 (parallel [
            (set (reg/v:SF 2 r2 [orig:167 s ] [167])
                (mem/u/c:SF (label_ref 521) [0  S4 A32]))
            (use (reg:SI 154 fpscr0))
            (clobber (mem/c:SI (plus:SI (reg:SI 2 r2 [306])
                        (const_int 60 [0x3c])) [29 %sfp+-4 S4 A32]))
        ]) "s-valrea.adb":358:12 -1
     (nil))

during mach pass.  Looks LRA allocates mem for the scratch pattern of movsf_ie
(clobber (match_scratch:SI 2 "=...&z...")) of which constraint is early
clobbered r0.
Looks an LRA specific auxiliary movsf pattern for constant load works as a
workaround.

The patches are not tested well and can cause new issues.  Tested only target
libgcc/libstdc++v3/libada build with -O2 -m4 -mlra.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #234 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
OK, I'll add both patch 59061 and patch 59062 and give it a try with all
languages enabled except for D which requires a working libphobos which I don't
have.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #235 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #234)
> OK, I'll add both patch 59061 and patch 59062 and give it a try with all
> languages enabled except for D which requires a working libphobos which I
> don't have.

Seems like the original problem with Ada is fixed, but it still fails with a
stack overflow error:

/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fchecking=1 -c -g -O2
-fchecking=1  -gnatpg -gnata -W -Wall -fPIC -nostdinc -I- -I. -Iada/generated
-Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat -Iada/gcc-interface
-I../../gcc/ada/gcc-interface ../../gcc/ada/sem_smem.adb -o ada/sem_smem.o

raised STORAG
E_ERROR : stack overflow or errronaeiosuesd  memory acScTeOsRsAGE_ERROR
 :
stack overflow or erroneous memory access
raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access


rraaiisseedd  SSTTOORRAAGGEE__EERRRROORR  ::  ssttaacckk  oovveerrffllooww 
oorr  eerrrroonneeoouuss  mmeemmoorryy  aacccceessss


raised STORAGE_ERROR : stack
overflow or erroneous memory access
raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_case.o]
Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:171: ada/seinfo.o] Error
1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem.o] Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_attr.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_aggr.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_cat.o]
Error 1


raised raSTORiAGsEe_dE RRORSTORAGE_ERRO R:  : stack overflow or errsonteaocuks 
omveemrofrlyo wa cocre sesrroneous memory access

make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch11.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch12.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch13.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch10.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_aux.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166:
ada/accessibility.o] Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous
memory access
raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : make[3]: ***
[../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch4.o] Error 1
stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch7.o]
Error 1

raised STORAGE_ERROR : make[3]: ***
[../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch3.o] Error 1
stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflowmake[3]: ***
[../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch2.o] Error 1
 or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch6.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch8.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_eval.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_disp.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch5.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access


raised STORAGE_ERROR
 : raised STsOtRaAcGkE_ EoRvReOrRflow or erroneous m er:m oariys eadc
cessSTORAGE_ERROR
stac k:  overflow or erroneous memory accessstack ov
erflow or erroneous memory access

raised STORAGE_ERROR

 : stack overflow or erroneous memory access
rraaiisseedd  SSTTOORRAAGGEE__EERRRROORR  ::  ssttaacckk  oovveerrffllooww 
oorr  eerrrroonneeoouuss  mmeemmoorryy  aacccceessss

make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_mech.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_elim.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_prag.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_elab.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch9.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_smem.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_dim.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_dist.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_intr.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_scil.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_res.o]
Error 1
make[3]: Leaving directory '/srv/glaubitz/gcc/build/gcc'
make[2]: *** [Makefile:5135: all-stage3-gcc] Error 2
make[2]: Leaving directory '/srv/glaubitz/gcc/build'
make[1]: *** [Makefile:26986: stage3-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc/build'
make: *** [Makefile:1099: all] Error 2

Not sure though whether this is related at all. Will go back to the known
working version and retry with all patches.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #236 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #235)
> Not sure though whether this is related at all. Will go back to the known
> working version and retry with all patches.

OK, the stack overflow issue is reproducible. Will try with LRA disabled now to
see if it's a side-effect or LRA or the patches 59061 and 59062.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #237 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #236)
> (In reply to John Paul Adrian Glaubitz from comment #235)
> > Not sure though whether this is related at all. Will go back to the known
> > working version and retry with all patches.
> 
> OK, the stack overflow issue is reproducible. Will try with LRA disabled now
> to see if it's a side-effect or LRA or the patches 59061 and 59062.

Turns out the stack overflow is unrelated to 59061 and 59062, and indeed, the
two patches fix the problem with previous problem with Ada. So the two patches
are fine.

Let me try to bisect the stack overflow bug. Will report back once I know more.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #238 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #237)
> Let me try to bisect the stack overflow bug. Will report back once I know
> more.

It's one of the other LRA patches, but it takes me longer than expected to
bisect this.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #239 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #238)
> (In reply to John Paul Adrian Glaubitz from comment #237)
> > Let me try to bisect the stack overflow bug. Will report back once I know
> > more.
> 
> It's one of the other LRA patches, but it takes me longer than expected to
> bisect this.

My suspicion is that it is caused by patch 59000 which I am leaving out now.

Luckily, we have patch 58895 as a workaround.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #240 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
My trial of the 3-stage bootstrap of gcc with enabling c,c++,lto,ada on qemu
has been done successfully with "-g -O2 -m4 -mlra" flags.  I'm using the gcc
master commit 592a335de563a3a9e36d362c5b9f3fb0a990c1d8  + LRA patch series
which is equal to sh-lra branch to https://github.com/kazkojima/gcc.git.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #241 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #240)
> My trial of the 3-stage bootstrap of gcc with enabling c,c++,lto,ada on qemu
> has been done successfully with "-g -O2 -m4 -mlra" flags.  I'm using the gcc
> master commit 592a335de563a3a9e36d362c5b9f3fb0a990c1d8  + LRA patch series
> which is equal to sh-lra branch to https://github.com/kazkojima/gcc.git.

Did that include patch 59000?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #242 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #241)
> (In reply to Kazumoto Kojima from comment #240)
> Did that include patch 59000?

Yes.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #243 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #242)
> (In reply to John Paul Adrian Glaubitz from comment #241)
> > (In reply to Kazumoto Kojima from comment #240)
> > Did that include patch 59000?
> 
> Yes.

Is that with qemu-user or qemu-system? I tried multiple times and I always got
a stack overflow with 59000. Trying without now.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #244 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #243)
> Is that with qemu-user or qemu-system? I tried multiple times and I always
> got a stack overflow with 59000. Trying without now.

qemu-user.  I'm using the default stack size.
Of course that is not the real sh4-linux environment, so there could be
differences.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #245 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #244)
> (In reply to John Paul Adrian Glaubitz from comment #243)
> > Is that with qemu-user or qemu-system? I tried multiple times and I always
> > got a stack overflow with 59000. Trying without now.
> 
> qemu-user.  I'm using the default stack size.
> Of course that is not the real sh4-linux environment, so there could be
> differences.

Hmm, I'm on qemu-user as well building inside a current Debian unstable sh4
chroot.

[Bug target/55212] [SH] Switch to LRA

[schwab@linux-m68k.org]

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

--- Comment #246 from Andreas Schwab <schwab@linux-m68k.org> ---
GCC requires a stack size of 64MB.  qemu-user needs to allocate the stack on
startup and cannot change its size at runtime (any attempt to use
setrlimit(RLIMIT_STACK) will be ignored).

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #247 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Applying all necessary patches except 59000 makes the stack overflow with
reload go away.

Will try an LRA build now with the following patches and Ada enabled:

- 58832
- 58833
- 58883
- 58905
- 59034
- 59044
- 59061
- 59062
- 58995

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #248 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59102&action=edit
a reduced C test case for the wrong code problem c#192

typedef struct { int c[64]; } obj;

extern void bar (int, int, int, int, obj *);
void foo (obj *p)
{
  obj bobj = *p;
  bar (0, 0, 0, 0, &bobj);
}

With "-O2 -m4 -mlra -ffixed-r7 -ffixed-r8 -ffixed-r9 -ffixed-r10 -ffixed-r11
-ffixed-r12 -ffixed-r13", it's compiled to

foo:
        mov.l   r14,@-r15       ! 32    [c=4 l=2]  movsi_ie/8
        mov     r4,r5   ! 23    [c=4 l=2]  movsi_ie/1
        sts.l   pr,@-r15        ! 33    [c=4 l=2]  movsi_ie/10
        mov.w   .L6,r1  ! 34    [c=10 l=2]  *movhi/0
        mov     #31,r6  ! 11    [c=4 l=2]  movsi_ie/2
        mov.l   .L4,r14 ! 29    [c=10 l=2]  movsi_ie/0
        mov     #0,r7   ! 16    [c=4 l=2]  movsi_ie/2
        sub     r1,r15  ! 35    [c=4 l=2]  *subsi3_internal
        mov     r15,r4  ! 30    [c=4 l=2]  movsi_ie/1
        jsr     @r14    ! 12    [c=1 l=2]  block_lump_real_i4/0
        add     #4,r4   ! 31    [c=4 l=2]  *addsi3_compact_lra/0
        mov.l   .L5,r1  ! 27    [c=10 l=2]  movsi_ie/0
        mov     #0,r6   ! 17    [c=4 l=2]  movsi_ie/2
        mov.l   r4,@r15 ! 14    [c=4 l=2]  movsi_ie/8
        mov     #0,r5   ! 18    [c=4 l=2]  movsi_ie/2
        jsr     @r1     ! 20    [c=0 l=2]  calli
        mov     #0,r4   ! 19    [c=4 l=2]  movsi_ie/2

r4 clobbered by block_lump_real_i4 is wrongly used as the 5-th argument of the
bar function.  ffixed-reg options are used to make register starvation.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #249 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #248)
> Created attachment 59102 [details]
> a reduced C test case for the wrong code problem c#192
> 
> typedef struct { int c[64]; } obj;
> 
> extern void bar (int, int, int, int, obj *);
> void foo (obj *p)
> {
>   obj bobj = *p;
>   bar (0, 0, 0, 0, &bobj);
> }
> 
> With "-O2 -m4 -mlra -ffixed-r7 -ffixed-r8 -ffixed-r9 -ffixed-r10 -ffixed-r11
> -ffixed-r12 -ffixed-r13", it's compiled to
> 

Very nice.  Can you please add it as a test case under
gcc/testsuite/gcc.target/sh/torture on your github repo?

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #250 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #247)
> Applying all necessary patches except 59000 makes the stack overflow with
> reload go away.
> 
> Will try an LRA build now with the following patches and Ada enabled:
> 
> - 58832
> - 58833
> - 58883
> - 58905
> - 59034
> - 59044
> - 59061
> - 59062
> - 58995

This builds fine. I will try to build Kaz's tree now as it is.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #251 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #249)
> Very nice.  Can you please add it as a test case under
> gcc/testsuite/gcc.target/sh/torture on your github repo?

I've just add it as testsuite/gcc.target/sh/pr55212-c248.c.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #252 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #250)
> This builds fine. I will try to build Kaz's tree now as it is.

I suggest, once this is verified to work, that we start upstreaming the patches
and perform potentially needed bug fixing later.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #253 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #252)
> (In reply to John Paul Adrian Glaubitz from comment #250)
> > This builds fine. I will try to build Kaz's tree now as it is.
> 
> I suggest, once this is verified to work, that we start upstreaming the
> patches and perform potentially needed bug fixing later.

Some of the patches could be merged in master as-is.  However, some of them are
clearly quick hacks to get it to work somehow right now and get the overall
picture of the problem, like Kaz said himself before.

For some of the issues the actual reason should be investigated first. 
Otherwise this "we will fix it later" will never happen and we'll have an even
bigger mess of hacks to maintain further down the line -- like with some of the
> 20 year old issues in the backend.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #254 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #253)
> (In reply to John Paul Adrian Glaubitz from comment #252)
> > (In reply to John Paul Adrian Glaubitz from comment #250)
> > > This builds fine. I will try to build Kaz's tree now as it is.
> > 
> > I suggest, once this is verified to work, that we start upstreaming the
> > patches and perform potentially needed bug fixing later.
> 
> Some of the patches could be merged in master as-is.  However, some of them
> are clearly quick hacks to get it to work somehow right now and get the
> overall picture of the problem, like Kaz said himself before.
> 
> For some of the issues the actual reason should be investigated first. 
> Otherwise this "we will fix it later" will never happen and we'll have an
> even bigger mess of hacks to maintain further down the line -- like with
> some of the > 20 year old issues in the backend.

OK, thanks for the clarification. I'd suggest then to upstream everything that
has been tested to work and is also fine to merge as-is.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #255 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #254)

> OK, thanks for the clarification. I'd suggest then to upstream everything
> that has been tested to work and is also fine to merge as-is.

Having the compiler bootstrapping is already a big step, but how about building
other packages?  With the patched up and bootstrapping compiler, can you start
building packages and collect some data, like how many build / fail and so on?

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #256 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #255)
> (In reply to John Paul Adrian Glaubitz from comment #254)
> 
> > OK, thanks for the clarification. I'd suggest then to upstream everything
> > that has been tested to work and is also fine to merge as-is.
> 
> Having the compiler bootstrapping is already a big step, but how about
> building other packages?  With the patched up and bootstrapping compiler,
> can you start building packages and collect some data, like how many build /
> fail and so on?

I'm planning to do that next. It takes just a little time with QEMU.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #257 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #256)
> > 
> > Having the compiler bootstrapping is already a big step, but how about
> > building other packages?  With the patched up and bootstrapping compiler,
> > can you start building packages and collect some data, like how many build /
> > fail and so on?
> 
> I'm planning to do that next. It takes just a little time with QEMU.

That would be great.  Don't worry, we have time.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #258 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #250)
> This builds fine. I will try to build Kaz's tree now as it is.

So, for Kaz's tree, I'm getting the comparison failure:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/gimple-lower-bitint.o differs
make[2]: *** [Makefile:25560: compare] Error 1
make[2]: Leaving directory '/srv/glaubitz/gcc-sh/build'
make[1]: *** [Makefile:25540: stage3-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc-sh/build'
make: *** [Makefile:1098: all] Error 2

Thus, the best result for me so far is with the following patches:

- 58832
- 58833
- 58883
- 58905
- 59034
- 59044
- 59061
- 59062
- 58995

Will try to build a Debian package next and use that to test-compile various
packages.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #259 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I totally agree with Oleg. We are still close to the starting point.

The experiment with 58895/59000 shows that there might be some issue with the
SH sfunc when LRA is enabled. It only paper over the real problem, though.  We
should look into what is going on when the sfunc pattern is used in register
starvation.

Also agreed with that more tests are needed.  We have not yet run even all gcc
testsuites.

The comparison failure with just one file depending on the environments could
mean unstable behavior due to some hidden problem.  Expect that more tests will
clarify it.

[Bug target/55212] [SH] Switch to LRA

[hp at gcc dot gnu.org]

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

--- Comment #260 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Random advice that some of you know, but it's also easy to forget: reorg (the
delayed-branch-slot-filling pass) is a usual suspect: there be dragons.  So,
when suspecting wrong-code for DELAY_SLOTS such as sh, also try
-fno-delayed-branch.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #261 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I'm a little concerned because of PR 115949.  It shows that there are some
fundamental issues with move patterns like `movsi_ie`.  It seems real-world
code is very easy to hit that problem.

I'm thinking to remove the FP alternatives from 'movsi_ie' and similarly,
remove the GP alternatives from 'movsf_ie'.  Kaz, since you've been looking in
similar places recently ( e.g.
https://github.com/kazkojima/gcc/commit/ed9236ca72bda40f4f68ce6ff0cea7a47d710836
), what's your opinion on that?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #262 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #261)
> I'm a little concerned because of PR 115949.  It shows that there are some
> fundamental issues with move patterns like `movsi_ie`.  It seems real-world
> code is very easy to hit that problem.
> 
> I'm thinking to remove the FP alternatives from 'movsi_ie' and similarly,
> remove the GP alternatives from 'movsf_ie'.  Kaz, since you've been looking
> in similar places recently ( e.g.
> https://github.com/kazkojima/gcc/commit/
> ed9236ca72bda40f4f68ce6ff0cea7a47d710836 ), what's your opinion on that?

movsf_ie_ra was a workaround for the issue that LRA tends to allocate memory
displacemant for the scratch register.  I'm not sure that is related directly
with pr115949.

I've found many issues even with movsf_ie_ra by checking the result of "make
check-gcc RUNTESTFLAGS="--target_board=unix/-m4/-mlra" on qemu.  After all, the
constraints in match_scratch of movsf_ie_ra will make problems on SH.  I'm
trying to remove them with splitting movsf_ie_ra into several patterns and some
of them use more restricted predicates.

general_mov{src,dst}_operand has some codes for that LRA behavior, but perhaps
more ristricted predicates and specific patterns will be safer as you pointed
out.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #263 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59132&action=edit
a patch rewriting movsh_ie_ra

This patch splits movsf_ie_ra into several new patterns to remove
match_scratch.  Also define a new sub-pattern of movdf for constant loads.

    * gcc/config/sh/predicates.md (pc_relative_load_operand):
    New predicate.
    * gcc/config/sh/sh-protos.h (sh_movsf_ie_ra_split_p): Remove.
    (sh_movsf_ie_y_split_p): New proto.
    * gcc/config/sh/sh.cc: (sh_movsf_ie_ra_split_p): Remove.
    (sh_movsf_ie_y_split_p): New function.
    * gcc/config/sh/sh.md (movdf_i4_F_z): New insn pattern.
    (movdf): Use it.
    (movsf_ie_ra): Use define_insn instead of define_insn_and_split.
    (movsf_ie_F_z): Rename from movsf_ie_const_ra.
    (movsf_ie_Q_z, movsf_ie_y): New insn pattern.
    (movsf): Use new patterns.
    (movdf_i4_F_z+7): New splitter.

With it, now "make check-gcc" has no new ICEs with unix/-m4/-mlra when
comparing unix/-m4.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #264 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #263)
> Created attachment 59132 [details]
> a patch rewriting movsh_ie_ra
> 
> This patch splits movsf_ie_ra into several new patterns to remove
> match_scratch.  Also define a new sub-pattern of movdf for constant loads.
>     
>     * gcc/config/sh/predicates.md (pc_relative_load_operand):
>     New predicate.
>     * gcc/config/sh/sh-protos.h (sh_movsf_ie_ra_split_p): Remove.
>     (sh_movsf_ie_y_split_p): New proto.
>     * gcc/config/sh/sh.cc: (sh_movsf_ie_ra_split_p): Remove.
>     (sh_movsf_ie_y_split_p): New function.
>     * gcc/config/sh/sh.md (movdf_i4_F_z): New insn pattern.
>     (movdf): Use it.
>     (movsf_ie_ra): Use define_insn instead of define_insn_and_split.
>     (movsf_ie_F_z): Rename from movsf_ie_const_ra.
>     (movsf_ie_Q_z, movsf_ie_y): New insn pattern.
>     (movsf): Use new patterns.
>     (movdf_i4_F_z+7): New splitter.
> 
> With it, now "make check-gcc" has no new ICEs with unix/-m4/-mlra when
> comparing unix/-m4.

Very nice!  So it seems indeed, splitting up the "mega move patterns" into
simpler ones where predicates are more closer to the actual constraints give
better results (if I'm not mistaken).  Have you also tried using these patterns
without LRA?  I'm just wondering if we need to distinguish between LRA/non-LRA
case at all.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #265 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59133&action=edit
a revised patch of 58883

I noticed that I accidentally pushed unintended changes to the patch 58883 and
59000. I'd like to remove them from these two patches and update them. Sorry
for the inconvenience.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #266 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59134&action=edit
a revised patch of 59000

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #267 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #264)
> Very nice!  So it seems indeed, splitting up the "mega move patterns" into
> simpler ones where predicates are more closer to the actual constraints give
> better results (if I'm not mistaken).  Have you also tried using these
> patterns without LRA?  I'm just wondering if we need to distinguish between
> LRA/non-LRA case at all.

I'll give it a try and report back.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #268 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #265)
> Created attachment 59133 [details]
> a revised patch of 58883
> 
> I noticed that I accidentally pushed unintended changes to the patch 58883
> and 59000. I'd like to remove them from these two patches and update them.
> Sorry for the inconvenience.

This makes another problem.  Please ignore 59133.  Sorry for my mess.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #269 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #267)
> (In reply to Oleg Endo from comment #264)
> > Very nice!  So it seems indeed, splitting up the "mega move patterns" into
> > simpler ones where predicates are more closer to the actual constraints give
> > better results (if I'm not mistaken).  Have you also tried using these
> > patterns without LRA?  I'm just wondering if we need to distinguish between
> > LRA/non-LRA case at all.
> 
> I'll give it a try and report back.

Unfortunately, it doesn't seem to work.  It can build target libgcc/libstdc++v3
libs, but I got the our old friend when compiling
gcc.c-torture/compile/20031220-2.c with -O2

... error: unable to find a register to spill in class 'R0_REGS'
... error: this is the insn:
(insn 4 27 158 6 (parallel [
            (set (reg/v:SF 174 [ h ])
                (const_double:SF 5.0e-1 [0x0.8p+0]))
            (use (reg:SI 154 fpscr0))
            (clobber (reg:SI 0 r0))
        ]) "/git/gcc/gcc/testsuite/gcc.c-torture/compile/20031220-2.c":27:11
233
 {movsf_ie}

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #270 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #269)
> (In reply to Kazumoto Kojima from comment #267)
> > (In reply to Oleg Endo from comment #264)
> > > Very nice!  So it seems indeed, splitting up the "mega move patterns" into
> > > simpler ones where predicates are more closer to the actual constraints give
> > > better results (if I'm not mistaken).  Have you also tried using these
> > > patterns without LRA?  I'm just wondering if we need to distinguish between
> > > LRA/non-LRA case at all.
> > 
> > I'll give it a try and report back.
> 
> Unfortunately, it doesn't seem to work.  It can build target
> libgcc/libstdc++v3 libs, but I got the our old friend when compiling
> gcc.c-torture/compile/20031220-2.c with -O2

OK, I'll wait with testing further patches then. In the mean time, I will use
an LRA-enabled GCC 15 to test against older bug reports against the SH backend.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #271 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I just did some testing with the LRA-enabled gcc-15 to see which bugs would be
fixed and while I can confirm that both PR target/81426 and PR target/115148 no
longer occur, another ICE has just popped up:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g0 -O1 -ffile-prefix-map=/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 --param ggc-min-expand=10
-DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkGeometry.cpp.o -MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkGeometry.cpp.o.d -o
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkGeometry.cpp.o -c
/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkGeometry.cpp
during RTL pass: postreload
/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkGeometry.cpp:
In member function 'SkPoint SkConic::evalAt(SkScalar) const':
/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkGeometry.cpp:1362:1:
internal compiler error: in reload_combine_note_use, at postreload.cc:1524
 1362 | }
      | ^
0x1b489eb diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag*, diagnostic_t)
        ???:0
0x1b561e7 internal_error(char const*, ...)
        ???:0
0x66af4f fancy_abort(char const*, int, char const*)
        ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccYWv2JM.out file, please attach this to
your bugreport.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #272 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #271)
> I just did some testing with the LRA-enabled gcc-15 to see which bugs would
> be fixed and while I can confirm that both PR target/81426 and PR
> target/115148 no longer occur, another ICE has just popped up:

Ah, it doesn't occur with -O2. I happed to still build with -O1 due to earlier
issues when building with Reload instead of LRA.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #273 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Ran into another one:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g1 -O2 -ffile-prefix-map=/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/pathops/SkPathOpsCubic.cpp.o -MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/pathops/SkPathOpsCubic.cpp.o.d
-o Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/pathops/SkPathOpsCubic.cpp.o
-c
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp:
In member function 'bool SkDCubic::isLinear(int, int) const':
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp:239:1:
error: unrecognizable insn:
  239 | }
      | ^
(insn 6 1028 1030 (parallel [
            (set (reg:DF 1 r1 [orig:248 lineParameters$fC ] [248])
                (mem/u/c:DF (label_ref 1298) [0  S8 A32]))
            (use (reg:SI 154 fpscr0))
            (clobber (mem/c:SI (plus:SI (reg:SI 1 r1 [694])
                        (const_int 24 [0x18])) [187 %sfp+-40 S4 A32]))
        ])
"/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkLineParameters.h":128:26
-1
     (nil))
during RTL pass: mach
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp:239:1:
internal compiler error: in insn_min_length, at config/sh/sh.md:4190
0x1b489eb diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag*, diagnostic_t)
        ???:0
0x1b561e7 internal_error(char const*, ...)
        ???:0
0x66af4f fancy_abort(char const*, int, char const*)
        ???:0
0x6502f7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ???:0
0x650325 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ???:0
0x184692b insn_min_length(rtx_insn*)
        ???:0
0xb9eaab shorten_branches(rtx_insn*)
        ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccpQI6hF.out file, please attach this to
your bugreport.

Will attach the pre-processed source, also for comment #271.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #274 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 59151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59151&action=edit
Preprocessed source from from comment #271

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #275 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 59152
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59152&action=edit
Preprocessed source from from comment #273

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #276 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
It will take some time to sort out the known issues and there may be unknown
problems.  Further testing with gcc-15 sounds like a good idea.

Here is a list of known issues and their status.

* call_pcrel patterns: match_scratch can cause ICE for the corner case.  We use
a fixed register instead of scratch as a quick fix.  More investigation is
needed.

* movsf: match_scratch can be satisfied with memory displacement unexpectedly. 
It may be solved with splitting movesf_ie_ra to several patterns to remove
match_scratch.  Work in progress.

* mov<mode>, extend<mode>: Some QIHI move or extend patterns will make long R0
live ranges for the indexed/short-displacement memory and could confuse LRA. 
We define new {mov,extend}<mode> patterns for them with hard R0 to shorten R0
live ranges.

* sfunc: Looks some hard reg clobbering patterns don't work with LRA.  We get a
handy test case.  More investigation is needed.

Current my assumption on the sfunc issue: LRA doesn't handle the clobber hard
reg pattern if that hard reg is recognized as the input reg.  I don't know the
direct way to give the output modifier to the raw hard reg pattern.  I'm trying
match_operand instead of raw reg so to modify it to the output.  For example,
rewriting block_lump_real_i4 to

(define_insn "block_lump_real_i4"
  [(parallel [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
                   (mem:BLK (match_operand:SI 3 "" "r,r")))
              (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
              (use (match_operand 1 "" "Z,Ccl"))
              (use (match_operand:SI 4 "" "r,r"))
              (clobber (match_scratch:SI 5 "=2,2"))
              (clobber (match_scratch:SI 6 "=3,3"))
              (clobber (match_scratch:SI 7 "=4,4"))
              (clobber (reg:SI PR_REG))
              (clobber (reg:SI T_REG))
              (clobber (reg:SI R0_REG))
              (clobber (reg:SI R1_REG))
              (clobber (reg:SI R2_REG))
              (clobber (reg:SI R3_REG))])]
  "TARGET_HARD_SH4"
  "@
        jsr     @%0%#
        bsrf    %0\n%O1:%#"
  [(set_attr "type" "sfunc")
   (set_attr "needs_delay_slot" "yes")])

with setting operands[2] = r4, operands[3] = r5 and operands[4] = r6 looks
working as expected.  block_lump_real, udivsi3_i1, udivsi3_i4 and
udivsi3_i4_single have the similar issue.  I'll test the similar changes of
those sfuncs.

FYI, it seems that LRA handles call insns specially so as to process the
clobber pattern of the input hard reg.  These are based on my vague
understanding of RA, though.

[Bug target/55212] [SH] Switch to LRA

[aoliva at gcc dot gnu.org]

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

--- Comment #277 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 59153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59153&action=edit
[lra] take scratch as implicit unused output reloads

> * call_pcrel patterns: match_scratch can cause ICE for the corner case.  We use a fixed register instead of scratch as a quick fix.  More investigation is needed.

This sounds familiar.  I may have an LRA patch to address this problem, but
it's got very little testing.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #278 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Alexandre Oliva from comment #277)
> Created attachment 59153 [details]
> [lra] take scratch as implicit unused output reloads
> 
> > * call_pcrel patterns: match_scratch can cause ICE for the corner case.  We use a fixed register instead of scratch as a quick fix.  More investigation is needed.
> 
> This sounds familiar.  I may have an LRA patch to address this problem, but
> it's got very little testing.

Thanks!  I'll give it a try.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #279 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #275)
> Created attachment 59152 [details]
> Preprocessed source from from comment #273

Thanks for test cases.  Both .ii are compiled successfully with the WIP cross
compiler here, though I could use wrong flags.

./cc1plus -quiet -m4 -mlra -g0 -O1 -std=c++23 -fno-strict-aliasing
-fno-exceptions -fno-rtti -fcoroutines -ffunction-sections -fdata-sections
-fPIC -fvisibility=hidden -ffp-contract=off -fstrict-aliasing
pr-55212-271/SkGeometry.cpp.ii -o /dev/null

./cc1plus -quiet -m4 -mlra -g1 -O2 -std=c++23 -fno-strict-aliasing
-fno-exceptions -fno-rtti -fcoroutines -ffunction-sections -fdata-sections
-fPIC -fvisibility=hidden -ffp-contract=off -fstrict-aliasing
pr-55212-273/SkPathOpsCubic.cpp.ii -o /dev/null

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #280 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #279)
> (In reply to John Paul Adrian Glaubitz from comment #275)
> > Created attachment 59152 [details]
> > Preprocessed source from from comment #273
> 
> Thanks for test cases.  Both .ii are compiled successfully with the WIP
> cross compiler here, though I could use wrong flags.

The flags look correct to me.

Could you tell me what patches you were testing? Then I'll rebuild my local GCC
and retry building webkit2gtk with the updated compiler.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #281 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #280)
> (In reply to Kazumoto Kojima from comment #279)
> > (In reply to John Paul Adrian Glaubitz from comment #275)
> > > Created attachment 59152 [details]
> > > Preprocessed source from from comment #273
> > 
> > Thanks for test cases.  Both .ii are compiled successfully with the WIP
> > cross compiler here, though I could use wrong flags.
> 
> The flags look correct to me.
> 
> Could you tell me what patches you were testing? Then I'll rebuild my local
> GCC and retry building webkit2gtk with the updated compiler.

I can't show the complete patch set as it's still WIP.  Could you please give
me a little more time?

However, c#273 seems very similar to the error resolved with the patch 59132.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #282 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #281)
> (In reply to John Paul Adrian Glaubitz from comment #280)
> > (In reply to Kazumoto Kojima from comment #279)
> > > (In reply to John Paul Adrian Glaubitz from comment #275)
> > > > Created attachment 59152 [details]
> > > > Preprocessed source from from comment #273
> > > 
> > > Thanks for test cases.  Both .ii are compiled successfully with the WIP
> > > cross compiler here, though I could use wrong flags.
> > 
> > The flags look correct to me.
> > 
> > Could you tell me what patches you were testing? Then I'll rebuild my local
> > GCC and retry building webkit2gtk with the updated compiler.
> 
> I can't show the complete patch set as it's still WIP.  Could you please
> give me a little more time?

Sure, no problem. I wasn't aware the patch is WIP. Sorry for that

> However, c#273 seems very similar to the error resolved with the patch 59132.

OK, thanks. But I'll wait. Let me know when you want me to retest.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #283 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #276)
> Current my assumption on the sfunc issue: LRA doesn't handle the clobber
> hard reg pattern if that hard reg is recognized as the input reg.  I don't
> know the direct way to give the output modifier to the raw hard reg pattern.
> I'm trying match_operand instead of raw reg so to modify it to the output. 
> For example, rewriting block_lump_real_i4 to
> 
> (define_insn "block_lump_real_i4"
>   [(parallel [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
> 		   (mem:BLK (match_operand:SI 3 "" "r,r")))
> 	      (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> 	      (use (match_operand 1 "" "Z,Ccl"))
> 	      (use (match_operand:SI 4 "" "r,r"))
> 	      (clobber (match_scratch:SI 5 "=2,2"))
> 	      (clobber (match_scratch:SI 6 "=3,3"))

It turned out that the c#276 version of block_lump_real_i4 works correctly in
only the limited cases.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #284 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #283)
> (In reply to Kazumoto Kojima from comment #276)
> > Current my assumption on the sfunc issue: LRA doesn't handle the clobber
> > hard reg pattern if that hard reg is recognized as the input reg.  I don't
> > know the direct way to give the output modifier to the raw hard reg pattern.
> > I'm trying match_operand instead of raw reg so to modify it to the output. 
> > For example, rewriting block_lump_real_i4 to
> > 
> > (define_insn "block_lump_real_i4"
> >   [(parallel [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
> > 		   (mem:BLK (match_operand:SI 3 "" "r,r")))
> > 	      (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> > 	      (use (match_operand 1 "" "Z,Ccl"))
> > 	      (use (match_operand:SI 4 "" "r,r"))
> > 	      (clobber (match_scratch:SI 5 "=2,2"))
> > 	      (clobber (match_scratch:SI 6 "=3,3"))
> 
> It turned out that the c#276 version of block_lump_real_i4 works correctly
> in only the limited cases.

Have you tried writing the pattern as 

(define_insn "block_lump_real_i4"
  [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
                   (mem:BLK (match_operand:SI 3 "" "r,r")))
   (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
   (use (match_operand 1 "" "Z,Ccl"))
   ...

i.e. without the parallel in there?  Sorry, maybe it's a stupid idea but ...

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #285 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #284)
> (In reply to Kazumoto Kojima from comment #283)
...
> > It turned out that the c#276 version of block_lump_real_i4 works correctly
> > in only the limited cases.
> 
> Have you tried writing the pattern as 
> 
> (define_insn "block_lump_real_i4"
>   [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
>  		   (mem:BLK (match_operand:SI 3 "" "r,r")))
>    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
>    (use (match_operand 1 "" "Z,Ccl"))
>    ...
> 
> i.e. without the parallel in there?  Sorry, maybe it's a stupid idea but ...

The last time I tried it against slightly different patterns, there was no
difference. I'll try it again.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #286 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59157
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59157&action=edit
a revised patch to movsf issue which splits movesf_ie_ra

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #287 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59158&action=edit
a revised patch to QIHI extend/move

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #288 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59159&action=edit
a revised workaround sfunc issue

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #289 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
I've reconstructed patches as follows:

[59157] a revised patch to movsf issue which splits movesf_ie_ra
[59158] a revised patch to QIHI extend/move
[59159] a revised workaround sfunc issue
[59153] Alex's patch works magically for call_pcrel* issue.

I've also created sh-lra-take2 branch of https://github.com/kazkojima/gcc.git
with these patches for the reference.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #290 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #263)
> Created attachment 59132 [details]
> a patch rewriting movsh_ie_ra
> 
> This patch splits movsf_ie_ra into several new patterns to remove
> match_scratch.  Also define a new sub-pattern of movdf for constant loads.
>     
>     * gcc/config/sh/predicates.md (pc_relative_load_operand):
>     New predicate.
>     * gcc/config/sh/sh-protos.h (sh_movsf_ie_ra_split_p): Remove.
>     (sh_movsf_ie_y_split_p): New proto.
>     * gcc/config/sh/sh.cc: (sh_movsf_ie_ra_split_p): Remove.
>     (sh_movsf_ie_y_split_p): New function.
>     * gcc/config/sh/sh.md (movdf_i4_F_z): New insn pattern.
>     (movdf): Use it.
>     (movsf_ie_ra): Use define_insn instead of define_insn_and_split.
>     (movsf_ie_F_z): Rename from movsf_ie_const_ra.
>     (movsf_ie_Q_z, movsf_ie_y): New insn pattern.
>     (movsf): Use new patterns.
>     (movdf_i4_F_z+7): New splitter.
> 
> With it, now "make check-gcc" has no new ICEs with unix/-m4/-mlra when
> comparing unix/-m4.

I have added this patch on top of the other patches and got an ICE when
bootstrapping Ada natively:

a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
            (set (reg:SF 449 [orig:184 _24 ] [184])
                (reg:SF 463))
            (use (reg:SI 154 fpscr0))
        ]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
     (expr_list:REG_DEAD (reg:SF 463)
        (nil)))
during RTL pass: reload

[Bug target/55212] [SH] Switch to LRA

[pinskia at gcc dot gnu.org]

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

--- Comment #291 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #285)
> (In reply to Oleg Endo from comment #284)
> > (In reply to Kazumoto Kojima from comment #283)
> ...
> > > It turned out that the c#276 version of block_lump_real_i4 works correctly
> > > in only the limited cases.
> > 
> > Have you tried writing the pattern as 
> > 
> > (define_insn "block_lump_real_i4"
> >   [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
> >  		   (mem:BLK (match_operand:SI 3 "" "r,r")))
> >    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> >    (use (match_operand 1 "" "Z,Ccl"))
> >    ...
> > 
> > i.e. without the parallel in there?  Sorry, maybe it's a stupid idea but ...
> 
> The last time I tried it against slightly different patterns, there was no
> difference. I'll try it again.


One of the explicit parallel issue was fixed with my commit
g:da33ad53bcb57943fa671c745938a53f4de89a1b 
But there could be more hiding.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #292 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #289)
> I've reconstructed patches as follows:
> 
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI extend/move
> [59159] a revised workaround sfunc issue
> [59153] Alex's patch works magically for call_pcrel* issue.
> 
> I've also created sh-lra-take2 branch of https://github.com/kazkojima/gcc.git
> with these patches for the reference.

OK, I'm trying this branch now. I assume I won't need any other patches.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #293 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #292)
> (In reply to Kazumoto Kojima from comment #289)
> > I've reconstructed patches as follows:
> > 
> > [59157] a revised patch to movsf issue which splits movesf_ie_ra
> > [59158] a revised patch to QIHI extend/move
> > [59159] a revised workaround sfunc issue
> > [59153] Alex's patch works magically for call_pcrel* issue.
> > 
> > I've also created sh-lra-take2 branch of https://github.com/kazkojima/gcc.git
> > with these patches for the reference.
> 
> OK, I'm trying this branch now. I assume I won't need any other patches.

The reconstructed patches were tested only with c,c++ cross build and
testsuite.  I've verified that cross ada can be built successfully as well on
sh-lra-take2 branch.  a-ngcefu.adb is compiled with no ICE when building cross
ada.  It may not be seen with the cross compiler, though.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #294 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #291)
> One of the explicit parallel issue was fixed with my commit
> g:da33ad53bcb57943fa671c745938a53f4de89a1b 
> But there could be more hiding.

Thanks for your comment.  I've confirmed that your commit
da33ad53bcb57943fa671c745938a53f4de89a1b is included in the master branch I'm
using.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #295 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #285)
> (In reply to Oleg Endo from comment #284)
> > (In reply to Kazumoto Kojima from comment #283)
> ...
> > > It turned out that the c#276 version of block_lump_real_i4 works correctly
> > > in only the limited cases.
> > 
> > Have you tried writing the pattern as 
> > 
> > (define_insn "block_lump_real_i4"
> >   [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
> >  		   (mem:BLK (match_operand:SI 3 "" "r,r")))
> >    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> >    (use (match_operand 1 "" "Z,Ccl"))
> >    ...
> > 
> > i.e. without the parallel in there?  Sorry, maybe it's a stupid idea but ...
> 
> The last time I tried it against slightly different patterns, there was no
> difference. I'll try it again.

It seems that there is no difference w/wo the explicit parallel pattern.

BTW, a bit monstrous version of that pattern seems to work at least for gcc
testsuite and our handy test case:

(define_insn "block_lump_real_i4"
  [(set (mem:BLK (match_operand:SI 2 "" "=r,r"))
           (mem:BLK (match_operand:SI 3 "" "=r,r")))
   (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
   (use (match_operand 1 "" "Z,Ccl"))
   (use (match_operand:SI 4 "" "=r,r"))
   (use (reg:SI R4_REG))
   (use (reg:SI R5_REG))
   (use (reg:SI R6_REG))
   (clobber (match_dup 2))
   (clobber (match_dup 3))
   (clobber (match_dup 4))
   (clobber (reg:SI PR_REG))
   (clobber (reg:SI T_REG))
   (clobber (reg:SI R0_REG))
   (clobber (reg:SI R1_REG))
   (clobber (reg:SI R2_REG))
   (clobber (reg:SI R3_REG))]
  "TARGET_HARD_SH4
  && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
  && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG
  && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG"
  "@
        jsr     @%0%#
        bsrf    %0\n%O1:%#"
  [(set_attr "type" "sfunc")
   (set_attr "needs_delay_slot" "yes")])

The extra use patterns avoid allocating R4-R6 to operands[0].
Adding explicit emit_clobber R4-R6 looks better than this to me, though.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #296 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #295)
> (In reply to Kazumoto Kojima from comment #285)
> > (In reply to Oleg Endo from comment #284)
> > > (In reply to Kazumoto Kojima from comment #283)
> > ...
> > > > It turned out that the c#276 version of block_lump_real_i4 works correctly
> > > > in only the limited cases.
> > > 
> > > Have you tried writing the pattern as 
> > > 
> > > (define_insn "block_lump_real_i4"
> > >   [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
> > >  		   (mem:BLK (match_operand:SI 3 "" "r,r")))
> > >    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> > >    (use (match_operand 1 "" "Z,Ccl"))
> > >    ...
> > > 
> > > i.e. without the parallel in there?  Sorry, maybe it's a stupid idea but ...
> > 
> > The last time I tried it against slightly different patterns, there was no
> > difference. I'll try it again.
> 
> It seems that there is no difference w/wo the explicit parallel pattern.
> 
> BTW, a bit monstrous version of that pattern seems to work at least for gcc
> testsuite and our handy test case:
> 
> (define_insn "block_lump_real_i4"
>   [(set (mem:BLK (match_operand:SI 2 "" "=r,r"))
> 	   (mem:BLK (match_operand:SI 3 "" "=r,r")))
>    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
>    (use (match_operand 1 "" "Z,Ccl"))
>    (use (match_operand:SI 4 "" "=r,r"))
>    (use (reg:SI R4_REG))
>    (use (reg:SI R5_REG))
>    (use (reg:SI R6_REG))
>    (clobber (match_dup 2))
>    (clobber (match_dup 3))
>    (clobber (match_dup 4))
>    (clobber (reg:SI PR_REG))
>    (clobber (reg:SI T_REG))
>    (clobber (reg:SI R0_REG))
>    (clobber (reg:SI R1_REG))
>    (clobber (reg:SI R2_REG))
>    (clobber (reg:SI R3_REG))]
>   "TARGET_HARD_SH4
>   && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
>   && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG
>   && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG"
>   "@
> 	jsr	@%0%#
> 	bsrf	%0\n%O1:%#"
>   [(set_attr "type" "sfunc")
>    (set_attr "needs_delay_slot" "yes")])


> 
> The extra use patterns avoid allocating R4-R6 to operands[0].

This sounds almost logical and easy to understand.

> Adding explicit emit_clobber R4-R6 looks better than this to me, though.

Having to use the "emit_clobber" when instantiating that pattern might be easy
to forget.  It's easier to deal with it when it's all contained in one place. 
Ideally a single 'emit_insn' should suffice, IMHO.

>   && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
>   && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG
>   && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG"

Out of curiousity, why are these checks needed?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #297 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #296)
> This sounds almost logical and easy to understand.
> 
> > Adding explicit emit_clobber R4-R6 looks better than this to me, though.
> 
> Having to use the "emit_clobber" when instantiating that pattern might be
> easy to forget.  It's easier to deal with it when it's all contained in one
> place.  Ideally a single 'emit_insn' should suffice, IMHO.

Indeed.

> >   && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
> >   && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG
> >   && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG"
> 
> Out of curiousity, why are these checks needed?

Otherwise, operands[2-4] can be replaced by another register. I've seen that in
some cases.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #298 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Here is one ICE I have run into while building webkit2gtk with the latest
patches on top of an older GCC snapshot:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g1 -O2 -ffile-prefix-map=/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o -MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o.d -o
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o -c
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp 
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:
In constructor 'SkCubicMap::SkCubicMap(SkPoint, SkPoint)':
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
error: unable to find a register to spill
  106 | }
      | ^
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
error: this is the insn:
(insn 34 307 35 8 (parallel [
            (set (reg:SF 170 [ prephitmp_18 ])
                (reg:SF 335))
            (use (reg:SI 154 fpscr0))
        ]) "/usr/lib/gcc-snapshot/include/c++/15/bits/stl_algobase.h":262:15
222 {movsf_ie_ra}
     (expr_list:REG_DEAD (reg:SF 335)
        (nil)))
during RTL pass: reload
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868
0x2b7c113f __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x2b7c1223 __libc_start_main_impl
        ./csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.

I am going to retest this with Kaz's tree which I am currently building.

While provide the preprocessed source in a follow-up comment.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #299 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 59169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59169&action=edit
Preprocessed source from from comment #298

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #300 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #297)
> 
> > >   && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
> > >   && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG
> > >   && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG"
> > 
> > Out of curiousity, why are these checks needed?
> 
> Otherwise, operands[2-4] can be replaced by another register. I've seen that
> in some cases.

So the checks fail the pattern match unless all hard regs are in place and so
if something tries to change the reg operands in the insn it will fail and will
stay put?  Is that what's happening there?

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #301 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #292)
> (In reply to Kazumoto Kojima from comment #289)
> > I've reconstructed patches as follows:
> > 
> > [59157] a revised patch to movsf issue which splits movesf_ie_ra
> > [59158] a revised patch to QIHI extend/move
> > [59159] a revised workaround sfunc issue
> > [59153] Alex's patch works magically for call_pcrel* issue.
> > 
> > I've also created sh-lra-take2 branch of https://github.com/kazkojima/gcc.git
> > with these patches for the reference.
> 
> OK, I'm trying this branch now. I assume I won't need any other patches.

I can confirm that I can successfully perform a full native bootstrap with the
following languages enabled:

- c,c++,fortran,objc,obj-c++,m2

There were no segfaults or comparison failures either.

I can also confirm that this branch fixes the problems reported in comment
#271, comment #273 and comment #298.

Last will be verifying that Go and Ada still work.

This is a huge step forward so far. Congratulations!

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #302 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #300)
> (In reply to Kazumoto Kojima from comment #297)
> > 
> > > >   && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
> > > >   && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG
> > > >   && REG_P (operands[4]) && REGNO (operands[4]) == R6_REG"
> > > 
> > > Out of curiousity, why are these checks needed?
> > 
> > Otherwise, operands[2-4] can be replaced by another register. I've seen that
> > in some cases.
> 
> So the checks fail the pattern match unless all hard regs are in place and
> so if something tries to change the reg operands in the insn it will fail
> and will stay put?  Is that what's happening there?

Yes, that's what I suppose.  If the operands of that pattern match with another
registers, the instruction with the operands[2-4] other than r4-r6 would be
recognizable.
I'm not sure if my memory is correct, but such rewriting was attempted and
succeeded at the RA or post reload stage.
Another way would be to define a predicate sfunc_arg[012]_reg which matches
r[456] only and use it in match_operand to avoid unexpected matching.

(define_insn "block_lump_real_i4"
  [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
           (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r")))
   (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
   (use (match_operand 1 "" "Z,Ccl"))
   (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r"))
...
   (clobber (reg:SI R3_REG))]
   "TARGET_HARD_SH4"
...

It also worked for me.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #303 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59174&action=edit
a patch replacing 59159 for sfunc issue

No explicit clobber + sfunc_arg[012]_reg predicate version. Tested with
libgcc/libstdc++v3 build and c testsuite only.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #304 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #302)
> 
> Yes, that's what I suppose.  If the operands of that pattern match with
> another registers, the instruction with the operands[2-4] other than r4-r6
> would be recognizable.
> I'm not sure if my memory is correct, but such rewriting was attempted and
> succeeded at the RA or post reload stage.
> Another way would be to define a predicate sfunc_arg[012]_reg which matches
> r[456] only and use it in match_operand to avoid unexpected matching.
> 
> (define_insn "block_lump_real_i4"
>   [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
> 	   (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r")))
>    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
>    (use (match_operand 1 "" "Z,Ccl"))
>    (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r"))
> ...
>    (clobber (reg:SI R3_REG))]
>    "TARGET_HARD_SH4"
> ...
> 
> It also worked for me.

I think this is a bit clearer, thanks!  One more question .... 

(define_insn "block_lump_real"
  [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
           (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r")))
   (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
   (use (match_operand 1 "" "Z,Ccl"))
   (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r"))

   (use (reg:SI R4_REG))        <<<<<<
   (use (reg:SI R5_REG))        <<<<<<
   (use (reg:SI R6_REG))        <<<<<<

   (clobber (match_dup 2))
   (clobber (match_dup 3))
   (clobber (match_dup 4))
   (clobber (reg:SI PR_REG))

Is it possible to do '(use (match_dup 2)' and so on instead of having the hard
regs in there?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #305 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #304)
> I think this is a bit clearer, thanks!  One more question .... 
> 
> (define_insn "block_lump_real"
>   [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
>   	   (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r")))
>    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
>    (use (match_operand 1 "" "Z,Ccl"))
>    (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r"))
> 
>    (use (reg:SI R4_REG))        <<<<<<
>    (use (reg:SI R5_REG))        <<<<<<
>    (use (reg:SI R6_REG))        <<<<<<
> 
>    (clobber (match_dup 2))
>    (clobber (match_dup 3))
>    (clobber (match_dup 4))
>    (clobber (reg:SI PR_REG))
> 
> Is it possible to do '(use (match_dup 2)' and so on instead of having the
> hard regs in there?

It isn't.  When replacing hard reg with match_dup, it compiles our tiny sfunc
test to:

foo:
        mov.l   r14,@-r15       ! 32    [c=4 l=2]  movsi_ie/8
        mov     r4,r5   ! 23    [c=4 l=2]  movsi_ie/1
        sts.l   pr,@-r15        ! 33    [c=4 l=2]  movsi_ie/10
        mov.w   .L6,r1  ! 34    [c=10 l=2]  *movhi/0
        mov     #0,r7   ! 16    [c=4 l=2]  movsi_ie/2
        mov.l   .L4,r6  ! 29    [c=10 l=2]  movsi_ie/0
        sub     r1,r15  ! 35    [c=4 l=2]  *subsi3_internal
        mov     r15,r14 ! 30    [c=4 l=2]  movsi_ie/1
        add     #4,r14  ! 31    [c=4 l=2]  *addsi3_compact_lra/0
        jsr     @r6     ! 12    [c=1 l=2]  block_lump_real_i4/0
        mov     r14,r4  ! 9     [c=4 l=2]  movsi_ie/1
        ...
.L6:
        .short  260

which wrongly assigns r6 to the function address, for example.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #306 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #301)
> I can confirm that I can successfully perform a full native bootstrap with
> the following languages enabled:
> 
> - c,c++,fortran,objc,obj-c++,m2
> 
> There were no segfaults or comparison failures either.
> 
> I can also confirm that this branch fixes the problems reported in comment
> #271, comment #273 and comment #298.
> 
> Last will be verifying that Go and Ada still work.
> 
> This is a huge step forward so far. Congratulations!

Ada and Go work fine, too. Let me test lto and jit.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #307 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #306)
> (In reply to John Paul Adrian Glaubitz from comment #301)
> > I can confirm that I can successfully perform a full native bootstrap with
> > the following languages enabled:
> > 
> > - c,c++,fortran,objc,obj-c++,m2
> > 
> > There were no segfaults or comparison failures either.
> > 
> > I can also confirm that this branch fixes the problems reported in comment
> > #271, comment #273 and comment #298.
> > 
> > Last will be verifying that Go and Ada still work.
> > 
> > This is a huge step forward so far. Congratulations!
> 
> Ada and Go work fine, too. Let me test lto and jit.

LTO and JIT build without issues, too.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #308 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #305)
> (In reply to Oleg Endo from comment #304)
> > I think this is a bit clearer, thanks!  One more question .... 
> > 
> > (define_insn "block_lump_real"
> >   [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
> >   	   (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r")))
> >    (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> >    (use (match_operand 1 "" "Z,Ccl"))
> >    (use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r"))
> > 
> >    (use (reg:SI R4_REG))        <<<<<<
> >    (use (reg:SI R5_REG))        <<<<<<
> >    (use (reg:SI R6_REG))        <<<<<<
> > 
> >    (clobber (match_dup 2))
> >    (clobber (match_dup 3))
> >    (clobber (match_dup 4))
> >    (clobber (reg:SI PR_REG))
> > 
> > Is it possible to do '(use (match_dup 2)' and so on instead of having the
> > hard regs in there?
> 
> It isn't.  When replacing hard reg with match_dup, it compiles our tiny
> sfunc test to:
> 
> foo:
> 	mov.l	r14,@-r15	! 32	[c=4 l=2]  movsi_ie/8
> 	mov	r4,r5	! 23	[c=4 l=2]  movsi_ie/1
> 	sts.l	pr,@-r15	! 33	[c=4 l=2]  movsi_ie/10
> 	mov.w	.L6,r1	! 34	[c=10 l=2]  *movhi/0
> 	mov	#0,r7	! 16	[c=4 l=2]  movsi_ie/2
> 	mov.l	.L4,r6	! 29	[c=10 l=2]  movsi_ie/0
> 	sub	r1,r15	! 35	[c=4 l=2]  *subsi3_internal
> 	mov	r15,r14	! 30	[c=4 l=2]  movsi_ie/1
> 	add	#4,r14	! 31	[c=4 l=2]  *addsi3_compact_lra/0
> 	jsr	@r6	! 12	[c=1 l=2]  block_lump_real_i4/0
> 	mov	r14,r4	! 9	[c=4 l=2]  movsi_ie/1
> 	...
> .L6:
> 	.short	260
> 
> which wrongly assigns r6 to the function address, for example.

Thanks for confirming it.  In this case, wouldn't it be better to explicitly
mention the hard reg numbers everywhere, where they are involved?  Otherwise
the definitions are bara-bara all over the place.  For example:

(define_insn "block_lump_real"
  [(set (mem:BLK (match_operand:SI 2 "hard_reg_r4" "=r,r"))
           (mem:BLK (match_operand:SI 3 "hard_reg_r5" "=r,r")))
   (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
   (use (match_operand 1 "" "Z,Ccl"))
   (use (match_operand:SI 4 "hard_reg_r6" "=r,r"))
   (use (reg:SI R4_REG))
   (use (reg:SI R5_REG))
   (use (reg:SI R6_REG))
   (clobber (match_dup 2))
   (clobber (match_dup 3))
   (clobber (match_dup 4))
   (clobber (reg:SI PR_REG))


But actually, why are the register constraints "=r,r"?  The insn only takes
inputs, but those are declared as outputs.  That looks wrong to me.  Perhaps
that's why the need for the seemingly superflous (use (reg:SI ... )?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #309 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #308)
> Thanks for confirming it.  In this case, wouldn't it be better to explicitly
> mention the hard reg numbers everywhere, where they are involved?  Otherwise
> the definitions are bara-bara all over the place.  For example:
> 
> (define_insn "block_lump_real"
>   [(set (mem:BLK (match_operand:SI 2 "hard_reg_r4" "=r,r"))

Sure. hard_reg_r[456] sounds better.

> But actually, why are the register constraints "=r,r"?  The insn only takes
> inputs, but those are declared as outputs.  That looks wrong to me.  Perhaps
> that's why the need for the seemingly superflous (use (reg:SI ... )?

If "=" is removed, it doesn't work, unfortunately. It compiles our tiny case to

foo:
        mov.l   r14,@-r15       ! 32    [c=4 l=2]  movsi_ie/8
        mov     r4,r5   ! 23    [c=4 l=2]  movsi_ie/1
        sts.l   pr,@-r15        ! 33    [c=4 l=2]  movsi_ie/10
        mov.w   .L6,r1  ! 34    [c=10 l=2]  *movhi/0
        mov     #31,r6  ! 11    [c=4 l=2]  movsi_ie/2
        mov.l   .L4,r14 ! 29    [c=10 l=2]  movsi_ie/0
        mov     #0,r7   ! 16    [c=4 l=2]  movsi_ie/2
        sub     r1,r15  ! 35    [c=4 l=2]  *subsi3_internal
        mov     r15,r4  ! 30    [c=4 l=2]  movsi_ie/1
        jsr     @r14    ! 12    [c=1 l=2]  block_lump_real_i4/0
        add     #4,r4   ! 31    [c=4 l=2]  *addsi3_compact_lra/0
        mov.l   .L5,r1  ! 27    [c=10 l=2]  movsi_ie/0
        mov     #0,r6   ! 17    [c=4 l=2]  movsi_ie/2
        mov.l   r4,@r15 ! 14    [c=4 l=2]  movsi_ie/8

which uses r4 as if it isn't clobbered.
As mentioned in c#276, I assume that LRA doesn't handle the clobber reg pattern
if that reg is recognized as the input reg, unless it's call_insn.  It would
have been nice if the pattern in c#276 had worked.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #310 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Hmm, I just realized I performed the tests without enabling LRA by default. I
just noticed that because with LRA enabled, Ada actually fails with:

/<<PKGBUILDDIR>>/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-teioed.adb -o a-teioed.o
/<<PKGBUILDDIR>>/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-textio.adb -o a-textio.o
/<<PKGBUILDDIR>>/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-tgdico.ads -o a-tgdico.o
/<<PKGBUILDDIR>>/build/./gcc/xgcc -B/<<PKGBUILDDIR>>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-tiboio.adb -o a-tiboio.o
a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
            (set (reg:SF 499 [orig:184 _24 ] [184])
                (reg:SF 513))
            (use (reg:SI 154 fpscr0))
        ]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
     (expr_list:REG_DEAD (reg:SF 513)
        (nil)))
during RTL pass: reload
+===========================GNAT BUG DETECTED==============================+
| 15.0.0 20240922 (experimental) (sh4-linux-gnu) GCC error:                |
| in lra_split_hard_reg_for, at lra-assigns.cc:1868                        |
| Error detected around a-ngcefu.adb:177:8                                 |
| Compiling a-ncelfu.ads                                                   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
a-ncelfu.ads
a-numeri.ads
ada.ads
a-nucoty.ads
a-ngcoty.ads
a-ngcefu.ads
s-exctab.ads
s-stalib.ads
a-unccon.ads
a-ngcefu.adb
a-ngelfu.ads
a-except.ads
s-parame.ads
s-traent.ads
s-fatflt.ads
s-fatgen.ads
a-ngelfu.adb
a-nagefl.ads
a-nallfl.ads
a-naliop.ads
a-nalofl.ads
a-nuaufl.ads
a-nashfl.ads
s-exnflt.ads
s-exponr.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:412
make[9]: *** [../gcc-interface/Makefile:303: a-ncelfu.o] Error 1
make[9]: *** Waiting for unfinished jobs....
a-ngcefu.adb: In function
'Ada.Numerics.Short_Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
            (set (reg:SF 499 [orig:184 _24 ] [184])
                (reg:SF 513))
            (use (reg:SI 154 fpscr0))
        ]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
     (expr_list:REG_DEAD (reg:SF 513)
        (nil)))
during RTL pass: reload
+===========================GNAT BUG DETECTED==============================+
| 15.0.0 20240922 (experimental) (sh4-linux-gnu) GCC error:                |
| in lra_split_hard_reg_for, at lra-assigns.cc:1868                        |
| Error detected around a-ngcefu.adb:177:8                                 |
| Compiling a-nscefu.ads                                                   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

Will need to do more testing. Sorry for the noise.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #311 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59185&action=edit
a reduced test case for c#298

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #312 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #298)
> Here is one ICE I have run into while building webkit2gtk with the latest
> patches on top of an older GCC snapshot:

Although not tested well,

diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index a2b2130d166..d9e7e67cba6 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -11465,11 +11462,15 @@ sh_movsf_ie_y_split_p (rtx op0, rtx op1)
 {
   /* f, r */
   if (REG_P (op0)
-      && (SUBREG_P (op1) && GET_MODE (SUBREG_REG (op1)) == SImode))
+      && (SUBREG_P (op1)
+         && (GET_MODE (SUBREG_REG (op1)) == SImode
+             || GET_MODE (SUBREG_REG (op1)) == DImode)))
     return true;
   /* r, f */
   if (REG_P (op1)
-      && (SUBREG_P (op0) && GET_MODE (SUBREG_REG (op0)) == SImode))
+      && (SUBREG_P (op0)
+         && (GET_MODE (SUBREG_REG (op0)) == SImode
+             || GET_MODE (SUBREG_REG (op0)) == DImode)))
     return true;

   return false;

fixes the ICE for the original and reduced test case 59185 here.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #313 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #312)
> (In reply to John Paul Adrian Glaubitz from comment #298)
> > Here is one ICE I have run into while building webkit2gtk with the latest
> > patches on top of an older GCC snapshot:
> 
> Although not tested well,
> 
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index a2b2130d166..d9e7e67cba6 100644
> --- a/gcc/config/sh/sh.cc
> +++ b/gcc/config/sh/sh.cc
> @@ -11465,11 +11462,15 @@ sh_movsf_ie_y_split_p (rtx op0, rtx op1)
>  {
>    /* f, r */
>    if (REG_P (op0)
> -      && (SUBREG_P (op1) && GET_MODE (SUBREG_REG (op1)) == SImode))
> +      && (SUBREG_P (op1)
> +	  && (GET_MODE (SUBREG_REG (op1)) == SImode
> +	      || GET_MODE (SUBREG_REG (op1)) == DImode)))
>      return true;
>    /* r, f */
>    if (REG_P (op1)
> -      && (SUBREG_P (op0) && GET_MODE (SUBREG_REG (op0)) == SImode))
> +      && (SUBREG_P (op0)
> +	  && (GET_MODE (SUBREG_REG (op0)) == SImode
> +	      || GET_MODE (SUBREG_REG (op0)) == DImode)))
>      return true;
>  
>    return false;
> 
> fixes the ICE for the original and reduced test case 59185 here.

Thanks, trying this now. FWIW, all the other languages are not affected by this
ICE.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #314 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #312)
> (In reply to John Paul Adrian Glaubitz from comment #298)
> > Here is one ICE I have run into while building webkit2gtk with the latest
> > patches on top of an older GCC snapshot:
> 
> Although not tested well,
> 
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index a2b2130d166..d9e7e67cba6 100644
> --- a/gcc/config/sh/sh.cc
> +++ b/gcc/config/sh/sh.cc
> @@ -11465,11 +11462,15 @@ sh_movsf_ie_y_split_p (rtx op0, rtx op1)
>  {
>    /* f, r */
>    if (REG_P (op0)
> -      && (SUBREG_P (op1) && GET_MODE (SUBREG_REG (op1)) == SImode))
> +      && (SUBREG_P (op1)
> +	  && (GET_MODE (SUBREG_REG (op1)) == SImode
> +	      || GET_MODE (SUBREG_REG (op1)) == DImode)))
>      return true;
>    /* r, f */
>    if (REG_P (op1)
> -      && (SUBREG_P (op0) && GET_MODE (SUBREG_REG (op0)) == SImode))
> +      && (SUBREG_P (op0)
> +	  && (GET_MODE (SUBREG_REG (op0)) == SImode
> +	      || GET_MODE (SUBREG_REG (op0)) == DImode)))
>      return true;
>  
>    return false;
> 
> fixes the ICE for the original and reduced test case 59185 here.

Can you please add the patch to your github branch?
I would like to ask some Dreamcast folks to try and test the GCC LRA branch
with some bigger real-world software.  For that we need to have a "known good
state" of a branch on github.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #315 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexandre Oliva from comment #277)
> Created attachment 59153 [details]
> [lra] take scratch as implicit unused output reloads
> 
> > * call_pcrel patterns: match_scratch can cause ICE for the corner case.  We use a fixed register instead of scratch as a quick fix.  More investigation is needed.
> 
> This sounds familiar.  I may have an LRA patch to address this problem, but
> it's got very little testing.

Alex, thanks for the patch.  It seems to be doing OK here.  What else is needed
to upstream it?

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #316 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #314)
> Can you please add the patch to your github branch?
> I would like to ask some Dreamcast folks to try and test the GCC LRA branch
> with some bigger real-world software.  For that we need to have a "known
> good state" of a branch on github.

I've pushed the sfunc patch with lengthy sfunc patterns using hard_reg_r[456] +
the patch in c#312 on the top of

[59157] a revised patch to movsf issue which splits movesf_ie_ra
[59158] a revised patch to QIHI extend/move
[59153] Alex's patch works magically for call_pcrel* issue.

as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git.  Hope this
helps.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #317 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #316)
> (In reply to Oleg Endo from comment #314)
> > Can you please add the patch to your github branch?
> > I would like to ask some Dreamcast folks to try and test the GCC LRA branch
> > with some bigger real-world software.  For that we need to have a "known
> > good state" of a branch on github.
> 
> I've pushed the sfunc patch with lengthy sfunc patterns using
> hard_reg_r[456] + the patch in c#312 on the top of
> 
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI extend/move
> [59153] Alex's patch works magically for call_pcrel* issue.
> 
> as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git.  Hope this
> helps.

Thanks. I'm going to test this now. It seems that the untested patch from
comment #312 didn't fix the Ada bootstrap for me.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #318 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #317)
> Thanks. I'm going to test this now. It seems that the untested patch from
> comment #312 didn't fix the Ada bootstrap for me.

The issue unfortunately persists:

a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
            (set (reg:SF 499 [orig:184 _24 ] [184])
                (reg:SF 513))
            (use (reg:SI 154 fpscr0))
        ]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
     (expr_list:REG_DEAD (reg:SF 513)
        (nil)))
during RTL pass: reload

I'll try to get the preprocessed source.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #319 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Created attachment 59188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59188&action=edit
Preprocessed source from from comment #318

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #320 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Full command line is:

/home/glaubitz/gcc-kaz/build/./gcc/xgcc -B/home/glaubitz/gcc-kaz/build/./gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/
-isystem /usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include    -c -g -O2  -fpic -fno-lto  -W
-Wall -gnatpg -nostdinc   a-nscefu.ads -o a-nscefu.o

which is run from the build/gcc/ada/rts subfolder. The problem goes away with
-O0 or -mno-lra.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #321 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #320)
> Full command line is:
> 
> /home/glaubitz/gcc-kaz/build/./gcc/xgcc
> -B/home/glaubitz/gcc-kaz/build/./gcc/
> -B/usr/local/sh4-unknown-linux-gnu/bin/
> -B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
> /usr/local/sh4-unknown-linux-gnu/include -isystem
> /usr/local/sh4-unknown-linux-gnu/sys-include    -c -g -O2  -fpic -fno-lto 
> -W -Wall -gnatpg -nostdinc   a-nscefu.ads -o a-nscefu.o
> 
> which is run from the build/gcc/ada/rts subfolder. The problem goes away
> with -O0 or -mno-lra.

Adding -fno-split-wide-types to the command line fixes the problem.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #322 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #316)
> (In reply to Oleg Endo from comment #314)
> > Can you please add the patch to your github branch?
> > I would like to ask some Dreamcast folks to try and test the GCC LRA branch
> > with some bigger real-world software.  For that we need to have a "known
> > good state" of a branch on github.
> 
> I've pushed the sfunc patch with lengthy sfunc patterns using
> hard_reg_r[456] + the patch in c#312 on the top of
> 
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI extend/move
> [59153] Alex's patch works magically for call_pcrel* issue.
> 
> as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git.  Hope this
> helps.

Thanks!

I've also created a branch with your patches here:
https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/sh-lra

I've retouched the commits a little bit here and there, mainly in the comments
and commit messages.

If you have more patches or make a new branch, I will gradually merge them over
and try to keep the devel/sh-lra branch in a useful state.

With the current state, some open issues like PR 112115 are resolved.  But
others like PR 115949 or PR 113193 still remain.  Although those cases have
been also problematic before LRA as well.

I might be wrong, but I've got this feeling that whenever LRA hits the "reload
limit" it's an indicator that something is running in circles in the move-insn
pattern definitions.

I've noticed one thing.  The patch 'SH: pin input args to hard-regs via
predicates for sfuncs' skips the change for the patterns 'udivsi3_i4_int' and
'block_move_real_i4'.  Is this intentional or by accident?

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #323 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I've tried getting some code size numbers from CSiBE comparision for
'sh-elf-gcc -m4-single -O2' with the devel/sh-lra branch.

The numbers are code size in bytes with -mno-lra and -mlra

OpenTCP-1.0.4                  total:     29498 -> 29470      -28 / -0.094922 %
bzip2-1.0.2                    total:     65894 -> 67010      +1116 / +1.693629
%
cg_compiler_opensrc            total:    129771 -> 130147     +376 / +0.289741
%
compiler                       total:     27603 -> 27767      +164 / +0.594138
%
flex-2.5.31                    total:    244507 -> 243955     -552 / -0.225760
%
jikespg-1.3                    total:    214135 -> 213427     -708 / -0.330633
%
jpeg-6b                        total:    125100 -> 125784     +684 / +0.546763
%
libmspack                      total:     63369 -> 63525      +156 / +0.246177
%
libpng-1.2.5                   total:    108836 -> 108840     +4 / +0.003675 %
linux-2.4.23-pre3-testplatform total:    956603 -> 956920     +317 / +0.033138
%
lwip-0.5.3.preproc             total:     83129 -> 83333      +204 / +0.245402
%
mpeg2dec-0.3.1                 total:     51046 -> 50954      -92 / -0.180230 %
mpgcut-1.1                     total:     19576 -> 19740      +164 / +0.837761
%
replaypc-0.4.0.preproc         total:     57206 -> 57518      +312 / +0.545397
%
teem-1.6.0-src                 total:   1120729 -> 1123341    +2612 / +0.233063
%
ttt-0.10.1.preproc             total:     15344 -> 15356      +12 / +0.078206 %
unrarlib-0.4.0                 total:     14152 -> 14192      +40 / +0.282646 %
zlib-1.1.4                     total:     34326 -> 34162      -164 / -0.477772
%

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #324 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #322)
> I've also created a branch with your patches here:
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/sh-lra
> 
> I've retouched the commits a little bit here and there, mainly in the
> comments and commit messages.
> 
> If you have more patches or make a new branch, I will gradually merge them
> over and try to keep the devel/sh-lra branch in a useful state.
> 
> With the current state, some open issues like PR 112115 are resolved.  But
> others like PR 115949 or PR 113193 still remain.  Although those cases have
> been also problematic before LRA as well.

Thanks!

> I might be wrong, but I've got this feeling that whenever LRA hits the
> "reload limit" it's an indicator that something is running in circles in the
> move-insn pattern definitions.

You are right.  I have not seen any other cases yet.

> I've noticed one thing.  The patch 'SH: pin input args to hard-regs via
> predicates for sfuncs' skips the change for the patterns 'udivsi3_i4_int'
> and 'block_move_real_i4'.  Is this intentional or by accident?

It's intentional.  Those sfunc's don't clobber r4, r5 and r6.  sdivsi3_* and
other are in the similar situation.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #325 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #319)
> Created attachment 59188 [details]
> Preprocessed source from from comment #318

Thanks for the test case and other comments.  I can reproduce the ICE with
cross gnat1.  From the rtl dumps, it seems

* A complex valued function returns SCmode value in fr0 and fr1 pair.
* The real/imaginary part of this value is moved to the SFmode reg.

(insn 105 104 106 16 (parallel [
            (set (reg:SF 184 [ _24 ])
                (subreg:SF (reg:SC 241) 0))
            (use (reg:SI 154 fpscr0))
        ]) "a-ngcefu.adb":164:17 -1
     (nil))

* subreg1 pass splits this multiword subreg to single word subreg but with
SImode reg.

(insn 103 101 104 10 (parallel [
            (set (subreg:SF (reg:SI 344) 0)
                (reg:SF 64 fr0))
            (use (reg:SI 154 fpscr0))
        ]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
     (expr_list:REG_DEAD (reg:SF 64 fr0)
        (nil)))
...
(insn 105 104 106 10 (parallel [
            (set (reg:SF 184 [ _24 ])
                (subreg:SF (reg:SI 344) 0))
            (use (reg:SI 154 fpscr0))
        ]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
     (expr_list:REG_DEAD (reg:SI 344)
        (nil)))

Our movsf logic for LRA doesn't handle these well.  If these reg from/to subreg
of SImode move is splitted with fpul, it will cause some very bad code or ICE.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #326 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 59190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59190&action=edit
a quick fix for c#318

This also reverts the change in c#312 and gives another fix for that issue.
Tested only with target libgcc/libstdc++v3 build and c testsuite.
I've updated sh-lra-take3 branch with this change.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #327 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Kazumoto Kojima from comment #326)
> Created attachment 59190 [details]
> a quick fix for c#318
> 
> This also reverts the change in c#312 and gives another fix for that issue.
> Tested only with target libgcc/libstdc++v3 build and c testsuite.
> I've updated sh-lra-take3 branch with this change.

Thanks, testing this now.