to variables that are no longer live. This analysis is built on top
of CFGs and the LiveVariables analysis.
changes to driver:
added driver option "-check-dead-stores" to run the analysis
llvm-svn: 41754
source-level CFGs. This code may change significantly in the near
future as we explore different means to implement dataflow analyses.
Added a driver option, -dump-live-variables, to view the output of
live variable analysis. This output is very ALPHA; it will be improved shortly.
llvm-svn: 41737
- ArrayType::getBaseType(), and
- ConstantArrayType::getMaximumElements().
Wanted to do this cleanup before adding structure support, which will add more complexity.
llvm-svn: 41715
warn about the last stmt in a stmtexpr, f.e. there should be no warning for:
int maxval_stmt_expr(int x, int y) {
return ({int _a = x, _b = y; _a > _b ? _a : _b; });
}
llvm-svn: 41655
be passed as an (optional) argument to StmtPrinter to customize
printing of AST nodes.
Used new PrinterHelper interface to enhance printing and visualization
of CFGs. The CFGs now illustrate the semantic connectives between
statements and terminators, wheras in the previous printing certain
expressions would (visible) be printed multiple times to reflect which
expressions used the results of other expressions.
The end result is that the CFG is easier to read for flow of
expression values (following principles similar to the LLVM IR).
llvm-svn: 41651
For example, -parse-ast-dump now prints:
static inline int __inline_isinff(float __x)
(CompoundStmt 0x2409a20
(ReturnStmt 0x2409a10
(BinaryOperator 0x24099f0 'int' <///usr/include/architecture/i386/math.h:183:63, col:102> '=='
(CallExpr 0x24098f0 'float' <col:63, col:82>
(ImplicitCastExpr 0x24098e0 'float (*)(float)' <col:63>
(DeclRefExpr 0x2409880 'float (float)' <col:63> Decl='__builtin_fabsf' 0x2409840))
(DeclRefExpr 0x24098a0 'float' <col:79> Decl='__x' 0x2409810))
(CallExpr 0x24099c0 'float' <col:87, col:102>
(ImplicitCastExpr 0x2409870 'float (*)(void)' <col:87>
(DeclRefExpr 0x2409980 'float (void)' <col:87> Decl='__builtin_inff' 0x2409940))))))
where it only prints filename/line# if it changes from the previous value. We
really need loc info on stmts though, like we have on exprs.
llvm-svn: 41602
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
This means that we get rid of tons of intermediate allocas. For
example:
void foo(double _Complex a, double _Complex b) {
a = b+a+a;
}
this used to have 4 temporary allocas, now it has zero of them.
This also simplifies the individual visitor methods because they
now can all operate on real/imag pairs instead of having to
load/store all over the place.
llvm-svn: 41217
"I've coded up some support in clang to flag warnings for non-constant format strings used in calls to printf-like functions (all the functions listed in "man fprintf"). Non-constant format strings are a source of many security exploits in C/C++ programs, and I believe are currently detected by gcc using the flag -Wformat-nonliteral."
llvm-svn: 41003
the AST in a structural, non-pretty, form useful for understanding
the AST. It isn't quite done yet, but is already somewhat useful.
For this example:
int test(short X, long long Y) {
return X < ((100));
}
we get (with -parse-ast-dump):
int test(short X, long long Y)
(CompoundStmt 0x2905ce0
(ReturnStmt 0x2905cd0
(BinaryOperator 0x2905cb0 '<'
(ImplicitCastExpr 0x2905ca0
(DeclRefExpr 0x2905c20 Decl='X' 0x2905bb0))
(ParenExpr 0x2905c80
(ParenExpr 0x2905c60
(IntegerLiteral 0x2905c40 100))))))
llvm-svn: 40954
This test case currently generates the following unexpected warnings (when compared with gcc).
[dylan:clang/test/Parser] admin% ../../../../Debug/bin/clang -parse-ast-check builtin_types_compatible.c
Warnings seen but not expected:
Line 28: expression result unused
Line 29: expression result unused
Line 30: expression result unused
Line 31: expression result unused
Line 32: expression result unused
Line 33: expression result unused
llvm-svn: 40789
This resulted in the following errors when compiling promote_types_in_proto.c test...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang test/Parser/promote_types_in_proto.c
test/Parser/promote_types_in_proto.c:7:24: error: incompatible types passing 'char *[]' to function expecting 'char *const []'
arrayPromotion(argv);
~~~~~~~~~~~~~~ ^~~~
test/Parser/promote_types_in_proto.c:8:27: error: incompatible types passing 'void (char *const [])' to function expecting 'void (char *const [])'
functionPromotion(arrayPromotion);
~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~
2 diagnostics generated.
When fixing this, noticed that both ParseCallExpr() and ParseReturnStmt() were prematurely comparing types for
equivalence. This is incorrect (since the expr. promotions haven't been done yet). To fix this, I moved the
check "down" to Sema::CheckAssignmentConstraints().
I also converted Type::isArrayType() to the modern API (since I needed it). Still more Type predicates to
convert.
llvm-svn: 40475
bottleneck for -E computation, because every token that starts a line needs
to determine *which* line it is on (so -E mode can insert the appropriate
vertical whitespace). This optimization improves this common case where
it is striding through the line # table.
This speeds up -E on xalancbmk by 3.2%
llvm-svn: 40459
needs to query the expression for the type. Since both these functions guarantee the expression
contains a valid type, removed old/vacuous asserts (from code calling both of these routines).
llvm-svn: 39930
accurate diagnostics. For test/Lexer/comments.c we now emit:
int x = 000000080; /* expected-error {{invalid digit}} */
^
constants.c:7:4: error: invalid digit '8' in octal constant
00080; /* expected-error {{invalid digit}} */
^
The last line is due to an escaped newline. The full line looks like:
int y = 0000\
00080; /* expected-error {{invalid digit}} */
Previously, we emitted:
constants.c:4:9: error: invalid digit '8' in octal constant
int x = 000000080; /* expected-error {{invalid digit}} */
^
constants.c:6:9: error: invalid digit '8' in octal constant
int y = 0000\
^
which isn't too bad, but the new way is better for the user,
regardless of whether there is an escaped newline or not.
All the other lexer-related diagnostics should switch over
to using AdvanceToTokenCharacter where appropriate. Help
wanted :).
This implements test/Lexer/constants.c.
llvm-svn: 39906
Submitted by:
Reviewed by:
Removed Attr.[h,cpp]...they didn't have any useful content.
When more (GCC) attributes are added, we might want to create a file
of this ilk. For now, it's better to remove them (to eliminate any confusion).
I also update the Xcode project file...
llvm-svn: 39729
Submitted by:
Reviewed by:
Lot's of attribute scaffolding.
Modernized ParseArraySubscriptExpr...call DefaultFunctionArrayConversion (which
simplified the logic considerably) and upgrade Diags to use the range support.
llvm-svn: 39628
diag.c:1:9: error: invalid digit '8' in octal constant
int x = 000080;
^
diag.c:2:9: error: invalid digit 'A' in decimal constant
int z = 1000080ABC;
^
instead of:
diag.c:1:9: error: invalid suffix '80' on integer constant
int x = 000080;
^
diag.c:2:9: error: invalid suffix 'ABC' on integer constant
int z = 1000080ABC;
^
llvm-svn: 39605
Reviewed by: Chris Lattner
- Separated out the diagnostic client from the clang driver. This is in
preparation for creating a diagnostic client that will be used to check
error and warning messages.
llvm-svn: 39603
Submitted by:
Reviewed by:
The following code illustrates a bug in the semantic analysis for assignments:
int func() {
int *P;
char *x;
P = x; // type of this assignment expression should be "int *", NOT "char *".
}
While the type checking/diagnostics are correct, the type of the assignment
expression is incorrect (which shows up during code gen). With the fix,
the llvm code looks correct...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang cast.c -emit-llvm
cast.c:4:5: warning: incompatible pointer types assigning 'char *' to 'int *'
P = x; // type of assignment expression is "int *", NOT "char *".
~ ^ ~
; ModuleID = 'foo'
define i32 @func() {
entry:
%P = alloca i32* ; <i32**> [#uses=1]
%x = alloca i8* ; <i8**> [#uses=1]
%allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0]
%tmp = load i8** %x ; <i8*> [#uses=1]
%conv = bitcast i8* %tmp to i32* ; <i32*> [#uses=1]
store i32* %conv, i32** %P
ret i32 undef
}
Even though the fix was simple, I decided to rename/refactor the surrounding code
to make a clearer distinction between constraint checking and conversion.
- Renamed AssignmentConversionResult -> AssignmentCheckResult.
- Renamed UsualAssignmentConversions -> CheckAssignmentConstraints.
- Changed the return type of CheckAssignmentConstraints and CheckPointerTypesForAssignment
from QualType -> AssignmentCheckResult. These routines no longer take a reference to the result (obviously).
- Changed CheckAssignmentOperands to return the correct type (with spec annotations).
llvm-svn: 39601
Submitted by:
Reviewed by:
Apply UsualUnaryConversion() to statement conditions that expect scalars.
UsualUnaryConversion() converts function/arrays to pointers.
This fixes the following...
int func() {
int A[10];
while (A) {
}
if (A) ;
for (; A; ) ;
}
llvm-svn: 39580
Submitted by:
Reviewed by:
Implement support for GCC __attribute__.
- Implement "TODO" in Parser::ParseAttributes. Changed the return type from
void to Parser::DeclTy. Changed all call sites to accept the return value.
- Added Action::ParseAttribute and Sema::ParseAttribute to return an
appropriate AST node. Added new node AttributeDecl to Decl.h.
Still to do...hook up to the Decl...
llvm-svn: 39539
Submitted by:
Reviewed by:
Refine Sema::ParseCallExpr() diags (range support, add types).
Before:
func-assign.c:27:11: warning: passing argument 1 from incompatible pointer type
pintFunc(&FOO);
^
func-assign.c:28:12: error: incompatible type for argument 1
floatFunc(&FOO);
^
func-assign.c:29:12: error: too many arguments to function
floatFunc(1,2,3);
^
After:
func-assign.c:27:11: warning: passing incompatible pointer 'struct foo *' to function expecting 'int *'
pintFunc(&FOO);
~~~~~~~~^~~~~
func-assign.c:28:12: error: passing incompatible type 'struct foo *' to function expecting 'float'
floatFunc(&FOO);
~~~~~~~~~^~~~~
func-assign.c:29:12: error: too many arguments to function
floatFunc(1,2,3);
~~~~~~~~~^ ~
llvm-svn: 39513
Submitted by:
Reviewed by:
- Added type checking to Sema::ParseReturnStmt (still under construction).
- Improved Expr::isLvalue() and Expr::isModifiableLvalue() to return more
info. Used the info in Sema::CheckAssignmentOperands() to produce more
descriptive diagnostics. Added FIXME to other clients of isLvalue()/etc.
- Added a SourceLocation slot to MemberExpr...changed the implementation
of getSourceRange().
- Added getResultType() helper to FunctionDecl.
- Changed many Diag calls to use the SourceRange support (now that it's
a big hit...we better milk it:-).
llvm-svn: 39501
Submitted by:
Reviewed by:
One bug compiling "Carbon.h" on Leopard, one diagnostic tweak.
- CheckIndirectionOperand wasn't operating on the canonical type (so it
was complaining about typedef names).
- The diagnostic was less than great. Here's what is was:
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang t.c
t.c:4:3: error: invalid argument type to unary expression 'int'
*p;
^~
And here's what I changed it to...
snaroff:clang naroff$ ../../Debug/bin/clang bug.c
bug.c:5:3: error: indirection requires a pointer ('int' operand invalid)
*p;
^~
llvm-svn: 39481
Submitted by:
Reviewed by:
Fix two bugs...
- Sema::CheckConditionalOperands(). Needed to move the check for
null pointer constants up to the clause dealing with two pointers types.
The previous code would never get executed.
- Expr::isNullPointerConstant(). This predicate was much too naive...it
should have had a FIXME (my bad). It now deals with "void *" cast expressions.
It still has one major bug...it needs to evaluate the expression to correctly
determine if it is a null pointer constant (e.g. 7-7 should pass).
llvm-svn: 39464
of a subexpression when emitting a diagnostic. Consider this example:
struct A { int X; };
void test1(void *P, int C) {
return ((C*40) + *P) / 42+P;
}
void test2(struct A friendlystruct, int C) {
return (C *40) + friendlystruct;
}
void test3(struct A friendlystruct, int C) {
return friendlystruct + test2(friendlystruct
, C);
}
clang now produces this output:
t.c:4:18: error: invalid operands to binary expression ('int' and 'void')
return ((C*40) + *P) / 42+P;
~~~~~~ ^ ~~
This shows the important pieces of a nested (and potentially very complex)
expression.
t.c:8:18: error: invalid operands to binary expression ('int' and 'struct A')
return (C *40) + friendlystruct;
~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
This shows that tabs in source files (after the 'C') and multichar tokens
(friendlystruct) are handled correctly.
t.c:12:25: error: invalid operands to binary expression ('struct A' and 'void')
return friendlystruct + test2(friendlystruct
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~
This shows how multiline ranges are printed. Any part of the range that is
not on the same line as the carat is just ignored. This also shows that
trailing spaces on the line aren't highlighted.
llvm-svn: 39459
Submitted by:
Reviewed by:
- Implement type checking for Sema::CheckConditionalOperands.
- Fixed crasher in Sema::UsualUnaryConversion (incorrect use of cast<>).
- Added a few diagnostics and started passing 2 args! (Thanks Chris!).
Here's some diagnostic output that is much nicer than gcc...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang cond.c
cond.c:12:14: error: used type 'struct foo' where arithmetic or pointer type is required
result = s ? 1 : 2;
^
cond.c:13:14: error: incompatible operand types ('struct foo' and 'struct bar')
result = a ? s : s2;
^
cond.c:14:14: warning: pointer type mismatch ('struct foo *' and 'struct bar *')
result = a ? ps : ps2;
^
cond.c:14:10: warning: assignment makes integer from pointer without a cast
result = a ? ps : ps2;
^
cond.c:15:14: error: incompatible operand types ('struct foo *' and 'struct foo')
result = a ? ps : s;
^
cond.c:16:14: warning: pointer type mismatch ('void (*)(int)' and 'void (*)(int, int)')
result = a ? func : func2;
^
cond.c:16:10: warning: assignment makes integer from pointer without a cast
result = a ? func : func2;
^
7 diagnostics generated.
[dylan:~/llvm/tools/clang] admin% cc -c cond.c
cond.c: In function 'main':
cond.c:12: error: used struct type value where scalar is required
cond.c:13: error: type mismatch in conditional expression
cond.c:14: warning: pointer type mismatch in conditional expression
cond.c:14: warning: assignment makes integer from pointer without a cast
cond.c:15: error: type mismatch in conditional expression
cond.c:16: warning: pointer type mismatch in conditional expression
cond.c:16: warning: assignment makes integer from pointer without a cast
llvm-svn: 39451
Submitted by:
Reviewed by:
Fixed a bug in Sema::CheckAddressOfOperand(). It was (incorrectly) using
isModifiableLvalue() instead of isLvalue(). This motivated me to (finally)
cleanup methods surrounding lsLvalue/isModifiableLvalue. Cleanup involved:
- adding Expr::isLvalue().
- modified Expr::isModifiableLvalue() to use Expr::isLvalue().
- removed Type::isLvalue(), Type::isModifiableLvalue(), and
QualType::isModifiableLvalue(). They were confusing...the respective logic
is now a part of the Expr member functions...
- also added some comments and spec references, since these methods are
so central to expressions working properly.
llvm-svn: 39443
Submitted by:
Reviewed by:
- implement Type::functionTypesAreCompatible().
- fix bug in Sema::CheckAssignmentOperands(). Spec allows any pointer type
to be assigned to _Bool.
llvm-svn: 39428
Submitted by:
Reviewed by:
Continue working on type checking for unary operators. Added:
- Two 3 private functions to Sema: CheckAddressOfOperand(), CheckIndirectionOperand(),
and getDecl().
- Added Expr::isLvalue() - it was needed for CheckAddressOfOperand(). It will
also be needed for ++/-- and the assignment operators.
- Added a couple diagnostics for invalid lvalues (for & of).
llvm-svn: 39408
Submitted by:
Reviewed by:
Fix "FIXME: does this lose qualifiers from the typedef??" in ASTContext::getTypedefType().
This change was fairly pervasive...nevertheless, here are the highlights:
- Change the type of Type::CanonicalType to TypeRef (was "Type *").
- Change the implementation of TypeRef::getCanonicalType() to work for typedefs.
- Make the implementation of Type::getCanonicalType private (only TypeRef should access). This
will force clients to use TypeRef::getCanonicalType (the correct version of the function). Since
TypeRef overloads "->", it was very easy to fall into this bug...
- Changed many references of "Type *" to "TypeRef"...when the raw type pointer is required, use t.getTypePtr().
- Changed all the *Type classes to take a TypeRef.
- Made the Type constructor protected (cleanup).
- Removed function Expr::getType().
- Convert functions in SemaExpr to use the above support. This fixed the "const" bug I was originally investigating.
I will follow this check-in up with a rename of TypeRef->QualType. I will also make sure the constructor does not default to 0 (which can lead to broken code...).
llvm-svn: 39394
Submitted by:
Reviewed by:
Add three new classes to Decl.h: BlockVarDecl, FileVarDecl, and ParmVarDecl.
Made the constructor to VarDecl protected, to indicate it is "abstract".
Reorganized the Decl::Kind enum to allow us to add ObjectDecls/TypeDecls with
minimal breakage. In the process, realized the isa support for ObjectDecl was already broken (so
the reorg paid for itself already:-) The range check should also be more efficient...
llvm-svn: 39373
Submitted by:
Reviewed by:
- Finished up incomplete type analysis for varibles (in Sema::ParseDeclarator()).
- Added many spec refs, since this area is confusing (for top level decls
in particular).
- Added a FIXME to MergeVarDecl()...it needs to be taught about tentative
definitions. As a result, we currently issue some bogus diagnostics.
llvm-svn: 39372
Submitted by:
Reviewed by:
Moved numeric literal support from SemaExpr.cpp to LiteralSupport.[h,cpp]
in Lex. This will allow it to be used by both Sema and Preprocessor (and
should be the last major refactoring of this sub-system).. Over
time, it will be reused by anyone implementing an actions module (i.e.
any subclass of llvm::clang::Action. Minor changes to IntegerLiteral in Expr.h.
More to come...
llvm-svn: 39351
Submitted by:
Reviewed by:
More code to parse numeric constants. This checkin includes:
- Feedback from Chris.
- Support for parsing floating point constants.
- Moved the code to "Sema". Changed API in Action.
- More/better error diagnostics.
At this point, the parsing support should be largely complete. Next step
is to work on filling in sensible values (in IntegerLiteral/FloatLiteral).
llvm-svn: 39349
Submitted by:
Reviewed by:
First phase of parsing IntegerConstants. At the moment, all processing
is done in the Parser, not Sema. If necessary, this is easy to move.
Next steps:
- Convert well for strings to actual values (need to look @ APInt.h)
- Design the API between the Parser and Sema. Sema shouldn't have to be
concerned with any parsing issues...
llvm-svn: 39348
This set of changes includes:
- convert ExprCXX.h and add to the Xcode project file.
-- required adding CXXBoolLiteralExpr to StmtNodes.def.
-- required adding visitor support (decl/defn).
- make the class codes in StmtNodes.def explicit (to enable range checking).
-- this required changing all clients of the STMT macro.
- declare the instance data const.
llvm-svn: 39344
of source code. For example:
$ clang INPUTS/carbon_h.c -arch i386 -arch ppc
prints:
...
/usr/lib/gcc/i686-apple-darwin8/4.0.1/include/mmintrin.h:51:3: note: use of a target-specific builtin function, source is not 'portable'
__builtin_ia32_emms ();
^
because carbon.h pulls in xmmintrin.h, and __builtin_ia32_emms isn't a builtin on ppc.
Though clang now supports target-specific builtins, the full table isn't implemented yet.
llvm-svn: 39328
whose decl objects are lazily created the first time they are referenced.
Builtin functions are described by the clang/AST/Builtins.def file, which
makes it easy to add new ones.
This is missing two important pieces:
1. Support for the rest of the gcc builtins.
2. Support for target-specific builtins (e.g. __builtin_ia32_emms).
Just adding this builtins reduces the number of implicit function definitions
by 6, reducing the # diagnostics from 550 to 544 when parsing carbon.h.
I need to add all the i386-specific ones to eliminate several hundred more.
ugh.
llvm-svn: 39327
of having a loose collection of function pointers. This also allows clients to
maintain state, and reduces the size of the Preprocessor.h interface.
llvm-svn: 39203
thing properly. This allows us to print types like:
int (*A)[restrict static 4][6];
properly, in addition to representing them properly. :)
llvm-svn: 39178
fundamentally requires having an AST around, so move all sema to the
AST library. This is the first step, later steps will be needed to
clean up libast.
llvm-svn: 39150
case, speeding up parsing of this contrived example:
#define A {{}}
#define B A A A A A A A A A A
#define C B B B B B B B B B B
#define D C C C C C C C C C C
#define E D D D D D D D D D D
#define F E E E E E E E E E E
#define G F F F F F F F F F F
#define H G G G G G G G G G G
void foo() {
H
}
from 7.478s to 4.321s. GCC requires 8.2s.
llvm-svn: 39138
switch statements. Make break/continue check that they are inside of an
appropriate control-flow construct. This implements Parser/bad-control.c.
llvm-svn: 39136
Fariborz Jahanian