| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 65270
|
| |
|
|
|
|
| |
copy 'rule' if it doesn't already start with 'init', etc.
llvm-svn: 65269
|
| |
|
|
|
|
| |
immediate would fit in target addressing field.
llvm-svn: 65268
|
| |
|
|
| |
llvm-svn: 65267
|
| |
|
|
|
|
|
|
|
| |
as byval. Otherwise LLVM will have its own opinion about where to put
things.
We now pass all gcc dg.compat tests on x86_64.
llvm-svn: 65266
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
helper isConstantInitializer) to check whether an initializer is
constant. This passes tests, but it's possible that it'll cause
regressions with real-world code.
Future work:
1. The diagnostics obtained this way are lower quality at the moment;
some work both here and in Evaluate is needed for accurate diagnostics.
2. We probably need some extra code when we're in -pedantic mode so we
can strictly enforce the rules in C99 6.6p7.
3. Dead code cleanup (this should wait until after 2, because we might
want to re-use some of the code).
llvm-svn: 65265
|
| |
|
|
|
|
| |
about these much but <2 x i16> shows up in the gcc test suite.
llvm-svn: 65264
|
| |
|
|
|
|
|
| |
of sizes. Turns out we don't care very much about vector types that
don't map to the hardware.
llvm-svn: 65263
|
| |
|
|
|
|
|
| |
Also, make sure to pass <1 x i64> as i64 (not <1 x i64>, which doesn't
quite work yet in the backend).
llvm-svn: 65262
|
| |
|
|
|
|
|
|
| |
I know, these follow the exact same rules as pointers, so I just made
them use the same codepath. Someone more familiar with ObjC should
double-check this, though.
llvm-svn: 65261
|
| |
|
|
|
|
| |
partially done in r65258.)
llvm-svn: 65260
|
| |
|
|
|
|
|
| |
CodeGen. I'm not sure whether this actually makes any visible
difference, but it's better to be consistent anyway.
llvm-svn: 65259
|
| |
|
|
|
|
|
|
|
| |
PR3254 and part of PR3433.
The isICE changes are necessary to keep the computed results
consistent with Evaluate.
llvm-svn: 65258
|
| |
|
|
| |
llvm-svn: 65257
|
| |
|
|
|
|
| |
Fixes PR3641.
llvm-svn: 65256
|
| |
|
|
| |
llvm-svn: 65255
|
| |
|
|
|
|
| |
compilation results on failures.
llvm-svn: 65254
|
| |
|
|
|
|
|
|
|
|
| |
required to actually be an error for correctness. The attached testcase
now gives an error instead of mysteriously crashing.
Now, it's possible we actually want to support the given usage, but I
haven't looked at the relevant code closely.
llvm-svn: 65253
|
| |
|
|
| |
llvm-svn: 65252
|
| |
|
|
| |
llvm-svn: 65251
|
| |
|
|
| |
llvm-svn: 65250
|
| |
|
|
| |
llvm-svn: 65249
|
| |
|
|
|
|
| |
This is necessary 'plumbing' to fix <rdar://problem/6497631> Message lookup is sometimes different than gcc's.
llvm-svn: 65248
|
| |
|
|
|
|
| |
<prefix>/Headers, gross).
llvm-svn: 65247
|
| |
|
|
|
|
| |
load(bitcast(char[4] to i32*)) evaluation.
llvm-svn: 65246
|
| |
|
|
|
|
| |
value/definition/origin of FOO.
llvm-svn: 65245
|
| |
|
|
|
|
|
|
| |
Found while researching <rdar://problem/6497631> Message lookup is sometimes different than gcc's.
Will never be seen in user code. Needed to pass dejagnu testsuite.
llvm-svn: 65244
|
| |
|
|
| |
llvm-svn: 65243
|
| |
|
|
|
|
| |
stuff is mostly done. Move BlockHasCopyDispose up.
llvm-svn: 65242
|
| |
|
|
| |
llvm-svn: 65241
|
| |
|
|
|
|
| |
variable (objc2 gc specific).
llvm-svn: 65240
|
| |
|
|
| |
llvm-svn: 65239
|
| |
|
|
|
|
| |
as __weak (objc2 gc specific).
llvm-svn: 65238
|
| |
|
|
| |
llvm-svn: 65237
|
| |
|
|
|
|
| |
and compares up to 'len' characters. I tend to screw up string comparison functions, so anyone who is interested please review this\!
llvm-svn: 65236
|
| |
|
|
| |
llvm-svn: 65235
|
| |
|
|
|
|
|
| |
expr; hilarity ensued.
- PR3640.
llvm-svn: 65234
|
| |
|
|
|
|
| |
Should clang have a config.h or should we use the config.h of llvm or using the preprocessor is OK? I did a quick fix here, but having a guideline on how to handle non portable function would be great (or ask ted to stop breaking the windows build :)).
llvm-svn: 65233
|
| |
|
|
|
|
|
|
| |
<rdar://problem/6561076> [clang on Xcode] warning: cannot find protocol definition for 'OzzyP').
Removing the "cannot find protocol" warning is trivial if necessary (but I don't think it's the right thing to do).
llvm-svn: 65232
|
| |
|
|
|
|
|
|
|
|
| |
Move two key ObjC typechecks from Sema::CheckPointerTypesForAssignment() to ASTContext::mergeTypes().
This allows us to take advantage of the recursion in ASTContext::mergeTypes(), removing some bogus warnings.
This test case I've added includes an example where we still warn (and GCC doesn't). Need to talk with folks and decide what to do. At this point, the major bogosities should be fixed.
llvm-svn: 65231
|
| |
|
|
|
|
|
|
|
|
|
| |
Now we're using one gross, but quite robust hack :) (previous ones
did not work, for example, when ext_weak symbol was used deep inside
constant expression in the initializer).
The proper fix of this problem will require some quite huge asmprinter
changes and that's why was postponed. This fixes PR3629 by the way :)
llvm-svn: 65230
|
| |
|
|
| |
llvm-svn: 65229
|
| |
|
|
| |
llvm-svn: 65228
|
| |
|
|
| |
llvm-svn: 65227
|
| |
|
|
|
|
|
|
|
| |
handle method names that contain 'new', 'copy', etc., but those words might be
the substring of larger words such as 'newsgroup' and 'photocopy' that do not
indicate the allocation of objects. This should address the issues discussed in
<rdar://problem/6552389>.
llvm-svn: 65224
|
| |
|
|
| |
llvm-svn: 65223
|
| |
|
|
|
|
| |
does not exist an 'attribute_ignored_XXX.txt' file for that attribute.
llvm-svn: 65222
|
| |
|
|
|
|
| |
registers, and it doesn't produce side effects, just delete the instruction.
llvm-svn: 65218
|
| |
|
|
|
|
| |
into uses if they fit in address modes of all the uses.
llvm-svn: 65215
|
| |
|
|
| |
llvm-svn: 65213
|