For example, on:
#include <emmintrin.h>
int foo(int N) {
__m128i white2;
white2 = _mm_slli_si128(white2, N);
return 0;
}
we used to get:
fatal error: error in backend: Cannot yet select: intrinsic %llvm.x86.sse2.psll.dq
now we get:
/Users/sabre/t.c:4:11: error: argument to '__builtin_ia32_pslldqi128' must be a
constant integer
white2 = _mm_slli_si128(white2, N);
^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Users/sabre/t.c:1:
/Volumes/Projects/cvs/llvm/Debug+Asserts/lib/clang/2.9/include/emmintrin.h:781:13: note: instantiated from:
((__m128i)__builtin_ia32_pslldqi128((__m128i)(VEC), (IMM)*8))
^ ~~~~~~~
1 error generated.
llvm-svn: 115374
are expanded from macros (and if so, omit the warning). Previously we were just looking at the
location of the binary expression.
Fixes <rdar://problem/8435950>.
llvm-svn: 114044
the function processing the format string can decided whether or not to accept a null format string (e.g., asl_log). Fixes <rdar://problem/8269537>.
llvm-svn: 113469
The rationale behind this is that it is normal for callback functions to have a non-void return type
and it should still be possible to mark them noreturn. (JavaScriptCore is a good example of this).
llvm-svn: 112918
vectors that are the same size. Fix up testcases accordingly and add a new one
to make sure we still error if lax vector conversions are disabled.
Fixes rdar://8328190
llvm-svn: 112122
for incomplete enum types. An incomplete enum can't really be treated as
an "integral or enumeration" type, and the incorrect treatment leads to
bad behavior for many callers.
This makes isIntegralOrEnumerationType equivalent to isIntegerType; I think
we should globally replace the latter with the former; thoughts?
llvm-svn: 111512
than GCC 4.2 here when building 32-bit (where GCC will allow
allocation of an array for which we can't get a valid past-the-end
pointer), and emulate its odd behavior in 64-bit where it only allows
63 bits worth of storage in the array. The former is a correctness
issue; the latter is harmless in practice (you wouldn't be able to use
such an array anyway) and helps us pass a GCC DejaGNU test.
Fixes <rdar://problem/8212293>.
llvm-svn: 111338
Unused warnings for functions:
-static functions
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace
Unused warnings for variables:
-static variables
-variables in anonymous namespace
-static data members in anonymous namespace
-static data members specializations in anonymous namespace
Reveals lots of opportunities for dead code removal in llvm codebase that will
interest my esteemed colleagues.
llvm-svn: 111086
-static function declarations
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace
llvm-svn: 111026
from GCC's in that we warn on *any* increase in alignment requirements, not
just those that are enforced by hardware. Please let us know if this causes
major problems for you (which it shouldn't, since it's an optional warning).
llvm-svn: 110959
when the RHS of the ||/&& is ever 0 or 1. This handles a variety of
creative idioms for "true" used in C programs and fixes many false
positives at the expense of a few false negatives. This fixes
rdar://8230351.
llvm-svn: 109314
them as such. Type::is(Signed|Unsigned|)IntegerType() now return false
for vector types, and new functions
has(Signed|Unsigned|)IntegerRepresentation() cover integer types and
vector-of-integer types. This fixes a bunch of latent bugs.
Patch from Anton Yartsev!
llvm-svn: 109229
their call expressions synthetically have the "deduced" types based on their
first argument. We only insert conversions in the AST for arguments whose
values require conversion to match the value type expected. This keeps PR7600
closed by maintaining the return type, but avoids assertions due to unexpected
implicit casts making the type unsigned (test case added from Daniel).
The magic is moved into the codegen for the atomic builtin which inserts the
casts as needed at the IR level to raise the type to an integer suitable for
the LLVM intrinsic. This shouldn't cause any real change in functionality, but
now we can make the builtin be more truly polymorphic.
llvm-svn: 108638
This flag and warning match GCC semantics. Also, move it to -Wextra as this is
a largely cosmetic issue and doesn't seem to mask problems. Subsequent fixes to
the tests which no longer by default emit the warning. Added explicit test
cases for both C and C++ behavior with the warning turned on.
llvm-svn: 108325
t2.c:2:12: warning: use of logical && with constant operand; switch to bitwise &
or remove constant [-Wlogical-bitwise-confusion]
return x && 4;
^ ~
wording improvement suggestions are welcome.
llvm-svn: 108260
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
around by exempting enums from the check, but this doesn't handle a lot of
cases. A better approach is to directly check if the operator comes from
a macro expansion.
I've removed a reference to the rdar that originally led to the enum
suppression when removing it's overly contrived test case. Let me know if that
number or a more reasilistic test case involving enums is still needed.
llvm-svn: 108128
expected value type. This is necessary as the builtin is internally represented
as only operating on integral types.
Also, add a FIXME to add support for floating point value types.
llvm-svn: 108002
unknown attributes that we discard. Add a diagnostic group for unknown
attribute warnings to allow turning these off when we don't care. Also
consolidates the tests for this case.
llvm-svn: 107864
union whose first field has integral vector type. Also, clean up this
diagnostic a bit. Thanks to Eli for spotting this change in semantics
last week.
llvm-svn: 107296
As a bonus, fix the warning for || and && operators; it was emitted even if one of the operands had side effects, e.g:
x || test_logical_foo1();
emitted a bogus "expression result unused" for 'x'.
llvm-svn: 107274
have integral or enumeration type, so that we still check the contents
of the switch body. My previous patch made this worse; now we're back
to where we were previously.
llvm-svn: 107223
enumeration type out into a separate, reusable routine. The only
functionality change here is that we recover a little more
aggressively from ill-formed switch conditions.
llvm-svn: 107222
__real myvec and __imag myvec, since they aren't all that useful (it's
just an identity function) but we might want to use them in more
restricted cases in the future (e.g., "__real mycomplexvec" could
extract the real parts of a vector of complex numbers).
llvm-svn: 106601
of the callers of isRealType() already assumed this, and one of them
(increment/decrement) mistakenly permitted increments of vector types
because of it.
llvm-svn: 106596
types, updating callers of both isFloatingType() and
isRealFloatingType() accordingly. Caught at least one issue where we
allowed one to declare a vector of vectors (!), along with cleaning up
the standard-conversion logic for C++.
llvm-svn: 106595
http://llvm.org/bugs/show_bug.cgi?id=7377
Updated format string highlighting and fixits to take advantage of the new CharSourceRange class.
- Change HighlightRange to allow highlighting whitespace only in a CharSourceRange (for warnings about the ' ' (space) flag)
- Change format specifier range helper function to allow for half-open ranges (+1 to end)
- Enabled previously failing tests (FIXMEs/XFAILs removed)
- Small fixes and additions to format string test cases
M test/Sema/format-strings.c
M test/Sema/format-strings-fixit.c
M lib/Frontend/TextDiagnosticPrinter.cpp
M lib/Sema/SemaChecking.cpp
llvm-svn: 106480
- Precision toStrings shouldn't print a dot when they have no value.
- Length of char length modifier is now returned correctly.
- Added several fixit tests.
Note: fixit tests are currently broken due to a bug in HighlightRange. Marking as XFAIL for now.
M test/Sema/format-strings-fixit.c
M include/clang/Analysis/Analyses/PrintfFormatString.h
M lib/Analysis/PrintfFormatString.cpp
llvm-svn: 106275
- Added warning for undefined behavior when using field specifier
- Added warning for undefined behavior when using length modifier
- Fixed warnings for invalid flags
- Added warning for ignored flags
- Added fixits for the above warnings
- Fixed accuracy of detecting several undefined behavior conditions
- Receive normal warnings in addition to security warnings when using %n
- Fix bug where '+' flag would remain on unsigned conversion suggestions
Summary of changes:
- Added expanded tests
- Added/expanded warnings
- Added position info to OptionalAmounts for fixits
- Extracted optional flags to a wrapper class with position info for fixits
- Added several methods to validate a FormatSpecifier by component, each checking for undefined behavior
- Fixed conversion specifier checking to conform to C99 standard
- Added hooks to detect the invalid states in CheckPrintfHandler::HandleFormatSpecifier
Note: warnings involving the ' ' (space) flag are temporarily disabled until whitespace highlighting no longer triggers assertions. I will make a post about this on cfe-dev shortly.
M test/Sema/format-strings.c
M include/clang/Basic/DiagnosticSemaKinds.td
M include/clang/Analysis/Analyses/PrintfFormatString.h
M lib/Analysis/PrintfFormatString.cpp
M lib/Sema/SemaChecking.cpp
llvm-svn: 106233
- Added some handling of flags that become invalid when changing the conversion specifier.
- Changed fixit behavior to remove unnecessary length modifiers.
- Separated some tests out and added some comments.
modified:
lib/Analysis/PrintfFormatString.cpp
test/Sema/format-strings-fixit.c
llvm-svn: 105807
- Refactored LengthModifier to be a class.
- Added toString methods in all member classes of FormatSpecifier.
- FixIt suggestions keep user specified flags unless incorrect.
Limitations:
- The suggestions are not conversion specifier sensitive. For example, if we have a 'pad with zeroes' flag, and the correction is a string conversion specifier, we do not remove the flag. Clang will warn us on the next compilation.
A test/Sema/format-strings-fixit.c
M include/clang/Analysis/Analyses/PrintfFormatString.h
M lib/Analysis/PrintfFormatString.cpp
M lib/Sema/SemaChecking.cpp
llvm-svn: 105680
diagnostics. That would be while we're parsing string literals for the
sole purpose of producing a diagnostic about them. Fixes
<rdar://problem/8026030>.
llvm-svn: 104684
in several important ways:
- VLAs of non-POD types are not permitted.
- VLAs cannot be used in conjunction with C++ templates.
These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.
llvm-svn: 104443
about the permitted scopes. Specifically:
1) Permit labels and gotos to appear after a prologue of variable initializations.
2) Permit indirect gotos to jump out of scopes that don't require cleanup.
3) Diagnose possible attempts to indirect-jump out of scopes that do require
cleanup.
This requires a substantial reinvention of the algorithm for checking indirect
goto. The current algorithm is Omega(M*N), with M = the number of unique
scopes being jumped from and N = the number of unique scopes being jumped to,
with an additional factor that is probably (worst-case) linear in the depth
of scopes. Thus the entire thing is likely cubic given some truly bizarre
ill-formed code; on well-formed code the additional factor collapses to
an amortized constant (when amortized over the entire function) and so
the algorithm is quadratic. Even this requires every label to appear in
its own scope, which would be very unusual for indirect-goto code (and
extremely unlikely for well-formed code); it is far more likely that
all labels will be in the same scope and so the algorithm becomes linear.
For such a marginal feature, I am fairly happy with this result.
(this is using JumpDiagnostic's definition of scope, where successive
variables in a block appear in their own scope)
llvm-svn: 103536
"bottom-up" when implicit casts and comparisons are inserted, compute them
"top-down" when the full expression is finished. Makes it easier to
coordinate warnings and thus implement -Wconversion for signedness
conversions without double-warning with -Wsign-compare. Also makes it possible
to realize that a signedness conversion is okay because the context is
performing the inverse conversion. Also simplifies some logic that was
trying to calculate the ultimate comparison/result type and getting it wrong.
Also fixes a problem with the C++ explicit casts which are often "implemented"
in the AST with a series of implicit cast expressions.
llvm-svn: 103174
typedef int functype(int, int);
functype func;
also instantiate the synthesized function parameters for the resulting
function declaration.
With this change, Boost.Wave builds and passes all of its regression
tests.
llvm-svn: 103025
- This fixes the last known ABI issues with ARM/APCS.
- I've run the first 1k ABITests with '--no-unsigned --no-vector --no-complex'
on {armv6, armv7} x {-mno-thumb, -mthumb}, and the first 10k tests for armv7
-mthumb, for both function return types and single argument calls. These all
pass now (they failed horribly before without --no-bitfield).
llvm-svn: 102070
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:
t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
type 'int *' [-pedantic]
f(long_ptr);
^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
^
llvm-svn: 102038
checking into a single function and use that throughout. Remove some
now unnecessary diagnostics and update tests with now more accurate
diagnostics.
llvm-svn: 101610
that adds parentheses from the main diagnostic down to a new
note. This way, when the fix-it represents a choice between two
options, each of the options is associted with a note. There is no
default option in such cases. For example:
/Users/dgregor/t.c:2:9: warning: & has lower precedence than ==; ==
will be
evaluated first [-Wparentheses]
if (x & y == 0) {
^~~~~~~~
/Users/dgregor/t.c:2:9: note: place parentheses around the &
expression to
evaluate it first
if (x & y == 0) {
^
( )
/Users/dgregor/t.c:2:9: note: place parentheses around the ==
expression to
silence this warning
if (x & y == 0) {
^
( )
llvm-svn: 101249
we don't have enough information to tell them how to use 'strncmp'. Instead, change the
diagnostic to indicate they should use 'strncmp'.
llvm-svn: 100890
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
llvm-svn: 100832
(1) Do not assume the data arguments start after the format string
(2) Do not use the fact that a function is variadic to treat it like a va_list printf function
Fixes PR 6697.
llvm-svn: 99480
entering a function or block definition, not on every single declaration.
Unfortunately we don't have previous-lookup results around when it's time
to make this decision, so we have to redo the lookup. The alternative is
to use delayed diagnostics.
llvm-svn: 99172
Fixes an assertion arising C overload analysis, but really I can't imagine
that this wouldn't cause a thousand other uncaught failures.
Fixes PR6600.
llvm-svn: 98400
which has the label map, switch statement stack, etc. Previously, we
had a single set of maps in Sema (for the function) along with a stack
of block scopes. However, this lead to funky behavior with nested
functions, e.g., in the member functions of local classes.
The explicit-stack approach is far cleaner, and we retain a 1-element
cache so that we're not malloc/free'ing every time we enter a
function. Fixes PR6382.
Also, tweaked the unused-variable warning suppression logic to look at
errors within a given Scope rather than within a given function. The
prior code wasn't looking at the right number-of-errors count when
dealing with blocks, since the block's count would be deallocated
before we got to ActOnPopScope. This approach works with nested
blocks/functions, and gives tighter error recovery.
llvm-svn: 97518
larger unsigned value, since this is implementation-defined
behavior. (We previously suppressed this warning when converting from
a signed value to an unsigned value of the same size).
llvm-svn: 97430
an *almost* always incorrect case. This only does the lookahead
in the insanely unlikely case, so it shouldn't impact performance.
On this testcase:
struct foo {
}
typedef int x;
Before:
t.c:3:9: error: cannot combine with previous 'struct' declaration specifier
typedef int x;
^
After:
t.c:2:2: error: expected ';' after struct
}
^
;
llvm-svn: 97403
Sema and into analyze_printf::ParseFormatString(). Also use a bitvector to determine
what arguments have been covered (instead of just checking to see if the last argument consumed is the max argument). This is prep. for support positional arguments (an IEEE extension).
llvm-svn: 97248
types. Rank these conversions below other conversions. This allows overload
resolution when the only distinction is between a complex and scalar type. It
also brings the complex overload resolutin in line with GCC's.
llvm-svn: 97128
__alignof__ operator, make sure to take into account the packed alignment
of the struct/union/class itself. Matches GCC's behavior and fixes PR6362.
llvm-svn: 96884
errors, e.g.:
t.c:1:21: error: redefinition of parameter 'x'
int test(int x, int x);
^
t.c:1:14: note: previous declaration is here
int test(int x, int x);
^
llvm-svn: 96769
Enhance the printf format string checking when using the format
specifier flags ' ', '0', '+' with the 'p' or 's' conversions (since
they are nonsensical and undefined). This is similar to GCC's
checking.
Also warning when a precision is used with the 'p' conversin
specifier, since it has no meaning.
llvm-svn: 95869
attribute, so it uses Anton's new target-specific attribute support. It's
supposed to ensure that the stack is 16-byte aligned, but since necessary
support is lacking from LLVM, this is a no-op for now.
llvm-svn: 95820
Sema::ActOnUninitializedDecl over to InitializationSequence (with
default initialization), eliminating redundancy. More importantly, we
now check that a const definition in C++ has an initilizer, which was
an #if 0'd code for many, many months. A few other tweaks were needed
to get everything working again:
- Fix all of the places in the testsuite where we defined const
objects without initializers (now that we diagnose this issue)
- Teach instantiation of static data members to find the previous
declaration, so that we build proper redeclaration
chains. Previously, we had the redeclaration chain but built it
too late to be useful, because...
- Teach instantiation of static data member definitions not to try
to check an initializer if a previous declaration already had an
initializer. This makes sure that we don't complain about static
const data members with in-class initializers and out-of-line
definitions.
- Move all of the incomplete-type checking logic out of
Sema::FinalizeDeclaratorGroup; it makes more sense in
ActOnUnitializedDecl.
There may still be a few places where we can improve these
diagnostics. I'll address that as a separate commit.
llvm-svn: 95657
follows (as conservatively as possible) gcc's current behavior: attributes
written on return types that don't apply there are applied to the function
instead, etc. Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks). Consistently consume CC/noreturn
information throughout codegen; enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().
llvm-svn: 95436
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
const int i;
(void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
llvm-svn: 95167
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
llvm-svn: 95117
forgetting a ';' at the end of a struct. For something like:
class c {
}
void foo() {}
we now produce:
t.cc:3:2: error: expected ';' after class
}
^
;
instead of:
t.cc:4:1: error: cannot combine with previous 'class' declaration specifier
void foo() {}
^
t.cc:2:7: error: 'class c' can not be defined in the result type of a function
class c {
^
GCC produces:
t.cc:4: error: new types may not be defined in a return type
t.cc:4: note: (perhaps a semicolon is missing after the definition of ‘c’)
t.cc:4: error: two or more data types in declaration of ‘foo’
I *think* I got the follow set right, but if I forgot anything, we'll start
getting spurious "expected ';' after class" errors, let me know if you see
any.
llvm-svn: 95042
- In C++, prior to the closing '}', set the type of enumerators
based on the type of their initializer. Don't perform unary
conversions on the enumerator values.
- In C++, handle overflow when an enumerator has no initializer and
its value cannot be represented in the type of the previous
enumerator.
- In C, handle overflow more gracefully, by complaining and then
falling back to the C++ rules.
- In C, if the enumerator value is representable in an int, convert the
expression to the type 'int'.
Fixes PR5854 and PR4515.
llvm-svn: 95031
when checking if the format specifier matches the type of the data
argument and the length modifier indicates the data type is 'char' or
'short'.
llvm-svn: 94992
Abramo Bagnara