C11 was made default in LLVM commit ab506adf7d3ced6abcaf42f92de3d6cd15fa19e8,
released in 3.5.2.
C99 was made default in LLVM commit 17f76e04d244c80e70f1c81c94d4524b53d9772d,
released in 2.1. It was flipped a few times between C89 and C99 during the 2.1
cycle, but the C89 default never made it into a release.
C89, C99 flags in LLVM commit ff43821d5380ee38aff421701f1d461242b524ee.
C90 flag in LLVM commit 229ce60fc9983df5f7e83e25fa6b5c0ca4d2b135.
C1x flag in LLVM commit a686b5f8bf7b5a2ab636c0c2de5ad4c174aa33e0.
C11 flag in LLVM commit 6784aeb9ef96e5735850fa7226ed0cb45cb82e75.
Mark C90, C99 full support since 2.1. Might've been possibly a little later,
but source spelunking that much back is difficult.
Mark C11 full support since 3.0, which added _Static_assert in LLVM commit
3d9cbdc3e66e274d5d3cb94ce81a65478d9baae0.
The PGI ( and NVIDIA HPC ) compilers default C++ standard level
are based on the GCC system headers it is compiling against.
Therefore on newer platforms the default C++ level will be >= 11
and requesting C++98 compilation mode will fail as no explicit
flag will be set.
In commit 4620cf77f2 (Clang: Remove unused CUDA implicit link variables,
2021-02-14) we removed some references. It turns out they are non-empty
and necessary if using a non-scattered installation.
Fixes: #21863
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo test discovery when they match exactly.
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo detection when they match exactly.
The refactoring in 17e5516e60 (FetchContent: Invoke steps directly and
avoid a separate sub-build, 2021-01-29) uses a different way of writing
out the step scripts and updating time stamps when steps are executed.
That inadvertently always wrote out the scripts for custom commands,
even when the contents didn't change. This caused their timestamp to
always be updated, resulting in those steps always being seen as
out-of-date and needing to be re-executed.
The way timestamps were checked to determine whether to re-execute
a step also did not adequately account for file systems which only have
second-resolution timestamps. The IS_NEWER_THAN if condition also
returns true when timestamps are the same, so one needs to use the
negative form to get a true "is newer than" test.
ExternalProject is not susceptible to this problem because it uses
file(GENERATE) to write out the script files and that only updates the file's
timestamp if the contents change. It also mostly leaves timestamp
checking to the build tool.
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo downloads when they match exactly.
The NAG Fortran compiler's `-mdir` flag sets the module output
directory but does not add the directory to the search path for using
modules. This is inconsistent with other compilers like the GNU Fortran
compiler's `-J` flag that does both. In order to make these consistent,
add the module output directory with a `-I` flag on the NAG Fortran
compiler so that it will be searched when using modules too.
We already do this for the XL Fortran compiler since commit 210b0b99a9
(XL: Fix using Fortran modules from their output directory, 2020-02-28,
v3.18.0-rc1~640^2~1).
c9244f369a IntelLLVM: Make explicit Fortran preprocessing under Ninja more robust
056d4bf528 Merge branch 'backport-intel-fortran-preprocess'
af074c266e Intel: Make explicit Fortran preprocessing under Ninja more robust
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5826
c9244f369a IntelLLVM: Make explicit Fortran preprocessing under Ninja more robust
056d4bf528 Merge branch 'backport-intel-fortran-preprocess'
af074c266e Intel: Make explicit Fortran preprocessing under Ninja more robust
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5826
Tell the Fortran compiler to write preprocessor output directly to a
file, as we do for the GNU compiler. The previous "redirect stdout"
approach could break during ABI detection with some `mpif90` wrappers
that add version information to stdout when called with `-v`.
Issue: #21828
Tell the Fortran compiler to write preprocessor output directly to a
file, as we do for the GNU compiler. The previous "redirect stdout"
approach could break during ABI detection with some `mpif90` wrappers
that add version information to stdout when called with `-v`.
Fixes: #21828
The refactoring in 17e5516e60 (FetchContent: Invoke steps directly and
avoid a separate sub-build, 2021-01-29) contained a typo which resulted
in any PATCH_COMMAND being ignored. Fix the typo and add a test case
that would have caught the regression.
