struct stat defined in <asm/stat.h> is incorrect for x32. <asm/stat.h>
is included to get struct __old_kernel_stat. But struct __old_kernel_stat
isn't used for x86-64 nor x32. This patch includes <sys/stat.h> instead
of <asm/stat.h> and comments out size check of struct __old_kernel_stat
for x86-64.
Patch by H.J. Lu
llvm-svn: 199192
Add API to LTOCodeGenerator to specify a strategy for the -internalize
pass.
This is a new attempt at Bill's change in r185882, which he reverted in
r188029 due to problems with the gold linker. This puts the onus on the
linker to decide whether (and what) to internalize.
In particular, running internalize before outputting an object file may
change a 'weak' symbol into an internal one, even though that symbol
could be needed by an external object file --- e.g., with arclite.
This patch enables three strategies:
- LTO_INTERNALIZE_FULL: the default (and the old behaviour).
- LTO_INTERNALIZE_NONE: skip -internalize.
- LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden
visibility.
LTO_INTERNALIZE_FULL should be used when linking an executable.
Outputting an object file (e.g., via ld -r) is more complicated, and
depends on whether hidden symbols should be internalized. E.g., for
ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and
LTO_INTERNALIZE_HIDDEN can be used otherwise. However,
LTO_INTERNALIZE_FULL is inappropriate, since the output object file will
eventually need to link with others.
lto_codegen_set_internalize_strategy() sets the strategy for subsequent
calls to lto_codegen_write_merged_modules() and lto_codegen_compile*().
<rdar://problem/14334895>
llvm-svn: 199191
MSVC defines size_t without any explicit declarations. This change
allows us to be compatible with TUs that depend on this declaration
appearing from nowhere.
llvm-svn: 199190
When creating a virtual register for a def, the value type should be
used to pick the register class. If we only use the register class
constraint on the instruction, we might pick a too large register class.
Some registers can store values of different sizes. For example, the x86
xmm registers can hold f32, f64, and 128-bit vectors. The three
different value sizes are represented by register classes with identical
register sets: FR32, FR64, and VR128. These register classes have
different spill slot sizes, so it is important to use the right one.
The register class constraint on an instruction doesn't necessarily care
about the size of the value its defining. The value type determines
that.
This fixes a problem where InstrEmitter was picking 32-bit register
classes for 64-bit values on SPARC.
llvm-svn: 199187
The already allocatable DPair superclass contains odd-even D register
pair in addition to the even-odd pairs in the QPR register class. There
is no reason to constrain the set of D register pairs that can be used
for NEON values. Any NEON instructions that require a Q register will
automatically constrain the register class to QPR.
The allocation order for DPair begins with the QPR registers, so
register allocation is unlikely to change much.
llvm-svn: 199186
requires Clang 3.1 or GCC 4.7. If the compiler isn't Clang or GCC, we
don't try to do any sanity checking, but this give us at least
a reasonable baseline of modern compilers.
Also, I'm not claiming that this is the best way to do compiler version
tests. I'm happy for anyone to suggest better ways of doing this test.
llvm-svn: 199182
We need to ensure that StackSlotColoring.cpp does not reuse stack
spill slots in functions that call "returns_twice" functions such as
setjmp(), otherwise this can lead to miscompiled code, because a stack
slot would be clobbered when it's still live.
This was already handled correctly for functions that call setjmp()
(though this wasn't covered by a test), but not for functions that
invoke setjmp().
We fix this by changing callsFunctionThatReturnsTwice() to check for
invoke instructions.
This fixes PR18244.
llvm-svn: 199180
Also, so is stacker, llvm-tv, etc. Wow.
But will someone please fess up to what projects/privbracket is and why
our autoconf build supports it?
llvm-svn: 199179
This will allow it to be called from target independent parts of the main
streamer that don't know if there is a registered target streamer or not. This
in turn will allow targets to perform extra actions at specified points in the
interface: add extra flags for some labels, extra work during finalization, etc.
llvm-svn: 199174
This patch makes a small behavioral change to the interaction between
pack and alignment. Specifically it makes __declspec(align()) on a
field change that field's alignment without respect to pack but the
alignment change to the record alignment as a whole still obeys pack.
llvm-svn: 199172
consumable objects. These are useful for implementing error codes that
must be checked. Patch also includes some significant refactoring, which was
necesary to implement the new behavior.
llvm-svn: 199169
Although VBPtrs were being placed correctly by the ms-abi layout engine,
their offsets were being improperly reported to the ASTRecordLayout
builder due to a bug. This patch fixes that and fixes the test cases to
use the correct values.
y
llvm-svn: 199168
Fixes PR18435, where we generated a base ctor instead of a complete
ctor, and so failed to construct virtual bases when constructing the
complete object.
llvm-svn: 199160
This patch moves the check for pragma pack until after the application
of __declspec align to before pragma pack. This causes observable
changes in the use of tail padding for bases. A test case is included.
llvm-svn: 199154
so bump the minimum version in the standalone Clang CMake project as
well.
As I mentioned on the LLVM commit version of this, if this causes any
trouble for folks, just let me know. I'm trying to avoid re-implementing
functionality in CMake, but I will if there are problems using the newer
versions.
llvm-svn: 199152
option with the others in the top level CMakeLists, and put the check in
HandleLLVMOptions. This will also let it be used from the standalone
Clang builds.
llvm-svn: 199149
compiler version checking doesn't work on 2.8.7. This feature was
documented in 2.8.10, but existed for an unknown amount of time before
that.
I'm actually happy to revert this and remove the use of the feature if
there is anyone with a specific problem updating CMake. Please just let
me know. I don't want to re-implement this CMake functionality unless
there is a reason, and this is the only real way to find that out.
llvm-svn: 199148
likely to be reverted and re-applied a few times. The minimum versions
we're aiming at:
GCC 4.7
Clang 3.1
MSVC 17.0 (Visual Studio 2012)
Let me know if something breaks!
llvm-svn: 199145
Kostya Serebryany