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

[huangpei at loongson dot cn]

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

--- Comment #22 from huangpei at loongson dot cn <huangpei at loongson dot cn> ---
(In reply to Thomas Koenig from comment #21)
> (In reply to huangpei@loongson.cn from comment #20)
> > only loongarch64-unknown-linux-gnu 
> > 
> 
> > which arch did I need to test?
> > 
> > I can get access to x64@linux and arm64@linux
> 
> I understand that, right now, there is no independent test case which fails
> without the patch and succeeds with it.  Normally, this is a requirement
> for gcc patches, but if it requires non-standard libgfortran build
> options, I am not sure how to do it, at least as part of the regular
> testsuite.
> 
> Building this on as many systems as possible with different locking
> behavior and -O0 would be a good step. I could try that on POWER,
> for example.

Base on Comment 6 and Comment 15, we can confirm that there is data race
between
find_file0 and set_internal_unit/new_unit, but Comment 15 show that **Only**
under very weakly-order memory model with Same address Read after Read Out of
Oder, SEGV can be triggered. As far as I know, Only Loong64 meet this memory
modal. So I do not think this bug can be triggered on POWER64 or ARM64；


```
        ld.d    $r12,$r3,8
        ld.d    $r12,$r12,8    // first read #1 
        beqz    $r12,.L4   // Here, $r12 is not NULL.
        ld.d    $r12,$r3,8
        ld.d    $r12,$r12,8  // second read #2, when reloaded, it has already
become NULL because it reordered before #1 on LoongArch,. 
        st.d    $r12,$r3,24
        ldptr.d $r12,$r3,0
        ldptr.d $r13,$r12,0
        ld.d    $r12,$r3,24
        ld.d    $r12,$r12,72
```

Even under weakly order memory modal, #2 **can not** be reorder before #1,
since both #1 and #2 access same address, so #2 can never see u->s as NULL,
that why this bug is not triggered on any arch other than Loong64