[Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

            Bug ID: 112330
           Summary: [14 Regression] LoongArch: LTO bootstrap failure with
                    GAS 2.41
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

r14-5053 fails to LTO bootstrap with GAS 2.41 and the following configuration:

../gcc/configure --prefix=/home/xry111/gcc-dev --with-system-zlib
--disable-fixincludes --enable-default-ssp --enable-default-pie
--disable-werror --disable-multilib --with-build-config=bootstrap-lto && make
-j32

The error message is:

/usr/bin/as: /usr/bin/as: BFD (Gentoo 2.41 p2) 2.41.0 internal error, aborting
at /tmp/portage/sys-devel/binutils-2.41-r2/work/binutils-2.41/bfd/bfd.c:1185 in
_bfd_doprnt

/usr/bin/as: Please report this bug.

The problem is since r14-4674 we are relying on Binutils commit
1fb3cdd87ec61715a5684925fb6d6a6cf53bb97c, which is not available in GAS 2.41.

I guess the easiest solution is raising the minimal GAS requirement of
bootstrapping GCC 14 on LoongArch to 2.42.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #0)

> I guess the easiest solution is raising the minimal GAS requirement of
> bootstrapping GCC 14 on LoongArch to 2.42.

Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
sure if it's enough.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Created attachment 56483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56483&action=edit
The generated assembly triggering the GAS internal error

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn]

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

