Petr Hosek [Fri, 25 Jan 2019 02:42:30 +0000 (02:42 +0000)]
[AArch64] Make the test for rsr and rsr64 stricter
ACLE specifies that return type for rsr and rsr64 is uint32_t and
uint64_t respectively. D56852 change the return type of rsr64 from
unsigned long to unsigned long long which at least on Linux doesn't
match uint64_t, but the test isn't strict enough to detect that
because compiler implicitly converts unsigned long long to uint64_t,
but it breaks other uses such as printf with PRIx64 type specifier.
This change makes the test stricter enforcing that the return type
of rsr and rsr64 builtins is what is actually specified in ACLE.
Petr Hosek [Fri, 25 Jan 2019 02:16:29 +0000 (02:16 +0000)]
Revert "[AArch64] Use LL for 64-bit intrinsic arguments"
This reverts commit r351740: this broke on platforms where unsigned long
long isn't the same as uint64_t which is what ACLE specifies for the
return value of rsr64.
George Karpenkov [Fri, 25 Jan 2019 01:23:51 +0000 (01:23 +0000)]
[analysis] Introduce an AnyCall helper class, for abstraction over different callables
A lot of code, particularly in the analyzer, has to perform a lot of
duplication to handle functions/ObjCMessages/destructors/constructors in
a generic setting.
The analyzer already has a CallEvent helper class abstracting over such
calls, but it's not always suitable, since it's tightly coupled to other
analyzer classes (ExplodedNode, ProgramState, etc.) and it's not always
possible to construct.
This change introduces a very simple, very lightweight helper class to
do simple generic operations over callables.
In future, parts of CallEvent could be changed to use this class to
avoid some duplication.
George Karpenkov [Fri, 25 Jan 2019 01:23:37 +0000 (01:23 +0000)]
[AST] Add a method to get a call type from an ObjCMessageExpr
Due to references, expression type does not always correspond to an
expected method return type (e.g. for a method returning int & the
expression type of the call would still be int).
We have a helper method for getting the expected type on CallExpr, but
not on ObjCMessageExpr.
Alex Lorenz [Thu, 24 Jan 2019 23:07:58 +0000 (23:07 +0000)]
[clang-format] square parens with one token are not Objective-C message sends
The commit r322690 introduced support for ObjC detection in header files.
Unfortunately some C headers that use designated initializers are now
incorrectly detected as Objective-C.
This commit fixes it by ensuring that `[ token ]` is not annotated as an
Objective-C message send.
Alex Lorenz [Thu, 24 Jan 2019 19:14:39 +0000 (19:14 +0000)]
Add a priority field to availability attributes to prioritize explicit
attributes from declaration over attributes from '#pragma clang attribute'
Before this commit users had an issue when using #pragma clang attribute with
availability attributes:
The explicit attribute that's specified next to the declaration is not
guaranteed to be preferred over the attribute specified in the pragma.
This commit fixes this by introducing a priority field to the availability
attribute to control how they're merged. Attributes with higher priority are
applied over attributes with lower priority for the same platform. The
implicitly inferred attributes are given the lower priority. This ensures that:
- explicit attributes are preferred over all other attributes.
- implicitly inferred attributes that are inferred from an explicit attribute
are discarded if there's an explicit attribute or an attribute specified
using a #pragma for the same platform.
- implicitly inferred attributes that are inferred from an attribute in the
#pragma are not used if there's an explicit, explicit #pragma, or an
implicit attribute inferred from an explicit attribute for the declaration.
This is the resulting ranking:
`platform availability > platform availability from pragma > inferred availability > inferred availability from pragma`
Sam McCall [Thu, 24 Jan 2019 18:55:24 +0000 (18:55 +0000)]
[FileManager] Revert r347205 to avoid PCH file-descriptor leak.
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.
Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225
Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).
So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.
Erich Keane [Thu, 24 Jan 2019 15:28:57 +0000 (15:28 +0000)]
[CPU-Dispatch] Make pentium_iii_no_xmm_regs and pentium_iii alias.
I discovered that in ICC (where this list comes from), that the two
pentium_iii versions were actually identical despite the two different
names (despite them implying a difference). Because of this, they ended
up having identical manglings, which obviously caused problems when used
together.
This patch makes pentium_iii_no_xmm_regs an alias for pentium_iii so
that it can still be used, but has the same meaning as ICC. However, we
still prohibit using the two together which is different (albeit better)
behavior.
Gabor Marton [Thu, 24 Jan 2019 14:47:44 +0000 (14:47 +0000)]
[ASTImporter] Fix inequality of functions with different attributes
Summary:
FunctionType::ExtInfo holds such properties of a function which are needed
mostly for code gen. We should not compare these bits when checking for
structural equivalency.
Checking ExtInfo caused false ODR errors during CTU analysis (of tmux).
Serge Guelton [Thu, 24 Jan 2019 10:34:44 +0000 (10:34 +0000)]
Fix python3 compability issue in clang binding
The file contents could be of str type. Should use byte length instead
of str length, otherwise utf-8 encoded files may not get properly parsed
for completion.
Hsiangkai Wang [Thu, 24 Jan 2019 05:34:29 +0000 (05:34 +0000)]
Reland r345009 "[DebugInfo] Generate debug information for labels."
Generate DILabel metadata and call llvm.dbg.label after label
statement to associate the metadata with the label.
After fixing PR37395.
After fixing problems in LiveDebugVariables.
After fixing NULL symbol problems in AddressPool when enabling
split-dwarf-file.
After fixing PR39094.
After landing D54199 and D54465 to fix Chromium build failed.
Julian Lettner [Thu, 24 Jan 2019 01:06:19 +0000 (01:06 +0000)]
[Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls
Summary:
UBSan wants to detect when unreachable code is actually reached, so it
adds instrumentation before every `unreachable` instruction. However,
the optimizer will remove code after calls to functions marked with
`noreturn`. To avoid this UBSan removes `noreturn` from both the call
instruction as well as from the function itself. Unfortunately, ASan
relies on this annotation to unpoison the stack by inserting calls to
`_asan_handle_no_return` before `noreturn` functions. This is important
for functions that do not return but access the the stack memory, e.g.,
unwinder functions *like* `longjmp` (`longjmp` itself is actually
"double-proofed" via its interceptor). The result is that when ASan and
UBSan are combined, the `noreturn` attributes are missing and ASan
cannot unpoison the stack, so it has false positives when stack
unwinding is used.
Changes:
# UBSan now adds the `expect_noreturn` attribute whenever it removes
the `noreturn` attribute from a function
# ASan additionally checks for the presence of this attribute
Leonard Chan [Thu, 24 Jan 2019 00:11:35 +0000 (00:11 +0000)]
[Sema] Fix Modified Type in address_space AttributedType
This is a fix for https://reviews.llvm.org/D51229 where we pass the
address_space qualified type as the modified type of an AttributedType. This
change now instead wraps the AttributedType with either the address_space
qualifier or a DependentAddressSpaceType.
Raphael Isemann [Tue, 22 Jan 2019 17:59:45 +0000 (17:59 +0000)]
[ASTImporter] Fix importing OperatorDelete from CXXConstructorDecl
Summary:
Shafik found out that importing a CXXConstructorDecl will create a translation unit that
causes Clang's CodeGen to crash. The reason for that is that we don't copy the OperatorDelete
from the CXXConstructorDecl when importing. This patch fixes it and adds a test case for that.
Eli Friedman [Tue, 22 Jan 2019 00:11:17 +0000 (00:11 +0000)]
[CodeGen] Always use string computed in Sema for PredefinedExpr
We can't use any other string, anyway, because its type wouldn't
match the type of the PredefinedExpr.
With this change, we don't compute a "nice" name for the __func__ global
when it's used in the initializer for a constant. This doesn't seem like
a great loss, and I'm not sure how to fix it without either storing more
information in the AST, or somehow threading through the information
from ExprConstant.cpp.
This could break some situations involving BlockDecl; currently,
CodeGenFunction::EmitPredefinedLValue has some logic to intentionally
emit a string different from what Sema computed. This code skips that
logic... but that logic can't work correctly in general anyway. (For
example, sizeof(__func__) returns the wrong result.) Hopefully this
doesn't affect practical code.
Michal Gorny [Mon, 21 Jan 2019 17:05:43 +0000 (17:05 +0000)]
[test] Pass -ccc-install-dir in mac compilation db test
Pass -ccc-install-dir explicitly as the compilation database code does
not pass argv[0] to getMainExecutable(), while some systems require it
to return the correct path. Since the relevant code is apparently only
applicable to Darwin, just pass correct -ccc-install-dir to make
the tests pass on *BSD systems.
[OpenCL] Allow address spaces as method qualifiers.
Methods can now be qualified with address spaces to prevent
undesirable conversions to generic or to provide custom
implementation to be used if the object is located in certain
memory segments.
This commit extends parsing and standard C++ overloading to
work for an address space of a method (i.e. implicit 'this'
parameter).
Jonas Toth [Mon, 21 Jan 2019 13:26:18 +0000 (13:26 +0000)]
[clang] add tests to ExprMutAnalyzer that reproduced a crash in ASTMatchers
Summary:
This patch adds two unit-tests that are the result of reducing a crashing TU
when running ExprMutAnalyzer over it. They are added only to ensure the regression
that has been fixed with https://reviews.llvm.org/D56444 don't creep back.
Sam Parker [Mon, 21 Jan 2019 11:01:05 +0000 (11:01 +0000)]
[AArch64] Use LL for 64-bit intrinsic arguments
The ACLE states that 64-bit crc32, wsr, rsr and rbit operands are
uint64_t so we should have the clang builtin match this description
- which is what we already do for AArch32.
Chandler Carruth [Mon, 21 Jan 2019 09:52:34 +0000 (09:52 +0000)]
Fix typos throughout the license files that somehow I and my reviewers
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
Serge Guelton [Sun, 20 Jan 2019 21:19:56 +0000 (21:19 +0000)]
Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.
This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.
Note that the following specialization were invalid:
std::pair<T0, T1>
llvm::Optional<T>
Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.
As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)
Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.
Chandler Carruth [Sat, 19 Jan 2019 08:50:56 +0000 (08:50 +0000)]
Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
Chandler Carruth [Sat, 19 Jan 2019 06:36:08 +0000 (06:36 +0000)]
Convert two more files that were using Windows line endings and remove
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.
Chandler Carruth [Sat, 19 Jan 2019 06:29:07 +0000 (06:29 +0000)]
Update some code used in our visual studio plugins to use linux file
endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.
Chandler Carruth [Sat, 19 Jan 2019 06:14:24 +0000 (06:14 +0000)]
Install new LLVM license structure and new developer policy.
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Emit !callback metadata and introduce the callback attribute
With commit r351627, LLVM gained the ability to apply (existing) IPO
optimizations on indirections through callbacks, or transitive calls.
The general idea is that we use an abstraction to hide the middle man
and represent the callback call in the context of the initial caller.
It is described in more detail in the commit message of the LLVM patch
r351627, the llvm::AbstractCallSite class description, and the
language reference section on callback-metadata.
This commit enables clang to emit !callback metadata that is
understood by LLVM. It does so in three different cases:
1) For known broker functions declarations that are directly
generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
2) For known broker functions that are identified by their name and
source location through the builtin detection, e.g.,
pthread_create from the POSIX thread API.
3) For user annotated functions that carry the "callback(callee, ...)"
attribute. The attribute has to include the name, or index, of
the callback callee and how the passed arguments can be
identified (as many as the callback callee has). See the callback
attribute documentation for detailed information.
Artem Dergachev [Fri, 18 Jan 2019 23:05:07 +0000 (23:05 +0000)]
[analyzer] pr37688: Fix a crash upon evaluating a deleted destructor of a union.
Add a defensive check against an invalid destructor in the CFG.
Unions with fields with destructors have their own destructor implicitly
deleted. Due to a bug in the CFG we're still trying to evaluate them
at the end of the object's lifetime and crash because we are unable
to find the destructor's declaration.
Artem Dergachev [Fri, 18 Jan 2019 22:52:13 +0000 (22:52 +0000)]
[analyzer] Do not try to body-farm Objective-C properties with custom accessors.
If a property is defined with a custom getter, we should not behave as if
the getter simply returns an instance variable. We don't support setters,
so they aren't affected.
On top of being the right thing to do, this also fixes a crash on
the newly added test - in which a property and its getter are defined
in two separate categories.
Stephen Kelly [Fri, 18 Jan 2019 22:15:05 +0000 (22:15 +0000)]
[ASTDump] NFC: Remove redundant condition
These conditions are duplicated from the dumpDeclContext function called
within the if(). This is presumably an attempt to avoid calling the
function in the case it will do nothing.
That may have made sense in the past if the code was different, but it
doesn't make sense now.
Erik Pilkington [Fri, 18 Jan 2019 21:33:23 +0000 (21:33 +0000)]
[Sema] Suppress a warning about a forward-declared fixed enum in C mode
As of r343360, we support fixed-enums in C. This lead to some
warnings in project headers where a fixed enum is forward declared
then later defined. In C++, this is fine, the forward declaration is
treated as a complete type even though the definition isn't present.
We use this rule in C too, but still warn about the forward
declaration anyways. This patch suppresses the warning.
These two options enable/disable emission of R_{MICRO}MIPS_JALR fixups along
with PIC calls. The linker may then try to turn PIC calls into direct jumps.
By default, these fixups do get emitted by the backend, use
'-mno-relax-pic-calls' to omit them.
Summary:
This attribute will allow users to opt specific functions out of
speculative load hardening. This compliments the Clang attribute
named speculative_load_hardening. When this attribute or the attribute
speculative_load_hardening is used in combination with the flags
-mno-speculative-load-hardening or -mspeculative-load-hardening,
the function level attribute will override the default during LLVM IR
generation. For example, in the case, where the flag opposes the
function attribute, the function attribute will take precendence.
The sticky inlining behavior of the speculative_load_hardening attribute
may cause a function with the no_speculative_load_hardening attribute
to be tagged with the speculative_load_hardening tag in
subsequent compiler phases which is desired behavior since the
speculative_load_hardening LLVM attribute is designed to be maximally
conservative.
If both attributes are specified for a function, then an error will be
thrown.
Erich Keane [Fri, 18 Jan 2019 13:58:10 +0000 (13:58 +0000)]
Fix test failure from r351495
The test has problems due to some platforms having a different type for
ptrdiff_t, so the error message is different. The error message doesn't
matter to the test for anything other than an incompatible intger to
pointer conversion, so this patch removes the integral type from the
expected message.
projects / clang / log