| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
aren't supported at the moment. PR12040.
llvm-svn: 152891
|
| |
|
|
|
|
| |
storage class, the asm name doesn't specify a register. PR12244.
llvm-svn: 152873
|
| |
|
|
|
|
|
| |
the behavior of gcc with respect to the -fno-inline and -fno-inline-functions
flags.
llvm-svn: 152861
|
| |
|
|
|
|
| |
Patch by Silviu Baranga!
llvm-svn: 152788
|
| |
|
|
|
|
|
|
|
|
|
| |
-fno-inline-functions.
This behaves much like -fno-inline in gcc, but based on a discussion with
Daniel it was decided that -fno-inline-functions should subsume -fno-inline.
Please speak up if you object. The -fno-inline flag remains ignored.
Final part of rdar://10972766
llvm-svn: 152754
|
| |
|
|
|
|
| |
powerpc_types and add testing for the (long) double there.
llvm-svn: 152647
|
| |
|
|
| |
llvm-svn: 152552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- We do this when it is easy to determine that the backend will pass them on
the stack properly by itself.
Currently LLVM codegen is really bad in some cases with byval, for example, on
the test case here (which is derived from Sema code, which likes to pass
SourceLocations around)::
struct s47 { unsigned a; };
void f47(int,int,int,int,int,int,struct s47);
void test47(int a, struct s47 b) { f47(a, a, a, a, a, a, b); }
we used to emit code like this::
...
movl %esi, -8(%rbp)
movl -8(%rbp), %ecx
movl %ecx, (%rsp)
...
to handle moving the struct onto the stack, which is just appalling.
Now we generate::
movl %esi, (%rsp)
which seems better, no?
llvm-svn: 152462
|
| |
|
|
|
|
|
| |
-fno-inline.
Part of rdar://10972766
llvm-svn: 152145
|
| |
|
|
| |
llvm-svn: 152134
|
| |
|
|
|
|
| |
rdar://10972766
llvm-svn: 152130
|
| |
|
|
|
|
|
| |
we're making. We only ignore implicit casts. Add a testcase showing that
we get the right behavior with explicit casts.
llvm-svn: 151994
|
| |
|
|
|
|
| |
reported by Richard Smith.
llvm-svn: 151993
|
| |
|
|
|
|
|
| |
correct radar number to the test case for tracking purposes.
rdar://10551066
llvm-svn: 151746
|
| |
|
|
|
|
|
|
|
| |
by the BAA pass, which uses the default TargetLibraryInfo constructor.
Unfortunately, the default TargetLibraryInfo constructor assumes all library
calls are available and thus ignores -fno-builtin.
rdar://10947759
llvm-svn: 151745
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug that was caught by Apple's internal buildbots was valid and also showed another bug in my implementation.
These are now fixed, with regression tests added to catch them both (not Darwin-specific).
Original log:
====================
Revert r151638 because it causes assertion hit on PCH creation for Cocoa.h
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
====================
llvm-svn: 151712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
llvm-svn: 151667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
llvm-svn: 151638
|
| |
|
|
|
|
| |
<rdar://problem/10938628>
llvm-svn: 151549
|
| |
|
|
|
|
| |
being emitted at -O0, but are emitted when optimizations are enabled.
llvm-svn: 151533
|
| |
|
|
| |
llvm-svn: 151407
|
| |
|
|
|
|
| |
MS compatibility mode.
llvm-svn: 151295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
match the behavior of GCC. Also add a test for these intrinsics, which
apparently have *zero* tests. =[ Not surprisingly, Clang crashed when
compiling these.
Fix the bug in CodeGen where we failed to bitcast the argument type to
x86mmx prior to calling the LLVM intrinsic. This fixes an assert on the
new 3dnow-builtins.c test.
This is one issue impacting the efforts to get Clang to emulate the
Microsoft intrinsics headers -- 3dnow intrinsics are implictitly made
available there.
llvm-svn: 150948
|
| |
|
|
|
|
| |
This fixes PR5172 and allows clang to compile C++ programs on Solaris using the system headers.
llvm-svn: 150881
|
| |
|
|
| |
llvm-svn: 150242
|
| |
|
|
|
|
|
|
|
|
| |
This changes function prolog in such a way as to avoid out-of-bounds
stack store in the case when coerce-to type has a larger storage size
than the real argument type.
Fixes PR11905.
llvm-svn: 150238
|
| |
|
|
|
|
|
| |
Double fields of by-value class objects should be passed in floating point
registers.
llvm-svn: 150200
|
| |
|
|
|
|
| |
class objects follow the same rules as those returning struct objects.
llvm-svn: 150196
|
| |
|
|
|
|
| |
builtin_shufflevector.
llvm-svn: 150064
|
| |
|
|
|
|
| |
builtin_shufflevector.
llvm-svn: 150056
|
| |
|
|
|
|
| |
registers.
llvm-svn: 150035
|
| |
|
|
|
|
| |
same logic as FunctionDecl::isInlineDefinitionExternallyVisible to figure out whether to emit a definition. Based on work by Anton Yartsev.
llvm-svn: 149963
|
| |
|
|
|
|
|
|
| |
We had been generating load/store instructions with the default alignment
for the vector element type, even when the pointer argument had less alignment.
<rdar://problem/10538555>
llvm-svn: 149794
|
| |
|
|
| |
llvm-svn: 149726
|
| |
|
|
|
|
| |
rdar://10736625
llvm-svn: 149662
|
| |
|
|
| |
llvm-svn: 149594
|
| |
|
|
|
|
| |
extern inline case considered
llvm-svn: 149587
|
| |
|
|
|
|
| |
connecting intrinsics and builtins in IntrinsicsX86.td.
llvm-svn: 149233
|
| |
|
|
|
|
|
|
|
| |
There is really no reason to have these only available on x86. It's
just __builtin_c[tl]z for shorts.
Modernize the test while at it.
llvm-svn: 149183
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM supports clz and ctz directly and both operations have well-defined
results for zero. There is no disadvantage in performance to using the
defined-at-zero versions of llvm.ctlz/cttz intrinsics. We're running into
ARM-specific code written with the assumption that __builtin_clz(0) == 32,
even though that value is technically undefined. The code is failing now
because of llvm optimizations that are taking advantage of the undef
behavior (specifically svn r147255). There's nothing wrong with that
optimization on x86 where any incorrect assumptions about __builtin_clz(0)
will quickly be exposed. For ARM, though, optimizations based on that undef
behavior are likely to cause subtle bugs. Other targets with defined-at-zero
clz/ctz support may want to override the default behavior as well.
llvm-svn: 149086
|
| |
|
|
| |
llvm-svn: 149072
|
| |
|
|
| |
llvm-svn: 149066
|
| |
|
|
|
|
|
|
|
|
| |
end up in the same output file as the layout stuff. There may even be
a race condition which is causing this output to confuse the FileCheck
in some cases. I actually don't know how on earth the parsing of the
layout file even works given that there are diagnostics in the middle of
it. ;]
llvm-svn: 149058
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
provide the layout of records, rather than letting Clang compute
the layout itself. LLDB provides the motivation for this feature:
because various layout-altering attributes (packed, aligned, etc.)
don't get reliably get placed into DWARF, the record layouts computed
by LLDB from the reconstructed records differ from the actual layouts,
and badness occurs. This interface lets the DWARF data drive layout,
so we don't need the attributes preserved to get the answer write.
The testing methodology for this change is fun. I've introduced a
variant of -fdump-record-layouts called -fdump-record-layouts-simple
that always has the simple C format and provides size/alignment/field
offsets. There is also a -cc1 option -foverride-record-layout=<file>
to take the output of -fdump-record-layouts-simple and parse it to
produce a set of overridden layouts, which is introduced into the AST
via a testing-only ExternalASTSource (called
LayoutOverrideSource). Each test contains a number of records to lay
out, which use various layout-changing attributes, and then dumps the
layouts. We then run the test again, using the preprocessor to
eliminate the layout-changing attributes entirely (which would give us
different layouts for the records), but supplying the
previously-computed record layouts. Finally, we diff the layouts
produced from the two runs to be sure that they are identical.
Note that this code makes the assumption that we don't *have* to
provide the offsets of bases or virtual bases to get the layout right,
because the alignment attributes don't affect it. I believe this
assumption holds, but if it does not, we can extend
LayoutOverrideSource to also provide base offset information.
Fixes the Clang side of <rdar://problem/10169539>.
llvm-svn: 149055
|
| |
|
|
|
|
| |
MSVC-compatible way. Patch by Joe Groff.
llvm-svn: 148992
|
| |
|
|
| |
llvm-svn: 148944
|
| |
|
|
| |
llvm-svn: 148932
|
| |
|
|
| |
llvm-svn: 148928
|
| |
|
|
| |
llvm-svn: 148925
|
| |
|
|
|
|
| |
change was made for 128-bit versions a while back.
llvm-svn: 148919
|