This starts adding dso_local to clang.
The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.
This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.
llvm-svn: 324107
When trying to track down a different bug, we discovered
that calling __builtin_va_arg on a vec3f type caused
the SROA pass to issue a warning that there was an illegal
access.
Further research showed that the vec3f type is
alloca'ed as size '12', but the _builtin_va_arg code
on x86_64 was always loading this out of registers as
{double, double}. Thus, the 2nd store into the vec3f
was storing in bytes 12-15!
This patch alters the original implementation which always
assumed {double, double} to use the actual coerced type
instead, so the LLVM-IR generated is a load/GEP/store of
a <2 x float> and a float, rather than a double and a double.
Tests were added for all combinations I could think of that
would fit in 2 FP registers, and all work exactly as expected.
Differential Revision: https://reviews.llvm.org/D42811
llvm-svn: 324098
Summary:
It should be safe, since other code paths are already generating
implicit members even in invalid CXXRecordDecls (e.g. lookup).
If we don't generate implicit members on CXXRecordDecl's completion,
they will be generated by next lookup of constructors. This causes a
crash when the following conditions are met:
- a CXXRecordDecl is invalid,
- it is provided via ExternalASTSource (e.g. from PCH),
- it has inherited constructors (they create ShadowDecls),
- lookup of its constructors was not run before ASTWriter serialized
it.
This may require the ShadowDecls created for inherited constructors to
be removed from the class, but that's no longer possible since class is
provided by ExternalASTSource.
See provided lit test for an example.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42810
llvm-svn: 324062
This fixes building Qt as shared libraries with clang in MinGW
mode; previously subclasses of the QObjectData class (in other
DLLs than the base DLL) failed to find the typeinfo symbols
(that neither were emitted in the base DLL nor in the DLL
containing the subclass).
If the virtual destructor in the newly added testcase wouldn't
be pure (or if there'd be another non-pure virtual method),
it'd be a key function and things would work out even before this
change. Make sure to locally emit the typeinfo for these classes
as well.
This matches what GCC does in this specific testcase.
This fixes the root issue that spawned PR35146. (The difference
to GCC that is initially described in that bug still is present
though.)
Differential Revision: https://reviews.llvm.org/D42641
llvm-svn: 324059
No in-tree checkers use this callback so far, hence no tests. But better fix
this now than remember to fix this when the checkers actually appear.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42785
llvm-svn: 324053
If the return statement is stored, we might as well allow querying
against it.
Also fix the bug where the return statement is not stored
if there is no return value.
This change un-merges two ExplodedNodes during call exit when the state
is otherwise identical - the CallExitBegin node itself and the "Bind
Return Value"-tagged node.
And expose the return statement through
getStatement helper function.
Differential Revision: https://reviews.llvm.org/D42130
llvm-svn: 324052
Summary:
Fix NRVO for Gro variable.
Previously, we only marked the GRO declaration as an NRVO variable
when its QualType and the function return's QualType matched exactly
(using operator==). However, this was incorrect for two reasons:
1. We were marking non-class types, such as ints, as being NRVO variables.
2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL)
This patch fixes these bugs by marking the Gro variable as supporting NRVO only
when `BuildReturnStmt` marks the Gro variable as a coroutine candidate.
Reviewers: rsmith, GorNishanov, nicholas
Reviewed By: GorNishanov
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42343
llvm-svn: 324037
Indeed, "CHANGE" is not a thing yet, and we should probably not carry
around dead code which does not do anything apart from confusing the
reader.
Differential Revision: https://reviews.llvm.org/D42819
llvm-svn: 324027
We use CXXTempObjectRegion exclusively as a bailout value for construction
targets when we are unable to find the correct construction region.
Sometimes it works correctly, but rather accidentally than intentionally.
Now that we want to increase the amount of situations where it works correctly,
the first step is to introduce a different way of communicating our failure
to find the correct construction region. EvalCallOptions are introduced
for this purpose.
For now EvalCallOptions are communicating two kinds of problems:
- We have been completely unable to find the correct construction site.
- We have found the construction site correctly, and there's more than one of
them (i.e. array construction which we currently don't support).
Accidentally find and fix a test in which the new approach to communicating
failures produces better results.
Differential Revision: https://reviews.llvm.org/D42457
llvm-svn: 324018
DeclContext rather than injecting it wherever we happen to be.
This avoids creating functions whose DeclContext is a struct or similar.
llvm-svn: 323998
Summary:
This patch enables debugging of C99 VLA types by generating more precise
LLVM Debug metadata, using the extended DISubrange 'count' field that
takes a DIVariable.
This should implement:
Bug 30553: Debug info generated for arrays is not what GDB expects (not as good as GCC's)
https://bugs.llvm.org/show_bug.cgi?id=30553
Reviewers: echristo, aprantl, dexonsmith, clayborg, pcc, kristof.beyls, dblaikie
Reviewed By: aprantl
Subscribers: jholewinski, schweitz, davide, fhahn, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D41698
llvm-svn: 323952
This patch fixes a bug in CGRecordLowering::accumulateBitFields where it
unconditionally starts a new run and emits a storage field when it sees
a zero-sized bitfield, which causes an assertion in insertPadding to
fail when -fno-bitfield-type-align is used.
It shouldn't emit new storage if UseZeroLengthBitfieldAlignment and
UseBitFieldTypeAlignment are both false.
rdar://problem/36762205
llvm-svn: 323943
The patch ensures that a new storage unit is created when the new bitfield's
size is wider than the available bits.
rdar://36343145
Differential Revision: https://reviews.llvm.org/D42660
llvm-svn: 323921
Summary:
r312125, which introduced preprocessor indentation, shipped with a known
issue where "indentation of comments immediately before indented
preprocessor lines is toggled on each run". For example these two forms
toggle:
#ifndef HEADER_H
#define HEADER_H
#if 1
// comment
# define A 0
#endif
#endif
#ifndef HEADER_H
#define HEADER_H
#if 1
// comment
# define A 0
#endif
#endif
This happens because we check vertical alignment against the '#' yet
indent to the level of the 'define'. This patch resolves this issue by
aligning against the '#'.
Reviewers: krasimir, klimek, djasper
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42408
llvm-svn: 323904
Summary:
This patch modifies the text proto Google style to add spaces around braces.
I investigated using something different than Cpp11BracedListStyle, but it turns out it's what we want and also the java and js styles also depend on that.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42685
llvm-svn: 323860
If the CUDA toolkit is not installed to its default locations
in /usr/local/cuda, the user is forced to specify --cuda-path.
This is tedious and the driver can be smarter if well-known tools
(like ptxas) can already be found in the PATH environment variable.
Add option --cuda-path-ignore-env if the user wants to ignore
set environment variables. Also use it in the tests to make sure
the driver always finds the same CUDA installation, regardless
of the user's environment.
Differential Revision: https://reviews.llvm.org/D42642
llvm-svn: 323848
Clang can use CUDA-9.1 now, though new APIs (are not implemented yet.
The major change is that headers in CUDA-9.1 went through substantial
changes that started in CUDA-9.0 which required substantial changes
in the cuda compatibility headers provided by clang.
There are two major issues:
* CUDA SDK no longer provides declarations for libdevice functions.
* A lot of device-side functions have become nvcc's builtins and
CUDA headers no longer contain their implementations.
This patch changes the way CUDA headers are handled if we compile
with CUDA 9.x. Both 9.0 and 9.1 are affected.
* Clang provides its own declarations of libdevice functions.
* For CUDA-9.x clang now provides implementation of device-side
'standard library' functions using libdevice.
This patch should not affect compilation with CUDA-8. There may be
some observable differences for CUDA-9.0, though they are not expected
to affect functionality.
Tested: CUDA test-suite tests for all supported combinations of:
CUDA: 7.0,7.5,8.0,9.0,9.1
GPU: sm_20, sm_35, sm_60, sm_70
Differential Revision: https://reviews.llvm.org/D42513
llvm-svn: 323713
Summary:
Fix NRVO for Gro variable.
Previously, we only marked the GRO declaration as an NRVO variable
when its QualType and the function return's QualType matched exactly
(using operator==). However, this was incorrect for two reasons:
1. We were marking non-class types, such as ints, as being NRVO variables.
2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL)
This patch fixes these bugs by marking the Gro variable as supporting NRVO only
when `BuildReturnStmt` marks the Gro variable as a coroutine candidate.
Reviewers: rsmith, GorNishanov, nicholas
Reviewed By: GorNishanov
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42343
llvm-svn: 323712
Summary:
The existing unit tests in FormatTestObjC.cpp didn't fully cover
all the cases for protocol confirmance list formatting.
This extends the unit tests to more cases of protocol
conformance list formatting, especially how the behavior changes
when `BinPackParameters` changes from `true` (the default) to `false`.
Test Plan: make -j12 FormatTests && \
./tools/clang/unittests/Format/FormatTests --gtest_filter=FormatTestObjC.\*
Reviewers: krasimir, jolesiak, stephanemoore
Reviewed By: krasimir
Subscribers: benhamilton, klimek, cfe-commits, hokein, Wizard
Differential Revision: https://reviews.llvm.org/D42649
llvm-svn: 323684
Summary:
This disables some of the most commonly used text proto delimiters and functions
for google style until we resolve several style options for that style.
In particular, wheter there should be a space surrounding braces ``msg { sub { key : value } }``
and the extent of packing of submessages on a same line.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42651
llvm-svn: 323678
Summary:
`clang-format -dump-config path/to/file.h` never passed
anything for the Code parameter to clang::format::getStyle().
This meant the logic to guess Objective-C from the contents
of a .h file never worked, because LibFormat didn't have the
code to work with.
With this fix, we now correctly read in the contents of the
file if possible with -dump-config.
I had to update the lit config for test/Format/ because
the default config ignores .h files.
Test Plan: make -j12 check-clang
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak, krasimir
Subscribers: Wizard, klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D42395
llvm-svn: 323668
Autoconf and some other systems tend to add essential compilation
options to CC (e.g. -std=gnu99). When running such an auto-generated
makefile, scan-build does not need to change CC and CXX as they are
already set to use ccc-analyzer by a configure script.
Implement a new option --keep-cc as was proposed in this discussion:
http://lists.llvm.org/pipermail/cfe-dev/2013-September/031832.html
Patch by Paul Fertser!
llvm-svn: 323665
clang's -x option doesn't accept c-cpp-output as a language (even though
463eb6ab was merged, the driver still doesn't handle that).
This bug prevents testing C language projects when ccache is used.
Fixes#25851.
Investigation and patch by Dave Rigby.
llvm-svn: 323664
Summary:
This change is step three in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API.
Step 4) Update Polly to use the new IRBuilder API.
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment()
and getSourceAlignment() instead.
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.
Reference
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.htmlhttp://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
Reviewers: rjmccall
Subscribers: jyknight, nemanjai, nhaehnle, javed.absar, sbc100, aheejin, kbarton, fedor.sergeev, cfe-commits
Differential Revision: https://reviews.llvm.org/D41677
llvm-svn: 323617
Rafael Espindola