* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
@ 2023-11-01 8:42 ` xry111 at gcc dot gnu.org
2023-11-01 8:54 ` xry111 at gcc dot gnu.org
` (18 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-01 8:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
2023-11-01 8:42 ` [Bug target/112330] " xry111 at gcc dot gnu.org
@ 2023-11-01 8:54 ` xry111 at gcc dot gnu.org
2023-11-01 9:00 ` chenglulu at loongson dot cn
` (17 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-01 8:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
2023-11-01 8:42 ` [Bug target/112330] " xry111 at gcc dot gnu.org
2023-11-01 8:54 ` xry111 at gcc dot gnu.org
@ 2023-11-01 9:00 ` chenglulu at loongson dot cn
2023-11-01 9:07 ` xry111 at gcc dot gnu.org
` (16 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: chenglulu at loongson dot cn @ 2023-11-01 9:00 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (2 preceding siblings ...)
2023-11-01 9:00 ` chenglulu at loongson dot cn
@ 2023-11-01 9:07 ` xry111 at gcc dot gnu.org
2023-11-01 9:10 ` chenglulu at loongson dot cn
` (15 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-01 9:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (3 preceding siblings ...)
2023-11-01 9:07 ` xry111 at gcc dot gnu.org
@ 2023-11-01 9:10 ` chenglulu at loongson dot cn
2023-11-01 9:23 ` xry111 at gcc dot gnu.org
` (14 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: chenglulu at loongson dot cn @ 2023-11-01 9:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (4 preceding siblings ...)
2023-11-01 9:10 ` chenglulu at loongson dot cn
@ 2023-11-01 9:23 ` xry111 at gcc dot gnu.org
2023-11-01 9:33 ` chenglulu at loongson dot cn
` (13 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-01 9:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (5 preceding siblings ...)
2023-11-01 9:23 ` xry111 at gcc dot gnu.org
@ 2023-11-01 9:33 ` chenglulu at loongson dot cn
2023-11-01 9:56 ` xry111 at gcc dot gnu.org
` (12 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: chenglulu at loongson dot cn @ 2023-11-01 9:33 UTC (permalink / raw)
To: gcc-bugs
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？
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (6 preceding siblings ...)
2023-11-01 9:33 ` chenglulu at loongson dot cn
@ 2023-11-01 9:56 ` xry111 at gcc dot gnu.org
2023-11-01 9:58 ` [Bug target/112330] [14 Regression] LoongArch: Bootstrap " xry111 at gcc dot gnu.org
` (11 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-01 9:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (7 preceding siblings ...)
2023-11-01 9:56 ` xry111 at gcc dot gnu.org
@ 2023-11-01 9:58 ` xry111 at gcc dot gnu.org
2023-11-02 6:57 ` chenglulu at loongson dot cn
` (10 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-01 9:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (8 preceding siblings ...)
2023-11-01 9:58 ` [Bug target/112330] [14 Regression] LoongArch: Bootstrap " xry111 at gcc dot gnu.org
@ 2023-11-02 6:57 ` chenglulu at loongson dot cn
2023-11-02 7:43 ` xry111 at gcc dot gnu.org
` (9 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: chenglulu at loongson dot cn @ 2023-11-02 6:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (9 preceding siblings ...)
2023-11-02 6:57 ` chenglulu at loongson dot cn
@ 2023-11-02 7:43 ` xry111 at gcc dot gnu.org
2023-11-02 7:59 ` chenglulu at loongson dot cn
` (8 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-02 7:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (10 preceding siblings ...)
2023-11-02 7:43 ` xry111 at gcc dot gnu.org
@ 2023-11-02 7:59 ` chenglulu at loongson dot cn
2023-11-02 8:07 ` xry111 at gcc dot gnu.org
` (7 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: chenglulu at loongson dot cn @ 2023-11-02 7:59 UTC (permalink / raw)
To: gcc-bugs
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．
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (11 preceding siblings ...)
2023-11-02 7:59 ` chenglulu at loongson dot cn
@ 2023-11-02 8:07 ` xry111 at gcc dot gnu.org
2023-11-02 8:43 ` chenglulu at loongson dot cn
` (6 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-02 8:07 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (12 preceding siblings ...)
2023-11-02 8:07 ` xry111 at gcc dot gnu.org
@ 2023-11-02 8:43 ` chenglulu at loongson dot cn
2023-11-02 9:54 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: chenglulu at loongson dot cn @ 2023-11-02 8:43 UTC (permalink / raw)
To: gcc-bugs
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．
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (13 preceding siblings ...)
2023-11-02 8:43 ` chenglulu at loongson dot cn
@ 2023-11-02 9:54 ` rguenth at gcc dot gnu.org
2023-11-02 11:41 ` [Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error " xry111 at gcc dot gnu.org
` (4 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-11-02 9:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (14 preceding siblings ...)
2023-11-02 9:54 ` rguenth at gcc dot gnu.org
@ 2023-11-02 11:41 ` xry111 at gcc dot gnu.org
2023-11-14 9:37 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-02 11:41 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (15 preceding siblings ...)
2023-11-02 11:41 ` [Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error " xry111 at gcc dot gnu.org
@ 2023-11-14 9:37 ` cvs-commit at gcc dot gnu.org
2023-11-14 9:47 ` xry111 at gcc dot gnu.org
` (2 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-14 9:37 UTC (permalink / raw)
To: gcc-bugs
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=.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (16 preceding siblings ...)
2023-11-14 9:37 ` cvs-commit at gcc dot gnu.org
@ 2023-11-14 9:47 ` xry111 at gcc dot gnu.org
2024-02-22 3:17 ` cvs-commit at gcc dot gnu.org
2024-02-22 3:25 ` cvs-commit at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-11-14 9:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (17 preceding siblings ...)
2023-11-14 9:47 ` xry111 at gcc dot gnu.org
@ 2024-02-22 3:17 ` cvs-commit at gcc dot gnu.org
2024-02-22 3:25 ` cvs-commit at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-02-22 3:17 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 21+ messages in thread* [Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41
2023-11-01 8:38 [Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41 xry111 at gcc dot gnu.org
` (18 preceding siblings ...)
2024-02-22 3:17 ` cvs-commit at gcc dot gnu.org
@ 2024-02-22 3:25 ` cvs-commit at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-02-22 3:25 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 21+ messages in thread