James Molloy [Wed, 25 Jun 2014 11:46:24 +0000 (11:46 +0000)]
[AArch32] Fix a stupid error in an architectural guard
The < 8 instead of <= 8 meant that a bunch of vreinterprets were not available on v8 AArch32. Simplify the guard to just !defined(aarch64) while we're at it, and enable some v8 AArch32 testing.
David Majnemer [Wed, 25 Jun 2014 08:15:07 +0000 (08:15 +0000)]
AST: Initialization with dllimport functions in C
The C++ language requires that the address of a function be the same
across all translation units. To make __declspec(dllimport) useful,
this means that a dllimported function must also obey this rule. MSVC
implements this by dynamically querying the import address table located
in the linked executable. This means that the address of such a
function in C++ is not constant (which violates other rules).
However, the C language has no notion of ODR nor does it permit dynamic
initialization whatsoever. This requires implementations to _not_
dynamically query the import address table and instead utilize a wrapper
function that will be synthesized by the linker which will eventually
query the import address table. The effect this has is, to say the
least, perplexing.
Consider the following C program:
__declspec(dllimport) void f(void);
typedef void (*fp)(void);
static const fp var = &f;
const fp fun() { return &f; }
int main() { return fun() == var; }
MSVC will statically initialize "var" with the address of the wrapper
function and "fun" returns the address of the actual imported function.
This means that "main" will return false!
Note that LLVM's optimizers are strong enough to figure out that "main"
should return true. However, this result is dependent on having
optimizations enabled!
N.B. This change also permits the usage of dllimport declarators inside
of template arguments; they are sufficiently constant for such a
purpose. Add tests to make sure we don't regress here.
Zachary Turner [Wed, 25 Jun 2014 05:37:25 +0000 (05:37 +0000)]
Don't go through the TypeSourceInfo when getting the SourceRange.
VarDecl provides a method getSourceRange(), which provides a more
robust way of getting the SourceRange since the TypeSourceInfo can
be null in certain cases.
Reid Kleckner [Wed, 25 Jun 2014 00:28:35 +0000 (00:28 +0000)]
Fix parsing nested __if_exists blocks
Rather than having kw___if_exists be a special case of
ParseCompoundStatementBody, we can look for kw___if_exists in the big
switch over for valid statement tokens in ParseStatementOrDeclaration.
Nested __if_exists blocks are used in the DECLARE_REGISTRY_RESOURCEID
macro from atlcom.h.
Ben Langmuir [Tue, 24 Jun 2014 21:08:13 +0000 (21:08 +0000)]
Fix test issues from r211623 and remove test-only API
1) missing iterator bits needed by libstdc++4.7
Using find_if was convenient, but since operator++ wasn't a good
interface anyway, I just replaced with a range-based for loop and
removed operator++ from the directory_iterator class.
Rafael Espindola [Tue, 24 Jun 2014 20:01:50 +0000 (20:01 +0000)]
Correctly Load Mixed FP-GP Variadic Arguments for x86-64.
According to the x86-64 ABI, structures with both floating point and
integer members are split between floating-point and general purpose
registers, and consecutive 32-bit floats can be packed into a single
floating point register.
In the case of variadic functions these are stored to memory and the position
recorded in the va_list. This was already correctly implemented in
llvm.va_start.
The problem is that the code in clang for implementing va_arg was reading
floating point registers from the wrong location.
Ben Langmuir [Tue, 24 Jun 2014 19:37:16 +0000 (19:37 +0000)]
Add directory_iterator for (non-recursive) iteration of VFS directories
The API is based on sys::fs::directory_iterator, but it allows iterating
over overlays and the yaml-based VFS. For now, it isn't used by
anything (except its tests).
Alp Toker [Tue, 24 Jun 2014 19:23:10 +0000 (19:23 +0000)]
Simplify optimization-remark.c test following r211610
With LocTrackingOnly there's no longer a user-facing distinction so the NDEBUG
checks can go away. (Except maybe column info, but -verify only checks line
numbers anyway.)
Also add a RUN line to validate the traditional !LocTrackingOnly case.
Objective-C. When we use @selector(save:), etc. there may be more
than one method with mismatched type of same selector name.
clang issues a warning to point this out since it may cause
undefined behavior. There are cases though that some APIs
don't care about user methods and such warnings are perceived as
noise. This patch allows users to add paren delimiters around
selector name to turn off such warnings. So, @selector((save:)) will
turn off the warning. It also provides 'fixit' so user knows
what to do. // rdar://16458579
Diego Novillo [Tue, 24 Jun 2014 17:02:17 +0000 (17:02 +0000)]
Add new debug kind LocTrackingOnly.
Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
David Majnemer [Tue, 24 Jun 2014 06:40:51 +0000 (06:40 +0000)]
AST: Address of dllimport functions isn't constant
The address of dllimport functions can be accessed one of two ways:
- Through the IAT which is symbolically referred to with a symbol
starting with __imp_.
- Via the wrapper-function which ends up calling through the __imp_
symbol.
The problem with using the wrapper-function is that it's address will
not compare as equal in all translation units. Specifically, it will
compare unequally with the translation unit which defines the function.
David Majnemer [Tue, 24 Jun 2014 05:59:13 +0000 (05:59 +0000)]
AST: Address of dllimport variables isn't constant
The address of dllimport variables isn't something that can be
meaningfully used in a constexpr context and isn't suitable for
evaluation at load-time. They require loads from memory to properly
evaluate.
Nick Lewycky [Mon, 23 Jun 2014 22:57:51 +0000 (22:57 +0000)]
Propagate isAddressOfMember into typo correction so that we don't correct &qualified-id into &unqualified-id. Also make sure to set the naming class when we find the qualified-id in a different class than the nested name specifier specified so far. Fixes PR19681!
Ben Langmuir [Mon, 23 Jun 2014 16:36:40 +0000 (16:36 +0000)]
Stop sharing the FileManager in ASTUnit::Parse
We were using old stat values for any files that had previously been
looked up, leading to badness. There might be a more elegant solution in
invalidating the cache for those file (since we already know which ones
they are), but it seems too likely there are existing references to
them hiding somewhere.
NAKAMURA Takumi [Sun, 22 Jun 2014 12:42:29 +0000 (12:42 +0000)]
Revert r211402 (and r211408,r211410), "CodeGen: Refactor dynamic_cast and typeid" It crashes msvc codegen in clang/test/SemaCXX/undefined-internal.cpp.
Alp Toker [Sun, 22 Jun 2014 04:31:15 +0000 (04:31 +0000)]
Enable WindowsToolChain on all native Windows builds
Make binaries built by MSVC, mingw and clang functionally equivalent. The
checks are trivially performed at runtime to eliminate functional differences
between supported configurations that used to be hard-coded.
Alp Toker [Sun, 22 Jun 2014 03:27:52 +0000 (03:27 +0000)]
WindowsToolChain: decouple build environment from the toolchain
Don't try to find the MSVC version that the binaries were built with. Doing so
defeats testing by causing invalid test passes on the build servers.
Whichever Visual Studio (or clang-cl.exe) edition was used to build the clang
package, it's strictly orthogonal and has no relation to software versions
available on the user's PC.
Alp Toker [Sat, 21 Jun 2014 23:31:52 +0000 (23:31 +0000)]
TextDiagnostic: print remark level diagnostics in bold too
The purpose of bolding these is to make them visually distinct from
continuations (supplemental note diagnostics). Therefore, the bolding applies
to all severities _including_ remarks -- it's not in any way an indicator of
priority. Also simplify and comment.
David Majnemer [Sat, 21 Jun 2014 18:46:07 +0000 (18:46 +0000)]
Lex: Use the correct types for MS integer suffixes
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
Rafael Espindola [Sat, 21 Jun 2014 12:39:25 +0000 (12:39 +0000)]
Revert "Lex: Use the correct types for MS integer suffixes"
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
David Majnemer [Sat, 21 Jun 2014 00:51:59 +0000 (00:51 +0000)]
Lex: Use the correct types for MS integer suffixes
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
The version information for Visual Studio is spread over multiple variables.
The newer Windows SDK has started making use of some of the extended versioning
variables that were previously undefined. Enhance our compatibility definitions
for these cases.
_MSC_VER is defined to be the Major * 100 + Minor. _MSC_FULL_VER is defined to
be Major * 10000000 + Minor * 100000 + Build. And _MSC_BUILD is the build
revision of the compiler.
Extend the -fmsc-version option in a compatible manner. If the value is the
previous form of MMmm, then we assume that the build number is 0. Otherwise, a
specific build number may be passed by using the form MMmmbbbbb. Due to
bitwidth limitations of the option, it is currently not possible to define a
revision value.
The version information can be passed as either the decimal encoded value
(_MSC_FULL_VER or _MSC_VER) or as a dot-delimited value.
The change to the TextDiagnostic is to deal with the updated encoding of the
version information.
Justin Bogner [Fri, 20 Jun 2014 22:16:00 +0000 (22:16 +0000)]
Driver: Record that we're in crashdump and push flags to ConstructJob
It's more flexible and arguably better layering to set flags to modify
compiling for diagnostics in the CC1 job themselves, rather than
tweaking the driver flags and letting them propagate.
There is one visible change this causes: crash report files will now
get preprocessed names (.i and friends).
David Majnemer [Fri, 20 Jun 2014 21:11:00 +0000 (21:11 +0000)]
CodeGen: Refactor dynamic_cast and typeid
This refactors the emission of dynamic_cast and typeid expressions so
that ABI specific knowledge lives in appropriate places. There are
quite a few benefits for having the two implementations share a common
core like sharing logic for optimization opportunities.
Ulrich Weigand [Fri, 20 Jun 2014 16:37:40 +0000 (16:37 +0000)]
[PowerPC] Fix small argument stack slot offset for LE
When small arguments (structures < 8 bytes or "float") are passed in a
stack slot in the ppc64 SVR4 ABI, they must reside in the least
significant part of that slot. On BE, this means that an offset needs
to be added to the stack address of the parameter, but on LE, the least
significant part of the slot has the same address as the slot itself.
For the most part, this is handled in the LLVM back-end, where I just
fixed the LE case in commit r211368.
However, there is one piece of the clang front-end that is also aware of
these stack-slot offsets: PPC64_SVR4_ABIInfo::EmitVAArg. This patch
updates that routine to take endianness into account.
James Molloy [Fri, 20 Jun 2014 14:35:13 +0000 (14:35 +0000)]
The ability to use vector initializer lists is a GNU vector extension
and is unrelated to the NEON intrinsics in arm_neon.h. On little
endian machines it works fine, however on big endian machines it
exhibits surprising behaviour:
uint32x2_t x = {42, 64};
return vget_lane_u32(x, 0); // Will return 64.
Because of this, explicitly call out that it is unsupported on big
endian machines.
This patch will emit the following warning in big-endian mode:
test.c:3:15: warning: vector initializers are a GNU extension and are not compatible with NEON intrinsics [-Wgnu]
int32x4_t x = {0, 1, 2, 3};
^
test.c:3:15: note: consider using vld1q_s32() to initialize a vector from memory, or vcombine_s32(vcreate_s32(), vcreate_s32()) to initialize from integer constants
1 warning generated.
projects / clang / log