| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
Now we don't warn on this code:
void __stdcall f(void);
void __stdcall f();
My previous commit regressed this functionality because I didn't update
the relevant test case which used a definition.
llvm-svn: 221188
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We already have a warning on the call sites of code like this:
void f() { }
void g() { f(1, 2, 3); }
t.c:2:21: warning: too many arguments in call to 'f'
We can limit ourselves to diagnosing unprototyped forward declarations
of f to cut down on noise.
llvm-svn: 221184
|
| |
|
|
|
|
| |
is argument to a macro which is defined in system header.
llvm-svn: 221172
|
| |
|
|
|
|
| |
is supported. Complex numbers are not.
llvm-svn: 221170
|
| |
|
|
|
|
|
|
| |
parameters with nonnull attribute when comparison is always
true/false. Patch causes false positive when parameter is
modified in the function.
llvm-svn: 221163
|
| |
|
|
|
|
|
|
| |
Local variables are not initialized, and every target has
been (incorrectly) ignoring the unnecessary request for
zero initialization.
llvm-svn: 221162
|
| |
|
|
|
|
|
|
|
|
|
| |
Trying to import or export such classes doesn't make sense, and Clang
would assert trying to export vtables for them.
This is consistent with how we treat functions with internal linkage,
but it is stricter than MSVC so we may have to back down if it breaks
real code.
llvm-svn: 221160
|
| |
|
|
|
|
|
|
|
| |
This reverts commit b5bdb2ef59ab922bcb4d6e843fffaee1f7f68a8c.
This doesn't really seem necessary on second though and causes problems
with C++ enum formatting.
llvm-svn: 221158
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.
To fix this, make Clang never dllimport inline functions when targeting
MinGW.
llvm-svn: 221154
|
| |
|
|
| |
llvm-svn: 221132
|
| |
|
|
|
|
| |
in alphabetical order.
llvm-svn: 221131
|
| |
|
|
| |
llvm-svn: 221130
|
| |
|
|
|
|
| |
intrinsic headers. Add a run line with Broadwell as the cpu type to ms-intrin.cpp test to catch some of these in the future.
llvm-svn: 221127
|
| |
|
|
|
|
|
|
|
|
|
| |
Before:
enum SomeThing { ABC, CDE }
;
After:
enum SomeThing { ABC, CDE };
llvm-svn: 221125
|
| |
|
|
|
|
|
|
|
|
| |
Before:
< T extends B > T getInstance(Class<T> type);
After:
<T extends B> T getInstance(Class<T> type);
llvm-svn: 221124
|
| |
|
|
|
|
|
|
|
|
| |
Before:
public static<R> ArrayList<R> get() {}
After:
public static <R> ArrayList<R> get() {}
llvm-svn: 221122
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@SomeAnnotation()
abstract
class aaaaaaaaaaaa extends bbbbbbbbbbbbbbb implements cccccccccccc {
}
After:
@SomeAnnotation()
abstract class aaaaaaaaaaaa extends bbbbbbbbbbbbbbb
implements cccccccccccc {
}
llvm-svn: 221121
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
delete [] a -> b;
After:
delete[] a->b;
This fixes part of llvm.org/PR21419.
llvm-svn: 221114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
class SomeClass {
enum SomeThing { ABC, CDE } void f() {
}
}
After:
class SomeClass {
enum SomeThing { ABC, CDE }
void f() {
}
}
This fixed llvm.org/PR21458.
llvm-svn: 221113
|
| |
|
|
|
|
| |
This fixes llvm.org/PR21453.
llvm-svn: 221112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
synchronized(mData) {
// ...
}
After:
synchronized (mData) {
// ...
}
This fixes llvm.org/PR21455.
llvm-svn: 221110
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@Override
public Map < String,
? > getAll() {
// ...
}
After:
@Override
public Map<String, ?> getAll() {
// ...
}
This fixes llvm.org/PR21454.
llvm-svn: 221109
|
| |
|
|
| |
llvm-svn: 221104
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
abstract class SomeClass extends SomeOtherClass implements
SomeInterface {}
After:
abstract class SomeClass extends SomeOtherClass
implements SomeInterface {}
llvm-svn: 221103
|
| |
|
|
|
|
| |
Implement post-commit comment on r220989 from Eric Christopher.
llvm-svn: 221099
|
| |
|
|
|
|
| |
names for these intrinsics.
llvm-svn: 221066
|
| |
|
|
|
|
| |
for 0 before calling __builtin_ctz. Without this the optimizers may take advantage of the undefined behavior and produce incorrect results. LLVM itself still needs to be taught to merge the zero check into the llvm.cttz with defined zero behavior.
llvm-svn: 221065
|
| |
|
|
|
|
| |
for 0 before calling __builtin_clz. Without this the optimizers may take advantage of the undefined behavior and produce incorrect results. LLVM itself still needs to be taught to merge the zero check into the llvm.ctlz with defined zero behavior.
llvm-svn: 221064
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 221043
|
| |
|
|
|
|
|
| |
The ARM ABI virtual destructor thunks cannot be marked as 'returned'
because they return undef.
llvm-svn: 221042
|
| |
|
|
|
|
| |
[-Winconsistent-missing-override]
llvm-svn: 221039
|
| |
|
|
| |
llvm-svn: 221030
|
| |
|
|
|
|
|
|
|
|
| |
It says there is a narrowing conversion when we assign it to an unsigned
3 bit bitfield.
Also, use unsigned instead of size_t for the Size field of the struct in
question. Otherwise they won't run together in MSVC or clang-cl.
llvm-svn: 221019
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most complex aspect of the convention is the handling of homogeneous
vector and floating point aggregates. Reuse the homogeneous aggregate
classification code that we use on PPC64 and ARM for this.
This convention also has a C mangling, and we apparently implement that
in both Clang and LLVM.
Reviewed By: majnemer
Differential Revision: http://reviews.llvm.org/D6063
llvm-svn: 221006
|
| |
|
|
|
|
|
|
| |
,-objcmt-migrate-property-dot-syntax, when migarting to use
property-dot syntax in place of messaging expression.
rdar://18839124
llvm-svn: 221001
|
| |
|
|
| |
llvm-svn: 221000
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.
Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
flag" set. The virtual deleting destructor will return a pointer to
'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5996
llvm-svn: 220993
|
| |
|
|
|
|
|
| |
macros in user code when macros themselves are defined
in a system header. rdar://18295240
llvm-svn: 220992
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions. This patch
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.
The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed. The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h. Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.
The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.
I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c. This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.
Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error. The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.
There is a companion patch for LLVM.
llvm-svn: 220989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we are adding field paddings for asan even an empty dtor has to remain in the code,
so we ignore -mconstructor-aliases if the paddings are going to be added.
Test Plan: added a test
Reviewers: rsmith, rnk, rafael
Reviewed By: rafael
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6038
llvm-svn: 220986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@SomeAnnotation("With some really looooooooooooooong text") private static final
long something = 0L;
void SomeFunction(@Nullable
String something) {}
After:
@SomeAnnotation("With some really looooooooooooooong text")
private static final long something = 0L;
void SomeFunction(@Nullable String something) {}
llvm-svn: 220984
|
| |
|
|
|
|
| |
The style guide is changing..
llvm-svn: 220977
|
| |
|
|
| |
llvm-svn: 220974
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a
nice code deduplication, since they are roughly identical. A few virtual
method extension points are needed to understand how big an HVA can be
and what element types it can have for a given architecture.
Also make the record expansion code work in the presence of non-virtual
bases.
Reviewed By: uweigand, asl
Differential Revision: http://reviews.llvm.org/D6045
llvm-svn: 220972
|
| |
|
|
|
|
|
|
|
|
| |
Rather than executing this code only needed for an assertion even in a
non-asserts build, just roll the function into the assert. The assertion
text literally describes the two cases so it doesn't seem like this
benefits much from having a separate function (& have to hassle about
ifndef NDEBUG it out, etc)
llvm-svn: 220970
|
| |
|
|
|
|
| |
they are not needed.
llvm-svn: 220966
|
| |
|
|
|
|
| |
StorageClass is in the clang namespace.
llvm-svn: 220956
|
| |
|
|
| |
llvm-svn: 220955
|
| |
|
|
|
|
| |
name. Remove a typedef that matches an identical one in the clang namespace.
llvm-svn: 220954
|
| |
|
|
|
|
| |
unit, allow the -O settings of the two compilations to differ.
llvm-svn: 220943
|