| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch improves the warnings to show which user options override the
complex range. When a complex range is overridden, explicitly display
both the option name and the implied complex range value for both the
overriding and the overridden options.
See also the discussion in the following discourse post:
https://discourse.llvm.org/t/the-priority-of-fno-fast-math-regarding-complex-number-calculations/84679
|
|
RFC:
https://discourse.llvm.org/t/rfc-support-pseudo-probe-for-windows-coff/83820
Support emitting pseudo probe to .pseudo_probe and .pseudo_probe_desc
COFF sections.
|
|
cl.exe has /std:clatest, analogous to /std:c++latest, which sets the
language mode to the latest standard. For C, that's C23. This adds
support for the option.
Fixes #147233
|
|
(equivalent to MSVC's /d2epilogunwindrequirev2) (#143577)
#129142 added support for emitting Windows x64 unwind v2 information,
but it was "best effort". If any function didn't follow the requirements
for v2 it was silently downgraded to v1.
There are some parts of Windows (specifically kernel-mode code running
on Xbox) that require v2, hence we need the ability to fail the
compilation if v2 can't be used.
This change also adds a heuristic to check if there might be too many
unwind codes, it's currently conservative (i.e., assumes that certain
prolog instructions will use the maximum number of unwind codes).
Future work: attempting to chain unwind info across multiple tables if
there are too many unwind codes due to epilogs and adding a heuristic to
detect if an epilog will be too far from the end of the function.
|
|
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.
|
|
(Windows kernel loader replaceable functions) (#125320)
Adds support for MSVC's undocumented `/funcoverride` flag, which marks
functions as being replaceable by the Windows kernel loader. This is
used to allow functions to be upgraded depending on the capabilities of
the current processor (e.g., the kernel can be built with the naive
implementation of a function, but that function can be replaced at boot
with one that uses SIMD instructions if the processor supports them).
For each marked function we need to generate:
* An undefined symbol named `<name>_$fo$`.
* A defined symbol `<name>_$fo_default$` that points to the `.data`
section (anywhere in the data section, it is assumed to be zero sized).
* An `/ALTERNATENAME` linker directive that points from `<name>_$fo$` to
`<name>_$fo_default$`.
This is used by the MSVC linker to generate the appropriate metadata in
the Dynamic Value Relocation Table.
Marked function must never be inlined (otherwise those inline sites
can't be replaced).
Note that I've chosen to implement this in AsmPrinter as there was no
way to create a `GlobalVariable` for `<name>_$fo$` that would result in
a symbol being emitted (as nothing consumes it and it has no
initializer). I tried to have `llvm.used` and `llvm.compiler.used` point
to it, but this didn't help.
Within LLVM I referred to this feature as "loader replaceable" as
"function override" already has a different meaning to C++ developers...
I also took the opportunity to extract the feature symbol generation
code used by both AArch64 and X86 into a common function in AsmPrinter.
|
|
(equivalent to MSVC /d2epilogunwind) (#129142)
Adds support for emitting Windows x64 Unwind V2 information, includes
support `/d2epilogunwind` in clang-cl.
Unwind v2 adds information about the epilogs in functions such that the
unwinder can unwind even in the middle of an epilog, without having to
disassembly the function to see what has or has not been cleaned up.
Unwind v2 requires that all epilogs are in "canonical" form:
* If there was a stack allocation (fixed or dynamic) in the prolog, then
the first instruction in the epilog must be a stack deallocation.
* Next, for each `PUSH` in the prolog there must be a corresponding
`POP` instruction in exact reverse order.
* Finally, the epilog must end with the terminator.
This change adds a pass to validate epilogs in modules that have Unwind
v2 enabled and, if they pass, emits new pseudo instructions to MC that
1) note that the function is using unwind v2 and 2) mark the start of
the epilog (this is either the first `POP` if there is one, otherwise
the terminator instruction). If a function does not meet these
requirements, it is downgraded to Unwind v1 (i.e., these new pseudo
instructions are not emitted).
Note that the unwind v2 table only marks the size of the epilog in the
"header" unwind code, but it's possible for epilogs to use different
terminator instructions thus they are not all the same size. As a work
around for this, MC will assume that all terminator instructions are
1-byte long - this still works correctly with the Windows unwinder as it
is only using the size to do a range check to see if a thread is in an
epilog or not, and since the instruction pointer will never be in the
middle of an instruction and the terminator is always at the end of an
epilog the range check will function correctly. This does mean, however,
that the "at end" optimization (where an epilog unwind code can be
elided if the last epilog is at the end of the function) can only be
used if the terminator is 1-byte long.
One other complication with the implementation is that the unwind table
for a function is emitted during streaming, however we can't calculate
the distance between an epilog and the end of the function at that time
as layout hasn't been completed yet (thus some instructions may be
relaxed). To work around this, epilog unwind codes are emitted via a
fixup. This also means that we can't pre-emptively downgrade a function
to Unwind v1 if one of these offsets is too large, so instead we raise
an error (but I've passed through the location information, so the user
will know which of their functions is problematic).
|
|
which was mentioned in
https://devblogs.microsoft.com/cppblog/cpp-dynamic-debugging-full-debuggability-for-optimized-builds/
(That post also mentions /d2DDTrimInlines, which we already parse via
a /d2 catch-all.)
|
|
|
|
Also move the -fno-strict-overflow option definition next to the
-fstrict-overflow one while here.
Also add test coverage for f(no-)wrapv-pointer being a clang-cl option.
|
|
Also move the -fno-wrapv option definition next to the -fwrapv one while
here.
|
|
Exposing `-fdiagnostic-color=` to clang-cl and clang-dxc.
`-fcolor-diagnostics` and `-fno-color-diagnostics` are already allowed
in both of these and `-fdiagnostics-color=` allows one additional value,
`auto`.
I've added the tests for clang-cl to `cl-options.c` as per the comments
in the issue linked below. I couldn't finding a suitable existing file
to add the clang-dxc tests to so I've created a new one.
Resolves #119184
|
|
Those flags are introduced in #117282. They are not supported by MSVC.
|
|
Sampling PGO has already been supported on Windows. This patch adds
/fprofile-sample-use= /fprofile-sample-use: /fno-profile-sample-use and
supports -fprofile-sample-use= for CL.
|
|
As discussed in
https://discourse.llvm.org/t/clang-cl-adding-std-c-23preview/82553
|
|
`*-windows-msvc` on non cl driver modes (#109607)
Similar to previous PRs I've done to change some `IsCLMode` checks to
`isWindowsMSVCEnvironment`.
I stumbled into this one accidentally last week. I did some greps and I
think this is the last one for now. All the remaining `IsCLMode` checks
are only valid for the cl driver mode.
For the `*-windows-msvc` target MSVC link.exe and lld are supported. LTO
isn't supported with MSVC link.exe and so we error when lto is enabled
but MSVC link.exe is being used. However we only error if the driver
mode is cl.
If we are using the clang driver with the `*-windows-msvc` target then
ensure an error is also emitted when LTO and MSVC link.exe are used
together.
|
|
Several lit tests look for messages with text generated from strerror()
such as "no such file or directory". The value can change slightly from
system to system. Use the llvm-lit macro `%errc_<ERRCODE>` instead.
This was really noticable on z/OS because the generated text includes an
error code as well as the text.
|
|
This is used to set DebugInfoKind to "UnusedTypeInfo". This helps in the
context of Unreal Engine and NATVIS files that reference unused
otherwise `static constexpr` class members. See
https://udn.unrealengine.com/s/question/0D5QP00000N012h0AB/fname-debug-visualizer-fails-to-work-with-the-clang-compiler
This partially fixes https://github.com/llvm/llvm-project/issues/46924
|
|
According to the docs, this was added in VS2019 and specifies more
aggressive inlining than /Ob2. Let's treat it the same as /Ob2 for now.
|
|
/Ot (which is also implied by /O2) is supposed to optimize for maximum
speed, so -O3 seems like a better match.
|
|
second try (#88245)
This is a second try to reland
https://github.com/llvm/llvm-project/pull/87149.
The previous commit exposed failures on some targets. The reason is only
a few targets support COFF ObjectFormatType on Windows:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/TargetParser/Triple.cpp#L835-L842
With https://github.com/llvm/llvm-project/pull/87149, the targets don't
support COFF will report "warning: argument unused during compilation:
'-gcodeview-command-line' [-Wunused-command-line-argument]" in the test
gcodeview-command-line.c
I was thinking `REQUIRES: *-registered-target` could solve the problem,
but it didn't. We need to check the actual triple instead of just
`*-registered-target`.
|
|
Previously, since response (.rsp) files weren't expanded at the very
beginning of clang-scan-deps, we only parsed the command-line as
provided in the Clang .cdb file. Unfortunately, when using Unreal
Engine, arguments are always generated in a .rsp file (ie.
`/path/to/clang-cl.exe @/path/to/filename_args.rsp`).
After this patch, `/Fo` can be parsed and added to the final
command-line. Without this option, the make targets that are emitted are
made up from the input file name alone. We have some cases where the
same input in the project generates several output files, so we end up
with duplicate make targets in the scan-deps emitted dependency file.
|
|
(#89642)
For ASan, users already manually have to pass in the path to the lib,
and for other libraries they have to pass in the path to the libpath.
With LLVM's unreliable name of the lib (due to
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR confusion and whatnot), it's useful
to be able to opt in to just explicitly passing the paths to the libs
everywhere.
Follow-up of sorts to https://reviews.llvm.org/D65543, and to #87866.
|
|
This copies MSVC behavior, and avoids weird link errors in certain
cases.
|
|
The flag -fms-volatile has existed as a -cc1 flag for a while. It also
technically existed as a driver flag, but didn't do anything because it
wasn't wired up to anything in the driver.
This patch adds -fno-ms-volatile, and makes both -fms-volatile and
-fno-ms-volatile work the same way as the cl-mode flags. The defaults
are unchanged (default on for x86 in cl mode, default off otherwise).
|
|
This commit introduces support for the MSVC-specific C++11-style
attribute `[[msvc::constexpr]]`, which was introduced in MSVC 14.33.
The semantics of this attribute are enabled only under
MSVC compatibility (`-fms-compatibility-version`) 14.33 and higher.
Additionally, the default value of `_MSC_VER` has been raised to 1433.
The current implementation lacks support for:
- `[[msvc::constexpr]]` constructors (see #72149);
at the time of this implementation, such support would have required
an unreasonable number of changes in Clang.
- `[[msvc::constexpr]] return ::new` (constexpr placement new) from
non-std namespaces (see #74924).
Relevant to: #57696
|
|
The -g flag has been selecting whether to emit dwarf or codeview based
on the target ABI since 2018, so simply aliasing these flags does the
right thing for clang-cl.
This moves some code from Clang::ConstructJob to renderDebugOptions to
make things a little clearer now that we don't need to keep track of
whether we're doing codeview or not in multiple places, and also
combines the duplicate handling of the cl vs clang handling of jmc
flags as a result.
This is mostly NFC, but some -cc1 flags may be rendered in a slightly
different order because of the code that was moved around.
Differential Revision: https://reviews.llvm.org/D157794
|
|
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb10461d114783a1548201928549ace09755: add -nogpulib to some AMDGPU tests
* 9155e517e6e1cda474d0d0fa82f71696c325bc10: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5bbcca1364c2d4ae06127011eaba6389: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f0d1da8d8e421f4a628d7ec64d6e365: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
* ab68df505e5bb8808ee44f53044b50ca7575098e: add -resource-dir= and -fvisibility=hidden
to some -fsanitize=cfi tests
* d5ca1602f64114f612ad5630f04e4aa90591c78d: --rtlib=platform without --unwindlib= may fail if CLANG_DEFAULT_UNWINDLIB=unwindlib
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
|
|
This reverts commit 8c3550b1a78fde7bf28f420da8447d9fde37017f.
clang/test/Driver/fsanitize.c has a mysterious failure worth
investigation.
|
|
want the diagnostic
similar to 2a1edebdf1a887fdf01f039d60497626576c837b
|
|
the diagnostic
and remove a -### -fno-integrated-as test that would fail with --target=x86_64-windows-msvc.
|
|
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb10461d114783a1548201928549ace09755: add -nogpulib to some AMDGPU tests
* 9155e517e6e1cda474d0d0fa82f71696c325bc10: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5bbcca1364c2d4ae06127011eaba6389: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f0d1da8d8e421f4a628d7ec64d6e365: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
|
|
This reverts commit e39bf32b3bc2f0cc21d783ba789bd82553493875.
Some tests have different behaviors depent on whether certain directories/files are present on the host.
An incomplete list from https://lab.llvm.org/buildbot/#/builders/109/builds/70149
csky-toolchain.c
riscv*-toolchain.c
fuchsia.*
hip-*
ohos.c
|
|
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
|
|
Fixes unexpected warning.
Differential Revision: https://reviews.llvm.org/D150645
|
|
This reverts commit a4f366dcd85c440a611bbc82f1d24c2d9a735251.
Found a problem during backport it to 16.x branch.
https://github.com/llvm/llvm-project-release-prs/actions/runs/5036930270/jobs/9033427592?pr=451
The reason is `-implicit-check-not='warning'` may conflict with option
name, e.g., `-treat-scalable-fixed-error-as-warning`
|
|
Fixes unexpected warning.
Differential Revision: https://reviews.llvm.org/D150645
|
|
This reverts commit a4f366dcd85c440a611bbc82f1d24c2d9a735251.
Found a problem during backport it to 16.x branch.
https://github.com/llvm/llvm-project-release-prs/actions/runs/5036930270/jobs/9033427592?pr=451
The reason is `-implicit-check-not='warning'` may conflict with option
name, e.g., `-treat-scalable-fixed-error-as-warning`
|
|
Fixes unexpected warning.
Differential Revision: https://reviews.llvm.org/D150645
|
|
This reverts commit 3b6f7e45a20990fdbc2b43dc08457fc79d53bd39.
See comments on D150645.
|
|
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D150645
|
|
Now that we've updated to C++23, we need to add C++26/C++2c command line
flags, as discussed in
https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383
Differential Revision: https://reviews.llvm.org/D150450
|
|
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
|
|
|
|
There are currently two options that are used to tell the compiler to perform
unsafe floating-point optimizations:
'-ffast-math' and '-funsafe-math-optimizations'.
'-ffast-math' is enabled by default. It automatically enables the driver option
'-menable-unsafe-fp-math'.
Below is a table illustrating the special operations enabled automatically by
'-ffast-math', '-funsafe-math-optimizations' and '-menable-unsafe-fp-math'
respectively.
Special Operations -ffast-math -funsafe-math-optimizations -menable-unsafe-fp-math
MathErrno 0 1 1
FiniteMathOnly 1 0 0
AllowFPReassoc 1 1 1
NoSignedZero 1 1 1
AllowRecip 1 1 1
ApproxFunc 1 1 1
RoundingMath 0 0 0
UnsafeFPMath 1 0 1
FPContract fast on on
'-ffast-math' enables '-fno-math-errno', '-ffinite-math-only',
'-funsafe-math-optimzations' and sets 'FpContract' to 'fast'. The driver option
'-menable-unsafe-fp-math' enables the same special options than
'-funsafe-math-optimizations'. This is redundant.
We propose to remove the driver option '-menable-unsafe-fp-math' and use
instead, the setting of the special operations to set the function attribute
'unsafe-fp-math'. This attribute will be enabled only if those special
operations are enabled and if 'FPContract' is either 'fast' or set to the
default value.
Differential Revision: https://reviews.llvm.org/D135097
|
|
|
|
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D134788
|
|
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
GCC 12 has been released and contains unconditional support for
-ftrivial-auto-var-init=zero:
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
Maintain compatibility with GCC, and remove the -enable flag for "zero"
mode. The flag is left to generate an "unused" warning, though, to not
break all the existing users. The flag will be fully removed in Clang 17.
Link: https://github.com/llvm/llvm-project/issues/44842
Reviewed By: nickdesaulniers, MaskRay, srhines, xbolva00
Differential Revision: https://reviews.llvm.org/D125142
|
|
Based on a patch by Arlo Siemsen (D98438)!
Differential Revision: https://reviews.llvm.org/D134544
|
|
They were mapped as follows:
- /fp:except to --ftrapping-math
- /fp:except- to --fno-trapping-math
- /fp:strict to --fno-fast-math
- /fp:precise to --fno-fast-math
Let's map them as follows:
- /fp:except to --ffp-exception-behavior=strict
- /fp:except- to --ffp-exception-behavior=ignore
- /fp:strict to --ffp-model=strict
- /fp:precise to --ffp-model=ignore
I believe the changes to /fp:except are technically a no-op but it makes
the mapping a lot clearer. The changes for /fp:strict and /fp:precise are not
no-ops, they now match MSVC's behavior.
While we are here, also add support for /fp:contract by mapping it to
-ffp-contract=on.
|
