At this point, it's clear that the MSVC mangler uses the type-as-written
instead of the canonical type, so this should bring us closer to MSVC.
The main thrust of this change is to fix the way we mangle decayed array
parameters of function pointer parameters. With a DecayedType sugar
node, this code can now be much simpler.
Fixes PR16096.
This also fixes a separate issue that Richard spotted in review.
Because separate declarations of the same entity can be spelled and
mangled differently, MSVC always mangles the earliest declaration in an
attempt to avoid link errors. Clang now does the same.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D844
llvm-svn: 184777
The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
llvm-svn: 184763
print-size-type.cpp was checking for specific record layout output for invalid
decls; I've removed the checks but left the records as tests for not crashing.
llvm-svn: 184751
constructing a lookup table.
Previously, buildLookup would add lookup table entries for each item lexically
within the DC, and adding the first entry with a given name would trigger the
external source to add all its entries with that name. Then buildLookup would
carry on and re-add those entries all over again.
Instead, follow a simple rule: a declaration from an external source is only
ever made visible by the external source. One exception to this: since we don't
usually build a lookup table for the TU in C, and we never serialize one, we
don't expect the external source to provide lookups in the TU in C, so we build
those ones ourselves.
llvm-svn: 184696
There's still a problem here - since we're not appropriately using the
signedness/range of the enum to chooset the encoding and emission of
enumerators, but GCC has some bugs around this too so I assume that's
not /such/ a high priority though I may get to it soon out of
completeness.
llvm-svn: 184695
whether they replace any existing lookups in the context, rather than
accumulating a bunch of lookup results referring to the same entity.
llvm-svn: 184679
when specifying --coverage (or related) flags.
The system for doing this was based on the old LLVM-hosted profile_rt
library, and hadn't been updated for Linux to use the new compiler-rt
library. Also, it couldn't possibly work on multiarch or biarch systems
in many cases. The whole thing now works much the same as the sanitizer
libraries that are built and used out of the compiler-rt repo.
Note that other target OSes haven't been updated because I don't know if
they're doing anything special with the installation path of profile_rt.
I suspect however that *all* of these are wrong and would encourage
maintainers of each target to take a hard look at how compiler-rt
runtime libraries are linked on their platforms.
llvm-svn: 184666
verifies that we run the assembler and linker in the correct mode, and
that we can successfully use a bi-arch variant of a GCC installation in
a generic cross compilation invocation of Clang.
llvm-svn: 184662
Remove unneeded member in CommentSema, add a test for the XML schema (the
schema already allowed multiple paragraphs in <ResultDiscussion>, but there
were no tests for that), fix HTML generation (it is not allowed to have <p>
inside <dl>).
llvm-svn: 184652
The problem with r183462 was that we assumed that a diagnostic id of
zero would be silent.
This small correction to CheckDerivedToBaseConversion changes it's
behavior to omit the diagnostic when given a diagnostic id of zero.
This fix passes the test case added in r184402.
llvm-svn: 184631
This fixes false positives by allowing us to know that a loop is always entered if
the collection count method returns a positive value and vice versa.
Addresses radar://14169391.
llvm-svn: 184618
Empty structs are ignored for parameter passing purposes, but va_arg was
incrementing the pointer anyway which could lead to va_list getting out of
sync.
llvm-svn: 184605
According to the Itanium ABI (3.1.1), types with non-trivial copy constructors
passed by value should be passed indirectly, with the caller creating a
temporary.
We got this mostly correct, but forgot that empty structs can have non-trivial
constructors too and passed them incorrectly. This simply reverses the order of
the check.
llvm-svn: 184603
Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.
This reverts r184511 / 98123284826bb4ce422775563ff1a01580ec5766.
llvm-svn: 184561
Itanium destroys them in the caller at the end of the full expression,
but MSVC destroys them in the callee. This is further complicated by
the need to emit EH-only destructor cleanups in the caller.
This should help clang compile MSVC's debug iterators more correctly.
There is still an outstanding issue in PR5064 of a memcpy emitted by the
LLVM backend, which is not correct for C++ records.
Fixes PR16226.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D929
llvm-svn: 184543
This is to make test cases looking for definitions more legible by
making the definition explicit rather than just the absence of '[fwd]'.
This allowed the debug-info-record tests to be rephrased - and in the
interests of reducing the number of individual test cases/invocations we
have, I merged them into one file, separated them with namespaces (&
then moved them to C++ because namespaces are great). If they need to
remain 'C' only tests, they can be moved back. (I didn't group them with
'debug-info-class.cpp' because these tests only apply to
-fno-limit-debug-info)
I removed the pieces of code that would cause these tests to pass under
-flimit-debug-info to ensure the tests remain relevant to their fixes
should we ever improve -flimit-debug-info to catch that kind of code.
This commit is version locked with the corresponding change to
DebugInfo.h in LLVM. Except some transient buildbot fallout.
llvm-svn: 184524
Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.
As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.
<rdar://problem/14212563>
llvm-svn: 184511
As an optimization, we only kept declared methods with distinct
signatures in the global method pool, to keep the method lists
small. Under modules, however, one could have two different methods
with the same signature that occur in different (sub)modules. If only
the later submodule is important, message sends to 'id' with that
selector would fail because the first method (the only one that got
into the method pool) was hidden. When building a module, keep *all*
of the declared methods.
I did a quick check of both module build time and uses of modules, and
found no performance regression despite this causing us to keep more
methods in the global method pool. Fixes <rdar://problem/14148896>.
llvm-svn: 184504
directory for programs used by the driver is actually the standard
behavior we want to be compatible with GCC cross compilers -- it isn't
specific to SUSE or any other distro.
Also start fleshing out testing of the different cross compilation
patterns, both with a new very bare-bones tree of cross compilers and by
extending the multilib trees. Currently, we don't correctly model doing
a cross compile using the non-triple target of a bi-arch GCC install,
but I'll add support for that (and tests) next.
llvm-svn: 184499
This will enable users in security critical applications to perform
checked-arithmetic in a fast safe manner that is amenable to c.
Tests/an update to Language Extensions is included as well.
rdar://13421498.
llvm-svn: 184497
r174939-40 caused us to do this in the canonical terminate lpad,
but when the EH stack has other cleanups on it we use the
terminate handler block, which wasn't doing this.
Fixes the rest of rdar://11904428 given appropriate stdlib support.
llvm-svn: 184475
On Windows, it looks like FlagIndirectVariable is being set in Flags for
DIBuilder::createLocalVariable(), giving us an i32 of 8192 instead of 0,
as on Linux.
Fixes breakage from r184367.
llvm-svn: 184438
-gcc-toolchain foo -> --gcc-toolchain=foo
-target foo -> --target=foo
I've added legacy aliases for the original spellings. I've updated the
canonical tests to check both spellings, and switched all of the
-gcc-toolchain usages elsewhere in the test suite to use the new one.
I've updated some of the usages of -target to the new syntax, but will
finish that in a separate entirely mechanical change once I'm sure this
won't get rolled back for some reason (It touches a *huge* number of RUN
lines in the test suite unsurprisingly).
A nice result is that the three most common flags I end up using when
doing cross compiles are all now consistent: --target=, --sysroot=, and
--gcc-toolchain=.
llvm-svn: 184408
Summary:
When doing a reinterpret+dynamic cast from an incomplete type, the analyzer
would crash (bug #16308). This fix makes the dynamic cast evaluator ignore
incomplete types, as they can never be used in a dynamic_cast. Also adding a
regression test.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1006
llvm-svn: 184403
return false;
in a function returning a pointer. 'false' was a null pointer constant in C++98
but is not in C++11. Punch a very small hole in the initialization rules in
C++11 mode to allow this specific case in system headers.
llvm-svn: 184395
This will allow for longer running FileCheck based tests to be committed to
clang for use on buildbots, preventing the normal make-check cycle from
increasing in time significantly.
This is a necessary change in order to commit the end-to-end arm neon intrinsic
tests since FileCheck takes ~20 seconds to run said test due to the large amount
of neon intrinsics.
To force a test to run only when --param run_long_tests=true is passed in use
the following requires statement:
// REQUIRES: long_tests
llvm-svn: 184385
This is to fix the location information for such parameters to refer to
the object accessible through the pointer rather than to the pointer
parameter itself.
llvm-svn: 184367
1) Removed useless return value of CGCXXABI::EmitConstructorCall and CGCXXABI::EmitVirtualDestructorCall and implementations
2) Corrected last portion of CodeGenCXX/constructor-destructor-return-this to correctly test for non-'this'-return of virtual destructor calls
llvm-svn: 184330
In Itanium, dynamic classes have one vtable with several different
address points for dynamic base classes that can't share vtables.
In the MS C++ ABI, each vbtable that can't be shared gets its own
symbol, similar to how ctor vtables work in Itanium. However, instead
of mangling the subobject offset into the symbol, the unique portions of
the inheritance path are mangled into the symbol to make it unique.
This patch implements the MSVC 2012 scheme for forming unique vbtable
symbol names. MSVC 2010 use the same mangling with a different subset
of the path. Implementing that mangling and possibly others is TODO.
Each vbtable is an array of i32 offsets from the vbptr that points to it
to another virtual base subobject. The first entry of a vbtable always
points to the base of the current subobject, implying that it is the
same no matter which parent class contains it.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D636
llvm-svn: 184309
gcc's inputs are already added by the InputInfoList passed to
Action::ConstructJob.
Fixes a regression from r183989. This was manifesting when targetting
mingw as an extra input argument to gcc when assembling. It presumably
affects other situations where clang calls gcc.
Prior to r183989, forwardToGCC() was returning false because the INPUT
option defined in OptParser.td had the DriverOption flag set on it.
LLVM's Option library does not set this flag for INPUT.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D999
llvm-svn: 184308
Summary:
When processing a call to a function, which got passed less arguments than it
expects, the analyzer would crash.
I've also added a test for that and a analyzer warning which detects these
cases.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D994
llvm-svn: 184288
These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.
llvm-svn: 184276
This silences warnings that could occur when one is swapping partially initialized structs. We suppress
not only the assignments of uninitialized members, but any values inside swap because swap could
potentially be used as a subroutine to swap class members.
This silences a warning from std::try::function::swap() on partially initialized objects.
llvm-svn: 184256
Reid Kleckner