https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2023-12-21 00:00:00 |2024-7-2
--- Comment #15 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
First, I apologize for the delay in continuing the discussion here. Siemens
decided to cancel their Open Source Toolchains business (and more), so my group
had to find a new home...
At BayLibre, I first didn't run into this issue anymore. However, today I've
done some "environmental changes", and it's back: I switched from "local disk"
to "NFS" testing, that is, the testing directory is NFS-mounted.
(In reply to Lipeng Zhu from comment #14)
> (In reply to Lipeng Zhu from comment #13)
> > OK, I think I find the root cause of this error, when thread number greater
> > than 1000, the file_name = 1000_tst.dat, character(11) will overflow. This
> > will generate the same file_name like ***_tst.dat.
That's not the issue I've been running into, so:
> Can you help to verify if this draft patch will fix the error on your side?
No, that doesn't help in my case. (..., but supposedly is still necessary for
the "greater than 1000" case.)
The problem I'm running into, on the following system:
$ grep ^cpu < /proc/cpuinfo | uniq -c
128 cpu : POWER9, altivec supported
..., when running 'libgomp.fortran/rwlock_1.f90' via 'strace -o s -ff
[...]/rwlock_1.exe', that produces 25984 (!) 's.*' files (process 'clone's --
OpenMP threads, I suppose; I didn't try to understand that number in more
detail), and in total:
$ cat s.* | grep -F '_tst.dat' | wc -l
51712
... 51712 operations on '*_tst.dat' files (multiplied by the number of
operations on the respective opened file descriptors), and I assume that's what
overwhelms the NFS subsystem.
I don't think there's really any kind of existing mechanism/precedent for test
cases to open files outside of their current working directory (local disk, for
example: '/tmp/' instead of NFS in my case), or is there?
Are these 'libgomp.fortran/rwlock_{1,2,3}.f90' test cases intended to be
correctness test cases (and therefore may be limiting themselves to some
suitable lower 'OMP_NUM_THREADS', for example via 'num_threads' clauses, as
discussed before), or performance test cases that really need to exercise all
cores, for example?
