Account for backslashes in paths in mingw.cpp.
Testing clang with the <triple>-clang form seems to require the
x86 target to be enabled, when the triple is an x86 triple. Just
skip that aspect of the test, since the "clang --target=<triple>"
form should give enough test coverage here.
There's some variation in where different toolchain distributions
(and linux distributions) package the mingw sysroots - this is
so far handled by adding specific known subdirectory paths
to the include and lib directory lists.
There are multiple degrees of combinatorics involved here though;
the distros may use different locations such as
/usr/x86_64-w64-mingw32/include or
/usr/x86_64-w64-mingw32/sys-root/mingw/include.
So far, this setup has been treated as base=/usr, subdir=x86_64-w64-mingw32,
and the driver tries to add further subdirectories such as
<base>/<subdir>/include, <base>/<subdir>/sys-root/mingw/include.
When it comes to libstdc++ (and libc++), each of these come with
a large number of potential subdirectories. Instead of further
exploding the combinatorics another step by adding all combinations
of all paths, check whether <base>/<subdir>/sys-root/mingw/include
exists, and if it does, append that subpath into the subdir variable.
This allows finding libstdc++ headers in e.g.
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/x86_64-w64-mingw32
on Fedora.
The same logic (where everything belonging to this target fits
under one expanded <subdir> path, with just /include and /lib
under it) doesn't seem to apply on Gentoo, where the includes
are found in <base>/<subdir>/usr/include while the libraries
are in <base>/<subdir>/mingw/lib (see
8e218026f8). But apparently
the libstdc++ headers aren't installed under
<base>/<subdir>/usr/include, so that path hierarchy quirk doesn't
need to be taken into account in AddClangCXXStdlibIncludeArgs.
Differential Revision: https://reviews.llvm.org/D138693
There are three functions that try to detect the right implicit
sysroot and libgcc directory setup to use
- One which looks for mingw sysroots located in
<clangbin>/../<sysrootname>
- One which looks for a mingw-targeting gcc executables in the PATH
- One which looks in the <gccroot>/lib/gcc directory to find the
right one to use, and the right specific triple used for arch
specific directories in the gcc/libstdc++ install
These have mostly tried to look for executables named
"<arch>-w64-mingw32-gcc" or "mingw32-gcc" or subdirectories
named "<arch>-w64-mingw32" or "mingw32".
In the case of findClangRelativeSysroot, it also has looked
for directories with the name of the actual triple. This
was added in deff753627,
with the intent of looking for a directory matching exactly
the user provided literal triple - however the triple here
is the normalized one, not the one provided by the user on
the command line.
Improve and unify this logic somewhat:
- Always first look for things based on the literal triple
provided by the user.
- Secondly look for things based on the normalized triple
(which usually ends up as e.g. x86_64-w64-windows-gnu),
accessed via the Triple which is passed to the constructor
- Then look for the common triple form <arch>-w64-mingw32
The literal triple provided by the user is available via
Driver::getTargetTriple(), but computeTargetTriple() may
change e.g. the architecture of it, so we need to
reapply the effective architecture on the literal triple
spelling from Driver::getTargetTriple().
Do this consistently for all of findGcc, findClangRelativeSysroot
and findGccLibDir (while keeping the existing plain "mingw32"
cases in findGcc and findGccLibDir too).
Fedora 37 started shipping mingw sysroots targeting UCRT,
in addition to the traditional msvcrt.dll, and these use
triples in the form <arch>-w64-mingw32ucrt - see
https://fedoraproject.org/wiki/Changes/F37MingwUCRT.
Thus, in addition to the existing default tested triples,
try looking for triples in the form <arch>-w64-mingw32ucrt,
to automatically find the UCRT sysroots on Fedora 37.
By explicitly setting a specific target on the Clang command
line, the user can be more explicit with which flavour is
to be preferred.
This should fix the main issue in
https://github.com/llvm/llvm-project/issues/59001.
Differential Revision: https://reviews.llvm.org/D138692
This patch moves the outlined function registration, function attribute
configuration and function ID creation to the OpenMPIRBuilder. This will later
be used by flag as well.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D137587
When late parsed templates are used with PCH tokens are serialized. The
existing code does not handle annotation tokens which can occur due to
various pragmas.
This patch implements the serialization for annot_pragma_loop_hint.
This also enables use of OpenMP pragmas and #pragma unused which do not
need special serialization of the PtrData field.
Fixes https://github.com/llvm/llvm-project/issues/39504
Differential Revision: https://reviews.llvm.org/D138453
"win32" is never defined as a lit feature, AFAICT, and Windows bots
appear to be running this just fine.
Part of the project to eliminate special handling for triples in lit expressions.
This reverts commit a1255dc467.
This patch results in:
llvm/lib/CodeGen/SanitizerBinaryMetadata.cpp:57:17: error: no member
named 'size' in 'llvm::MDTuple'
This was assuming a direct reference to the global variable. The
constant string is placed in addrspace 4, and has a constexpr
addrspacecast to the generic address space.
Currently per-function metadata consists of:
(start-pc, size, features)
This adds a new UAR feature and if it's set an additional element:
(start-pc, size, features, stack-args-size)
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D136078
Summary:
The linker wrapper uses this metadata to determine which registration
code to emit, e.g. CUDA, HIP or OpenMP. If we encounter an OFK_None we
should just ignore it.
On AIX, profiled system libraries are stored at `/lib/profiled` and
`/usr/lib/profiled`. When compiling with `-pg`, we want to link against
libraries in those directories. This PR modifies the AIX toolchain to
add those directories to the linker search paths.
Differential Review: https://reviews.llvm.org/D137375
A follow-up to D136133. It was mentioned in #58382 that there is a need
to test for DRs that have not been officially resolved yet. This patch
aims to replace original "hackery" with proper handling for such cases.
Highlights:
- Availability can be suffixed (further) with "open", "drafting", or
"review", e.g. // dr2565: 16 open, // drXXXX: 16 c++17 drafting
- Checks are implemented to ensure that this suffix corresponds to
actual issue status
- Non-resolved DRs are counted (stdout of make_cxx_dr_status)
- No changes made to cxx_dr_status.html
- 'c++20' availability suffix added
- Remove 'concurrency' status since it's no longer
on the list of statuses in CWG Active Issues
Differential Revision: https://reviews.llvm.org/D138901
A follow-up to D138852. Apparently cxx_dr_status.html was changed
manually there, since make_cxx_dr_status script doesn't generate the
same HTML after that patch landed.
Differential Revision: https://reviews.llvm.org/D138895
This extension only adds builtin functions and thus doesn't need to be
included as an extension. Instead of a pragma, the builtin functions
of the extension can be exposed through enabling preprocessor defines.
When generating __clang_call_terminate use SetLLVMFunctionAttributes
to set the default function attributes, like we do for all the other
functions generated by clang. This fixes a problem where target
features from the command line weren't being applied to this function.
Differential Revision: https://reviews.llvm.org/D138679
As noticed in GH58962, we should only diagnose illegal overloads of member functions
when the ref qualifiers don't match if the trailing constraints are the same.
The fix is to move the existing constraints check earlier in Sema::IsOverload.
Closes https://github.com/llvm/llvm-project/issues/58962
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D138749
The zero-as-null-pointer-constant check should not fire if it is inside
a defaulted function, e.g. defaulted spaceship operators.
Add C++20 tests with spaceship operators.
Fixes#50221
Differential Revision: https://reviews.llvm.org/D138727
After accepted in Kona, update the code to accept static operator[] as well.
No big code changes: accept this operator as static in SemaDeclCXX, update AST call generation in SemaOverload and update feature macros + tests accordingly.
Reviewed By: cor3ntin, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D138387
Enable frame pointer optimization by default to match it with other targets.
This brings a small reduction in generated binary sizes.
Fixes bug #48327
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D138532
CWG2635 prohibits adding a constraint to a structured as a defect
report. This patch implements that restriction.
Differential Revision: https://reviews.llvm.org/D138852
Before the fix the scanning would fail with
`-Werror,-Wnon-modular-include-in-module` despite the warning being
suppressed in the source code.
Existing approach with `-Wno-error` is not sufficient because it negates
only general `-Werror` but not specific `-Werror=...` and some warnings
can still emitted as errors. Make the approach stricter by using `-w`
flag and ignore all warnings, including those upgraded to errors. This
approach is still valid as it doesn't affect the dependencies.
rdar://101588531
Differential Revision: https://reviews.llvm.org/D138252
This implement the C++23 paper P2647R1 (adopted in Kona)
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D138851
Over the years there's been many builtin types added without
corresponding USRs. Add a `@BT@<name>` USR for all these types. Also add
a comment so that hopefully this doesn't continue happening.
`MSGuid` was also missing a USR, use `@MG@GUID{<uuid>}` for it.
Resolves rdar://102198268.
Differential Revision: https://reviews.llvm.org/D138322
The OpenMP offloading toolchain uses wrapper headers to implement some
standard features on the GPU. Currently there is no way to turn these
off without also disabling all the standard includes altogether. This
patch makes `-nogpuinc` apply to these wrapper headers so we can use a
sterile toolchain. This was causing problems when attempting to compile
a `libc` for the GPU using OpenMP.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D138598
Based on include-cleaner's version, but:
- remove assert that can fail for input `/\<newline>* */`
- assert was also checking the wrong condition: that the prefix *differed* from
either `//` or from `/*`. Avoid use of strncmp where we can.
- add a comment that the brittleness of the text matching is intentional
Differential Revision: https://reviews.llvm.org/D138780
This reverts commit 1dc0a1e5d2.
Failures were caused by unintentional conversion to native slashes by
remove_dots, so undo that: we always suggest posix slashes for includes.
This could potentially be a change in behavior on windows if people were
spelling headers with backslashes and headermaps contained backslashes,
but that's all underspecified and I don't think anyone uses headermaps
on windows.
Differential Revision: https://reviews.llvm.org/D138709
This was triggered by some code in picolibc. The minimal version looks
like this:
double infinity(void) {
return 5;
}
extern long double infinityl() __attribute__((__alias__("infinity")));
These two declarations have a different type (not because of the 'long
double', which is also 'double' in IR, but because infinityl has
variadic parameters). This led to a crash in the bitcast which assumed
address space 0.
Differential Revision: https://reviews.llvm.org/D138681
This is a recommit of cf624b23bc,
which was reverted in 5cfc22cafe,
because the cut-off on the number of vector elements was not low enough,
and it triggered both SDAG SDNode operand number assertions,
and caused compile time explosions in some cases.
Let's try with something really *REALLY* conservative first,
just to get somewhere, and try to bump it (to 64/128) later.
FIXME: should this respect TTI reg width * num vec regs?
Original commit message:
Now, there's a big caveat here - these bytes
are abstract bytes, not the i8 we have in LLVM,
so strictly speaking this is not exactly legal,
see e.g. https://github.com/AliveToolkit/alive2/issues/860
^ the "bytes" "could" have been a pointer,
and loading it as an integer inserts an implicit ptrtoint.
But at the same time,
InstCombine's `InstCombinerImpl::SimplifyAnyMemTransfer()`
would expand a memtransfer of 1/2/4/8 bytes
into integer-typed load+store,
so this isn't exactly a new problem.
Note that in memory, poison is byte-wise,
so we really can't widen elements,
but SROA seems to be inconsistent here.
Fixes#59116.
Arbitrary lookahead restricts the implementation of our TokenSource,
specifically getting in the way of changes to handle macros better.
Instead, use getNextToken to parse lookahead linearly, and
getPosition/setPosition to unwind our lookahead.
Add a version to non-LLVM cmake package so that users needing an exact
version match can use the version parameter to find_package. Also adjust
the find_package(LLVM) to use an exact version match as well.
Reviewed By: arsenm, stellaraccident, mceier
Differential Revision: https://reviews.llvm.org/D138274
This patch implements assembly support for the 2022 A-Profile Architecture
extension FEAT_LRCPC3. FEAT_LRCPC3 is AArch64 only and introduces new
variants of load/store instructions with release consistency ordering.
Specs for individual instructions can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/
This feature is optionally available from v8.2a and therefore not enabled by
default.
Contributors:
Lucas Prates
Sam Elliot
Son Tuan Vu
Tomas Matheson
Differential Revision: https://reviews.llvm.org/D138579
Move print functions to start of UnwarppedLineParser so they can be
used from everywhere in the file.
Pull out function that doesn't hard-code the stream.
The unused variable fix also remove the test output of the tokens
that do not match, making debugging tests harder. Undo the semantic
changes of the build fix.
This used to be required, but the difference between asserts/!asserts
builds no longer exists for %clang_cc1 (only for %clang), so they pass
just fine without this flag.
Since D60873 we remove dotdots from the search path entries, but not the
filenames we're matching against, so do the latter too.
Since this also removes (single) dots, drop the logic to skip over them.
(Some of this was already dead, some is newly dead).
See D138676 for motivation.
Differential Revision: https://reviews.llvm.org/D138677
By default, clang assumes that all trailing array objects could be a
FAM. So, an array of undefined size, size 0, size 1, or even size 42 is
considered as FAMs for optimizations at least.
One needs to override the default behavior by supplying the
`-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of
FAM candidates. Value `3` is the most restrictive and `0` is the most
permissive on this scale.
0: all trailing arrays are FAMs
1: only incomplete, zero and one-element arrays are FAMs
2: only incomplete, zero-element arrays are FAMs
3: only incomplete arrays are FAMs
If the user is happy with consdering single-element arrays as FAMs, they
just need to remove the
`consider-single-element-arrays-as-flexible-array-members` from the
command line.
Otherwise, if they don't want to recognize such cases as FAMs, they
should specify `-fstrict-flex-arrays` anyway, which will be picked up by
CSA.
Any use of the deprecated analyzer-config value will trigger a warning
explaining what to use instead.
The `-analyzer-config-help` is updated accordingly.
Depends on D138657
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D138659
According to my measurement in https://reviews.llvm.org/D108230#3933232,
it seems like there is no drawback to enabling this analyzer-config by default.
Actually, enabling this by default would make it consistent with the
codegen of clang, which according to `-fstrict-flex-arrays`, assumes
by default that all trailing arrays could be FAMs, let them be of size
undefined, zero, one, or anything else.
Speaking of `-fstrict-flex-arrays`, in the next patch I'll deprecate
the analyzer-config FAM option in favor of that flag. That way, CSA will
always be in sync with what the codegen will think of FAMs.
So, if a new codebase sets `-fstrict-flex-arrays` to some value above 0,
CSA will also make sure that only arrays of the right size will be
considered as FAMs.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D138657
Incorrect `isOverriding` flag triggers the assertion
`!Overridden.empty()` in `ObjCMethodDecl::getOverriddenMethods` when a
method is marked as overriding but we cannot find any overrides.
When a method is declared in a category and defined in implementation,
we don't treat it as an override because it is the same method with
a separate declaration and a definition. But with modules we can find
a method declaration both in a modular category and a non-modular category
with different memory addresses. Thus we erroneously conclude the method
is overriding. Fix by comparing canonical declarations that are the same
for equal entities coming from different modules.
rdar://92845511
Differential Revision: https://reviews.llvm.org/D138630
This change moves the getName function from clang and moves the separator class
members from CGOpenMPRuntime into OMPIRBuilder. Also enusre all the getters
in the config class are const.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D137725
Adds support for NamespaceDecl to inform if its part of a nested namespace.
This flag only corresponds to the inner namespaces in a nested namespace declaration.
In this example:
namespace <X>::<Y>::<Z> {}
Only <Y> and <Z> will be classified as nested.
This flag isn't meant for assisting in building the AST, more for static analysis and refactorings.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D90568
Initialisation Guard Variables should take their DLL storage class
from the guarded variable. Otherwise, there will be a link error if
the compiler inlines a reference to the guard variable into another
module but that guard variable is not exported from the defining
module.
This is required for platforms such as PlayStation and
windows-itanium, that are aiming for source compatibility with MSVC
w.r.t. dllimport/export annotations, given Clang's existing design
which allows for inlining of a dllimport function as long as all the
variables/functions referenced are also marked dllimport.
A similar change exists for the MSVC ABI:
https://reviews.llvm.org/D4136.
I have added a run test for windows-itanium for this issue to the
build recipe: https://reviews.llvm.org/D88124.
Differential Revision: https://reviews.llvm.org/D138463
This patch replaces those occurrences of NoneType that would trigger
an error if the definition of NoneType were missing in None.h.
To keep this patch focused, I am deliberately not replacing None with
std::nullopt in this patch or updating comments. They will be
addressed in subsequent patches.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Differential Revision: https://reviews.llvm.org/D138539
This patch add the instructions of Zcd extension.
Zcd is a subset of C Ext which include the double-precision floating-point instructions (c.fld, c.fldsp, c.fsd, c.fsdsp).
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D134177
Extend SM_SLOC_BUFFER_BLOB_COMPRESSED to allow zstd, which is much faster
(compression/decompression) than zlib with a similar compression ratio.
An alternative is to add a value beside SM_SLOC_BUFFER_BLOB_COMPRESSED, but
reusing SM_SLOC_BUFFER_BLOB_COMPRESSED slightly simplifies the implementation
and leads to better diagnostics when a slightly older Clang consumes zstd
compressed blob.
Compressing AST takes a small portion of WriteAST, so we can pick a higher
compression level.
Compiling a relatively large .pcm (absl endian) with -fmodules-embed-all-files,
zstd level 9 has comparable performance with zlib-chromium level 6 (default),
but provides smaller output (5809156 => 5796016). Higher zstd levels will make
"Compress AST" notably slower and do not provide significant more size saving.
```
2.219345 Total ExecuteCompiler
0.746799 Total Frontend
0.736862 Total Source
0.339434 Total ReadAST
0.165452 Total WriteAST
0.043045 Total Compress AST
0.008236 Total ParseClass
0.00633 Total InstantiateClass
0.001887 Total isPotentialConstantExpr
0.001808 Total InstantiateFunction
0.001535 Total EvaluateForOverflow
0.000986 Total EvaluateAsRValue
0.000536 Total EvaluateAsBooleanCondition
0.000308 Total EvaluateAsConstantExpr
0.000156 Total EvaluateAsInt
3.4e-05 Total EvaluateKnownConstInt
8e-06 Total EvaluateAsInitializer
0 Total PerformPendingInstantiations
```
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D137885
It's more likely the user needs a const cast, but probably not sure
enough that we should suggest that either - so err on the side of
caution and offer no suggestion.
Fixes pr58958
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D138426
It broke the build, see comments on code review.
> Leaves the implementation and tests files in-place for right now, but
> deletes the ability to build the old sanitizer-common based scudo. This
> has been on life-support for a long time, and the newer scudo_standalone
> is much better supported and maintained.
>
> Also patches up some GWP-ASan wording, primarily related to the fact
> that -fsanitize=scudo now is scudo_standalone, and therefore the way to
> reference the GWP-ASan options through the environment variable has
> changed.
>
> Future follow-up patches will delete the original scudo, and migrate all
> its tests over to be part of the scudo_standalone test suite.
>
> Reviewed By: vitalybuka
>
> Differential Revision: https://reviews.llvm.org/D138157
This reverts commit ab1a5991fe.
Casting a pointer to a suitably large integral type by reinterpret-cast
should result in the same value as by using the `__builtin_bit_cast()`.
The compiler exploits this: https://godbolt.org/z/zMP3sG683
However, the analyzer does not bind the same symbolic value to these
expressions, resulting in weird situations, such as failing equality
checks and even results in crashes: https://godbolt.org/z/oeMP7cj8q
Previously, in the `RegionStoreManager::getBinding()` even if `T` was
non-null, we replaced it with `TVR->getValueType()` in case the `MR` was
`TypedValueRegion`.
It doesn't make much sense to auto-detect the type if the type is
already given. By not doing the auto-detection, we would just do the
right thing and perform the load by that type.
This means that we will cast the value to that type.
So, in this patch, I'm proposing to do auto-detection only if the type
was null.
Here is a snippet of code, annotated by the previous and new dump values.
`LocAsInteger` should wrap the `SymRegion`, since we want to load the
address as if it was an integer.
In none of the following cases should type auto-detection be triggered,
hence we should eventually reach an `evalCast()` to lazily cast the loaded
value into that type.
```lang=C++
void LValueToRValueBitCast_dumps(void *p, char (*array)[8]) {
clang_analyzer_dump(p); // remained: &SymRegion{reg_$0<void * p>}
clang_analyzer_dump(array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>}
clang_analyzer_dump((unsigned long)p);
// remained: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}}
clang_analyzer_dump(__builtin_bit_cast(unsigned long, p)); <--------- change #1
// previously: {{&SymRegion{reg_$0<void * p>}}}
// now: {{&SymRegion{reg_$0<void * p>} [as 64 bit integer]}}
clang_analyzer_dump((unsigned long)array); // remained: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}}
clang_analyzer_dump(__builtin_bit_cast(unsigned long, array)); <--------- change #2
// previously: {{&SymRegion{reg_$1<char (*)[8] array>}}}
// now: {{&SymRegion{reg_$1<char (*)[8] array>} [as 64 bit integer]}}
}
```
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D136603
Introduce a RVVTypeCache to hold the cache instead of using a local
static variable to maintain a cache.
Also made construct of RVVType to private, make sure that could be only
created by a cache manager.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D138429
This patch add the instructions of Zcf extension.
Zcf is a subset of C Ext which include the single-precision floating-point instructions.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D134176
GCC only defines `__ppc64__` for darwin while the darwin support has been
removed from llvm-project. The existence of `__ppc64__` makes some software
think we are compiling for big-endian PowerPC Mac; also it lures users to write
code which is not portable to GCC.
It is straightforward if a distro wants to keep the macro: add
`-D__ppc64__=1` to a Clang configuration file.
Reviewed By: thesamesam, nemanjai
Differential Revision: https://reviews.llvm.org/D137511
These macros are defined in avr-gcc and are useful when working with
assembly. For example, startup code needs to copy the contents of .data
from flash to RAM, but should use elpm (instead of lpm) on devices with
more than 64kB flash. Without __AVR_HAVE_ELPM__, there is no way to know
whether the elpm instruction is supported.
This partially fixes https://github.com/llvm/llvm-project/issues/56157.
Differential Revision: https://reviews.llvm.org/D137572
Now, there's a big caveat here - these bytes
are abstract bytes, not the i8 we have in LLVM,
so strictly speaking this is not exactly legal,
see e.g. https://github.com/AliveToolkit/alive2/issues/860
^ the "bytes" "could" have been a pointer,
and loading it as an integer inserts an implicit ptrtoint.
But at the same time,
InstCombine's `InstCombinerImpl::SimplifyAnyMemTransfer()`
would expand a memtransfer of 1/2/4/8 bytes
into integer-typed load+store,
so this isn't exactly a new problem.
Note that in memory, poison is byte-wise,
so we really can't widen elements,
but SROA seems to be inconsistent here.
Fixes#59116.
The KCFI sanitizer emits "kcfi" operand bundles to indirect
call instructions, which the LLVM back-end lowers into an
architecture-specific type check with a known machine instruction
sequence. Currently, KCFI operand bundle lowering is supported only
on 64-bit X86 and AArch64 architectures.
As a lightweight forward-edge CFI implementation that doesn't
require LTO is also useful for non-Linux low-level targets on
other machine architectures, add a generic KCFI operand bundle
lowering pass that's only used when back-end lowering support is not
available and allows -fsanitize=kcfi to be enabled in Clang on all
architectures.
This relands commit eb2a57ebc7 with
fixes.
Reviewed By: nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D135411
Breaks build of LLVMgold here:
```
/repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1108:19: error: no matching function for call to 'localCache'
Cache = check(localCache("ThinLTO", "Thin", options::cache_dir, AddBuffer));
^~~~~~~~~~
/repositories/llvm-project/llvm/include/llvm/Support/Caching.h:72:21: note: candidate function not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1102:20)' to 'llvm::AddBufferFn' (aka 'function<void (unsigned int, const llvm::Twine &, std::unique_ptr<MemoryBuffer>)>') for 4th argument
Expected<FileCache> localCache(
^
/repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1110:18: error: no viable conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'llvm::AddStreamFn' (aka 'function<Expected<std::unique_ptr<CachedFileStream>> (unsigned int, const llvm::Twine &)>')
check(Lto->run(AddStream, Cache));
^~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:375:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::nullptr_t' for 1st argument
function(nullptr_t) noexcept
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:386:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'const std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream>> (unsigned int, const llvm::Twine &)> &' for 1st argument
function(const function& __x)
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:404:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream>> (unsigned int, const llvm::Twine &)> &&' for 1st argument
function(function&& __x) noexcept
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:435:2: note: candidate template ignored: requirement '_Callable<(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &, (lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20), std::__invoke_result<(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &, unsigned int, const llvm::Twine &>>::value' was not satisfied [with _Functor = (lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &]
function(_Functor&& __f)
^
/repositories/llvm-project/llvm/include/llvm/LTO/LTO.h:278:25: note: passing argument to parameter 'AddStream' here
Error run(AddStreamFn AddStream, FileCache Cache = nullptr);
^
```
This reverts commit 387620aa8c.
Leaves the implementation and tests files in-place for right now, but
deletes the ability to build the old sanitizer-common based scudo. This
has been on life-support for a long time, and the newer scudo_standalone
is much better supported and maintained.
Also patches up some GWP-ASan wording, primarily related to the fact
that -fsanitize=scudo now is scudo_standalone, and therefore the way to
reference the GWP-ASan options through the environment variable has
changed.
Future follow-up patches will delete the original scudo, and migrate all
its tests over to be part of the scudo_standalone test suite.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D138157
This reverts commit 01023bfcd3. The extended test now triggers undefined behavior:
```
/b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp:577:41: runtime error: load of value 180, which is not a valid value for type 'bool'
#0 0xaaaae3333a30 in hasCFGChanged /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp:577:41
#1 0xaaaae3333a30 in llvm::ObjCARCOptPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp:2494:26
...
```
Currently the lto native object files have names like main.exe.lto.1.obj. In
PDB, those names are used as names for each compiland. Microsoft’s tool
SizeBench uses those names to present to users the size of each object files.
So, names like main.exe.lto.1.obj is not user friendly.
This patch makes the lto native object file names more readable by using
the bitcode file names as part of the file names. For example, if the input
bitcode file has path like "path/to/foo.obj", its corresponding lto native
object file path would be "path/to/main.exe.lto.foo.obj". Since the lto native
object file name only bothers PDB, this patch only changes the lld-linker's
behavior.
Reviewed By: tejohnson, MaskRay, #lld-macho
Differential Revision: https://reviews.llvm.org/D137217
The current header testing is pretty thin. This is in
preparation for a series of patches to replace many
builtin implementations.
I did try to stress everything in this header, but skipped
a few things. Mostly I didn't understand why we have
various language version checks which skip defining some
things. It doesn't seem right to have any of these if guards
on __cplusplus, __HIPCC_RTC__, and __OPENMP_AMDGCN__.
* Adds API support for widening of lattice elements and environments,
* Updates the algorithm to apply widening where appropriate,
* Implements widening for boolean values. In the process, moves the unsoundness
of comparison from the default implementation of
`Environment::ValueModel::compare` to model-specific handling inside
`DataflowEnvironment::equivalentTo`. This change is intended to clarify
the source and location of unsoundess.
This patch is a replacement for, and was based substantially on, https://reviews.llvm.org/D131645.
Differential Revision: https://reviews.llvm.org/D137948
When -fgpu-rdc is used for linking relocatable objects, clang driver launches
clang-offload-bundler to extract a device relocatable object from each input
relocatable object file and passes the extracted files to lld. The input relocatable
object file could either come from HIP program or C++ program. The relocatable
object file from C++ program does not contain device relocatable objects, therefore
clang-offload-bundler extracts an empty file and passes it to lld. lld treates
empty file as linker script. When there is no object input file to lld, lld
will emit error:
target emulation unknown: -m or at least one .o file required
This patch adds "elf64_amdgpu" to lld so that lld always know the target
no matter whether there are object input files or not.
Reviewed by: Artem Belevich, Fangrui Song
Differential Revision: https://reviews.llvm.org/D138221
This patch introudces the OpenMPIRBuilderConfig class which contains various
flags that are needed to lower OMP constructs to LLVM-IR. The purpose is to
keep the flags in one place so they do not have to be passed in every time.
The flags can be set optionally since some uses cases don't rely on functions
that depend on these flags.
Reviewed By: jdoerfert, tschuett
Differential Revision: https://reviews.llvm.org/D138220
This patch implements the 2022 Architecture General Data-Processing Instructions
They include:
Common Short Sequence Compression (CSSC) instructions
- scalar comparison instructions
SMAX, SMIN, UMAX, UMIN (32/64 bits) with or without immediate
- ABS (absolute), CNT (count non-zero bits), CTZ (count trailing zeroes)
- command-line options for CSSC
Associated with these instructions in the documentation is the Range Prefetch
Memory (RPRFM) instruction, which signals to the memory system that data memory
accesses from a specified range of addresses are likely to occur in the near
future. The instruction lies in hint space, and is made unconditional.
Specs for the individual instructions can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/
contributors to this patch:
- Cullen Rhodes
- Son Tuan Vu
- Mark Murray
- Tomas Matheson
- Sam Elliott
- Ties Stuij
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D138488
Pushing the `CatchRetScope` early causes cleanups for catch parameters to be emitted in the basic block of the catch handler instead of the `catchret.dest` block. This is important because the latter is not part of the catchpad and this caused code truncations due to ARC PreISel intrinsics in WinEHPrepare.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D137939
Add missing dependency for loongarch-resource-headers. This patch refers to D126892 to repair same error.
Differential Revision: https://reviews.llvm.org/D138403
`-fapprox-func` should be disabled by `-fp-model={strict|precise}`,
as well as other fast-math flags. See the last changes in
`clang/test/Driver/fp-model.c`.
Probably this route (`case options::OPT_ffp_model_EQ`) was forgot
to update in D106191 and D114564. There is no appropriate reason not
to disable the flag.
This commit also updates other regression tests, which are not directly
related to this bug, for consistency with other fast-math flags.
Differential Revision: https://reviews.llvm.org/D138109
This patch replaces:
return Optional<T>();
with:
return None;
to make the migration from llvm::Optional to std::optional easier.
Specifically, I can deprecate None (in my source tree, that is) to
identify all the instances of None that should be replaced with
std::nullopt.
Note that "return None" far outnumbers "return Optional<T>();". There
are more than 2000 instances of "return None" in our source tree.
All of the instances in this patch come from functions that return
Optional<T> except Archive::findSym and ASTNodeImporter::import, where
we return Expected<Optional<T>>. Note that we can construct
Expected<Optional<T>> from any parameter convertible to Optional<T>,
which None certainly is.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Differential Revision: https://reviews.llvm.org/D138464
Sphinx has the `option` directive. Most option descriptions
in `clang/docs/UsersManual.rst` used it but some didn't.
This commit changes the remaining option descriptions to use
the `option` directive. This makes a consistent view in HTML.
The `option` directive automatically creates a cross-reference target.
So labeling by `.. _opt_XXX:` is almost unnecessary. However, options
with and without `no-` (e.g. `-fno-show-column`/`-fshow-column`)
cannot be distinguish for the cross-reference. So some required
`.. _opt_XXX:` directives are kept unremoved.
Differential Revision: https://reviews.llvm.org/D138088
We would previously reject valid input where GNU attributes preceded the
standard attributes on top-level declarations. A previous attribute
handling change had begun rejecting this whilst GCC does honour this
layout. In practice, this breaks use of `extern "C"` attributed
functions which use both standard and GNU attributes as experienced by
the Swift runtime.
Objective-C deserves an honourable mention for requiring some additional
special casing. Because attributes on declarations and definitions
differ in semantics, we need to replicate some of the logic for
detecting attributes to declarations to which they appertain cannot be
attributed. This should match the existing case for the application of
GNU attributes to interfaces, protocols, and implementations.
Take the opportunity to split out the tooling tests into two cases: ones
which process macros and ones which do not.
Special thanks to Aaron Ballman for the many hints and extensive rubber
ducking that was involved in identifying the various places where we
accidentally dropped attributes.
Differential Revision: https://reviews.llvm.org/D137979Fixes: #58229
Reviewed By: aaron.ballman, arphaman
The vim Formatonsave integration is not working if we create a new file directly using vim.
eg: vi -V9t.log t.cpp
It will not able to format the buffer.
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> File "...clang/tools/clang-format/clang-format.py", line 156, in <module>
> main()
> File "...clang/tools/clang-format/clang-format.py", line 80, in main
> with open(vim.current.buffer.name, 'r') as f:
> FileNotFoundError: [Errno 2] No such file or directory: '...t.cpp'
This patch check the file before we try to open it.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D138234
Clang's lit.cfg.py reads this to add an "enable-shared" feature that
three of clang's lit tests use. Nothing else reads enable_shared, so
remove it from most lit.site.cfg.py.in files.
Differential Revision: https://reviews.llvm.org/D138301
The [Improving Clang's Diagnostics RFC][1] identifies eight broad fields
for Clang to surface, two of which are text-based. Since the current
diagnostics more closely map to the diagnostic summary (or headline), we
should rename them to ensure that there's no confusion when
Diagnostic.Reason is introduced in the near future.
[1]: https://discourse.llvm.org/t/rfc-improving-clang-s-diagnostics/62584
Reviewed By: aaron.ballman, erichkeane
Differential Revision: https://reviews.llvm.org/D135820
Add a version to non-LLVM cmake package so that users needing an exact
version match can use the version parameter to find_package. Also adjust
the find_package(LLVM) to use an exact version match as well.
Reviewed By: arsenm, stellaraccident
Differential Revision: https://reviews.llvm.org/D138274
This patch replaces NoneType() and NoneType::None with None in
preparation for migration from llvm::Optional to std::optional.
In the std::optional world, we are not guranteed to be able to
default-construct std::nullopt_t or peek what's inside it, so neither
NoneType() nor NoneType::None has a corresponding expression in the
std::optional world.
Once we consistently use None, we should even be able to replace the
contents of llvm/include/llvm/ADT/None.h with something like:
using NoneType = std::nullopt_t;
inline constexpr std::nullopt_t None = std::nullopt;
to ease the migration from llvm::Optional to std::optional.
Differential Revision: https://reviews.llvm.org/D138376
Previously, we used SHA-1 for hashing the CodeView type records.
SHA-1 in `GloballyHashedType::hashType()` is coming top in the profiles. By simply replacing with BLAKE3, the link time is reduced in our case from 15 sec to 13 sec. I am only using MSVC .OBJs in this case. As a reference, the resulting .PDB is approx 2.1GiB and .EXE is approx 250MiB.
Differential Revision: https://reviews.llvm.org/D137101
Clang language-level address spaces and LLVM pointer address spaces are
not the same thing (even though they will both have a numeric value of
zero in many cases). LangAS is a enum class to avoid implicit conversions,
but eba69b59d1 avoided the compiler error by
adding a `static_cast<>`. While touching this code, simplify it by using
CreatePointerBitCastOrAddrSpaceCast() which is already a no-op if the types
match.
This changes the code generation for spir64 to place the globals in
the sycl_global addreds space, which maps to `addrspace(1)`.
Reviewed By: bader
Differential Revision: https://reviews.llvm.org/D138284
This patch gives basic parsing and semantic analysis support for 'strict'
modifier with 'num_tasks' clause of 'taskloop' construct introduced in
OpenMP 5.1 (section 2.12.2)
Differential Revision: https://reviews.llvm.org/D138328
Checks for builtins for the following instructions were aded:
V6_v6mpyhubs10
V6_v6mpyhubs10_vxx
V6_v6mpyvubs10
V6_v6mpyvubs10_vxx
V6_vlutvvbi
V6_vlutvvb_oracci
V6_vlutvwhi
V6_vlutvwh_oracci
Summary:
AIX library functions frexpl(), ldexpl(), and modfl() are for 128-bit IBM long double, i.e. __ibm128. Other *l() functions, e.g., acosl(), are for 64-bit long double. The AIX Clang compiler currently maps builtin functions __builtin_frexpl(), __builtin_ldexpl(), and __builtin_modfl() to frexpl(), ldexpl(), and modfl() in 64-bit long double mode which results in seg-faults or incorrect return values. This patch changes to map __builtin_frexpl(), __builtin_ldexpl(), and __builtin_modfl() to double version lib functions frexp(), ldexp() and modf() in 64-bit long double mode.
Reviewed by: hubert.reinterpretcast, daltenty
Differential Revision: https://reviews.llvm.org/D137986
This matches OpenBSD, and it supports Swift's use of clang for its C interop
functionality. Recent changes to Swift use AddClangSystemIncludeArgs() to
inspect the cc1 args; this doesn't work for platforms where cc1 adds standard
include paths implicitly. See:
<cf3354222d>
Also clean up InitHeaderSearch, making it clearer which targets manage header
search paths in the driver.
Differential Revision: https://reviews.llvm.org/D138183
Enable using -module-summary with -S
(similarly to what currently can be achieved with opt <input> -o - | llvm-dis).
This is a recommit of ef9e62469.
Test plan: ninja check-all
Differential revision: https://reviews.llvm.org/D137768
This patch gives basic parsing and semantic analysis support for 'strict'
modifier with 'grainsize' clause of 'taskloop' construct introduced in
OpenMP 5.1 (section 2.12.2)
Differential Revision: https://reviews.llvm.org/D138217
It is meaningless to emit macro definitions for named modules. With some
small experiments, the size of the module for the named modules reduced
2%~4% after this patch.
Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumption (for standard c++ modules) about module interface. The module
interface should come from a module interface unit. And if it is a
header, it should be a header unit. And currently we have no ideas to
combine several headers together.
So I think this mode is an experimental one and it is not maintained and
it is not used. So it will be better to remove them.
Reviewed By: Bigcheese, dblaikie, bruno
Differential Revision: https://reviews.llvm.org/D137609
-ffp-model=strict -ffp-model=fast will still enable strict exception
handling behavior, therefore clang still emits constrained FP operations
in IR.
-ffp-model=fast -ffp-model=strict emits two warnings: one for strict
overriding fast, the other for strict overriding strict, which is
confusing.
Reviewed By: zahiraam
Differential Revision: https://reviews.llvm.org/D137618
When during parsing we encountered a duplicate `ObjCProtocolDecl`, we
were always emitting an error. With this change we accept
* when a previous `ObjCProtocolDecl` is in a hidden [sub]module;
* parsed `ObjCProtocolDecl` is the same as the previous one.
And in case of mismatches we provide more detailed error messages.
rdar://93069080
Differential Revision: https://reviews.llvm.org/D130327
This diff splits out (from LLVMCore) IR printing passes into IRPrinter.
This structure is similar to what we already have for IRReader and
enables us to avoid circular dependencies between LLVMCore and Analysis
(this is a preparation for https://reviews.llvm.org/D137768).
The legacy interface is left unchanged, once the legacy pass manager
is removed (in the future) we will be able to clean it up further.
The bazel build configuration has been updated as well.
Test plan:
1/ Tested the following cmake configurations: static/dynamic linking * lld/gold * clang/gcc
2/ bazel build --config=generic_clang @llvm-project//...
Differential revision: https://reviews.llvm.org/D138081
add some side effects so some (I guess guaranteed?) constant folding
doesn't happen, keeping the test testing the things it was testing..
The test passes with 14, 17, and 20 - so let's just leave the version
off so it might be able to be updated/used in C++20 when the default
changes to C++20 in the future.
This includes instruction formats, definitions, encodings, scheduling
classes, and builtins/intrinsics.
New and improved version of 76536989ba, so much so that even clang
builds with it.
This reverts commit 766536989b.
The commit caused:
clang/include/clang/Basic/BuiltinsHexagonDep.def:1896:69: error: use of undeclared identifier 'HVXV73'
TARGET_BUILTIN(__builtin_HEXAGON_V6_vadd_sf_bf, "V32iV16iV16i", "", HVXV73)
when building `clang`.
This reverts commit eb2a57ebc7.
llvm/include/llvm/Transforms/Instrumentation/KCFI.h including
llvm/CodeGen is a layering violation. We should use an approach where
Instrumementation/ doesn't need to include CodeGen/.
Sorry for not spotting this in the review.
This avoids depending on int->float or double->float conversion.
Improving codegen with #pragma STDC FENV_ACCESS ON.
Really we should improve constant folding somewhere, but this was
a cheap and easy improvement.
Fixes PR59052.
The KCFI sanitizer emits "kcfi" operand bundles to indirect
call instructions, which the LLVM back-end lowers into an
architecture-specific type check with a known machine instruction
sequence. Currently, KCFI operand bundle lowering is supported only
on 64-bit X86 and AArch64 architectures.
As a lightweight forward-edge CFI implementation that doesn't
require LTO is also useful for non-Linux low-level targets on
other machine architectures, add a generic KCFI operand bundle
lowering pass that's only used when back-end lowering support is not
available and allows -fsanitize=kcfi to be enabled in Clang on all
architectures.
Reviewed By: nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D135411
When a pcm has already been loaded from disk, reuse it from the
InMemoryModuleCache in readASTFileControlBlock. This avoids potentially
reading it again.
As noted in the FIXME, ideally we would also add the module to the cache
if it will be used again later, but that could modify its build state
and we do not have enough context currenlty to know if it's correct.
Differential Revision: https://reviews.llvm.org/D138160
Refactor StaticAnalyzer to use clang::SarifDocumentWriter for
serializing sarif diagnostics.
Uses clang::SarifDocumentWriter to generate SARIF output in the
StaticAnalyzer.
Various bugfixes are also made to clang::SarifDocumentWriter.
Summary of changes:
clang/lib/Basic/Sarif.cpp:
* Fix bug in adjustColumnPos introduced from prev move, it now uses
FullSourceLoc::getDecomposedExpansionLoc which provides the correct
location (in the presence of macros) instead of
FullSourceLoc::getDecomposedLoc.
* Fix createTextRegion so that it handles caret ranges correctly,
this should bring it to parity with the previous implementation.
clang/test/Analysis/diagnostics/Inputs/expected-sarif:
* Update the schema URL to the offical website
* Add the emitted defaultConfiguration sections to all rules
* Annotate results with the "level" property
clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp:
* Update SarifDiagnostics class to hold a clang::SarifDocumentWriter
that it uses to convert diagnostics to SARIF.
Add support for this GCC option which has the purpose of disallowing text
relative accesses of module local symbols with PIC. In effect, this changes
the code model to "medium".
Reviewed By: uweigand, efriedma, MaskRay
Differential Revision: https://reviews.llvm.org/D137044
Use FastEvaluateAsRValue() in EvaluateAsConstantExpr() as well, to
short-circuit evaluation of simple integrals.
Differential Revision: https://reviews.llvm.org/D138115
This change breaks no existing tests but does fix the linked issue.
Declarations of operator overloads are annotated with
`TT_FunctionDeclarationName` on the `operator` keyword, which is already
being checked for when aligning, so the extra `kw_operator` doesn't seem
to be necessary. (just for reference, it was added in
rG92b397fb9d55ccdf4632c2b1b15b4a0ee417cf74 / 92b397fb9d)
Fixes https://github.com/llvm/llvm-project/issues/55733
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D137223
I'm not exactly sure what the intent of that section of
`spaceRequiredBetween` is doing, it seems to handle templates and <<,
but the part which adds spaces before parens is way later, as part
of `spaceRequiredBeforeParens`.
Fixes https://github.com/llvm/llvm-project/issues/58821
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D137474
Martin Storsjö