[Bug libfortran/118935] Segmentation fault in 'libgomp.fortran/rwlock_1.f90' when compiling libgfortran with '-O0'

[xry111 at gcc dot gnu.org]

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

--- Comment #31 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to huangpei@loongson.cn 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).