On 1/1/26 1:33 PM, Thomas Koenig wrote:
Hi Jerry,
This will avoid potential undefined behavior on various systems. I will make
this change and test. If passes, OK for mainline?
Good thinking.
Your revised version is OK if it passes.
Thanks a lot for the patch!
Best regards
Thomas
I committed this and of course I get this a bit too late. One of the tests that
fail is this one:
! { dg-do run }
SUBROUTINE SUB()
COMMON /BLOCK/ X
PRINT *,X ! X is undefined
END SUBROUTINE SUB
PROGRAM A28_1
COMMON /BLOCK/ X
X = 1.0
!$OMP PARALLEL PRIVATE (X)
X = 2.0
CALL SUB()
!$OMP END PARALLEL
END PROGRAM A28_1
I am not a gomp master. I want to think calling a procedure like this should be
invalid because more than one thread is trying to write to the same unit.
However, I am probably wrong. I need some advice.
Jerry
-----
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find
some details below.
In gcc_check master-aarch64, after:
| commit gcc-16-6459-g489423763d3c
| Author: Jerry DeLisle <[email protected]>
| Date: Tue Dec 30 14:46:35 2025 -0800
|
| Fortran: Generate a runtime error on recursive I/O
|
| PR libfortran/119136
|
| gcc/fortran/ChangeLog:
| ... 17 lines of the commit log omitted.
Produces 39 regressions:
|
| regressions.sum:
| Running libgomp:libgomp.fortran/fortran.exp ...
| FAIL: libgomp.fortran/appendix-a/a.22.8.f90 -O0 execution test
| FAIL: libgomp.fortran/appendix-a/a.22.8.f90 -O1 execution test
| FAIL: libgomp.fortran/appendix-a/a.22.8.f90 -O2 execution test
| FAIL: libgomp.fortran/appendix-a/a.22.8.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
| ... and 35 more
