See `gcc -dumpspecs` that -r essentially implies -nostdlib and suppresses
default -l* and crt*.o. The behavior makes sense because otherwise there will be
assuredly conflicting definitions when the relocatable output is linked into the
final executable/shared object.
Reviewed By: thesamesam, phosek
Differential Revision: https://reviews.llvm.org/D116843
This completes the implementation of
WG14 N2412 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf),
which standardizes C on a twos complement representation for integer
types. The only work that remained there was to define the correct
macros in the standard headers, which this patch does.
Functions pointers should be created with program address space. This
patch introduces program address space in TargetInfo. Targets with
non-default (default is 0) address space for functions should explicitly
set this value. This patch fixes a crash on lvalue reference to function
pointer (in device code) when using oneAPI DPC++ compiler.
Differential Revision: https://reviews.llvm.org/D111566
to repro error.
As mentioned yesterday, I've got a problem that I can only reproduce on
Godbolt (none of the build configs on my local machine!), so this is at
least somewhat usable until I figure out a cause.
Without this patch when using CMAKE_CXX_STANDARD=20
and MSVC 19.30.30705.0 compilation fails with
clang\lib\Tooling\Syntax\Tree.cpp(347): error C2666: 'clang::syntax::Tree::ChildIteratorBase<clang::syntax::Tree::ChildIterator,clang::syntax::Node>::operator ==': 4 overloads have similar conversions
clang\lib\Tooling\Syntax\Tree.cpp(392): error C2666: 'clang::syntax::Tree::ChildIteratorBase<clang::syntax::Tree::ChildIterator,clang::syntax::Node>::operator ==': 4 overloads have similar conversions
Note that removed comment that
"iterator_facade_base requires == to be a member"
was made obsolete by change https://reviews.llvm.org/D78938
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D116904
https://github.com/llvm/llvm-project/issues/27037
Sorry its taken so long to get to this issue! (got it before it hit its 6th birthday!)
```
void operator delete(void *foo)ATTRIB;
```
(void *foo) is incorrectly determined to be a C-Style Cast resulting in the space being removed after the ) and before the attrib, due to the detection of
```
delete (A* )a;
```
The following was previously unaffected
```
void operator new(void *foo) ATTRIB;
```
Fixes#27037
Reviewed By: curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D116920
C++ member function bodies (including ctor initializers) are first captured
into a buffer and then parsed after the class is complete. (This allows
members to be referenced even if declared later).
When the boundary of the function body cannot be established, its buffer is
discarded and late-parsing never happens (it would surely fail).
For code completion this is the wrong tradeoff: the point of the parse is to
generate completions as a side-effect.
Today, when the ctor body wasn't typed yet there are no init list completions.
With this patch we parse such an init-list if it contains the completion point.
There's one caveat: the parser has to decide where to resume parsing members
after a broken init list. Often the first clear recovery point is *after* the
next member, so that member is missing from completion/signature help etc. e.g.
struct S {
S() m //<- completion here
int maaa;
int mbbb;
}
Here "int maaa;" is treated as part of the init list, so "maaa" is not available
as a completion. Maybe in future indentation can be used to recognize that
this is a separate member, not part of the init list.
Differential Revision: https://reviews.llvm.org/D116294
Minor adjustment in order of noundef analysis to be a bit more optimal (when disabled).
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D117078
This introduces clang command line support for new Armv8.8-A and
Armv9.3-A Hinted Conditional Branches feature, previously introduced
into LLVM in https://reviews.llvm.org/D116156.
Patch by Tomas Matheson and Son Tuan Vu.
Differential Revision: https://reviews.llvm.org/D116939
This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.
Reviewed-by: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D117123
Agreed policy is that RISC-V extensions that have not yet been ratified
should be marked as experimental, and enabling them requires the use of
the -menable-experimental-extensions flag when using clang alongside the
version number. These extensions have now been ratified, so this is no
longer necessary, and the target feature names can be renamed to no
longer be prefixed with "experimental-".
Differential Revision: https://reviews.llvm.org/D117131
I'm attempting to debug an issue that I can only get to happen on
godbolt, where the cpu-dispatch resolver for an out of line member
function is generated with the wrong name, causing a link failure.
This makes the mapping between iOS & tvOS/watchOS versions more accurate. For example, iOS 9.3 now gets correctly mapped into tvOS 9.2 and not tvOS 9.3.
Before this change, the incorrect mapping could cause excessive or missing warnings for code that specifies availability for iOS, but not for tvOS/watchOS.
rdar://81491680
Differential Revision: https://reviews.llvm.org/D116822
-Wdeclaration-after-statement currently only outputs an diagnostic if the user is compiling in C versions older than C99, even if the warning was explicitly requested by the user.
This patch makes the warning also available in later C versions. If the C version is C99 or later it is simply a normal warning that is disabled by default (as it is valid C99) and has to be enabled by users. In older versions it remains an extension warning, and therefore affected by -pedantic.
The above behaviour also matches GCCs behaviour.
Fixes https://bugs.llvm.org/show_bug.cgi?id=51931
Differential Revision: https://reviews.llvm.org/D114787
When `-ftrivial-auto-var-init=` is enabled, allocas unconditionally
receive auto-initialization since [1].
In certain cases, it turns out, this is causing problems. For example,
when using alloca to add a random stack offset, as the Linux kernel does
on syscall entry [2]. In this case, none of the alloca'd stack memory is
ever used, and initializing it should be controllable; furthermore, it
is not always possible to safely call memset (see [2]).
Introduce `__builtin_alloca_uninitialized()` (and
`__builtin_alloca_with_align_uninitialized`), which never performs
initialization when `-ftrivial-auto-var-init=` is enabled.
[1] https://reviews.llvm.org/D60548
[2] https://lkml.kernel.org/r/YbHTKUjEejZCLyhX@elver.google.com
Reviewed By: glider
Differential Revision: https://reviews.llvm.org/D115440
All kernels can be called from the host as per the SPIR_KERNEL calling
convention. As such, all kernels should have external linkage, but
block enqueue kernels were created with internal linkage.
Reported-by: Pedro Olsen Ferreira
Differential Revision: https://reviews.llvm.org/D115523
LLVM has a documented mechanism for passing configuration information to
an out of tree project using CMake. See
https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project.
Similar logic applies to "standalone" builds of other sub-projects
within LLVM that depend on each other. For example, a standalone build
of Flang will use this mechanism to acquire Clang's configuration.
Currently, the relevant CMake modules for Clang will only be copied into
the installation directory. This means that in order to configure a
standalone build of Flang, one has to first build and then install
Clang. This is not required for LLVM nor for MLIR - other sub-projects
that Flang depends on (i.e. the CMake modules for LLVM and MLIR are
available in the build dir, so installation is not needed).
This change removes the need for installing Clang in order to access its
configuration. It makes sure that the required CMake modules are copied
into the build directory. This will make Clang behave consistently with
LLVM and MLIR in this respect. It will also simplify building Flang as
standalone sub-project.
Differential Revision: https://reviews.llvm.org/D116731
MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified. Changing the alignment of f80
to 16 bytes so that we can be compatible with ICC's option.
Reviewed By: rnk, craig.topper
Differential Revision: https://reviews.llvm.org/D115942
Often we run into situations where we want to ignore
warnings from system headers, but Clang will still
give warnings about the contents of a macro defined
in a system header used in user-code.
Introduce a ShowInSystemMacro option to be able to
specify which warnings we do want to keep raising
warnings for. The current behavior is kept in this patch
(i.e. warnings from system macros are enabled by default).
The decision as to whether this should be an opt-in or opt-out
feature can be made in a separate patch.
To put the feature to test, replace duplicated code for
Wshadow and Wold-style-cast with the SuppressInSystemMacro tag.
Also disable the warning for C++20 designators, fixing #52944.
Differential Revision: https://reviews.llvm.org/D116833
This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.
Reviewed-by: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D117012
Passing any feature in the device-isa trait which is not supported by the host
was causing a compilation failure.
Differential Revision: https://reviews.llvm.org/D116549
Update UnresolvedSet to use (and expose) `SmallVector::truncate()` instead
of `SmallVector::set_size()`. The latter is going to made private in a
future commit to avoid misuse.
Differential Revision: https://reviews.llvm.org/D115386
Update `variadicMatcherDescriptor` to assert on reserved capacity and
to call `emplace_back()` instead of calling `set_size()` and constructing
the element in-place.
Differential Revision: https://reviews.llvm.org/D115379
The code generation for the UBSan VLA size check was qualified by a con-
dition that the parameter must be a signed integer, however the C spec
does not make any distinction that only signed integer parameters can be
used to declare a VLA, only qualifying that it must be greater than zero
if it is not a constant.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D116048
Prior to this patch, clang might suggest a deprecated name of a declaration over another name as the only mechanism for resolving two typo corrections referring to the same underlying declaration has previously been an alphabetical sort.
This patch adjusts this resolve by also taking into account whether one of two declarations are deprecated. If the new one is deprecated it may not replace a previous correction with a non-deprecated correction and a previous deprecated correction always gets replaced by a non-deprecated new correction.
Fixes https://github.com/llvm/llvm-project/issues/47272
Differential Revision: https://reviews.llvm.org/D116775
I noticed that the following case would compile in Clang but not GCC:
void *x(void) {
void *p = &&foo;
asm goto ("# %0\n\t# %l1":"+r"(p):::foo);
foo:;
return p;
}
Changing the output template above from %l2 would compile in GCC but not
Clang.
This demonstrates that when using tied outputs (say via the "+r" output
constraint), the hidden inputs occur or are numbered BEFORE the labels,
at least with GCC.
In fact, GCC does denote this in its documentation:
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Goto-Labels
> Output operand with constraint modifier ‘+’ is counted as two operands
> because it is considered as one output and one input operand.
For the sake of compatibility, I think it's worthwhile to just make this
change.
It's better to use symbolic names for compatibility (especially now
between released version of Clang that support asm goto with outputs).
ie. %l1 from the above would be %l[foo]. The GCC docs also make this
recommendation.
Also, I cleaned up some cruft in GCCAsmStmt::getNamedOperand. AFAICT,
NumPlusOperands was no longer used, though I couldn't find which commit
didn't clean that up correctly.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103640
Link: https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Goto-Labels
Reviewed By: void
Differential Revision: https://reviews.llvm.org/D115471
ROCm 4.5 device library introduced __ockl_dm_alloc and __ockl_dm_dealloc
for supporting device side malloc/free.
This patch redefines device malloc/free to use these functions.
It also fixes a bug in the wrapper header which incorrectly defines free
with return type void* instead of void.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D116967
when generating copy/dispose helper functions
Analyze the block captures just once before generating copy/dispose
block helper functions and honor the inert `__unsafe_unretained`
qualifier. This refactor fixes a bug where captures of ObjC
`__unsafe_unretained` and class types were needlessly retained/released
by the copy/dispose helper functions.
Differential Revision: https://reviews.llvm.org/D116948
Alternative to D116817.
This introduces a new value-based folding interface for Or (FoldOr),
which takes 2 values and returns an existing Value or a constant if the
Or can be simplified. Otherwise nullptr is returned. This replaces the
more restrictive CreateOr which takes 2 constants.
This is the used to implement a folder that uses InstructionSimplify.
The logic to simplify `Or` instructions is moved there. Subsequent
patches are going to transition other CreateXXX to the more general
FoldXXX interface.
Reviewed By: nikic, lebedev.ri
Differential Revision: https://reviews.llvm.org/D116935
Fixes https://github.com/llvm/llvm-project/issues/52976.
- Make no formatting for macros
- Attach comment with definition headers
- Make no change on use of empty lines at block start/end
- Fix misrecognition of keyword namespace
Differential Revision: https://reviews.llvm.org/D116663
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, curdeius
When spirv-link is found, it won't match a leading `"`. This fixes
the test added by commit dbb8d08637 ("[SPIR-V] Add linking using
spirv-link.", 2022-01-11).
In D116750, the `clangFrontend` library was added as a dependency of `LexTests` in order to make `clang::ApplyHeaderSearchOptions()` available. This increased the number of TUs the test depends on.
This patch moves the function into `clangLex` and removes dependency of `LexTests` on `clangFrontend`.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D117024
The elements of `SearchPath::SearchDirs` are being referenced to by their indices. This proved to be error-prone: `HeaderSearch::SearchDirToHSEntry` was accidentally not being updated in `HeaderSearch::AddSearchPath()`. This patch fixes that by referencing `SearchPath::SearchDirs` elements by their address instead, which is stable thanks to the bump-ptr-allocation strategy.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D116750
Jack Kirk