| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
t2.c:3:18: warning: expression result unused
x = ++x, ++y, y+2;
~~~~~~~~~~~~^ ~~~
llvm-svn: 41551
|
| |
|
|
|
|
| |
operator.
llvm-svn: 41550
|
| |
|
|
|
|
|
| |
directly in it. Remove TargetInfo::getEnumPolicy, as there is only
one policy that we support right now.
llvm-svn: 41548
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables that have a pointer type, or arrays that contain pointers.
This fixes a crash on the following code:
int *h[3];
int **foo(int i)
{
return &(h[i]);
}
This bug was reported by Keith Bauer (thanks!).
llvm-svn: 41546
|
| |
|
|
| |
llvm-svn: 41545
|
| |
|
|
| |
llvm-svn: 41544
|
| |
|
|
| |
llvm-svn: 41543
|
| |
|
|
| |
llvm-svn: 41533
|
| |
|
|
|
| |
TODO: update the types of the constants and the enum.
llvm-svn: 41532
|
| |
|
|
|
|
|
|
| |
t.c:1:12: warning: ISO C restricts enumerator values to range of 'int' (180388626432 is too large)
enum e {A, B = 42LL << 32, C = -4, D = 12456 };
^
llvm-svn: 41530
|
| |
|
|
| |
llvm-svn: 41528
|
| |
|
|
|
|
| |
Note the FIXME: we need some way to mark a decl erroneous :)
llvm-svn: 41524
|
| |
|
|
|
|
| |
implicit cast gets linked back into the AST.
llvm-svn: 41523
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types.
For example, the following code was resulting in spurious warnings. This was the result of
Sema::GetTypeForDeclarator() synthesizing a type to hand back to the caller (in this case,
"int []", instead of "struct s[]", which is invalid).
struct s;
struct s* t (struct s z[]) { // expected-error {{array has incomplete element type}}
return z;
}
Strategy: Flag the error in Declarator/DeclaratorChunk. This info is later stored in
the ParmVarDecl. If the decl is referenced, Sema::ParseIdentifierExpr() will check if
the type is invalid. If so, it quietly returns "true", without instantiating a DeclRefExpr.
This seems to work nicely. If Chris is happy with the approach, I will generalize this to
all VarDecls.
llvm-svn: 41521
|
| |
|
|
| |
llvm-svn: 41517
|
| |
|
|
| |
llvm-svn: 41515
|
| |
|
|
| |
llvm-svn: 41513
|
| |
|
|
| |
llvm-svn: 41499
|
| |
|
|
|
|
|
|
|
|
| |
implicit casts from T to T& at the topmost part of the return-value expression.
This checking may be needed within EvalAddr later on. We'll wait until
test cases show this kind of logic is necessary (as more C++ features are
implemented in clang).
llvm-svn: 41493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changed Sema::UsualArithmeticConversions to use the new API.
This fixes the following case...
_Complex double X;
double y;
void foo() {
X = X + y;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang complex.c -parse-ast-dump
Read top-level variable decl: 'X'
Read top-level variable decl: 'y'
void foo()
(CompoundStmt 0x2605cc0
(BinaryOperator 0x2605ca0 '_Complex double' '='
(DeclRefExpr 0x2605c10 '_Complex double' Decl='X' 0x2605ab0)
(BinaryOperator 0x2605c80 '_Complex double' '+'
(DeclRefExpr 0x2605c30 '_Complex double' Decl='X' 0x2605ab0)
(ImplicitCastExpr 0x2605c70 '_Complex double'
(DeclRefExpr 0x2605c50 'double' Decl='y' 0x2605ae0)))))
llvm-svn: 41483
|
| |
|
|
| |
llvm-svn: 41477
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified Type::typesAreCompatible() to use the above.
This fixes the following bug submitted by Keith Bauer (thanks!).
int equal(char *a, const char *b)
{
return a == b;
}
Also tweaked Sema::CheckCompareOperands() to ignore the qualifiers when
comparing two pointer types (though it doesn't relate directly to this bug).
llvm-svn: 41476
|
| |
|
|
|
|
|
|
|
| |
ASTContext::getFloatingTypeOfSizeWithinDomain().
Changed Sema::UsualArithmeticConversions to correctly implement complex/float conversions,
using maxFloatingType() with getFloatingTypeOfSizeWithinDomain().
llvm-svn: 41474
|
| |
|
|
| |
llvm-svn: 41473
|
| |
|
|
| |
llvm-svn: 41454
|
| |
|
|
|
|
|
|
|
|
| |
t.c:3:9: warning: invalid conversion '%B'
printf("%B\a\n", p);
~~~~~~ ^
Don't beep the console or print the newline.
llvm-svn: 41453
|
| |
|
|
| |
llvm-svn: 41452
|
| |
|
|
|
|
|
|
|
| |
Remove bogus type conversions in Sema::GetTypeForDeclarator(). This commit
only deals with the array types (DeclaratorCheck::Array), though the
rest of this routine should be reviewed. Given the complexity of C declarators,
I don't want to change the entire routine now (will discuss with Chris tomorrow).
llvm-svn: 41443
|
| |
|
|
|
|
|
|
| |
hold declarations. Instead, introduce a new "DeclScope" scope type that
holds them explicitly. For now, all scopes have this bit, but in the
future we can use them to fix some issues Neil noticed.
llvm-svn: 41431
|
| |
|
|
|
|
| |
fixes GCC PR33193
llvm-svn: 41428
|
| |
|
|
|
|
| |
specifier of functions.
llvm-svn: 41416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
represent imaginary literals:
float _Complex A;
void foo() {
A = 1.0iF;
}
generates:
(BinaryOperator 0x2305ec0 '_Complex float' '='
(DeclRefExpr 0x2305e60 '_Complex float' Decl='A' 0x2305cf0)
(ImaginaryLiteral 0x2305f40 '_Complex float'
(FloatingLiteral 0x2305ea0 'float' 1.000000))))
llvm-svn: 41413
|
| |
|
|
| |
llvm-svn: 41412
|
| |
|
|
|
|
| |
to merge duplicate code.
llvm-svn: 41410
|
| |
|
|
|
|
|
|
|
|
| |
char *C;
C != ((void*)0);
Should not warn about incompatible pointer types. Also, make sure to
insert an implicit conversion even if the operand is null.
llvm-svn: 41408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
change
eliminates the possibility that the left hand expression is an ImplicitCastExpr.
As a result, I removed the check for ImplicitCastExpr in Expr::isLvalue().
This results in the following AST's...
[dylan:~/llvm/tools/clang] admin% cat fix.c
short x; void test4(char c) {
x += c;
x = x + c;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang fix.c -parse-ast-dump
Read top-level variable decl: 'x'
void test4(char c)
(CompoundStmt 0x2605d30
(CompoundAssignOperator 0x2605c40 'short' '+='
(DeclRefExpr 0x2605c00 'short' Decl='x' 0x2605a80)
(DeclRefExpr 0x2605c20 'char' Decl='c' 0x2605bc0))
(BinaryOperator 0x2605d10 'short' '='
(DeclRefExpr 0x2605c60 'short' Decl='x' 0x2605a80)
(ImplicitCastExpr 0x2605d00 'short'
(BinaryOperator 0x2605ce0 'int' '+'
(ImplicitCastExpr 0x2605cc0 'int'
(DeclRefExpr 0x2605c80 'short' Decl='x' 0x2605a80))
(ImplicitCastExpr 0x2605cd0 'int'
(DeclRefExpr 0x2605ca0 'char' Decl='c' 0x2605bc0))))))
llvm-svn: 41404
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following:
******************** TEST 'Parser/cxx-bool.cpp' FAILED! ********************
Command:
clang -fsyntax-only Parser/cxx-bool.cpp
Output:
SemaExpr.cpp:731: failed assertion `!t.isNull() && "DefaultFunctionArrayConversion - missing type"'
Output/cxx-bool.cpp.out.script: line 1: 22697 Abort trap clang -fsyntax-only Parser/cxx-bool.cpp
llvm-svn: 41401
|
| |
|
|
| |
llvm-svn: 41398
|
| |
|
|
| |
llvm-svn: 41396
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"assignments",
while includes init decls, assignment exprs, call exprs, and return statements.
Here are a few examples with the correct AST's...
[dylan:~/llvm/tools/clang] admin% cat impcomp.c
_Complex double X;
void test2(int c) {
X = 5;
}
void foo() {
int i;
double d = i;
double _Complex a = 5;
test2(a);
a = 5;
d = i;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang impcomp.c -parse-ast-dump
Read top-level variable decl: 'X'
void test2(int c)
(CompoundStmt 0x2605ce0
(BinaryOperator 0x2605cc0 '_Complex double' '='
(DeclRefExpr 0x2605c70 '_Complex double' Decl='X' 0x2605af0)
(ImplicitCastExpr 0x2605cb0 '_Complex double'
(IntegerLiteral 0x2605c90 'int' 5))))
void foo()
(CompoundStmt 0x2606030
(DeclStmt 0x2605bd0
0x2605d90 "int i")
(DeclStmt 0x2605e20
0x2605de0 "double d =
(ImplicitCastExpr 0x2605e10 'double'
(DeclRefExpr 0x2605dc0 'int' Decl='i' 0x2605d90))")
(DeclStmt 0x2605e90
0x2605e50 "_Complex double a =
(ImplicitCastExpr 0x2605e80 '_Complex double'
(IntegerLiteral 0x2605e30 'int' 5))")
(CallExpr 0x2605f20 'void'
(ImplicitCastExpr 0x2605f00 'void (*)(int)'
(DeclRefExpr 0x2605ea0 'void (int)' Decl='test2' 0x2605c00))
(ImplicitCastExpr 0x2605f10 'int'
(DeclRefExpr 0x2605ec0 '_Complex double' Decl='a' 0x2605e50)))
(BinaryOperator 0x2605fa0 '_Complex double' '='
(DeclRefExpr 0x2605f50 '_Complex double' Decl='a' 0x2605e50)
(ImplicitCastExpr 0x2605f90 '_Complex double'
(IntegerLiteral 0x2605f70 'int' 5)))
(BinaryOperator 0x2606010 'double' '='
(DeclRefExpr 0x2605fc0 'double' Decl='d' 0x2605de0)
(ImplicitCastExpr 0x2606000 'double'
(DeclRefExpr 0x2605fe0 'int' Decl='i' 0x2605d90))))
llvm-svn: 41379
|
| |
|
|
| |
llvm-svn: 41377
|
| |
|
|
| |
llvm-svn: 41375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assignments,
it is o.k. for the LHS and RHS to have different types. Converting the type can cause
errors like the one Chris noticed (below).
This change required a fair number of diffs (since there is a lot of shared code
between single and compound assignments). This makes the API's look a bit uglier,
however I couldn't think of a better way to do it (without duplicating code).
Fix the following (incorrect) error:
int A;
long long B;
void foo() {
A /= B;
}
$ clang ~/scalar.c -emit-llvm
/Users/sabre/scalar.c:6:5: error: expression is not assignable
A /= B;
~ ^
Now it works properly...
[dylan:~/llvm/tools/clang] admin% cat compound.c
int A;
long long B;
void foo() {
A /= B;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang compound.c -parse-ast-dump
Read top-level variable decl: 'A'
Read top-level variable decl: 'B'
void foo()
(CompoundStmt 0x2605c40
(BinaryOperator 0x2605c20 'int' '/=' ComputeTy='long long'
(DeclRefExpr 0x2605be0 'int' Decl='A' 0x2605a80)
(DeclRefExpr 0x2605c00 'long long' Decl='B' 0x2605ab0)))
llvm-svn: 41364
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we emit the following when -pedantic-errors is enabled...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang complex.c -pedantic-errors
complex.c:4:3: error: ISO C does not support '++'/'--' on complex integer types
++x;
^ ~
complex.c:9:7: error: ISO C does not support '~' for complex conjugation
X = ~Y;
^
complex.c:10:7: error: ISO C does not support '~' for complex conjugation
x = ~y;
^
llvm-svn: 41362
|
| |
|
|
|
|
|
|
|
| |
fixes an assertion on:
void f (int z) { switch (z) { case ~0ULL: case -1: return; } }
testcase from Neil.
llvm-svn: 41343
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This following now compiles without error...
_Complex unsigned X, Y;
_Complex double x, y;
void test2(int c) {
X = ~Y;
x = ~y;
}
llvm-svn: 41341
|
| |
|
|
| |
llvm-svn: 41340
|
| |
|
|
|
|
|
|
|
|
|
| |
Now, the following test case succeeds...
_Complex double x, y;
void test2(int c) {
++x;
}
llvm-svn: 41335
|
| |
|
|
|
|
| |
verifying case ranges.
llvm-svn: 41331
|
| |
|
|
|
|
|
|
| |
switch.c:16:8: warning: empty case range specified
case 100 ... 99: ; // expected-warning {{empty case range}}
^~~~~~~~~~
llvm-svn: 41328
|