https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #32 from huangpei at loongson dot cn <huangpei at loongson dot cn> --- On Tue, Sep 01, 2026 at 09:44:00AM +0000, xry111 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935 > > --- Comment #31 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- > (In reply to [email protected] from comment #30) > > On Tue, Sep 01, 2026 at 04:30:29AM +0000, xry111 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935 > > > > > > --- Comment #29 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- > > > (In reply to Jerry DeLisle from comment #28) > > > > I have lost track here. It seems that the patch given in comment #16 > > > > fixes > > > > the issue but there is something wrong on the the 3A6000? I suppose it is another issue with same data race. > > > In comment 25, I say, >>>>> 3A6000+, while compatible with 3A50000, has changed this behavior by >>>>> new CPUCFG. So this is not a problem on newer cpu I mean the problem is SA-RAR-OoO and 3A6000+ can avoid it, not 3A6000 can avoid failing rwlock_1.f90. > > > I mean comment #25 indicated the issue was not reproducible *even without > > > the > > > patch* on 3A6000 but I can reproduce it there (still without the patch). > > > So > > > something in the discussions leading to the conclusion that the issue only > > > affects the "very weak order" implementations like 3A5000 does not add up. > > > You misunderstand it, the context in comment #15 and comment #25 is the SEGV with backtrace in comment #1 and Tsan log in comment #15, so "the issue" should be *the SEGV*, not rwlock_1.90 failed. > > > I'm not so concerning about this though, as data race is clearly an > > > undefined > > > behavior so any difference can be simply explained as "just good/bad > > > luck." Yes, data race is confirmed by Tsan. Data race, with Tsan and my assumption, can explain the SEGV. > > > > Please check whether CPUCFG.3.LD_SEQ_SA[bit23] return 1 on your 3A6000, > > It returns 1. AFAIK all publicly available firmware sets this to 1. Yes, I confirmed it on my 3A6000 on all core and my 3A6000 is without SA-RAR-OoO too. > > And the phenomena is a little different on my tester, I have: > > STOP 2 > Internal Error: Trying to free nonempty asynchronous unit > > Error termination. Backtrace: > STOP 2 > STOP 2 > Internal Error: Trying to free nonempty asynchronous unit > > Error termination. Backtrace: > #0 0x7ffff0b42873 in free_async_unit > at ../../../gcc-upstream/libgfortran/io/async.c:211 > #1 0x7ffff0b3584f in close_unit_1 > at ../../../gcc-upstream/libgfortran/io/unit.c:824 > #2 0x555557e6137f in ??? > #3 0x7ffff0845f97 in gomp_thread_start > at ../../../gcc-upstream/libgomp/team.c:129 > #4 0x7ffff062f343 in start_thread > at /home/xry111/sources/lfs/glibc-2.44/nptl/pthread_create.c:454 > #5 0x7ffff06d08b3 in __thread_start3 > at ../sysdeps/unix/sysv/linux/loongarch/clone3.S:74 > #6 0xffffffffffffffff in ??? > #0 0x7ffff0b42873 in free_async_unit > at ../../../gcc-upstream/libgfortran/io/async.c:211 > #1 0x7ffff0b3584f in close_unit_1 > at ../../../gcc-upstream/libgfortran/io/unit.c:824 > #2 0x7ffff0bccc4b in _dl_call_fini > at /home/xry111/sources/lfs/glibc-2.44/elf/dl-fini.c:120 > #4 0x7ffff05cf8d3 in __run_exit_handlers > at /home/xry111/sources/lfs/glibc-2.44/stdlib/exit.c:118 > #5 0x7ffff05cfa37 in __GI_exit > at /home/xry111/sources/lfs/glibc-2.44/stdlib/exit.c:148 > #6 0x555557e6155b in ??? > #7 0x7ffff0845f97 in gomp_thread_start > at ../../../gcc-upstream/libgomp/team.c:129 > #8 0x7ffff062f343 in start_thread > at /home/xry111/sources/lfs/glibc-2.44/nptl/pthread_create.c:454 > #9 0x7ffff06d08b3 in __thread_start3 > at ../sysdeps/unix/sysv/linux/loongarch/clone3.S:74 > #10 0xffffffffffffffff in ??? > FAIL: libgomp.fortran/rwlock_1.f90 -O0 execution test If the same SEGV reproduced on 3A6000, my assumption is definitely wrong, or something wrong on 3A6000. > > So maybe it's a different issue. I agree, and I wish it is caused by the same data race, too. By the way, have you try the patch on this issue? > > Also I have some vague memory about seeing this on other targets as well > (maybe > I actually saw PR 113005, I couldn't recall that precisely now unfortunately). > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
