- Change TargetData string to match llvm-gcc.
- Some -target-abi support for 'apcs-gnu', most importantly the alignment of double and long long changes.
llvm-svn: 81732
avoid emitting a warning on "someptr > 0". This is obviously questionable (they
could use != instead) but is reasonable, and the warning "ordered comparison
between pointer and integer" didn't make a ton of sense because 0 is a valid
null pointer constant.
Just silence the warning in this case, it is unlikely to indicate a bug.
llvm-svn: 79743
where sizeof(short) == sizeof(int). Move UsualArithmeticConversionsType
out of Sema, since it was only there as a historical artifact. Patch by
Enea Zaffanella.
llvm-svn: 79412
declarations (and not function pointers). This is consistent with GCC. Accepting
this attribute on function pointers means that the attribute should be treated
as a type qualifier, which apparently is not what GCC does. We obviously can
change this later should we desire to enhance the 'malloc' attribute in this
way.
llvm-svn: 79060
Fixes PR4704 problems
Addresses Eli's patch feedback re: ugly cast code
Updates all postfix operators to remove ParenListExprs. While this is awful,
no better solution (say, in the parser) is obvious to me. Better solutions
welcome.
llvm-svn: 78621
1. Passing something that isn't a string used to cause:
"argument to annotate attribute was not a string literal"
make it say "section attribute" instead.
2. Fix the location of the above message to point to the
bad argument instead of the section token.
3. Implement rdar://4341926, by diagnosing invalid section
specifiers in the frontend rather than letting them slip all
the way to the assembler (a QoI win).
An example of #3 is that we used to produce something like this:
/var/folders/n7/n7Yno9ihEm894640nJdSQU+++TI/-Tmp-//ccFPFGtT.s:2:Expected comma after segment-name
/var/folders/n7/n7Yno9ihEm894640nJdSQU+++TI/-Tmp-//ccFPFGtT.s:2:Rest of line ignored. 1st junk character valued 46 (.).
Daniel improved clang to use llvm_report_error, so now we got:
$ clang t.c -c
fatal error: error in backend: Global variable 'x' has an invalid section specifier 'sadf': mach-o section specifier
requires a segment and section separated by a comma.
with no loc info. Now we get:
$ clang t.c -fsyntax-only
t.c:4:30: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment
and section separated by a comma
int x __attribute__((section("sadf")));
^
which is nice :)
llvm-svn: 78586
--- Reverse-merging r78535 into '.':
D test/Sema/altivec-init.c
U include/clang/Basic/DiagnosticSemaKinds.td
U include/clang/AST/Expr.h
U include/clang/AST/StmtNodes.def
U include/clang/Parse/Parser.h
U include/clang/Parse/Action.h
U tools/clang-cc/clang-cc.cpp
U lib/Frontend/PrintParserCallbacks.cpp
U lib/CodeGen/CGExprScalar.cpp
U lib/Sema/SemaInit.cpp
U lib/Sema/Sema.h
U lib/Sema/SemaExpr.cpp
U lib/Sema/SemaTemplateInstantiateExpr.cpp
U lib/AST/StmtProfile.cpp
U lib/AST/Expr.cpp
U lib/AST/StmtPrinter.cpp
U lib/Parse/ParseExpr.cpp
U lib/Parse/ParseExprCXX.cpp
llvm-svn: 78551
In addition to being defined by the AltiVec PIM, this is also the vector
initializer syntax used by OpenCL, so that vector literals are compatible
with macro arguments.
llvm-svn: 78535
implementation of '#pragma unused' by not constructing intermediate
DeclRefExprs, but instead do the name lookup directly. The
implementation is greatly simplified.
Along the way, degrade '#pragma unused(undeclaredvariable)' to a
warning instead of being a hard error. This implements:
<rdar://problem/6761874> [sema] allow #pragma unused to reference undefined variable (with warning)
llvm-svn: 78019
Doug, please look at decltype-crash and instantiate-function-1.mm, I'm not sure
if they are actually testing the right thing / anything.
llvm-svn: 77070
value. This is on by default, and controlled by -Wreturn-type (-Wmost
-Wall). I believe there should be very few false positives, though
the most interesting case would be:
int() { bar(); }
when bar does:
bar() { while (1) ; }
Here, we assume functions return, unless they are marked with the
noreturn attribute. I can envision a fixit note for functions that
never return normally that don't have a noreturn attribute to add a
noreturn attribute.
If anyone spots other false positives, let me know!
llvm-svn: 76821
Objective-C pointers to using ObjCObjectPointerType.
Now the checking for 'attribute ((nonnull))' in Sema doesn't emit an error when
trying to apply that attribute to a parameter that is an Objective-C pointer
(this is a regression).
To prevent this regression from occuring in the future, the 'nonnull.c' test was
moved to test/SemaObjC and renamed 'nonnull.m'. I also enhanced the tests to
show that function calls involved a NULL Objective-C pointer constant does not
trigger a warning. This is consistent with GCC, but should likely be fixed.
llvm-svn: 75856
- These kinds of "shotgun" tests are very slow, and do not belong in the
regression suite. If these kinds of tests are regarded to have value, they
should be added to the LLVM test-suite.
- I would actually like to remove all of these tests, but I left Sema/carbon.c
and SemaObjC/cocoa.m...
llvm-svn: 75399
Handle rules for ExtVector + ExtVector and ExtVector + Scalar operations.
Fix problem Eli noticed where we were allowing pointer types to be splatted to
vector elements.
llvm-svn: 74404
C++. This logic is required to trigger implicit instantiation of
function templates and member functions of class templates, which will
be implemented separately.
This commit includes support for -Wunused-parameter, printing warnings
for named parameters that are not used within a function/Objective-C
method/block. Fixes <rdar://problem/6505209>.
llvm-svn: 73797
hack which introduces some strange inconsistencies in compatibility
for block pointers.
Note that unlike an earlier revision proposed on cfe-commits, this patch
still allows declaring block pointers without a prototype.
llvm-svn: 73041
valid declarations and doesn't give an error for autoconf-style invalid
redeclarations. This isn't quite ideal, but I don't see any other way
easy way to handle it. (The only thing I can think of that's reasonably
general is adding a new builtin type FILETy which is only compatible
with a type equivalent to FILE, and that seems like overkill.)
llvm-svn: 72760
definition variadic. I'm not completely sure it's legal, but the
standard can be interpreted as making it legal, and gcc seems to think
it's legal, so I didn't add an extension warning.
llvm-svn: 72689
an error to being a warning that defaults to error. If you want this to
be a warning, you have to explicitly pass -Winvalid-noreturn to clang to
map it back to a warning.
llvm-svn: 72669
-Makes typeof consistent with sizeof/alignof
-Fixes a bug when '>' is in a typeof expression, inside a template type param:
A<typeof(x>1)> a;
llvm-svn: 72255
This patch isn't quite ideal in that it eliminates the warning for
constructs like "int a = {1};", where the braces are in fact redundant.
However, that would have required a bunch of refactoring, and it's
much less likely to cause confusion compared to redundant nested braces.
llvm-svn: 71939
compared to gcc. This is worrisome, but I believe we are doing the
"correct" thing, and if I recall correctly I previously verified this
versus MSVC.
llvm-svn: 71723
It seems dubious to me that isIntegerType() returns true for
vectors of integers, but not complex integers. This should
probably be rethought, I'll file a bugzilla.
llvm-svn: 71640
don't support. While it would be nice to support this eventually,
this form is not common at all (just seen in gcc testsuite) and
it might be better to model vector_size as a type attribute anyway.
For now just emit a nice error on it.
llvm-svn: 71633
of the underlying _N builtin, not the the type of the pointee of the
actual type. This ensures that atomics involving pointers end up
using the correct integer type when they are resolved, avoiding
aborts in codegen.
llvm-svn: 71218
semantic rules that gcc and icc use. This implements the variadic
and concrete versions as builtins and has sema do the
disambiguation. There are probably a bunch of details to finish up
but this seems like a large monotonic step forward :)
llvm-svn: 71212
- This is a WIP...
- This adds -march= handling to the driver, and fixes the defaulting
of -mcpu on Darwin (which was using the wrong test).
Instead of handling -m{sse, ...} in the driver, pass them to clang-cc as
-target-feature [+-]name
In clang-cc, communicate with the (clang) target to discover the legal
features of a target, and the features which are enabled based on
-mcpu. This is currently hardcoded just enough to not be a feature
regression, we need to get this information from the backend's
TableGen information somehow.
This is used to construct the full list of features which are being
used, which is in turn used to initialize the predefines.
llvm-svn: 71061
number is not mentioned in the asm string, let it past sema.
Right now these are currently rejected by the llvm code generator
but this will be fixed next.
llvm-svn: 70670
into the left-hand side of an assignment expression. This completes
most of PR3500; the only remaining part is to deal with the
GCC-specific implementation-defined behavior for "unsigned long" (and
other) bit-fields.
llvm-svn: 70623
"aligned" attribute. Previously, we were skipping over these
attributes when we jumped directly to the canonical type. Now,
ASTContext::getTypeInfo walks through typedefs and other
"non-canonical" types manually, looking for "aligned" attributes on
typedefs.
As part of this change, I moved the GNU-specific logic (such as
determining the alignment of void or of a function pointer) out of the
expression evaluator and into ASTContext::getTypeInfo.
llvm-svn: 70497
This fixes <rdar://problem/6839489> 10A345: Clang does not warm about mismatched returns (void return from a bool function)
Will implement -Wreturn-type, -Wno-return-type in another commit.
llvm-svn: 70492
compatible with VC++ and GCC. The codegen/mangling angle hasn't
been fully ironed out yet. Note that we accept int128_t even in
32-bit mode, unlike gcc.
llvm-svn: 70464
type and argument types are missing, and let return type deduction
happen before we give errors for returning from a noreturn block.
Radar 6441502
llvm-svn: 70413
1. In a struct field redefinition, don't mark the struct erroneous. The
field is erroneous, but the struct is otherwise well formed.
2. Don't emit diagnostics about functions that are known to be broken already.
Either fix is sufficient to silence the second diagnostic in the example,
but the combination is better :)
llvm-svn: 70371
1. All all variants of -Wformat*, make them imply -Wformat. GCC warns
if you use -Wformatfoo without -Wformat. We just make one imply the
other.
2. Make -Wformat-nonliteral default to off, like gcc. It is an incredible
nuisance.
3. Accept but currently ignore -Wformat-extra-args.
llvm-svn: 70362
"function designator".
(This causes a minor glitch in the
diagnostics for C++ member pointers, but we weren't printing the
right diagnostic there anyway.)
llvm-svn: 70307
scheme to be more useful.
The new scheme introduces a set of categories that should be more
readable, and also reflects what we want to consider as an extension
more accurately. Specifically, it makes the "what is a keyword"
determination accurately reflect whether the keyword is a GNU or
Microsoft extension.
I also introduced separate flags for keyword aliases; this is useful
because the classification of the aliases is mostly unrelated to the
classification of the original keyword.
This patch treats anything that's in the implementation
namespace (prefixed with "__", or "_X" where "X" is any upper-case
letter) as a keyword without marking it as an extension. This is
consistent with the standards in that an implementation is allowed to define
arbitrary extensions in the implementation namespace without violating
the standard. This gets rid of all the nasty "extension used" warnings
for stuff like __attribute__ in -pedantic mode. We still warn for
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we
could add additional information to the keyword table.
This also removes processing for the unused "Boolean" language option;
such an extension isn't supported on any other C implementation, so I
don't see any point to adding it.
The changes to test/CodeGen/inline.c are required because previously, we
weren't actually disabling the "inline" keyword in -std=c89 mode.
I'll remove Boolean and NoExtensions from LangOptions in a follow-up
commit.
llvm-svn: 70281
offsetof correctly in the presence of anonymous structs/unions.
This could definitely use some cleanup, but I don't really want to mess
with the anonymous union/struct code.
llvm-svn: 70156
Before we emitted:
$ clang t.c -S -m64
llvm: error: Unsupported asm: input constraint with a matching output constraint of incompatible type!
Now we produce:
$ clang t.c -S -m64
t.c:5:40: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'int'
asm volatile("foo " : "=a" (a) :"0" (b));
~~~ ~^~
llvm-svn: 70142
Overall, I'm not particularly happy with the current situation regarding
constant expression diagnostics, but I plan to improve it at some point.
llvm-svn: 70089
VerifyIntegerConstantExpression instead of isIntegerConstantExpr.
This makes it ext-warn but tolerate things that fold to a constant
but that are not valid i-c-e's.
There must be a bug in the i-c-e computation though, because it
doesn't catch this case even with pedantic.
This also switches the later code to use EvaluateAsInt which is
simpler and handles everything that evaluate does.
llvm-svn: 70081
always return a non-null QualType + error bit. This fixes a bunch of
cases that didn't check for null result (and could thus crash) and eliminates
some crappy code scattered throughout sema.
This also improves the diagnostics in the recursive struct case to eliminate
a bogus second error. It also cleans up the case added to function.c by forming
a proper function type even though the declarator is erroneous, allowing the
parameter to be added to the function. Before:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*P)
^
t.c:4:3: error: use of undeclared identifier 'P'
P+1;
^
After:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*P)
^
llvm-svn: 70023
This gets rid of a bunch of random InvalidDecl bools in sema, changing
us to use the following approach:
1. When analyzing a declspec or declarator, if an error is found, we
set a bit in Declarator saying that it is invalid.
2. Once the Decl is created by sema, we immediately set the isInvalid
bit on it from what is in the declarator. From this point on, sema
consistently looks at and sets the bit on the decl.
This gives a very clear separation of concerns and simplifies a bunch
of code. In addition to this, this patch makes these changes:
1. it renames DeclSpec::getInvalidType() -> isInvalidType().
2. various "merge" functions no longer return bools: they just set the
invalid bit on the dest decl if invalid.
3. The ActOnTypedefDeclarator/ActOnFunctionDeclarator/ActOnVariableDeclarator
methods now set invalid on the decl returned instead of returning an
invalid bit byref.
4. In SemaType, refering to a typedef that was invalid now propagates the
bit into the resultant type. Stuff declared with the invalid typedef
will now be marked invalid.
5. Various methods like CheckVariableDeclaration now return void and set the
invalid bit on the decl they check.
There are a few minor changes to tests with this, but the only major bad
result is test/SemaCXX/constructor-recovery.cpp. I'll take a look at this
next.
llvm-svn: 70020
parameters in a functiondecl, even if the decl is invalid and has a confusing
Declarator. On the testcase, we now emit one beautiful diagnostic:
t.c:2:1: error: unknown type name 'unknown_type'
unknown_type f(void*)
^
GCC 4.0 produces:
t.c:2: error: syntax error before ‘f’
t.c: In function ‘f’:
t.c:2: error: parameter name omitted
and GCC 4.2:
t.c:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘f’
llvm-svn: 70016
typedef void foo(void);
We get a typedef for a functiontypeproto with no arguments, not
one with one argument and type void. This means the code being
removed in SemaDecl is dead.
llvm-svn: 70013
start of the declspec. The fixit still goes there, and we underline
the declspec. This helps when the start of the declspec came from a
macro that expanded from a system header. For example, we now produce:
t.c:2:8: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
static x;
~~~~~~ ^
llvm-svn: 69777
by marking the predefines buffer as a system header. The problem
with stdint is that it was getting problems like this:
/Volumes/Projects/cvs/llvm/Debug/lib/clang/1.0/include/stdint.h:43:9: warning: 'long long' is an extension when C99 mode is not enabled
typedef __INT64_TYPE__ int64_t;
^
<built-in>:73:29: note: instantiated from:
#define __INT64_TYPE__ long long
^
We correctly silence warnings in system headers, but only if the
spelling location of the token came from the system header. This is
designed so that if you use a system macro in your code that you don't
get punished for its definition. This is all cool except that the
predefines buffer wasn't considered a system header.
llvm-svn: 69770
extern. Previously we would warn about it and ignore the attribute.
This is incorrect, it should be handled as a c89 "extern inline"
function. Many thanks to Matthieu Castet for pointing this out and
beating me over the head until I got it.
PR3988: extern inline function are not externally visible
llvm-svn: 69756
mark exactly the blocks which have references that are "live through".
This fixes a rejects valid:
rdar://6808730 - [sema] [blocks] block rejected at global scope
llvm-svn: 69738
tentative definitions off to the ASTConsumer at the end of the
translation unit.
Eliminate CodeGen's internal tracking of tentative definitions, and
instead hook into ASTConsumer::CompleteTentativeDefinition. Also,
tweak the definition-deferal logic for C++, where there are no
tentative definitions.
Fixes <rdar://problem/6808352>, and will make it much easier for
precompiled headers to cope with tentative definitions in the future.
llvm-svn: 69681
minor accepts-invalid regressions, but we weren't really rejecting them for
the right reason. We really need a more general solution to detect all the
cases of the promotion of arrays with a register storage class.
llvm-svn: 69586
statements don't end up in the LabelMap so we don't have a quick way
to filter them. We could add state to Sema (a "has vla" and "has
jump" bit) to try to filter this out, but that would be sort of gross
and I'm not convinced it is the best way. Thoughts welcome.
llvm-svn: 69476
specific bad case instead of on the switch. Putting it on the
switch means you don't know what case is the problem. For
example:
scope-check.c:54:3: error: illegal switch case into protected scope
case 2:
^
scope-check.c:53:9: note: jump bypasses initialization of variable length array
int a[x];
^
llvm-svn: 69462
produce better diagnostics, and be more correct in ObjC cases (fixing
rdar://6803963).
An example is that we now diagnose:
int test1(int x) {
goto L;
int a[x];
int b[x];
L:
return sizeof a;
}
with:
scope-check.c:15:3: error: illegal goto into protected scope
goto L;
^
scope-check.c:17:7: note: scope created by variable length array
int b[x];
^
scope-check.c:16:7: note: scope created by variable length array
int a[x];
^
instead of just saying "invalid jump". An ObjC example is:
void test1() {
goto L;
@try {
L: ;
} @finally {
}
}
t.m:6:3: error: illegal goto into protected scope
goto L;
^
t.m:7:3: note: scope created by @try block
@try {
^
There are a whole ton of fixme's for stuff to do, but I believe that this
is a monotonic improvement over what we had.
llvm-svn: 69437
1. We had logic in sema to decide whether or not to emit the error
based on manually checking whether in a system header file.
2. we were allowing redefinitions of typedefs in class scope in C++
if in header file.
3. there was no way to force typedef redefinitions to be accepted
by the C compiler, which annoys me when stripping linemarkers out
of .i files.
The fix is to split the C++ class typedef redefinition path from the
C path, and change the C path to be a warning that normally maps to
error. This causes it to properly be ignored in system headers,
etc. and gives us a way to control it. Passing
-Wtypedef-redefinition now turns the error into a warning.
One behavior change is that we now diagnose cases where you redefine
a typedef in your .c file that was defined in a header file. This
seems like reasonable behavior, and the diagnostic now indicates that
it can be controlled with -Wtypedef-redefinition.
llvm-svn: 69391
Daniel Dunbar