Clang implements the part of the ARM ABI saying that certain functions
(e.g., constructors and destructors) return "this", but Apple's version of
gcc and llvm-gcc did not. The libstdc++ dylib on iOS 5 was built with
llvm-gcc, which means that clang cannot safely assume that code from the C++
runtime will correctly follow the ABI. It is also possible to run into this
problem when linking with other libraries built with gcc or llvm-gcc. Even
though there is no way to reliably detect that situation, it is most likely
to come up when targeting older versions of iOS. Disabling the optimization
for any code targeting iOS 5 solves the libstdc++ problem and has a reasonably
good chance of fixing the issue for other older libraries as well.
<rdar://problem/16377159>
llvm-svn: 205272
Fallout from r205261, ensure it doesn't matter how we disable compressed
debug info, even if zlib is missing and that we warn when we don't have
zlib and don't warn when we do, all while silently suppressing these
tests on the systems they weren't intended for...
llvm-svn: 205271
It turns out that the ranges where the '?' <letter> manglings occur are
identical to the ranges of ASCII characters OR'd with 0x80.
Thanks to Richard Smith for the insight!
No functional change.
llvm-svn: 205270
Code review feedback from Eric Christopher on r204261.
I didn't want to go into too much detail (the revision history should
provide the full stuff) - but I can add more if that's preferred.
Also moved this up to right by the construction of the MCAsmInfo so
there's less chance that other things might sneak in in between.
llvm-svn: 205267
For those playing at home this produced some fairly subtle behavior. The
sections created in InitMCObjectFileInfo were created without compressed
debug info (a mistake, but not necessarily /broken). Since these
sections were almost always referenced by the existing MCSection object,
this almost worked.
This got weird when we got to handling the relocations for a section.
See ELFObjectWriter::WriteSection where we compute the true section for
a relocation section by simply stripping the ".rela" prefix and then
looking up that section - doing so hit the compression codepath, looked
up .zdebug_blah and found a newly constructed empty section... thus,
things got weird.
This is untestable without a cross-project test (let me know if people
would prefer that to no testing).
llvm-svn: 205261
This adds coverage for Unicode code points which are encoded with
non-zero values in the upper half of the wchar_t.
No functionality change.
llvm-svn: 205251
This removes a diagnostic that is no longer required (the semantic engine now properly handles attribute syntax so __declspec and __attribute__ spellings no longer get mismatched). This caused several testcases to need updating for a slightly different wording.
llvm-svn: 205234
Summary:
The definition of a type later in a translation unit may change it's
type from {}* to (%struct.foo*)*. Earlier function definitions may use
the former while more recent definitions might use the later. This is
fine until they interact with one another (like one calling the other).
In these cases, a bitcast is needed because the inalloca must match the
function call but the store to the lvalue which initializes the argument
slot has to match the rvalue's type.
This technique is along the same lines with what the other,
non-inalloca, codepaths perform.
This fixes PR19287.
Reviewers: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3224
llvm-svn: 205217
This adds support for the various NEON intrinsics used by
aarch64-neon-intrinsics.c (originally written for AArch64) and enables the
test.
My implementations are designed to be semantically correct, the actual code
quality looks like its a wash between the two backends, and is frequently
different (hence the large number of CHECK changes).
llvm-svn: 205210
A redeclaration may not add dllimport or dllexport attributes. dllexport is
sticky and can be omitted on redeclarations while dllimport cannot.
llvm-svn: 205197
Clean up the __has_attribute implementation without modifying its behavior.
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 205181
contents than the header file by the same name under the system header
search root. Surprisingly, this is required to get the test to pass on
some systems.
So, it turns out that there exist filesystems in the world which unique
the inode of all files based on their contents. This results in two
files with the same contents at different paths suddenly having the same
inode. This doesn't actually cause any problems in practice as the
contents are the same, and the path used to access the files are the
same. However, it can cause tests like this one to be more brittle
because the file manager ends up de-duplicating the file entries by
inode. We don't have any other really easy ways to observe the behavior
shift because the whole point is that the #include written in the source
code doesn't contain the information -- instead it is contained in the
header map.
If folks have other solutions they would prefer, I'm more than happy to
work on them, but this seems a reasonable way to ensure that the test in
question exercises the code it wants to exercise.
llvm-svn: 205149
Really, all tests outside of the Driver tree should use %clang_cc1, but
these are new and easy to fix, and many of them use buitlin headers
which don't work as well without using %clang_cc1.
llvm-svn: 205147
At least on REL6 (Linux/glibc 2.12), the proper symbol for generating gprof
data is _mcount, not mcount. Prior to this change, compiling with -pg would
generate linking errors (because of unresolved references to mcount), after
this change -pg seems at least minimally functional.
llvm-svn: 205144
Summary:
Declaring a function as inline after it has been defined is in violation
of [dcl.fct.spec]p4. The program would get a strong definition instead
of getting a function with linkonce_odr linkage.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3220
llvm-svn: 205129
The delta between '\xe1' and '\xc1' is equivalent to the one between 'a'
and 'A'. This allows us to reuse the computation between '\xe1' and
'\xfa' for the '\xc1' to '\xda' case.
No functionality change.
llvm-svn: 205128
Some ABIs and C++ libraries may make different trade-offs in how RTTI
is emitted (currently with respect to visibility and so on). This
implements one scheme, as used by ARM64.
llvm-svn: 205101
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
The peculiarities of C99 create scenario where an LLVM IR function
declaration may need to be replaced with a definition baring a different
type because the prototype and definition are not required to agree.
However, we were not properly deferring this when it occurred.
This fixes PR19280.
llvm-svn: 205099
Richard Smith