| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
address if its offet is greater than zero doesn't actually correctly tell us wether the address is section offset or not. A symbol could be the first symbol in a section and its offset can be zero. Also, a non-section offset lldb_private::Address can have a NULL section and calling GetOffset() will return the absolute address. To really test if an address is section offset clients should use Address::IsSectionOffset(). Also simplified the code that backs the address up by one to use the Address::Slide() function.
llvm-svn: 190955
|
| |
|
|
| |
llvm-svn: 190954
|
| |
|
|
|
|
|
|
|
|
|
| |
We now have symbols with floating-point type to make sure that
(double)x == (double)x comes out true, but we still can't do much with
these. For now, don't even bother trying to create a floating-point zero
value; just give up on conversion to bool.
PR14634, C++ edition.
llvm-svn: 190953
|
| |
|
|
| |
llvm-svn: 190952
|
| |
|
|
|
|
|
|
|
|
|
| |
Base relocation block should be aligned on a 32-bit boundary. While the PECOFF
spec mentions only aligning the blocks, and not padding them, link.exe seems
to add an extra IMAGE_REL_I386_ABSOLUTE entry (just a zeroed WORD) in order to
pad the blocks.
Patch by Ron Ofir.
llvm-svn: 190951
|
| |
|
|
| |
llvm-svn: 190950
|
| |
|
|
| |
llvm-svn: 190949
|
| |
|
|
| |
llvm-svn: 190948
|
| |
|
|
|
|
|
| |
of methods annotated with attributes.
// rdar://14987909
llvm-svn: 190947
|
| |
|
|
|
|
|
|
|
|
| |
work as
advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will
"reset" if you shutdown llvm and try to come back for seconds. This is a subtle
behavior change, but I'm assuming that nobody is affected by it.
llvm-svn: 190946
|
| |
|
|
|
|
|
|
|
|
|
| |
platforms and called in lldb.cpp while it is built only on some, excluding OSX.
There is no reason to not build it then by default on all platforms.
This fixes build on OSX using llvm configure & make scripts.
Patch (2 of 2) by Adam Strzelecki!
llvm-svn: 190945
|
| |
|
|
|
|
|
|
| |
- If it is not defined (empty) everything remain as it was before.
Patch (1 of 2) by Adam Strzelecki!
llvm-svn: 190944
|
| |
|
|
|
|
|
| |
'deprecated' container before doing the 'instancetype'
inference.
llvm-svn: 190943
|
| |
|
|
| |
llvm-svn: 190942
|
| |
|
|
|
|
| |
-Wunused-private-field with Clang.
llvm-svn: 190941
|
| |
|
|
| |
llvm-svn: 190940
|
| |
|
|
|
|
| |
enabled with the run-time option
llvm-svn: 190939
|
| |
|
|
|
|
| |
should be excluded when XCore is not built.
llvm-svn: 190938
|
| |
|
|
| |
llvm-svn: 190937
|
| |
|
|
|
|
|
|
|
|
| |
registers.
XCore target: Add XCoreTargetTransformInfo
This is where getNumberOfRegisters() resides, which in turn returns the
number of vector registers (=0).
llvm-svn: 190936
|
| |
|
|
|
|
| |
clang-format's -lines parameter makes this significantly easier.
llvm-svn: 190935
|
| |
|
|
| |
llvm-svn: 190934
|
| |
|
|
| |
llvm-svn: 190933
|
| |
|
|
|
|
| |
output for fake stack
llvm-svn: 190932
|
| |
|
|
|
|
| |
Patch by Bradley Smith!
llvm-svn: 190931
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason I never got around to adding these at the same time as
the signed versions. No idea why.
I'm not sure whether this SystemZII::BranchC* stuff is useful, or whether
it should just be replaced with an "is normal" flag. I'll leave that
for later though.
There are some boundary conditions that can be tweaked, such as preferring
unsigned comparisons for equality with [128, 256), and "<= 255" over "< 256",
but again I'll leave those for a separate patch.
llvm-svn: 190930
|
| |
|
|
| |
llvm-svn: 190929
|
| |
|
|
|
|
| |
Patch by Bradley Smith!
llvm-svn: 190928
|
| |
|
|
| |
llvm-svn: 190927
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for PR16752. Second commit.
PR16752: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth methods. Methods asks target for proper type for given bit width.
2. Fix handleModeAttr according to new methods in TargetInfo.
Fixes:
1st Commit (Done): Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth
2nd Commit (Current): Fix SemaDeclAttr, handleModeAttr function.
Also test/Sema/attr-mode.c was fixed. 'XC' mode test was disabled for PPC64 machines.
llvm-svn: 190926
|
| |
|
|
|
|
|
| |
vtst and vtstq currently support poly8 types, but they should also work on
poly16.
llvm-svn: 190925
|
| |
|
|
|
|
| |
unsupported code in MSVC.
llvm-svn: 190924
|
| |
|
|
|
|
| |
I'll roll it back in when I have a chance to look at it in detail.
llvm-svn: 190923
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For all libm __builtin_* functions that are defined, this adds the
corresponding LIBBUILTIN definitions (tagged, as necessary, with "e" instead of
"c" when the function may set errno).
Note that this changes the current definitions for lrint and fma
(unfortunately). The Linux man page documents that these don't set errno, but
the POSIX standard says that they should.
llvm-svn: 190922
|
| |
|
|
|
|
|
|
|
|
| |
work as
advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will
"reset" if you shutdown llvm and try to come back for seconds. This is a subtle
behavior change, but I'm assuming that nobody is affected by it.
llvm-svn: 190921
|
| |
|
|
|
|
| |
they've already been enabled. The extra call ends up clearing the bit in FeatureBits since its a 'toggle'. Can't prove that anything was broken because of this since I don't think the FeatureBits for these are used.
llvm-svn: 190920
|
| |
|
|
|
|
| |
InitMCProcessorInfo right after detecting them. Instead add a new function that only updates the scheduling model and call that.
llvm-svn: 190919
|
| |
|
|
|
|
| |
still work correctly.
llvm-svn: 190917
|
| |
|
|
|
|
| |
VINSERTF128/VEXTRACTF128. Fixes PR17268.
llvm-svn: 190916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.
C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.
llvm-svn: 190915
|
| |
|
|
| |
llvm-svn: 190914
|
| |
|
|
|
|
| |
argument list, but could be instantiated with argument list of <>.
llvm-svn: 190913
|
| |
|
|
|
|
| |
PR17142.
llvm-svn: 190912
|
| |
|
|
| |
llvm-svn: 190911
|
| |
|
|
|
|
| |
referenced, try to instantiate its definition in order to complete the type.
llvm-svn: 190910
|
| |
|
|
|
|
|
|
|
|
| |
as suggested by Jordan on IRC. Also, use the unqualified name
in Job.cpp.
And while we're here, refer to StringRef with the unqualified
name, because we have a using directive for that too.
llvm-svn: 190909
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This will define _MSC_VER to 1700 by default and avoid linker errors
from /failifmismatch linker directives in the C++ standard headers.
Most people trying out the Visual Studio integration are using 2012,
since that's the only version that clang-format works with. This way
they don't have to pass funky -Xclang -fmsc-version=1700 flags just to
link against the standard C++ runtime.
llvm-svn: 190908
|
| |
|
|
|
|
| |
The first one broke the build, and the latter one made it worse.
llvm-svn: 190907
|
| |
|
|
|
|
|
|
|
|
| |
Seems like it was intentional to export ArgStringList as
driver::ArgStringList, and e.g. examples/clang-interpreter/main.cpp
uses it this way.
However, exporting it with a typedef seems like a more common way to do it.
llvm-svn: 190906
|
| |
|
|
| |
llvm-svn: 190905
|