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 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. > > > > 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." > > 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. 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 So maybe it's a different 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).
