| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Long double is 64 bits on FreeBSD PPC, so the f128 entry is superfluous.
llvm-svn: 185583
|
|
|
|
|
|
| |
Long double is 64 bits on FreeBSD PPC, so the f128 entry is superfluous.
llvm-svn: 185582
|
|
|
|
| |
llvm-svn: 185581
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR16456 reported that Clang implements a hybrid between AltiVec's
"Keyword and Predefine Method" and its "Context Sensitive Keyword
Method," where "bool" is always a keyword, but "vector" and "pixel"
are context-sensitive keywords. This isn't permitted by the AltiVec
spec. For consistency with gcc, this patch implements the Context
Sensitive Keyword Method for bool, and stops treating true and false
as keywords in Altivec mode.
The patch removes KEYALTIVEC as a trigger for defining these keywords
in include/clang/Basic/TokenKinds.def, and adds logic for "vector
bool" that mirrors the existing logic for "vector pixel." The test
case is taken from the bug report.
llvm-svn: 185580
|
|
|
|
|
|
| |
is not reproducible anymore.
llvm-svn: 185579
|
|
|
|
| |
llvm-svn: 185578
|
|
|
|
| |
llvm-svn: 185577
|
|
|
|
|
|
| |
- should resolve remaining failures on clang buildbot
llvm-svn: 185576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
certain Thumb2 add immediate T3 encodings.
Before the fix Thumb2 instructions of type "add rD, rN, #imm" (T3 encoding, see ARM ARM A8.8.4) with rD and rN both being low registers (r0-r7) were classified as having the T4 encoding.
The T4 encoding doesn't have a cc_out operand so for above instructions the operand gets erroneously removed, corrupting the token stream and leading to parse errors later in the process.
This bug prevented "add r1, r7, #0xcbcbcbcb" from being assembled correctly.
Fixes <rdar://problem/14224440>.
llvm-svn: 185575
|
|
|
|
| |
llvm-svn: 185574
|
|
|
|
| |
llvm-svn: 185573
|
|
|
|
|
|
| |
It's not the case on ie. FreeBSD.
llvm-svn: 185572
|
|
|
|
|
|
| |
- this issue was detected on recent GCC buildbot runs
llvm-svn: 185571
|
|
|
|
| |
llvm-svn: 185570
|
|
|
|
|
|
| |
Howard, and annotated by me
llvm-svn: 185569
|
|
|
|
|
|
|
|
|
|
|
| |
Without fmath-errno, Clang currently generates calls to @llvm.pow.* intrinsics
when it sees pow*(). This may not be suitable for all targets (for
example le32/PNaCl), so the attached patch adds a target hook that CodeGen
queries. The target can state its preference for having or not having the
intrinsic generated. Non-PNaCl behavior remains unchanged;
PNaCl-specific test added.
llvm-svn: 185568
|
|
|
|
|
|
|
| |
- argparse_compat library does not support reading environment variables
- should unblock Linux GCC buildbot from running tests again
llvm-svn: 185567
|
|
|
|
|
|
| |
Patch by Alex Crichton <alex@crichton.co>. Approved by Chris Lattner.
llvm-svn: 185566
|
|
|
|
|
|
| |
<stdint.h> (which might not exist or might not work).
llvm-svn: 185565
|
|
|
|
|
|
|
| |
This adds support for the load/store multiple instructions,
currently used by the asm parser only.
llvm-svn: 185564
|
|
|
|
|
|
| |
Verify that assembling an empty file does not auto-include altivec.h.
llvm-svn: 185563
|
|
|
|
|
|
|
| |
Fixes crash when trying to recover from a crash on an assembler-with-cpp
file. (Not sure how to write a testcase.)
llvm-svn: 185562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just as with mfocrf, it is also preferable to use mtocrf instead of
mtcrf when only a single CR register is to be written.
Current code however always emits mtcrf. This probably does not matter
when using an external assembler, since the GNU assembler will in fact
automatically replace mtcrf with mtocrf when possible. It does create
inefficient code with the integrated assembler, however.
To fix this, this patch adds MTOCRF/MTOCRF8 instruction patterns and
uses those instead of MTCRF/MTCRF8 everything. Just as done in the
MFOCRF patch committed as 185556, these patterns will be converted
back to MTCRF if MTOCRF is not available on the machine.
As a side effect, this allows to modify the MTCRF pattern to accept
the full range of mask operands for the benefit of the asm parser.
llvm-svn: 185561
|
|
|
|
|
|
|
|
| |
- build fails due to PyCallable template definition inside an extern "C" scope
This commit reverts 185240, 184893 and 184608.
llvm-svn: 185560
|
|
|
|
| |
llvm-svn: 185559
|
|
|
|
|
|
|
|
| |
which on
x86/x86-64 clang optimizes to direct word accesses anyway. This fixes an unaligned word access in murmurhash/cityhash.
llvm-svn: 185558
|
|
|
|
| |
llvm-svn: 185557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When accessing just a single CR register, it is always preferable to
use mfocrf instead of mfcr, if the former is available on the CPU.
Current code makes that distinction in many, but not all places
where a single CR register value is retrieved. One missing
location is PPCRegisterInfo::lowerCRSpilling.
To fix this and make this simpler in the future, this patch changes
the bulk of the back-end to always assume mfocrf is available and
simply generate it when needed.
On machines that actually do not support mfocrf, the instruction
is replaced by mfcr at the very end, in EmitInstruction.
This has the additional benefit that we no longer need the
MFCRpseud hack, since before EmitInstruction we always have
a MFOCRF instruction pattern, which already models data flow
as required.
The patch also adds the MFOCRF8 version of the instruction,
which was missing so far.
Except for the PPCRegisterInfo::lowerCRSpilling case, no change
in generated code intended.
llvm-svn: 185556
|
|
|
|
|
|
|
|
|
|
| |
This is important for preprocessing steps, which may output to stdout.
Also, change ENV accesses using barewords to use string keys instead.
PR16414
llvm-svn: 185555
|
|
|
|
| |
llvm-svn: 185554
|
|
|
|
|
|
|
|
| |
function prologue code with line info if so.
Differential Revision: http://llvm-reviews.chandlerc.com/D1082
llvm-svn: 185553
|
|
|
|
|
|
|
| |
It was only passing because 'grep andpd' was not finding any andpd, but
we don't fail if part of a pipe fails.
llvm-svn: 185552
|
|
|
|
| |
llvm-svn: 185551
|
|
|
|
| |
llvm-svn: 185550
|
|
|
|
| |
llvm-svn: 185549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the CMake build still tried to link clang against the static
analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off.
Furthermore, clang-check depends on the analyzer, so it should be disabled
(in both CMake and configure builds).
In theory, clang-check could be made to conditionally include analyzer
support (like clang itself), but for now this at least gets a CMake ALL_BUILD
working.
Patch by Stephen Kelly, modified by me.
llvm-svn: 185548
|
|
|
|
|
|
| |
While there, use early returns to reduce nesting.
llvm-svn: 185547
|
|
|
|
|
|
|
| |
This is a small compatibility improvement with gnu nm and makes llvm-nm more
useful as a testing tool.
llvm-svn: 185546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the -maltivec flag is present, altivec.h is auto-included for the
compilation. This is not appropriate when the job action is to
preprocess a file containing assembly code. So don't do that.
I was unable to convert the test in the bug report into a regression
test. The original symptom was exposed with:
% touch x.S
% ./bin/clang -target powerpc64-unknown-linux-gnu -maltivec -S -o - x.S
I tried this test (and numerous variants) on a PPC64 system:
----------------------------------------------------------------------------
// RUN: touch %t
// RUN: %clang -maltivec -S %t -o - | FileCheck %s
// Verify that assembling an empty file does not auto-include altivec.h.
// CHECK-NOT: static vector
----------------------------------------------------------------------------
However, this test passes for some reason even on a clang built
without the fix. I'd be happy to add a test case but at this point
I'm not able to figure one out, and I don't want to hold up the patch
unnecessarily. Please let me know if you have ideas.
Thanks,
Bill
llvm-svn: 185544
|
|
|
|
| |
llvm-svn: 185543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The subroutine getCRIdxForSetCC has a parameter "Other" and comment:
If this returns with Other != -1, then the returned comparison
is an or of two simpler comparisons.
However for at least the last five years this routine has never
returned a value of Other != -1; these cases are now handled
differently to begin with.
This patch removes the parameter and the code in SelectSETCC that
attempted to handle the Other != -1 case.
llvm-svn: 185541
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185540
|
|
|
|
|
|
|
|
| |
the start of svn info results and to check for spaces after 'I' instead of just after '?'.
Previously it was able to match 'I' anywhere in the filenames of the svn info results instead of just files that where ignored or unknown to svn. This would cause 'make update' to infinitely recurse if a file was modified with I anywhere in its name since svn info would return a Path pointing to the llvm root for those files.
llvm-svn: 185539
|
|
|
|
|
|
|
| |
This changes behavior of -msan-poison-stack=0 flag from not poisoning stack
allocations to actively unpoisoning them.
llvm-svn: 185538
|
|
|
|
|
|
| |
Patch by Johannes Obermayr.
llvm-svn: 185537
|
|
|
|
| |
llvm-svn: 185536
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new transform to replace uses of 'std::auto_ptr' by 'std::unique_ptr'.
Copy-ctor and assign-operator are wrapped with a call to 'std::move()'.
Note that until header modification is ready it is not that useful, that's why
it's marked as (EXPERIMENTAL) in the command line description and a "Known
Limitations" section is present in the transform documentation.
Author: Guillaume Papin <guillaume.papin@epitech.eu>
llvm-svn: 185535
|
|
|
|
|
|
| |
unmapped page.
llvm-svn: 185534
|
|
|
|
|
|
|
|
|
|
|
| |
A couple of AltiVec patterns are just specialized forms of the
generic instruction pattern, and should therefore be marked
isCodeGenOnly to avoid confusing the asm parser:
VCFSX_0, VCTUXS_0, VCFUX_0, VCTSXS_0, and V_SETALLONES.
Noticed by inspection of the generated PPCGenAsmMatcher.inc.
llvm-svn: 185533
|
|
|
|
|
|
|
|
|
| |
This adds support for the generic forms of mtspr/mfspr
for the asm parser. The compiler will continue to use
the specialized patters for mtlr etc. since those are
needed to correctly describe data flow.
llvm-svn: 185532
|