| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
check is triggered appropriately. Reported on cfe-dev.
llvm-svn: 129231
|
| |
|
|
|
|
| |
pageexec@freemail.hu, tweaks by me.
llvm-svn: 129206
|
| |
|
|
| |
llvm-svn: 129202
|
| |
|
|
|
|
| |
Patch by Dave Zarzycki!
llvm-svn: 129189
|
| |
|
|
|
|
| |
to eliminate a divide-by-8. No change in functionality intended.
llvm-svn: 129180
|
| |
|
|
|
|
| |
the base offset. No change in functionality intended.
llvm-svn: 129179
|
| |
|
|
| |
llvm-svn: 129176
|
| |
|
|
|
|
| |
zero also indicates one element array.
llvm-svn: 129157
|
| |
|
|
|
|
|
| |
Change the return type of CodeGenVTables::getVirtualBaseOffsetOffset() to
CharUnits. No change in functionality intended.
llvm-svn: 129072
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
llvm-svn: 129065
|
| |
|
|
|
|
|
|
|
| |
with debug info.]
Use CharUnits for the offsets in the VirtualBaseClassOffsetOffsetsMapTy. No
change in functionality intended.
llvm-svn: 129048
|
| |
|
|
|
|
|
|
|
| |
info.]
Use CharUnits for the offset type in the ClassNamesAndOffsets map in
dumpLayout(). No change in functionality intended.
llvm-svn: 129046
|
| |
|
|
|
|
|
| |
Use CharUnits for the offsets in the VBaseOffsetOffsetsMapTy types. No
change in functionality intended.
llvm-svn: 129043
|
| |
|
|
|
|
|
| |
pass a previously failing clang test.
// rdar://8808439
llvm-svn: 129004
|
| |
|
|
|
|
| |
intrinsic's attributes.
llvm-svn: 129000
|
| |
|
|
| |
llvm-svn: 128957
|
| |
|
|
|
|
|
| |
As a result, I had to remove a c++ version of a clang
test which requires more scrutiny on my part.
llvm-svn: 128950
|
| |
|
|
| |
llvm-svn: 128948
|
| |
|
|
|
|
|
| |
targets) when load/store results in multiple instructions.
// rdar://8808439
llvm-svn: 128937
|
| |
|
|
| |
llvm-svn: 128928
|
| |
|
|
| |
llvm-svn: 128921
|
| |
|
|
| |
llvm-svn: 128915
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.
Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.
llvm-svn: 128911
|
| |
|
|
| |
llvm-svn: 128908
|
| |
|
|
| |
llvm-svn: 128893
|
| |
|
|
|
|
| |
Does anyone want to buy me a new brain?
llvm-svn: 128890
|
| |
|
|
|
|
| |
handling.
llvm-svn: 128866
|
| |
|
|
| |
llvm-svn: 128857
|
| |
|
|
| |
llvm-svn: 128855
|
| |
|
|
| |
llvm-svn: 128842
|
| |
|
|
|
|
| |
CharUnits. No change in functionality intended.
llvm-svn: 128776
|
| |
|
|
|
|
| |
change in functionality intended.
llvm-svn: 128773
|
| |
|
|
|
|
| |
dumpLayout(). No change in functionality intended.
llvm-svn: 128771
|
| |
|
|
|
|
| |
change in functionality intended.
llvm-svn: 128770
|
| |
|
|
|
|
| |
functionality intended.
llvm-svn: 128756
|
| |
|
|
|
|
| |
CharUnits. No change in functionality intended.
llvm-svn: 128754
|
| |
|
|
|
|
| |
functionality intended.
llvm-svn: 128753
|
| |
|
|
|
|
| |
No change in functionality intended.
llvm-svn: 128752
|
| |
|
|
| |
llvm-svn: 128725
|
| |
|
|
|
|
| |
that of the array element type.
llvm-svn: 128698
|
| |
|
|
|
|
| |
arrays by propagating", it's breaking test in ways I don't understand yet.
llvm-svn: 128693
|
| |
|
|
|
|
|
|
| |
the array alignment to the array access.
- This is more or less the best we can do without having alignment present in
the type system, but is a long way from truly matching how GCC handles this.
llvm-svn: 128691
|
| |
|
|
| |
llvm-svn: 128621
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
__block object copy/dispose helpers for C++ objects with those for
different variables with completely different semantics simply because
they happen to both be no more aligned than a pointer.
Found by inspection.
Also, internalize most of the helper generation logic within CGBlocks.cpp,
and refactor it to fit my peculiar aesthetic sense.
llvm-svn: 128618
|
| |
|
|
|
|
| |
change.
llvm-svn: 128608
|
| |
|
|
| |
llvm-svn: 128607
|
| |
|
|
|
|
| |
expression
llvm-svn: 128605
|
| |
|
|
|
|
|
| |
VCallAndVBaseOffsetBuilder::getCurrentOffsetOffset() to CharUnits. No change
in functionality intended.
llvm-svn: 128603
|
| |
|
|
|
|
|
| |
VCallAndVBaseOffsetBuilder::AddVBaseOffsets() to CharUnits. No change in
functionality intended.
llvm-svn: 128600
|
| |
|
|
|
|
| |
constructor to CharUnits. No change in functionality intended.
llvm-svn: 128598
|