We currently transfer the opt level from the user clang call to CC1 args
at the end of the `ConstructJob` function, this might lead to bugs as
`ConstructJob` is a big function and we easily could add a change that
would return early from it. That would cause the opt level to not be
transferred to CC1 args and lead to wrong opt level compilation and
would be hard to spot. This PR moves the opt level to the beginning of
the function as opt level should be a direct transfer without any
problems, it also removes the redundancy where it was added 2 times
through the function.
Without this, `-###` prints the linker invocation as well, which
can lead to `-Wno-msvc-not-found` warnings on Windows bots that
don't have MSVC on path, causing the test to fail.
Since the test isn't trying to test linker-related things, just
pass `-c`. See discussion on #98736.
This patch implements consensus on the corresponding RFC documented
here: https://discourse.llvm.org/t/rfc-deprecate-ofast/78687/72
Specifically, I added a deprecation warning for `-Ofast`, that suggests
to use `-O3` or `-O3` with `-ffast-math`, and a new diagnostic group for
aforementioned warning.
Deprecation period is going to be lengthy, so I hope this PR can be
merged in time for Clang 19.
From looking at the rest of code and from my own understanding, the
driver mode is supposed to be independent of MSVC compatibility when the
target triple is `*-windows-msvc`.
Therefore strict aliasing should be disabled by default when the target
triple is `*-windows-msvc` so code assuming MSVC behaves as expected
when compiled with Clang.
Specifically, allow the flags that fall under this umbrella (i.e., -O3,
-ffast-math, and -fstrict-aliasing) to be overridden/disabled with the
individual -O[0|1|2|s|z]/-fno- flags.
This also fixes the handling of various floating point optimization
flags that are modified by -ffast-math (and thus -Ofast as well).
Part of rdar://13622687
llvm-svn: 180204