--- Comment #3 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #1)
> (In reply to Xi Ruoyao from comment #0)
> 
> > I guess the easiest solution is raising the minimal GAS requirement of
> > bootstrapping GCC 14 on LoongArch to 2.42.
> 
> Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
> sure if it's enough.

This issue really doesn't happen after adding -mno-relax, but is it really
necessary to judge the version of binutils because of this?

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #3)
> (In reply to Xi Ruoyao from comment #1)
> > (In reply to Xi Ruoyao from comment #0)
> > 
> > > I guess the easiest solution is raising the minimal GAS requirement of
> > > bootstrapping GCC 14 on LoongArch to 2.42.
> > 
> > Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
> > sure if it's enough.
> 
> This issue really doesn't happen after adding -mno-relax, but is it really
> necessary to judge the version of binutils because of this?

I'm not sure if -mno-relax is the proper fix.  For now I've reduced the test
case to:

a:
.rept 100000
nop
.endr
beq $r12, $r13, a

but this still does not work with GAS 2.41 even if -mno-relax.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn]

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

--- Comment #5 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to chenglulu from comment #3)
> > (In reply to Xi Ruoyao from comment #1)
> > > (In reply to Xi Ruoyao from comment #0)
> > > 
> > > > I guess the easiest solution is raising the minimal GAS requirement of
> > > > bootstrapping GCC 14 on LoongArch to 2.42.
> > > 
> > > Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
> > > sure if it's enough.
> > 
> > This issue really doesn't happen after adding -mno-relax, but is it really
> > necessary to judge the version of binutils because of this?
> 
> I'm not sure if -mno-relax is the proper fix.  For now I've reduced the test
> case to:
> 
> a:
> .rept 100000
> nop
> .endr
> beq $r12, $r13, a
> 
> but this still does not work with GAS 2.41 even if -mno-relax.

If this is the assembly code compiled by gcc, then I think it's a gcc bug,
although AS shouldn't be an internal error.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

--- Comment #6 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #5)
> (In reply to Xi Ruoyao from comment #4)
> > (In reply to chenglulu from comment #3)
> > > (In reply to Xi Ruoyao from comment #1)
> > > > (In reply to Xi Ruoyao from comment #0)
> > > > 
> > > > > I guess the easiest solution is raising the minimal GAS requirement of
> > > > > bootstrapping GCC 14 on LoongArch to 2.42.
> > > > 
> > > > Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
> > > > sure if it's enough.
> > > 
> > > This issue really doesn't happen after adding -mno-relax, but is it really
> > > necessary to judge the version of binutils because of this?
> > 
> > I'm not sure if -mno-relax is the proper fix.  For now I've reduced the test
> > case to:
> > 
> > a:
> > .rept 100000
> > nop
> > .endr
> > beq $r12, $r13, a
> > 
> > but this still does not work with GAS 2.41 even if -mno-relax.
> 
> If this is the assembly code compiled by gcc, then I think it's a gcc bug,
> although AS shouldn't be an internal error.

The internal error issue is fixed by Binutils commit
f87cf663af71e5d78c8d647fa48562102f3b0615.

I think I've over-simplified the test case.  GCC does not generate something
like this.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn]

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

--- Comment #7 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to chenglulu from comment #5)
> > (In reply to Xi Ruoyao from comment #4)
> > > (In reply to chenglulu from comment #3)
> > > > (In reply to Xi Ruoyao from comment #1)
> > > > > (In reply to Xi Ruoyao from comment #0)
> > > > > 
> > > > > > I guess the easiest solution is raising the minimal GAS requirement of
> > > > > > bootstrapping GCC 14 on LoongArch to 2.42.
> > > > > 
> > > > > Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
> > > > > sure if it's enough.
> > > > 
> > > > This issue really doesn't happen after adding -mno-relax, but is it really
> > > > necessary to judge the version of binutils because of this?
> > > 
> > > I'm not sure if -mno-relax is the proper fix.  For now I've reduced the test
> > > case to:
> > > 
> > > a:
> > > .rept 100000
> > > nop
> > > .endr
> > > beq $r12, $r13, a
> > > 
> > > but this still does not work with GAS 2.41 even if -mno-relax.
> > 
> > If this is the assembly code compiled by gcc, then I think it's a gcc bug,
> > although AS shouldn't be an internal error.
> 
> The internal error issue is fixed by Binutils commit
> f87cf663af71e5d78c8d647fa48562102f3b0615.
> 
> I think I've over-simplified the test case.  GCC does not generate something
> like this.

Uh, I also thought about this gcc and binutils matching issue when I submitted
r14-4674, but I didn't think about whether this should be solved? How to fix
it？

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #7)

> Uh, I also thought about this gcc and binutils matching issue when I
> submitted r14-4674, but I didn't think about whether this should be solved?
> How to fix it？

I'm not sure either.

The easiest way is just claiming we need Binutils 2.42 for GCC 14 (documenting
this in "Host/target specific installation notes for GCC", install.texi).

If we want to maintain the compatibility with 2.41, I think the best solution
would be probing the capability of GAS and disable relaxation by default if
necessary.

There is already another issue breaking relaxation with Binutils 2.41 anyway:
https://sourceware.org/bugzilla/show_bug.cgi?id=30944. Mengqinggang has posted
a fix at https://sourceware.org/pipermail/binutils/2023-October/129941.html but
it's still under testing. Hopefully the fix will be committed before Binutils
2.42 freeze.

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 Regression] LoongArch:  |[14 Regression] LoongArch:
                   |LTO bootstrap failure with  |Bootstrap failure with GAS
                   |GAS 2.41                    |2.41

--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Xuerui informed me that non-LTO bootstrapping is broken too.

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn]

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

--- Comment #10 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #9)
> Xuerui informed me that non-LTO bootstrapping is broken too.

Well, this has nothing to do with whether to open lto or not, it is caused by
binutils inserting "nop" when relaxing optimization.

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

--- Comment #11 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41 and
get some better error message:

t.s:98064: Error: Reloc overflow
t.s:101127: Error: Reloc overflow
t.s:101453: Error: Reloc overflow
t.s:101555: Error: Reloc overflow

t.s is the assembly file in attachments.

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn]

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

--- Comment #12 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #11)
> I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
> and get some better error message:
> 
> t.s:98064: Error: Reloc overflow
> t.s:101127: Error: Reloc overflow
> t.s:101453: Error: Reloc overflow
> t.s:101555: Error: Reloc overflow
> 
> t.s is the assembly file in attachments.

1fb3cdd87ec61715a5684925fb6d6a6cf53bb97c is also required．

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

[xry111 at gcc dot gnu.org]

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

--- Comment #13 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #12)
> (In reply to Xi Ruoyao from comment #11)
> > I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
> > and get some better error message:
> > 
> > t.s:98064: Error: Reloc overflow
> > t.s:101127: Error: Reloc overflow
> > t.s:101453: Error: Reloc overflow
> > t.s:101555: Error: Reloc overflow
> > 
> > t.s is the assembly file in attachments.
> 
> 1fb3cdd87ec61715a5684925fb6d6a6cf53bb97c is also required．

I know, I'm just trying to understand the issue better.

I don't really understand why this was not a problem before r14-4674.  And this
issue also did not show up immediately after r14-4674 (it even did not show up
when I was developing r14-4851).

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn]

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

--- Comment #14 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #13)
> (In reply to chenglulu from comment #12)
> > (In reply to Xi Ruoyao from comment #11)
> > > I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
> > > and get some better error message:
> > > 
> > > t.s:98064: Error: Reloc overflow
> > > t.s:101127: Error: Reloc overflow
> > > t.s:101453: Error: Reloc overflow
> > > t.s:101555: Error: Reloc overflow
> > > 
> > > t.s is the assembly file in attachments.
> > 
> > 1fb3cdd87ec61715a5684925fb6d6a6cf53bb97c is also required．
> 
> I know, I'm just trying to understand the issue better.
> 
> I don't really understand why this was not a problem before r14-4674.  And
> this issue also did not show up immediately after r14-4674 (it even did not
> show up when I was developing r14-4851).


We can clearly delete the macro ASM_OUTPUT_ALIGN_WITH_NOP in r14-4674, and
before deleting this macro, the generated assembly file looks like this:

...
   .align 16,54525952,4
.L1:
...
   blt  $r12,$r13,.L１
...

after:

   .align 16
.L1:
...
   blt $r12,$r13,.L1
...

First of all, if you add -mrelax during the assembly process,".align
16,54525952,4" will be based on the situation at the time of assembly, and the
choice is to insert a nop function without insertion.But this ".align 16" will
insert 3 nops unconditionally. When calculating the jump range of the
conditional branch, gcc calculates the space required for .align according to
the actual alignment.
So after r14-4674 there will be an error．

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|build                       |
            Summary|[14 Regression] LoongArch:  |[14 Regression] LoongArch:
                   |Bootstrap failure with GAS  |Outputted .align directive
                   |2.41                        |may trigger assembler error
                   |                            |with GAS 2.41

--- Comment #15 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #14)

> First of all, if you add -mrelax during the assembly process,".align
> 16,54525952,4" will be based on the situation at the time of assembly, and
> the choice is to insert a nop function without insertion.But this ".align
> 16" will insert 3 nops unconditionally. When calculating the jump range of
> the conditional branch, gcc calculates the space required for .align
> according to the actual alignment.
> So after r14-4674 there will be an error．

Well, this indicates that the issue can be only triggered with some "bad luck".
 In fact with latest GCC trunk (r14-5075) this issue does not show up.

But this is an real issue and we need a fix anyway...

[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r14-5434-gfe23a2ff1f5072559552be0e41ab55bf72f5c79f
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Fri Nov 3 21:19:59 2023 +0800

    LoongArch: Disable relaxation if the assembler don't support conditional
branch relaxation [PR112330]

    As the commit message of r14-4674 has indicated, if the assembler does
    not support conditional branch relaxation, a relocation overflow may
    happen on conditional branches when relaxation is enabled because the
    number of NOP instructions inserted by the assembler will be more than
    the number estimated by GCC.

    To work around this issue, disable relaxation by default if the
    assembler is detected incapable to perform conditional branch relaxation
    at GCC build time.  We also need to pass -mno-relax to the assembler to
    really disable relaxation.  But, if the assembler does not support
    -mrelax option at all, we should not pass -mno-relax to the assembler or
    it will immediately error out.  Also handle this with the build time
    assembler capability probing, and add a pair of options
    -m[no-]pass-mrelax-to-as to allow using a different assembler from the
    build-time one.

    With this change, if GCC is built with GAS 2.41, relaxation will be
    disabled by default.  So the default value of -mexplicit-relocs= is also
    changed to 'always' if -mno-relax is specified or implied by the
    build-time default, because using assembler macros for symbol addresses
    produces no benefit when relaxation is disabled.

    gcc/ChangeLog:

            PR target/112330
            * config/loongarch/genopts/loongarch.opt.in: Add
            -m[no]-pass-relax-to-as.  Change the default of -m[no]-relax to
            account conditional branch relaxation support status.
            * config/loongarch/loongarch.opt: Regenerate.
            * configure.ac (gcc_cv_as_loongarch_cond_branch_relax): Check if
            the assembler supports conditional branch relaxation.
            * configure: Regenerate.
            * config.in: Regenerate.  Note that there are some unrelated
            changes introduced by r14-5424 (which does not contain a
            config.in regeneration).
            * config/loongarch/loongarch-opts.h
            (HAVE_AS_COND_BRANCH_RELAXATION): Define to 0 if not defined.
            * config/loongarch/loongarch-driver.h (ASM_MRELAX_DEFAULT):
            Define.
            (ASM_MRELAX_SPEC): Define.
            (ASM_SPEC): Use ASM_MRELAX_SPEC instead of "%{mno-relax}".
            * config/loongarch/loongarch.cc: Take the setting of
            -m[no-]relax into account when determining the default of
            -mexplicit-relocs=.
            * doc/invoke.texi: Document -m[no-]relax and
            -m[no-]pass-mrelax-to-as for LoongArch.  Update the default
            value of -mexplicit-relocs=.

[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

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

--- Comment #17 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Fixed for 14.

[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by LuluCheng
<chenglulu@gcc.gnu.org>:

https://gcc.gnu.org/g:186381812dce832c95cc5c4ace47b0efb0aee41f

commit r12-10171-g186381812dce832c95cc5c4ace47b0efb0aee41f
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Fri Nov 3 21:19:59 2023 +0800

    LoongArch: Disable relaxation if the assembler don't support conditional
branch relaxation [PR112330]

    As the commit message of r14-4674 has indicated, if the assembler does
    not support conditional branch relaxation, a relocation overflow may
    happen on conditional branches when relaxation is enabled because the
    number of NOP instructions inserted by the assembler will be more than
    the number estimated by GCC.

    To work around this issue, disable relaxation by default if the
    assembler is detected incapable to perform conditional branch relaxation
    at GCC build time.  We also need to pass -mno-relax to the assembler to
    really disable relaxation.  But, if the assembler does not support
    -mrelax option at all, we should not pass -mno-relax to the assembler or
    it will immediately error out.  Also handle this with the build time
    assembler capability probing, and add a pair of options
    -m[no-]pass-mrelax-to-as to allow using a different assembler from the
    build-time one.

    With this change, if GCC is built with GAS 2.41, relaxation will be
    disabled by default.  So the default value of -mexplicit-relocs= is also
    changed to 'always' if -mno-relax is specified or implied by the
    build-time default, because using assembler macros for symbol addresses
    produces no benefit when relaxation is disabled.

    gcc/ChangeLog:

            PR target/112330
            * config/loongarch/genopts/loongarch.opt.in: Add
            -m[no]-pass-relax-to-as.  Change the default of -m[no]-relax to
            account conditional branch relaxation support status.
            * config/loongarch/loongarch.opt: Regenerate.
            * configure.ac (gcc_cv_as_loongarch_cond_branch_relax): Check if
            the assembler supports conditional branch relaxation.
            * configure: Regenerate.
            * config.in: Regenerate.  Note that there are some unrelated
            changes introduced by r14-5424 (which does not contain a
            config.in regeneration).
            * config/loongarch/loongarch-opts.h
            (HAVE_AS_COND_BRANCH_RELAXATION): Define to 0 if not defined.
            * config/loongarch/loongarch.h (ASM_MRELAX_DEFAULT): Define.
            (ASM_MRELAX_SPEC): Define.
            (ASM_SPEC): Use ASM_MRELAX_SPEC instead of "%{mno-relax}".
            * doc/invoke.texi: Document -m[no-]relax and
            -m[no-]pass-mrelax-to-as for LoongArch.

    (cherry picked from commit fe23a2ff1f5072559552be0e41ab55bf72f5c79f)

[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by LuluCheng
<chenglulu@gcc.gnu.org>:

https://gcc.gnu.org/g:727ae33dae301d9ae5cc753493764ded1876a1ac

commit r13-8351-g727ae33dae301d9ae5cc753493764ded1876a1ac
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Fri Nov 3 21:19:59 2023 +0800

    LoongArch: Disable relaxation if the assembler don't support conditional
branch relaxation [PR112330]

    As the commit message of r14-4674 has indicated, if the assembler does
    not support conditional branch relaxation, a relocation overflow may
    happen on conditional branches when relaxation is enabled because the
    number of NOP instructions inserted by the assembler will be more than
    the number estimated by GCC.

    To work around this issue, disable relaxation by default if the
    assembler is detected incapable to perform conditional branch relaxation
    at GCC build time.  We also need to pass -mno-relax to the assembler to
    really disable relaxation.  But, if the assembler does not support
    -mrelax option at all, we should not pass -mno-relax to the assembler or
    it will immediately error out.  Also handle this with the build time
    assembler capability probing, and add a pair of options
    -m[no-]pass-mrelax-to-as to allow using a different assembler from the
    build-time one.

    With this change, if GCC is built with GAS 2.41, relaxation will be
    disabled by default.  So the default value of -mexplicit-relocs= is also
    changed to 'always' if -mno-relax is specified or implied by the
    build-time default, because using assembler macros for symbol addresses
    produces no benefit when relaxation is disabled.

    gcc/ChangeLog:

            PR target/112330
            * config/loongarch/genopts/loongarch.opt.in: Add
            -m[no]-pass-relax-to-as.  Change the default of -m[no]-relax to
            account conditional branch relaxation support status.
            * config/loongarch/loongarch.opt: Regenerate.
            * configure.ac (gcc_cv_as_loongarch_cond_branch_relax): Check if
            the assembler supports conditional branch relaxation.
            * configure: Regenerate.
            * config.in: Regenerate.  Note that there are some unrelated
            changes introduced by r14-5424 (which does not contain a
            config.in regeneration).
            * config/loongarch/loongarch-opts.h
            (HAVE_AS_COND_BRANCH_RELAXATION): Define to 0 if not defined.
            * config/loongarch/loongarch.h (ASM_MRELAX_DEFAULT): Define.
            (ASM_MRELAX_SPEC): Define.
            (ASM_SPEC): Use ASM_MRELAX_SPEC instead of "%{mno-relax}".
            * doc/invoke.texi: Document -m[no-]relax and
            -m[no-]pass-mrelax-to-as for LoongArch.

    (cherry picked from commit fe23a2ff1f5072559552be0e41ab55bf72f5c79f)