Summary:
Adds an optional parameter to `buildASTFromCodeWithArgs` that allows the user to
pass additional files that the main code needs to compile. This change makes
`buildASTFromCodeWithArgs` consistent with `runToolOnCodeWithArgs`.
Patch by Alexey Eremin.
Reviewers: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70175
Cleanup handling of the denormal-fp-math attribute. Consolidate places
checking the allowed names in one place.
This is in preparation for introducing FP type specific variants of
the denormal-fp-mode attribute. AMDGPU will switch to using this in
place of the current hacky use of subtarget features for the denormal
mode.
Introduce a new header for dealing with FP modes. The constrained
intrinsic classes define related enums that should also be moved into
this header for uses in other contexts.
The verifier could use a check to make sure the denorm-fp-mode
attribute is sane, but there currently isn't one.
Currently, DAGCombiner incorrectly asssumes non-IEEE behavior by
default in the one current user. Clang must be taught to start
emitting this attribute by default to avoid regressions when this is
switched to assume ieee behavior if the attribute isn't present.
The const-correctness of match() was fixed in rL372764, which allows
uses of Regex objects to be const in cases they couldn't be before. This
patch tightens up the const-ness of Regex in various such cases.
Reviewers: thopre
Reviewed By: thopre
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68155
Currently only support the set of multilibs same to riscv-gnu-toolchain.
Reviewers: espindola, asb, kito-cheng, lenary
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D67508
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Differential Revision: https://reviews.llvm.org/D70274
Assign artificial locations to calls to special struct-related helper
functions.
Such calls may not inherit a location if emitted within FinishFunction,
at which point the lexical scope stack may be empty, causing CGDebugInfo
to report the current DebugLoc as empty.
Fixes an IR verifier complaint about a call to '__destructor_8_s0' not
having a !dbg location attached.
rdar://57293361
checkTargetFeatures was incorrectly checking for cpu_specific instead of
just 'target'. While this function was never called in that situation,
it seemed correct to fix the condition. Additionally, multiversion
functions can never be always_inline, but if any function accidentially
ended up here we shouldn't diagnose.
Note that the adding of target-features to the list is unnecessary since
the getFunctionFeatureMap actually considers attribute target,
however adding it results in significantly better error messages by
putting the 'target' features first (and thus first to fail).
Otherwise, the error message would be the first feature 'implied' by the
target attribute, and not necessarily the feature listed in the
attribute itself.
Summary:
This allows `clang` to be used to compile CUDA programs. Compiled
simple helloworld.cu with this.
Reviewers: dim, emaste, tra, yaxunl, ABataev
Reviewed By: tra
Subscribers: dim, emaste, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69990
__attribute__((objc_direct)) is an attribute on methods declaration, and
__attribute__((objc_direct_members)) on implementation, categories or
extensions.
A `direct` property specifier is added (@property(direct) type name)
These attributes / specifiers cause the method to have no associated
Objective-C metadata (for the property or the method itself), and the
calling convention to be a direct C function call.
The symbol for the method has enforced hidden visibility and such direct
calls are hence unreachable cross image. An explicit C function must be
made if so desired to wrap them.
The implicit `self` and `_cmd` arguments are preserved, however to
maintain compatibility with the usual `objc_msgSend` semantics,
3 fundamental precautions are taken:
1) for instance methods, `self` is nil-checked. On arm64 backends this
typically adds a single instruction (cbz x0, <closest-ret>) to the
codegen, for the vast majority of the cases when the return type is a
scalar.
2) for class methods, because the class may not be realized/initialized
yet, a call to `[self self]` is emitted. When the proper deployment
target is used, this is optimized to `objc_opt_self(self)`.
However, long term we might want to emit something better that the
optimizer can reason about. When inlining kicks in, these calls
aren't optimized away as the optimizer has no idea that a single call
is really necessary.
3) the calling convention for the `_cmd` argument is changed: the caller
leaves the second argument to the call undefined, and the selector is
loaded inside the body when it's referenced only.
As far as error reporting goes, the compiler refuses:
- making any overloads direct,
- making an overload of a direct method,
- implementations marked as direct when the declaration in the
interface isn't (the other way around is allowed, as the direct
attribute is inherited from the declaration),
- marking methods required for protocol conformance as direct,
- messaging an unqualified `id` with a direct method,
- forming any @selector() expression with only direct selectors.
As warnings:
- any inconsistency of direct-related calling convention when
@selector() or messaging is used,
- forming any @selector() expression with a possibly direct selector.
Lastly an `objc_direct_members` attribute is added that can decorate
`@implementation` blocks and causes methods only declared there (and in
no `@interface`) to be automatically direct. When decorating an
`@interface` then all methods and properties declared in this block are
marked direct.
Radar-ID: rdar://problem/2684889
Differential Revision: https://reviews.llvm.org/D69991
Reviewed-By: John McCall
When the driver is targeting multiple architectures at once, for things
like Universal Mach-Os, we need to emit different remark files for each
cc1 invocation to avoid overwriting the files from a different
invocation.
For example:
$ clang -c -o foo.o -fsave-optimization-record -arch x86_64 -arch x86_64h
will create two remark files:
* foo-x86_64.opt.yaml
* foo-x86_64h.opt.yaml
and a follow-up NFC rearrangement as it's causing a crash on valid. Testcase is on the original review thread.
This reverts commits af57dbf12e and e6584b2b7b
When the driver is targeting multiple architectures at once, for things
like Universal Mach-Os, we need to emit different remark files for each
cc1 invocation to avoid overwriting the files from a different
invocation.
For example:
$ clang -c -o foo.o -fsave-optimization-record -arch x86_64 -arch x86_64h
will create two remark files:
* foo-x86_64.opt.yaml
* foo-x86_64h.opt.yaml
Without this fix, the tests introduced here produce the following
assert fail:
```
clang: /home/jdenny/llvm/clang/include/clang/Basic/AttributeCommonInfo.h:163: unsigned int clang::AttributeCommonInfo::getAttributeSpellingListIndex() const: Assertion `(isAttributeSpellingListCalculated() || AttrName) && "Spelling cannot be found"' failed.
```
The bug was introduced by D67368, which caused `AsmLabelAttr`'s
spelling index to be set to `SpellingNotCalculated`.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D70349
For RISC-V the value provided to -march should determine whether to
compile for 32- or 64-bit RISC-V irrespective of the target provided to
the Clang driver. This adds a test for this flag for RISC-V and sets the
Target architecture correctly in these cases.
Differential Revision: https://reviews.llvm.org/D54214
This adds the `vcmp` family of ACLE MVE intrinsics: vector/vector,
vector/scalar, and the predicated forms of both. All are represented
using standard existing IR: vector/scalar comparisons are represented
by making a vector out of the scalar first, and predicated forms are
represented by taking the bitwise AND of the input predicate and the
output of the comparison. Existing LLVM-side tests demonstrate that
ISel will pattern-match all of that back down to single MVE VCMPs.
The idiom of handling a vector/scalar operation by generating IR to
expand the scalar into a second vector is going to be needed for a lot
of MVE intrinsics, so to make that easy, I've provided a helper
function that automatically works out the element count.
The comparison intrinsics are the first ones that have to //return// a
predicate, in the user-facing `mve_pred16_t` format. This means we
have to use the `arm_mve_pred_v2i` low-level intrinsic to convert it
back from the logical `<n x i1>` form used in IR. I've done that
explicitly in the code gen specification for the builtins, because it
happens much more rarely in the ACLE API than passing a Predicate as
input, so it didn't seem worth automating in MveEmitter.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Reviewed By: dmgreen
Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D70297
Summary:
Semantically they're the same thing, and it's important when the underlying
struct is anonymous.
There doesn't seem to be a problem attaching the same comment to multiple things
as it already happens with `/** doc */ int a, b;`
This affects an Index test but the results look better (name present, USR points
to the typedef).
Fixes https://github.com/clangd/clangd/issues/189
Reviewers: kadircet, lh123
Subscribers: ilya-biryukov, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70203
Provides support for using r6-r11 as globally scoped
register variables. This requires a -ffixed-rN flag
in order to reserve rN against general allocation.
If for a given GRV declaration the corresponding flag
is not found, or the the register in question is the
target's FP, we fail with a diagnostic.
Differential Revision: https://reviews.llvm.org/D68862
This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE.
When explicit alignment is specified.
Patch by Awanish Pandey <Awanish.Pandey@amd.com>
Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok,
deadalinx
Differential Revision: https://reviews.llvm.org/D70111
Summary: Adds a new option SpaceBeforeBrackets to add spaces before brackets (i.e. int a[23]; -> int a [23];) This is present as an option in the Visual Studio C++ code formatting settings, but there was no matching setting in clang-format.
Reviewers: djasper, MyDeveloperDay, mitchell-stellar
Reviewed By: MyDeveloperDay
Subscribers: llvm-commits, cfe-commits, klimek
Patch by: Anteru
Tags: #clang, #clang-format, #llvm
Differential Revision: https://reviews.llvm.org/D6920
Builtins are rarely if ever accessed via the Preprocessor. They are
typically found on the ASTContext, so there should be no performance
penalty to using a pointer indirection to store the builtin context.
always_inline.
The assertion in SetLLVMFunctionAttributesForDefinition used to fail
when there was attribute OptimizeNone on the AST function and attribute
always_inline on the IR function. This happens because base destructors
are annotated with always_inline when the code is compiled with
-fapple-kext (see r124757).
rdar://problem/57169694
Summary:
For the extended defaultmap, most of the work is inside sema.
The only difference for codegen is to set different initial
maptype for different implicit-behavior.
Reviewers: jdoerfert, ABataev
Reviewed By: ABataev
Subscribers: dreachem, sandoval, cfe-commits
Tags: #clang, #openmp
Differential Revision: https://reviews.llvm.org/D69204
Line ending detection is now set with the `DeriveLineEnding` option.
CRLF can now be used as the default line ending by setting `UseCRLF`.
When line ending detection is disabled, all line endings are converted
according to the `UseCRLF` option.
Differential Revision: https://reviews.llvm.org/D19031
There doesn't seem to be much sense in defaulting "on" unwind tables on
amd64 and not on other arches. It causes surprising differences between
platforms, such as the PR below[1].
Prior to this change, FreeBSD inherited the default implementation of the
method from the Gnu.h Generic_Elf => Generic_GCC parent class, which
returned true only for amd64 targets. Override that and opt on always,
similar to, e.g., NetBSD's driver.
[1] https://bugs.freebsd.org/241562
Patch by cem (Conrad Meyer).
Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D70110
Summary:
Clang/LLVM is a cross-compiler, and so we don't have to make a choice
about `-march`/`-mabi` at build-time, but we may have to compute a
default `-march`/`-mabi` when compiling a program. Until now, each
place that has needed a default `-march` has calculated one itself.
This patch adds a single place where a default `-march` is calculated,
in order to avoid calculating different defaults in different places.
This patch adds a new function `riscv::getRISCVArch` which encapsulates
this logic based on GCC's for computing a default `-march` value
when none is provided. This patch also updates the logic in
`riscv::getRISCVABI` to match the logic in GCC's build system for
computing a default `-mabi`.
This patch also updates anywhere that `-march` is used to now use the
new function which can compute a default. In particular, we now
explicitly pass a `-march` value down to the gnu assembler.
GCC has convoluted logic in its build system to choose a default
`-march`/`-mabi` based on build options, which would be good to match.
This patch is based on the logic in GCC 9.2.0. This commit's logic is
different to GCC's only for baremetal targets, where we default
to rv32imac/ilp32 or rv64imac/lp64 depending on the target triple.
Tests have been updated to match the new logic.
Reviewers: asb, luismarques, rogfer01, kito-cheng, khchen
Reviewed By: asb, luismarques
Subscribers: sameer.abuasal, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69383
Summary:
This is shorter, shouldn't be confusing (is consistent with how they're declared),
and avoids messy cases that are printed as myclass<type-param-0-0>(int) in the
case of partial specialization.
Fixes part of https://github.com/clangd/clangd/issues/76
Reviewers: hokein, lh123
Subscribers: ilya-biryukov, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70307
Summary:
ASTImporter makes now difference between class templates with same
name in different translation units if these are not visible outside.
Reviewers: martong, a.sidorin, shafik
Reviewed By: martong
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67543
Enumerations that describe rounding mode and exception behavior were
defined inside ConstrainedFPIntrinsic. It makes sense to use the same
definitions to represent the same properties in other cases, not only
in constrained intrinsics. It was however inconvenient as required to
include constrained intrinsics definitions even if they were not needed.
Also using long scope prefix reduced readability.
This change moves these definitioins to the namespace llvm::fp.
No functional changes.
Differential Revision: https://reviews.llvm.org/D69552
I am planning to use this feature to make update_cc_test_checks.py less fragile
by obtaining the mangled names directly from -ast-dump=json. Currently,
it uses c-index-test which ignores the -triple=, etc. arguments that are
in the RUN: line and therefore does not generate checks for some targets.
The AST dump tests were updated using the following command:
`python $LLVM_BINDIR/gen_ast_dump_json_test.py --update --source $LLVM_SRC/clang/test/AST/*-json.*`
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: rsmith, MaskRay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69564
It turns out that the ExprMutationAnalyzer can be very slow when AST
gets huge in some cases. The idea is to move this analysis to the LLVM
back-end level (more precisely, in the LiveDebugValues pass). The new
approach will remove the performance regression, simplify the
implementation and give us front-end independent implementation.
Differential Revision: https://reviews.llvm.org/D68206
Summary:
This doesn't cover decls in diagnostics, which use NamedDecl::getNameForDiagnostic().
(That should also be fixed later I think).
This covers some cases of https://github.com/clangd/clangd/issues/76
(hover, but not outline or sighelp)
Reviewers: hokein
Subscribers: ilya-biryukov, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70236
This patch is a follow-up for commit 4e2ce228ae
[BPF] Add preserve_access_index attribute for record definition
to restrict attribute for C only. A new test case is added
to check for this restriction.
Additional code polishing is done based on
Aaron Ballman's suggestion in https://reviews.llvm.org/D69759/new/.
Differential Revision: https://reviews.llvm.org/D70257
We need to use a 64-bit type in 64-bit mode so a 64-bit register
will get used in the generated assembly. I've also changed the
constraints to just use "r" intead of "q". "q" forces to a only
an a/b/c/d register in 32-bit mode, but I see no reason that
would matter here.
Fixes Nico's note in PR19301 over 4 years ago.
Differential Revision: https://reviews.llvm.org/D70101
Before this patch if we pass "-mcpu=hexagonv65 -march=hexagon" in this order,
the driver fails to figure out the correct cpu version. This patch fixed this
issue.
Summary:
Tooling around DWARF 5 is still not mature enough for this to be a sane
default, and the AMDGPU and HIP toolchains should agree on a single
default.
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, aprantl, dstuttard, tpr, t-tye, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70191
Summary:
This adds `-mreference-types` and `-mno-reference-types` flags to clang
and make `-fwasm-exceptions` enables reference types feature in clang
and the backend.
Reviewers: tlively
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69832
Avoids the need to include TargetMachine.h from various places just for
an enum. Various other enums live here, such as the optimization level,
TLS model, etc. Data suggests that this change probably doesn't matter,
but it seems nice to have anyway.
If a GCC installation is not detected, then this attempts to
use compiler-rt and the compiler-rt crtbegin/crtend
implementations as a fallback.
Differential Revision: https://reviews.llvm.org/D68407
This is a resubmission for the previous reverted commit
9434360401 with the same subject. This commit fixed the
segfault issue and addressed additional review comments.
This patch introduced a new bpf specific attribute which can
be added to struct or union definition. For example,
struct s { ... } __attribute__((preserve_access_index));
union u { ... } __attribute__((preserve_access_index));
The goal is to simplify user codes for cases
where preserve access index happens for certain struct/union,
so user does not need to use clang __builtin_preserve_access_index
for every members.
The attribute has no effect if -g is not specified.
When the attribute is specified and -g is specified, any member
access defined by that structure or union, including array subscript
access and inner records, will be preserved through
__builtin_preserve_{array,struct,union}_access_index()
IR intrinsics, which will enable relocation generation
in bpf backend.
The following is an example to illustrate the usage:
-bash-4.4$ cat t.c
#define __reloc__ __attribute__((preserve_access_index))
struct s1 {
int c;
} __reloc__;
struct s2 {
union {
struct s1 b[3];
};
} __reloc__;
struct s3 {
struct s2 a;
} __reloc__;
int test(struct s3 *arg) {
return arg->a.b[2].c;
}
-bash-4.4$ clang -target bpf -g -S -O2 t.c
A relocation with access string "0:0:0:0:2:0" will be generated
representing access offset of arg->a.b[2].c.
forward declaration with attribute is also handled properly such
that the attribute is copied and populated in real record definition.
Differential Revision: https://reviews.llvm.org/D69759
Summary:
Flags that generate output could result in failures when creating
syntax only actions. This patch introduces initial logic for filtering out
those. The first such flag is "save-temps", which saves intermediate
files(bitcode, assembly, etc.) into a specified directory.
Fixes https://github.com/clangd/clangd/issues/191
Reviewers: hokein
Subscribers: ilya-biryukov, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70173
This patch adds the ACLE intrinsics for all the MVE load and store
instructions not already handled by D69791. These ones don't need new
IR intrinsics, because they can be implemented in terms of standard
LLVM IR constructions.
Some of the load and store instructions access less than 128 bits of
memory, sign/zero extending each value to a wider vector lane on load
or truncating it on store. These are represented in IR by a load of a
shorter vector followed by a zext/sext, and conversely, a trunc
followed by a short store. Existing ISel patterns already recognize
those combinations and turn them into the right MVE instructions.
The predicated forms of all these instructions are represented in the
same way, except that the ordinary load/store operation is replaced
with the existing intrinsics @llvm.masked.{load,store}. These are
currently only code-generated as predicated MVE load/store
instructions if you give LLVM the `-enable-arm-maskedldst` option; so
I've done that in the LLVM codegen test. When we make that the
default, that option can be removed.
In the Tablegen backend, I've had to add a handful of extra support
features:
* We need to be able to make clang::Address objects out of a
pointer and an alignment (previously we only needed these when the
user passed us an existing one).
* We can now specify vector types that aren't 128 bits wide (for use
in those intermediate values in IR), the parametrized type system
can make one starting from two existing vector types (using the lane
count of one and the element type of the other).
* I've added support for code generation of pointer casts, and for
specifying LLVM types as operands to IRBuilder operations (for zext
and sext, though I think they'll come in useful again).
* Now not all IR construction operations need to be specified as
Builder.CreateFoo; some don't involve a Builder at all, and one
passes it as a parameter to a tiny static helper function in
CGBuiltin.cpp.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Subscribers: kristof.beyls, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D70088
Add the remaining half (fp16) vector data load and store builtin
functions from the OpenCL C specification.
Patch by Pierre Gondois and Sven van Haastregt.
8548 CPU is GCC's name for the e500v2, so accept this in clang. The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well,
as GCC does.
Differential Revision: https://reviews.llvm.org/D67787
This is a fix for PR43315. An assertion error is hit for this minimal example:
```
//clang -cc1 -triple x86_64-- -S tstVMStructRC-min.cpp
int (a b)(); // Assertion `Chunk.Kind == DeclaratorChunk::Function' failed.
```
This is because we do not cover the case in the FunctionTypeUnwrapper where it
receives a MacroQualifiedType. We have not run into this earlier because this
is a unique case where the __attribute__ contains both __cdecl__ and
__regparm__ (in that order), and we are compiling for x86_64. Changing the
architecture or the order of __cdecl__ and __regparm__ does not raise the
assertion.
Differential Revision: https://reviews.llvm.org/D67992
Summary:
By additional regex match, grouping of main include can be enabled in files that are not normally considered as a C/C++ source code.
For example, this might be useful in templated code, where template implementations are being held in *Impl.hpp files.
On the occassion, 'assume-filename' option description was reworded as it was misleading. It has nothing to do with `style=file` option and it does not influence sourced style filename.
Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch by: furdyna
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67750
Let the checkers use a reference instead of a copy in a range-based
for loop.
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.
Differential Revision: https://reviews.llvm.org/D70047
The std::pair<const clang::ValueDecl *, llvm::ArrayRef<clang::OMPClauseMappableExprCommon::MappableComponent>>
type will be copied in a range-based for loop. Make the copy explicit to
avoid the -Wrange-loop-analysis warning.
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.
Differential Revision: https://reviews.llvm.org/D70046
The AssociationIteratorTy type will be copied in a range-based for loop.
Make the copy explicit to avoid the -Wrange-loop-analysis warning.
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.
Differential Revision: https://reviews.llvm.org/D70045
If ReadASTBlock does not find its top-level submodule, there's something
wrong the with the PCM. Error in that case, to avoid hitting problems
further from the source.
Note that the Swift compiler sometimes hits a case in
CompilerInstance::loadModule where the top-level submodule mysteriously
does not have Module::IsFromModuleFile set. That will emit a confusing
warn_missing_submodule, which was never intended for the main module.
The recent audit of error-handling in ReadAST may have rooted out the
real problem. If not, this commit will help to clarify the real
problem, and replace a confusing warning with an error pointing at the
malformed PCM file.
We're specifically sniffing out whether the top-level submodule was
found/processed, in case there is a malformed module file that is
missing it. If there is an error encountered during ReadSubmoduleBlock
the return status should already propagate through. It would be nice to
detect other missing submodules around here to catch other instances of
warn_missing_submodule closer to the source, but that's left as a future
exercise.
https://reviews.llvm.org/D70063
ReadASTBlock and ReadASTExtensions can both return failures. Be
consistent and remove all the just-loaded modules, just like when
ReadASTCore returns failures.
https://reviews.llvm.org/D70055
These were found via an audit. In the case of `ParseLineTable` this is
actually dead code, since parsing the line table always succeeds, but
it's prudent to be defensive since it's possible an assertion there
could be converted to a `true` return in the future.
Split a loop in ReadAST that visits the just-loaded module chain,
between an initial loop that reads further from the ASTs (and can fail)
and a second loop that does some preloading (and cannot fail). This
makes it less likely for a reading failure to affect the AST.
This is not fixing a known bug and the behaviour change may not be
observable, it's just part of an audit to look at all of the error
handling in the ASTReader.
https://reviews.llvm.org/D70056
As part of an audit of whether all errors are being reported from the
ASTReader, delay err_module_file_conflict if a diagnostic is already in
flight when it is hit. This required plumbing an extra argument through
the delayed diagnostic mechanics in DiagnosticsEngine.
simd-based directives.
According to OpenMP 5.0 standard, ordered simd, atomic and simd
directives are allowed as nested directives in the simd-based
directives.
Summary:
This revision introduces a new interface `MatchComputation` which generalizes
the `Stencil` interface and replaces the `std::function` interface of
`MatchConsumer`. With this revision, `Stencil` (as an abstraction) becomes just
one collection of implementations of
`MatchComputation<std::string>`. Correspondingly, we remove the `Stencil` class
entirely in favor of a simple type alias, deprecate `MatchConsumer` and change
all functions that accepted `MatchConsumer<std::string>` to use
`MatchComputation<std::string>` instead.
Reviewers: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69802
Summary:
JavaScript / TypeScript is adding two new operators: the null
propagating operator `?.` and the nullish coalescing operator `??`.
const x = foo ?? 'default';
const z = foo?.bar?.baz;
This change adds support to lex and format both.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69971
This started passing target-features on the linker line, not just for RISCV but
for all targets, leading to error messages in Chromium Android build:
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
See Phabricator review for details.
Reverting until this can be fixed properly.
> Summary:
> 1. enable LTO need to pass target feature and abi to LTO code generation
> RISCV backend need the target feature to decide which extension used in
> code generation.
> 2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
> 3. add general tools::getTargetABI in CommonArgs.h because different target uses different
> way to get the target ABI.
>
> Patch by Kuan Hsu Chen (khchen)
>
> Reviewers: lenary, lewis-revill, asb, MaskRay
>
> Reviewed By: lenary
>
> Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D67409
The other paremeters appear to be sufficient to determine which modules
have just been loaded and need to be removed, so stop collecting and
sending in that set explicitly.
This patch introduced a new bpf specific attribute which can
be added to struct or union definition. For example,
struct s { ... } __attribute__((preserve_access_index));
union u { ... } __attribute__((preserve_access_index));
The goal is to simplify user codes for cases
where preserve access index happens for certain struct/union,
so user does not need to use clang __builtin_preserve_access_index
for every members.
The attribute has no effect if -g is not specified.
When the attribute is specified and -g is specified, any member
access defined by that structure or union, including array subscript
access and inner records, will be preserved through
__builtin_preserve_{array,struct,union}_access_index()
IR intrinsics, which will enable relocation generation
in bpf backend.
The following is an example to illustrate the usage:
-bash-4.4$ cat t.c
#define __reloc__ __attribute__((preserve_access_index))
struct s1 {
int c;
} __reloc__;
struct s2 {
union {
struct s1 b[3];
};
} __reloc__;
struct s3 {
struct s2 a;
} __reloc__;
int test(struct s3 *arg) {
return arg->a.b[2].c;
}
-bash-4.4$ clang -target bpf -g -S -O2 t.c
A relocation with access string "0:0:0:0:2:0" will be generated
representing access offset of arg->a.b[2].c.
forward declaration with attribute is also handled properly such
that the attribute is copied and populated in real record definition.
Differential Revision: https://reviews.llvm.org/D69759
Before when the overflow occured an assertion was triggered. Now check
whether the maximum has been reached and warn properly.
This patch fixes the original submission of PR19607.
Differential Revision: https://reviews.llvm.org/D63975
When bugreporter::trackExpressionValue() is invoked on a DeclRefExpr,
it tries to do most of its computations over the node in which
this DeclRefExpr is computed, rather than on the error node (or whatever node
is stuffed into it). One reason why we can't simply use the error node is
that the binding to that variable might have already disappeared from the state
by the time the bug is found.
In case of the inlined defensive checks visitor, the DeclRefExpr node
is in fact sometimes too *early*: the call in which the inlined defensive check
has happened might have not been entered yet.
Change the visitor to be fine with tracking dead symbols (which it is totally
capable of - the collapse point for the symbol is still well-defined), and fire
it up directly on the error node. Keep using "LVState" to find out which value
should we be tracking, so that there weren't any problems with accidentally
loading an ill-formed value from a dead variable.
Differential Revision: https://reviews.llvm.org/D67932
Adding support for processing the following Decls: NonTypeTemplateParmDecl,
CXXConversionDecl, UnresolvedUsingValueDecl, UsingDecl, UsingShadowDecl,
TypeAliasTemplateDecl, TypeAliasDecl, VarTemplateDecl,
VarTemplateSpecializationDecl, UsingDirectiveDecl, TemplateTemplateParmDecl,
ClassTemplatePartialSpecializationDecl, IndirectFieldDecl.
Also, this allows for processing NamedDecls that don't have an identifier and
skips over VarDecls that are dependent on template types.
Differential Revision: https://reviews.llvm.org/D69995
This has the nice side-effect of also fixing a crash in Clang.
Starting with DWARF 5 we are emitting ObjC method declarations as
children of their containing entity. This worked for interfaces, but
didn't consider the case of synthessized properties. When a property
of a protocol is synthesized in an interface implementation the
ObjCMethodDecl that was passed to CGF::StartFunction was the property
*declaration* which obviously couldn't have a containing
interface. This patch passes the containing interface all the way
through to CGDebugInfo, so the function declaration can be created
with the correct parent (= the class implementing the protocol).
rdar://problem/53782400
Differential Revision: https://reviews.llvm.org/D66121
Alexey Bataev