Hi Thomas,
Thomas Koenig wrote:
Attached is a long overdue bug fix, given that OpenMP's declare variant
is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021).
(and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp
declare simd' was already handled in the .mod file, 'declare variant'
was not. It is easily missed in single-file testcases (esp. after the
commitr15-7595-g8268c8256) as the
whole-file handling mostly hides it.
Just one question - as this will change the module file, will we
still be compatible with reading gfortran 8 to gfortran 14-written
module files?
It shouldn't. On writing there is:
* mio_omp_declare_simd [old function, additional condition]: if (*odsp
== NULL) { if (ns->omp_declare_variant) { mio_lparen (); mio_rparen ();
} return; 4439,4-11 55% Thus, on writing, it only writes '(' if there is
a 'declare simd' (with its context, unchanged) - or (new) an empty '( )'
if there is a 'declare variant'. * mio_omp_declare_variant itself has
code: if (iomode == IO_OUTPUT) { if (*odvp == NULL) return;
Thus, if there is no 'declare variant', the output for 'declare simd'
should the same as before - and the code is simple enough that I would
even claim 'is' (unless the memory is corrupted). And as the output
remains the same in that case, there should be also no problem reading
both old .mod files with new compiler - and even the reverse, i.e.
reading .mod files, written by after this patch, with an old GCC
version. [The latter will fail due to the recent version bump, but
that's unrelated to this patch.] The only potentially failing cases are:
* Code that contains 'declare variant' that is written by a new
compiler, but read by an old compiler (missing downward compatibility).
- But due to the version bump in GCC 15 (r15-6704-g21ee71afa72746;Jan
25, 2025), this only affects GCC 15 version between January and March -
and only when the module contained 'declare variant'. [The mode-reading
error is that the code stumbles over the '(' [ followed by some items
and ')'] - while expecting the outer ')'.] * Some bug in the added code.
This is very unlikely to hit code without 'declare variant', but there
is some chance that I missed some corner case with 'declare variant'
present - which might either cause missing data, wrong data (that might
cause later fails [ICE, bogus diagnostic, wrong code]) or even a .mod
reading issue. - While I ran into all those issues (with declare variant
present) - fund in course of writing the test cases, I hope that I found
most if not all such bugs. Thus, we should be all fine. I guess, we
eventually will have some additions to the context selectors in the
'match' clauses, which will break downward (but not upward)
compatibility. At least the TODO in openmp.cc implies that some work is
needed and there is some chance that the current code will not handle
it. (That's tracked as https://gcc.gnu.org/PR113067 ) Cheers, Tobias
