| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
-Wuninitialized to avoid cascading warnings. Patch by Kaelyn Uhrain.
llvm-svn: 135217
|
| |
|
|
| |
llvm-svn: 135208
|
| |
|
|
|
|
| |
thing to do.
llvm-svn: 135152
|
| |
|
|
|
|
| |
cases to be more portable with an explicit target triple.
llvm-svn: 135134
|
| |
|
|
|
|
|
|
| |
on 32-bit, so we shouldn't warn about using"
It fails on freebsd, mingw and msvc10.
llvm-svn: 135129
|
| |
|
|
|
|
|
|
| |
shouldn't warn about using
an "int" format specifier with a "long" type in 32-bit.
llvm-svn: 135075
|
| |
|
|
|
|
| |
conversion specifiers. My recent change was a mistake.
llvm-svn: 135048
|
| |
|
|
|
|
| |
specifiers for character types.
llvm-svn: 135046
|
| |
|
|
|
|
|
|
|
| |
and (while I'm at it) teach it to grok the results of simple
assignments.
The first is PR10336.
llvm-svn: 135034
|
| |
|
|
|
|
| |
As it turns out, this is my fault for not noticing this was an issue when I was looking at this a long time ago. :(
llvm-svn: 135026
|
| |
|
|
|
|
| |
behavior. PR10201.
llvm-svn: 134926
|
| |
|
|
|
|
| |
functions. Fixes <rdar://problem/9731999>.
llvm-svn: 134897
|
| |
|
|
|
|
|
|
|
|
|
|
| |
should not imply -mno-sse.
Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__.
clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much.
<rdar://problem/9694837>
llvm-svn: 134770
|
| |
|
|
|
|
|
|
| |
extra register.
Part of PR10299 and rdar://9740322
llvm-svn: 134657
|
| |
|
|
|
|
| |
This fixes PR10223.
llvm-svn: 134183
|
| |
|
|
| |
llvm-svn: 134171
|
| |
|
|
|
|
| |
This fell out when Chandler landed the patch in r134138.
llvm-svn: 134163
|
| |
|
|
|
|
| |
initialized via initializer lists. Fixes <rdar://problem/9694686>.
llvm-svn: 134099
|
| |
|
|
|
|
|
| |
replace the existing declaration appropriately. Patch by Jordy Rose,
fixes PR10013 / <rdar://problem/9584157>.
llvm-svn: 134097
|
| |
|
|
|
|
| |
Fixes rdar://9281377
llvm-svn: 134016
|
| |
|
|
|
|
|
| |
functions with arguments of transparent unions type.
// rdar://9584012
llvm-svn: 133941
|
| |
|
|
|
|
| |
a pointer to void.
llvm-svn: 133912
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
|
| |
|
|
| |
llvm-svn: 133842
|
| |
|
|
|
|
|
|
| |
expression into the LHS of a compound assignment. Fixes compound assignment of various "compatible" vector types, including NEON-vector and gcc-vector types.
<rdar://problem/9640356>
llvm-svn: 133737
|
| |
|
|
|
|
| |
declared variable and ignore it. // rdar://9538608
llvm-svn: 133654
|
| |
|
|
|
|
|
| |
Removes dead code found in the process.
Adds a test to verify that ParenListExprs do not have NULL types.
llvm-svn: 133637
|
| |
|
|
|
|
|
| |
expression of '?:'. Add a test case for this pattern, and also test the
code that led to the crash in a "working" case as well.
llvm-svn: 133523
|
| |
|
|
|
|
| |
Patch by Henry Mason with tweaks by me.
llvm-svn: 133453
|
| |
|
|
|
|
|
|
| |
pointers I found while working on the NULL arithmetic warning. We here
always assuming the LHS was the pointer, instead of using the selected
pointer expression.
llvm-svn: 133428
|
| |
|
|
| |
llvm-svn: 133264
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pretty. In particular this makes it much easier for me to read messages
such as:
x.cc:42: ?: has lower ...
Where I'm inclined to associate the third ':' with a missing column
number, but in fact column numbers have been turned off. Similar
punctuation collisions happened elsewhere as well.
llvm-svn: 133121
|
| |
|
|
|
|
|
| |
either imlicitly (for builtins) or explicitly (due to multiple
specification of the same attributes). Fixes <rdar://problem/9612060>.
llvm-svn: 133045
|
| |
|
|
| |
llvm-svn: 133036
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the output for -Wshift-overflow and
-Wshift-sign-overflow to an unsigned hexadecimal. It makes
more sense for looking at bits than a signed decimal does.
Also, change the diagnostic's wording from "overrides"
to "sets".
This uses a new optional argument in APInt::toString()
that adds the '0x' prefix to hexademical numbers.
This fixes PR 9651.
Patch by nobled@dreamwidth.org!
llvm-svn: 133033
|
| |
|
|
|
|
|
| |
no-format-y2k turn off -Wformat altogether.
// rdar://9504680
llvm-svn: 133015
|
| |
|
|
|
|
|
|
|
|
| |
folded to a constant
as constant size arrays. This has slightly different semantics in some insane cases, but allows
us to accept some constructs that GCC does. Continue to be pedantic in -std=c99 and other
modes. This addressed rdar://8733881 - error "variable-sized object may not be initialized"; g++ accepts same code
llvm-svn: 132983
|
| |
|
|
|
|
|
| |
- Move a test from test/SemaTemplate/instantiate-expr-3.cpp, it did not belong there
- Incomplete and abstract types are considered hard errors
llvm-svn: 132979
|
| |
|
|
| |
llvm-svn: 132975
|
| |
|
|
|
|
|
|
| |
functions in gnu89 mode in terms of redefinitions.
rdar://9559708 .
llvm-svn: 132953
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to r132565, and should address the rest of PR9969:
Warn about cases such as
int foo(A a, bool b) {
return a + b ? 1 : 2; // user probably meant a + (b ? 1 : 2);
}
also when + is an overloaded operator call.
llvm-svn: 132784
|
| |
|
|
|
|
| |
range checking for immediate operands. Radar 9558930.
llvm-svn: 132783
|
| |
|
|
|
|
| |
builders.
llvm-svn: 132694
|
| |
|
|
| |
llvm-svn: 132691
|
| |
|
|
|
|
|
|
|
|
| |
Warn in cases such as "x + someCondition ? 42 : 0;",
where the condition expression looks arithmetic, and has
a right-hand side that looks boolean.
This (partly) addresses http://llvm.org/bugs/show_bug.cgi?id=9969
llvm-svn: 132565
|
| |
|
|
| |
llvm-svn: 132422
|
| |
|
|
|
|
|
|
|
|
|
|
| |
return f() || -1;
where the user meant to write '|'.
This bootstraps without any additional warnings.
Patch by Richard Trieu.
llvm-svn: 132327
|
| |
|
|
| |
llvm-svn: 131202
|
| |
|
|
| |
llvm-svn: 131170
|
| |
|
|
|
|
| |
a logical operation.
llvm-svn: 131158
|