The AST was constructed so that this builtin returned the default BoolTy and
since I'd opted for custom SemaChecking, I should have set it properly at that
point.
This caused an assertion failure when the types didn't match up with what we
generated. This makes it return an IntTy, which is as good as anything.
llvm-svn: 193606
which doesn't use that multilib. As a consequence, fix Clang's support
for cross compiling environments that were relying on this quirk to
ensure the correct library search path ordering.
This also re-instates the new test cases from Rafael's r193528 for
cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the
existing test cases (they were no longer needed).
This solution was the result of a lot of IRC debugging and trying to
understand *exactly* what quirk was being relied upon. It took some time
for me to figure out that it was the use of 'lib32' is a multilib that
was throwing a wrench in the works.
In case you are thinking that its silly to use a multilib of 'lib' at
all, entertainingly, GCC does so as well (you can see it with the
.../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of
search paths (multilib followed by non-multilib) has observable (if
dubious) consequences. =/ Yuck.
llvm-svn: 193601
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
llvm-svn: 193549
With this patch we correctly determine that ubuntu's ARM tree is not biarch
and use "lib" istead of "lib32".
Without this patch the search inside the arm tree for the crt files was failing
and we would end up trying to use the i686 ones in lib32.
llvm-svn: 193528
We only considered FieldDecl and CXXMethodDecl as appropriate which
would cause us to believe the IndirectFieldDecl corresponded to an
argument of it's field type instead of a pointer-to-member type.
This fixes PR17696.
llvm-svn: 193461
We could certainly be more precise in many of our diagnostics, but before we
were printing "Assuming x is && y", which is just ridiculous.
<rdar://problem/15167979>
llvm-svn: 193455
GCC on fedora 18 ARM only uses 2 -L options. Clang prints two extra ones, but
we should not include them in the test as they are not required.
llvm-svn: 193430
Specifically, this warns when a character literal is added (using '+') to a
variable with type 'char *' (or any other pointer to character type). Like
-Wstring-plus-int, there is a fix-it to change "foo + 'a'" to "&foo['a']"
iff the character literal is on the right side of the string.
Patch by Anders Rönnholm!
llvm-svn: 193418
Change the uninitialized field warnings so that field initializers are checked
inside the constructor. Previously, in class initializers were checked
separately. Running one set of checks also simplifies the logic for preventing
duplicate warnings. Added new checks to warn when an uninitialized field is
used in base class initialization. Also fixed misspelling of uninitialized
and moved all code for this warning together.
llvm-svn: 193386
Although we wire up a bit for v8fp for macro setting
purposes, we don't set a macro yet. Need to ask list
about that.
Change-Id: Ic9819593ce00882fbec72757ffccc6f0b18160a0
llvm-svn: 193367
Adds some Cortex-A53 strings where they were missing before.
Cortex-A57 is entirely new to clang.
Doesn't touch code only used by Darwin, in consequence of which
one of the A53 lines has been removed.
Change-Id: I5edb58f6eae93947334787e26a8772c736de6483
llvm-svn: 193364
This GCC flag is useful when you want to control whether implicit
template instantiation occurs at the commandline level. Clang doesn't
currently support such controls, but technically *always* implicitly
instantiating (what Clang does, and what every other compiler still in
use does by default) is valid behavior even under
-fno-implicit-templates, it just may be slow and very wasteful. If
people really want this, we can try to implement it, but I don't have an
actual use.
This should help fix the build of libstdc++ with Clang, its build system
uses this flag.
llvm-svn: 193319
flag. We should probably wire at least some variants of this up to our
actual diagnostics engine, but I'm leaving that for someone else. This
fixes the builds of packages which hard code something here, at least
including libstdc++ itself.
llvm-svn: 193318
This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).
Two problems needed to be fixed which this patch exposed:
1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.
2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.
llvm-svn: 193314
Chris Wailes