Allow the proper recognition of Enum values and global variables inside ms inline-asm memory / immediate expressions, as they require some additional overhead and treated incorrect if doesn't early recognized.
supersedes D33278, D35774
Differential Revision: https://reviews.llvm.org/D37413
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314494 91177308-0d34-0410-b5e6-96231b3b80d8
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299316 91177308-0d34-0410-b5e6-96231b3b80d8
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290539 91177308-0d34-0410-b5e6-96231b3b80d8
This solves PR23715 in a way that is compatible with LTO.
MSVC supports jumping to source-level labels and between inline asm
blocks, but we don't.
Also revert the old solution, r255201, which was to mark these calls as
noduplicate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288059 91177308-0d34-0410-b5e6-96231b3b80d8
The purpose of this patch is to keep the same functionality without using LookupResult's implicit copy ctor and assignment operator, because they cause warnings when -Wdeprecated is passed.
This patch is meant to help the following review: http://reviews.llvm.org/D18123.
The functionality is covered by the tests in my original commit (255890)
The test case in this patch was added to test a bug caught in the review of the first version of this fix.
Differential Revision: http://reviews.llvm.org/D18175
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263630 91177308-0d34-0410-b5e6-96231b3b80d8
Build up a dependent expression for MS-style inline assembly if the
identifier's type is dependent.
This fixes PR26001.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256795 91177308-0d34-0410-b5e6-96231b3b80d8
In MS inline asm syntax a label with '$' char produces an error, while in AT&T it does not.
In AT&T inline asm syntax Clang escapes the '$' char and replaces it with "$$". Adopted same approach for MS syntax.
Differential Revision: http://reviews.llvm.org/D15795
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256545 91177308-0d34-0410-b5e6-96231b3b80d8
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
Several inputs may not refer to one output constraint in inline assembler
insertions, clang was failing on assertion on such test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248158 91177308-0d34-0410-b5e6-96231b3b80d8
Now we can parse code like this:
struct A {
int field;
};
int f(A o) {
__asm mov eax, o.field
}
Fixes PR19117.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246088 91177308-0d34-0410-b5e6-96231b3b80d8
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.
Patch by Andrey Bokhanko
Differential Revision: http://reviews.llvm.org/D10086
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239153 91177308-0d34-0410-b5e6-96231b3b80d8
During device-side CUDA compilation clang currently complains about
all TLS variables, regardless of whether they are __host__ or
__device__.
This patch suppresses "TLS unsupported" errors for host variables
during device compilation and for device variables during host
compilation.
Differential Revision: http://reviews.llvm.org/D9269
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235907 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, when the following piece of code was compiled, clang would
incorrectly warn that the size of "wide_two" does not match register size
specified by the constraint and modifier":
long wide_two = two;
asm ("%w0 %1" : "+r" (one), "+r"(wide_two));
This was caused by a miscalculation of ConstraintIdx in Sema::ActOnGCCAsmStmt.
This commit fixes PR21270 and rdar://problem/18668354.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228089 91177308-0d34-0410-b5e6-96231b3b80d8
Add additional constraint checking for target specific behaviour for inline
assembly constraints. We would previously silently let all arguments through
for these constraints. In cases where the constraints were violated, we could
end up failing to select instructions and triggering assertions or worse,
silently ignoring instructions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225244 91177308-0d34-0410-b5e6-96231b3b80d8
GCC permits array l-values in asm output operands even though they
aren't modifiable l-values. We used to permit it but this behavior
regressed in r224916.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224918 91177308-0d34-0410-b5e6-96231b3b80d8
Functions are l-values in C++ but shouldn't be available as output
parameters in inline assembly. Neither should overloaded function
l-values.
This fixes PR21949.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224916 91177308-0d34-0410-b5e6-96231b3b80d8
While we would correctly handle asm("foo") and reject asm(L"bar"), we
weren't careful to handle cases where an ascii literal could be
concatenated with a wide literal.
This fixes PR21822.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223992 91177308-0d34-0410-b5e6-96231b3b80d8
Clang won't emit any prologues for such functions, so it would assert trying to
codegen the parameter references.
This patch makes Clang check the extended asm inputs and outputs for
references to function parameters.
Differential Revision: http://reviews.llvm.org/D5640
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219272 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This fixes PR20023. In order to implement this scoping rule, we piggy
back on the existing LabelDecl machinery, by creating LabelDecl's that
will carry the "internal" name of the inline assembly label, which we
will rewrite the asm label to.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4589
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218230 91177308-0d34-0410-b5e6-96231b3b80d8
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217298 91177308-0d34-0410-b5e6-96231b3b80d8
variable that has regiser constraint "r" is not 64-bit.
General register operands are output using 64-bit "x" register names, regardless
of the size of the variable, unless the asm operand is prefixed with the "%w"
modifier. This surprises and confuses many users who aren't familiar with
aarch64 inline assembly rules.
With this commit, a note and fixit hint are printed which tell the users that
they need modifier "%w" in order to output a "w" register instead of an "x"
register.
<rdar://problem/12764785>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216260 91177308-0d34-0410-b5e6-96231b3b80d8
Coby Tayree