(I have now also left out the gcc* mailing list, leaving only
fortran@gcc.gnu.org in.)
On 23.02.23 16:24, Damian Rouson wrote:
I wonder if a relatively easy starting point would be enabling the
declaration of do concurrent construct variables:
do concurrent (integer :: i = 1:n)
It’s a minor convenience and less exciting than adding locality
specifiers but possibly a good first exercise.
I concur that this is a useful Fortran 2018 feature. But this creates a
new scope which is also not that straight forward. Thus, maybe rather
something for a third instead of for the first exercise :-)
But in any case, another F2018 omission – and good that you spotted the
omission.
* * *
Regarding building GCC: If you build as mentioned in my previous email,
GCC is bootstrapped. That is: It is build first with the system compiler
(likely some older GCC), then the just build compiler is used to build
GCC again (without debugging symbols), then that one is used to build
GCC a third time (with debugging symbols) — and then there is a check
whether the generated in Stage 3 with debugging symbols stripped is
identical to the one in Stage 2.
If you develop, a faster way is to build with: --disable-bootstrap
--disable-multilib --disable-libstdcxx-pch
* The first one disables the three-stage build process and builds only
with the system compiler. (Caveat: This one might have different
warnings. Thus, when a patch is ready, a bootstrap build is required to
avoid surprises with warnings treated as errors.)
* The second one disables 32bit support, which is usually build
alongside 64bit support on Linux.
* PCH are C++ pre-compiled headers. Those take some time to build and
also slows building down.
Running the GCC testsuite:
"make check-fortran -j12" in the main build directory tests everything
Fortran related (libgomp/testsuite/ and gcc/testsuite/*fortran*/.) – To
check for a specific testcase in the latter, do "cd gcc" in the build
directory and run 'make check-fortran RUNTESTFLAGS="dg.exp=myTest*.f90"'
where dg.exp is the file in the gfortran.dg/ directory and myTest*.f90
matches the file name.
What is done with the tests is determined by '{ dg-... }' in the comment
lines, in particular 'dg-do run/compile' tells whether it is a run-time
or compile-time check. And 'dg-error'/'dg-warning' check for the
presence of diagnostic lines.
* * *
I think I stop here. — If you have questions or something is unclear or
does not work, please tell.
Tobias
PS: For the greater picture, in particular Nvidia did some experiments
with running do concurrent really concurrently (with offloading to their
accelerators). See for instance:
https://developer.nvidia.com/blog/using-fortran-standard-parallel-programming-for-gpu-acceleration/
and
https://developer.nvidia.com/blog/accelerating-fortran-do-concurrent-with-gpus-and-the-nvidia-hpc-sdk/
That's unsurprisingly a bit Nvidia centric, but it should give an idea
how concurrency handling could look like.
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
