Hans Wennborg [Thu, 11 Jun 2015 21:21:57 +0000 (21:21 +0000)]
[ms] Do lookup in dependent base classes also when overload resolution fails (PR23810)
This patch does two things in order to enable compilation of the problematic code in PR23810:
1. In Sema::buildOverloadedCallSet, it postpones lookup for MS mode when no
viable candidate is found in the overload set. Previously, lookup would only
be postponed here if the overload set was empty.
2. Make BuildRecoveryCallExpr call Sema::DiagnoseEmptyLookup under more circumstances.
There is a comment in DiagnoseTwoPhaseLookup that says "Don't diagnose names we find in
classes; we get much better diagnostics for these from DiagnoseEmptyLookup." The problem
was that DiagnoseEmptyLookup might not get called later, and we failed to recover.
Ahmed Bougacha [Thu, 11 Jun 2015 18:19:34 +0000 (18:19 +0000)]
[CodeGen] Emit Constants for immediate inlineasm arguments.
For inline assembly immediate constraints, we currently always use
EmitScalarExpr, instead of directly emitting the constant. When the
overflow sanitizer is enabled, this generates overflow intrinsics
instead of constants.
Instead, emit a constant for constraints that either require an
immediate (e.g. 'I' on X86), or only accepts constants (immediate
or symbolic; i.e., don't accept registers or memory).
Sanjay Patel [Thu, 11 Jun 2015 14:53:41 +0000 (14:53 +0000)]
add the -mrecip driver flag and process its options (3rd try)
The 1st and 2nd tries to land this (r238055, r238851) were reverted due to
bot failures caused by the LLVM part of the patch. That was hopefully fixed
after r239001.
This is the front-end counterpart to D8982.
The -mrecip option interface is based on maintaining compatibility with gcc:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289
...while adding more functionality (allowing users to specify the number of refinement steps for each
estimate type).
Daniel Jasper [Thu, 11 Jun 2015 13:31:45 +0000 (13:31 +0000)]
clang-format: Make SFS_Inline imply SFS_Empty.
In the long run, these two might be independent or we might to only
allow specific combinations. Until we have a corresponding request,
however, it is hard to do the right thing and choose the right
configuration options. Thus, just don't touch the options yet and
just modify the behavior slightly.
Richard Smith [Wed, 10 Jun 2015 20:30:23 +0000 (20:30 +0000)]
[modules] Track all default template arguments for a given parameter across
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
Serge Pavlov [Wed, 10 Jun 2015 19:06:59 +0000 (19:06 +0000)]
Do not parse members of incomplete class.
If definition of a class is unknown and out-of-line definition of its
member is encountered, do not parse the member declaration.
This change fixes PR18542.
Teresa Johnson [Wed, 10 Jun 2015 17:49:45 +0000 (17:49 +0000)]
Pass down the -flto option to the -cc1 job, and from there into the
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
Alexander Musman [Wed, 10 Jun 2015 11:20:26 +0000 (11:20 +0000)]
PR5172: Fix for a bug in pragma redefine_extname implementation:
it doesn't work correctly when a structure is declared before pragma
and then a function with the same name declared after pragma.
Richard Smith [Wed, 10 Jun 2015 01:47:58 +0000 (01:47 +0000)]
[modules] Reconstruct template default argument inheritance on reload rather
than wasting storage and triggering eager deserializations by serializing it.
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Daniel Jasper [Tue, 9 Jun 2015 11:39:22 +0000 (11:39 +0000)]
clang-format: [JS] Hotfix for runtime issue with deeply nested JS code.
I have not succeeded in writing a proper test case for this yet and we
also need to solve the underlying fundamental problem of trying too
many combinations with nested blocks (basically this somewhat works
around our Dijkstra algorithm). Preventing this linebreak is good
anyways as usually the penalties never make us choose it (that's why I
can't create a test) and it also looks ugly.
Also cleaned up state comparison code that I discovered while hunting
this down.
David Majnemer [Tue, 9 Jun 2015 06:30:01 +0000 (06:30 +0000)]
[Driver] Preserve the object file format in ComputeEffectiveClangTriple
The object file format is sometimes overridden for MSVC targets to use
ELF instead of COFF. Make sure we preserve this choice when setting the
msvc version number in the triple.
David Majnemer [Tue, 9 Jun 2015 02:41:08 +0000 (02:41 +0000)]
[MSVC Compatibility] Don't diagnose c-style cast from void-ptr to fn-ptr
The machinery added to permit a static_cast from void-ptr to fn-ptr
unintentionally gets triggered for c-style casts and function-style
casts. The observable effect was a diagnostic issued inappropriately.
Hans Wennborg [Tue, 9 Jun 2015 00:39:09 +0000 (00:39 +0000)]
Enable DLL attribute propagation on explicit instantiation definitions (PR23770)
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
Hans Wennborg [Tue, 9 Jun 2015 00:39:03 +0000 (00:39 +0000)]
Enable propagation of dll attributes to previously instantiated base class templates in some cases
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
Hans Wennborg [Tue, 9 Jun 2015 00:38:56 +0000 (00:38 +0000)]
Narrow the -Wunsupported-dll-base-class-template warning.
Don't warn about not being able to propagate dll attribute to a base class template
when that base already has a different attribute.
MSVC doesn't actually try to do this; the first attribute that was propagated
takes precedence, so Clang is already doing the right thing and there's no
need to warn.
Richard Smith [Tue, 9 Jun 2015 00:35:49 +0000 (00:35 +0000)]
[modules] Fix some visibility issues with default template arguments.
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
Tyler Nowicki [Mon, 8 Jun 2015 23:13:43 +0000 (23:13 +0000)]
Correct Loop Hint Diagnostic Message
When pragma clang loop unroll() is specified without an argument the diagnostic message should inform that user that 'full' and 'disable' are valid arguments (not 'enable').
Hubert Tong [Mon, 8 Jun 2015 21:59:59 +0000 (21:59 +0000)]
Consider unsigned long for non-u/U decimal literals (C90/C++03)
Summary:
This modifies Clang to reflect that under pre-C99 ISO C, decimal
constants may have type `unsigned long` even if they do not contain `u`
or `U` in their suffix (C90 subclause 6.1.3.2 paragraph 5). The same is
done for C++ without C++11 which--because of undefined behaviour--allows
for behaviour compatible with ISO C90 in the case of an unsuffixed
decimal literal and is otherwise identical to C90 in its treatment of
integer literals (C++03 subclause 2.13.1 [lex.icon] paragraph 2).
Messages are added to the `c99-compat` and `c++11-compat` groups to warn
on such literals, since they behave differently under the newer
standards.
Fixes PR 16678.
Test Plan:
A new test file is added to exercise both pre-C99/C++11 and C99/C++11-up
on decimal literals with no suffix or suffixes `l`/`L` for both 32-bit
and 64-bit `long`.
In the file, 2^31 (being `INT_MAX+1`) is tested for the expected type
using `__typeof__` and multiple declarations of the same entity. 2^63
is similarly tested when it is within the range of `unsigned long`.
Preprocessor arithmetic tests are added to ensure consistency given
that Clang (like GCC) uses greater than 32 bits for preprocessor
arithmetic even when `long` and `unsigned long` is 32 bits and a
pre-C99/C++11 mode is in effect.
Fix for PR14269: Clang crashes when a bit field is used as inline assembler
input / output with memory constraint.
One generally can't get address of a bit field, so the general solution is to
error on such cases. GCC does the same.
John Brawn [Fri, 5 Jun 2015 13:34:11 +0000 (13:34 +0000)]
[ARM] Use TargetParser to determine FPU subtarget features
The main effect of this is to fix anomalies where certain -mfpu options didn't
disable everything that they should causing strange behaviour when combined
with -mcpu or -march values that themselves enabled fpu subtarget features,
e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as
-mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled.
Invalid -mfpu options now also give an error, which is consistent with the
handling of the .fpu directive.
Hubert Tong [Fri, 5 Jun 2015 01:10:24 +0000 (01:10 +0000)]
[Concepts] lex keywords: concept and requires
Summary:
This patch enables lexing of `concept` and `requires` as keywords.
Further changes which add messages for future keyword compat are to
follow.
Test Plan:
Testing of C++14 + Concepts TS mode is added to
`test/Lexer/keywords_test.cpp`, which expects that the new keywords are
enabled under said mode.
Bill Seurer [Thu, 4 Jun 2015 18:45:44 +0000 (18:45 +0000)]
[PowerPC] This revision adds 68 of the missing "Predefined Functions for Vector Programming" from appendix A of the OpenPOWER ABI for Linux Supplement document.
I also added tests for the new functions and updated another test that was looking for specific line numbers in error messages from altivec.h.
James Y Knight [Thu, 4 Jun 2015 15:36:29 +0000 (15:36 +0000)]
[SPARC] Fix types of size_t, intptr_t, and ptrdiff_t on Linux.
They should be 'int' instead of 'long int' everywhere else except
NetBSD too, from what I gather in GCC's spec files. So, optimistically
changing it for everyone else, too.
James Y Knight [Thu, 4 Jun 2015 04:15:33 +0000 (04:15 +0000)]
Fix fragile source-col-map.c test-case.
The test passing was dependent upon your source tree being checked out
in a directory with a long enough path, to cause the diagnostics to
wrap at the expected locations.
Use stdin instead, so that the error messages consistently use
<stdin> as the filename, and get wrapped consistently.
Ahmed Bougacha [Thu, 4 Jun 2015 01:43:41 +0000 (01:43 +0000)]
[CodeGen][NEON] Emit constants for "immediate" intrinsic arguments.
On ARM/AArch64, we currently always use EmitScalarExpr for the immediate
builtin arguments, instead of directly emitting the constant. When the
overflow sanitizer is enabled, this generates overflow intrinsics
instead of constants, breaking assumptions in various places.
Instead, use the knowledge of "immediates" to directly emit a constant:
- teach the tablegen backend to emit the "immediate" modifiers
- use those modifiers in the NEON CodeGen, on ARM and AArch64.
projects / clang / log