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？
