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 [email protected] 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
