| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
That change did:
-#if defined(__BIG_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
If __BYTE_ORDER__ and __ORDER_BIG_ENDIAN__ aren't defined, like
they are with MSVC, this condition is true (0 == 0).
Fixes PR26919.
llvm-svn: 263324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
__BIG_ENDIAN__ and __LITTLE_ENDIAN__ are not supported by gcc, which
eg. for ubsan Value::getFloatValue will silently fall through to
the little endian branch, breaking display of float values by ubsan.
Use __BYTE_ORDER__ == __ORDER_BIG/LITTLE_ENDIAN__ as the condition
instead, which is supported by both clang and gcc.
Noticed while porting ubsan to s390x.
Patch by Marcin Kościelnicki!
Differential Revision: http://reviews.llvm.org/D17660
llvm-svn: 263077
|
| |
|
|
|
|
|
| |
Account for the case when uptr is 32-bit instead of trying to fix this case
using the little endian path.
llvm-svn: 244646
|
| |
|
|
|
|
|
|
|
|
| |
This fixes the bug https://llvm.org/bugs/show_bug.cgi?id=24152
The float value resides in the first 4 bytes of ValueHandle for both mips and mipsel.
Reviewers: dsanders, samsonov
Subscibers: rsmith, hans, mohit.bhakkad, jaydeep, llvm-commits
Differential: http://reviews.llvm.org/D11448
llvm-svn: 243384
|
| |
|
|
|
|
|
|
| |
One test case is updated to allow for differences between power and other architectures in behavior when returning from main in certain instances
http://reviews.llvm.org/D8743
llvm-svn: 233813
|
| |
|
|
| |
llvm-svn: 233295
|
| |
|
|
| |
llvm-svn: 209516
|
| |
|
|
|
|
| |
value argument.
llvm-svn: 177689
|
| |
|
|
|
|
|
| |
a problem with __int128 arithmetic but the runtime was not built with __int128
support.
llvm-svn: 165913
|
| |
|
|
|
|
|
|
|
| |
emulating 128-bit arithmetic on 32-bit x86 targets. This should get the
bootstrap back for GCC 4.6 at least.
Suggestions on better ways to do the detection here are welcome...
llvm-svn: 165863
|
| |
|
|
|
|
|
|
|
| |
to or
from a floating-point type where the source value is not in the range of
representable values of the destination type.
llvm-svn: 165844
|
|
|
llvm-svn: 165533
|