| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is something of an edge case, but when the $HOME environment
variable is not set, we can still look in the password database
to get the current user's home directory.
Added a test for this by getting the value of $HOME, then unsetting
it, then calling home_directory() and verifying that it succeeds
and that the value is the same as what we originally read from
the environment.
llvm-svn: 298513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
by negating (int)-2147483648. By pure luck, none of the pre-existing tests triggered this; so I'm adding one.
Summary: Thanks to Vitaly Buka for helping catch this.
Reviewers: rengolin, jmolloy, efriedma, vitalybuka
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D31242
llvm-svn: 298512
|
| |
|
|
| |
llvm-svn: 298511
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce another level of alias metadata to distinguish the individual
non-aliasing accesses that have inter iteration alias-free base pointers
marked with "Inter iteration alias-free" mark nodes. It can be used to,
for example, distinguish different stores (loads) produced by unrolling of
the innermost loops and, subsequently, sink (hoist) them by LICM.
Reviewed-by: Tobias Grosser <tobias@grosser.es>
Differential Revision: https://reviews.llvm.org/D30606
llvm-svn: 298510
|
| |
|
|
|
|
|
| |
This reverts commit r298465 as it breaks
TestLLVM.TestHomeDirectory.test_tilde_home_directory.
llvm-svn: 298509
|
| |
|
|
|
|
| |
This matches gas behavior and is part of pr31888.
llvm-svn: 298508
|
| |
|
|
|
|
|
|
|
|
|
| |
Map the new load to the base pointer of the invariant load hoisted load
to be able to find the alias information for it.
Reviewed-by: Tobias Grosser <tobias@grosser.es>
Differential Revision: https://reviews.llvm.org/D30605
llvm-svn: 298507
|
| |
|
|
|
|
| |
This matches gas and is part of pr31888.
llvm-svn: 298506
|
| |
|
|
|
|
|
| |
These sections are merged together by the linker, so they should have
the same time.
llvm-svn: 298505
|
| |
|
|
|
|
|
| |
This reverts commit r298410 (which produces incorrect warnings, see
comments on https://reviews.llvm.org/rL298410).
llvm-svn: 298504
|
| |
|
|
|
|
|
| |
This reverts commit r298433. (Required to revert r298410, see comments
there.)
llvm-svn: 298503
|
| |
|
|
|
|
|
|
|
|
| |
Fixed v_mad_i64_i32/u64_u32 encoding
Reviewers: artem.tamazov
Differential Revision: https://reviews.llvm.org/D30828
llvm-svn: 298502
|
| |
|
|
| |
llvm-svn: 298501
|
| |
|
|
| |
llvm-svn: 298500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case style
Summary:
Using CaseType::CT_AnyCase for selected identifier results in inheriting case style setting from more basic identifier type.
This patch changes CT_AnyCase behavior to ignore case style of specified identifier. If case style was not set, llvm::Optional will be used for keeping this information (llvm::Optional<>::hasVal), thus CT_AnyCase will no longer mean more general identifier style should be used.
This eliminates false-positives when naming convention is not clear for specific areas of code (legacy, third party) or for selected types.
Reviewers: berenm, alexfh
Reviewed By: alexfh
Subscribers: cfe-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D30931
llvm-svn: 298499
|
| |
|
|
|
|
|
| |
String concatenation used in r298336 allowed to get rid of extra spaces
but also resulted in lost delimiter spaces, so use previous method.
llvm-svn: 298498
|
| |
|
|
|
|
| |
As discussed on PR28513, add tests for constant multiplication by constants between 1 to 32
llvm-svn: 298497
|
| |
|
|
|
|
|
|
|
|
|
| |
- First time, during calculation of the cost in InlineCost.cpp
- Second time, during calculation of the cost in Inliner.cpp
This patches fixes this.
Differential Revision: https://reviews.llvm.org/D31137
llvm-svn: 298496
|
| |
|
|
| |
llvm-svn: 298495
|
| |
|
|
|
|
|
|
|
|
| |
explaining why we have to ignore errors here even though in other parts
of codegen we can be more strict with builtins.
Also add a test case based on the code in a TSan test that found this
issue.
llvm-svn: 298494
|
| |
|
|
|
|
|
|
| |
rdar://30659700
Differential Revision: https://reviews.llvm.org/D31134
llvm-svn: 298493
|
| |
|
|
|
|
| |
s/covert_morder/convert_morder/
llvm-svn: 298492
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations and calls instead of just definitions, and then teach it to
*not* attach such attributes even if the source code contains them.
This follows the design direction discussed on cfe-dev here:
http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html
The idea is that for C standard library builtins, even if the library
vendor chooses to annotate their routines with __attribute__((nonnull)),
we will ignore those attributes which pertain to pointer arguments that
have an associated size. This allows the widespread (and seemingly
reasonable) pattern of calling these routines with a null pointer and
a zero size. I have only done this for the library builtins currently
recognized by Clang, but we can now trivially add to this set. This will
be controllable with -fno-builtin if anyone should care to do so.
Note that this does *not* change the AST. As a consequence, warnings,
static analysis, and source code rewriting are not impacted.
This isn't even a regression on any platform as neither Clang nor LLVM
have ever put 'nonnull' onto these arguments for declarations. All this
patch does is enable it on other declarations while preventing us from
ever accidentally enabling it on these libc functions due to a library
vendor.
It will also allow any other libraries using this annotation to gain
optimizations based on the annotation even when only a declaration is
visible.
llvm-svn: 298491
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: rsmith, rizsotto.mailinglist
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31133
llvm-svn: 298490
|
| |
|
|
|
|
|
|
| |
This reverts commit rL298481
Fails clang-with-lto-ubuntu build.
llvm-svn: 298489
|
| |
|
|
|
|
| |
calculating known bits for calls to bitreverse intrinsic.
llvm-svn: 298488
|
| |
|
|
|
|
|
|
|
| |
and into TargetInfo::adjust so that it gets called in more places
throughout the compiler (AST serialization in particular).
Should fix PPC modules after removing of faltivec.
llvm-svn: 298487
|
| |
|
|
|
|
| |
getHighBits/getLowBits. NFCI
llvm-svn: 298486
|
| |
|
|
|
|
| |
function warning.
llvm-svn: 298485
|
| |
|
|
|
|
|
|
| |
Make sure that any operands, e.g. of an implicit def of a super reg is
transferred to the new instruction.
Review: Ulrich Weigand
llvm-svn: 298484
|
| |
|
|
|
|
|
|
|
|
| |
including the amended (no UB anymore) fix for adding/subtracting -2147483648."
Fails check-llvm with ubsan
This reverts commit r298417.
llvm-svn: 298482
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows SCEV predicate analysis to prove implication of some expression predicates
from context predicates related to arguments of those expressions.
It introduces three new rules:
For addition:
(A >X && B >= 0) || (B >= 0 && A > X) ===> (A + B) > X.
For division:
(A > X) && (0 < B <= X + 1) ===> (A / B > 0).
(A > X) && (-B <= X < 0) ===> (A / B >= 0).
Using these rules, SCEV is able to prove facts like "if X > 1 then X / 2 > 0".
They can also be combined with the same context, to prove more complex expressions like
"if X > 1 then X/2 + 1 > 1".
Diffirential Revision: https://reviews.llvm.org/D30887
Reviewed by: sanjoy
llvm-svn: 298481
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Depending on C++11 <system_error> introduces a link-time requirement to
C++11 symbols. Removing it allows us to depend on header-only C++11 and
up libraries.
Partially fixes http://llvm.org/PR32274 -- we know there's more invasive work
to be done, but we're doing it incrementally.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31233
llvm-svn: 298480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`assert.assertItemEqual` went away in Python 3. Seeing how lists
are ordered, comparing a list against each other should work just
as well.
Patch by @jbergstroem (Johan Bergström).
Reviewers: modocache, gparker42
Reviewed By: modocache
Differential Revision: https://reviews.llvm.org/D31229
llvm-svn: 298479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
side of subtracts
Summary: Subtracts can have constants on the left side, but we don't shrink them based on demanded bits. This patch fixes that to match the right hand side.
Reviewers: davide, majnemer, spatel, sanjoy, hfinkel
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31119
llvm-svn: 298478
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation.
We don't know whether some other instantiation of the template might be able to
reach the annotation, so warning on it has a high chance of false positives.
Patch by Ahmed Asadi!
Differential Revision: https://reviews.llvm.org/D31069
llvm-svn: 298477
|
| |
|
|
| |
llvm-svn: 298476
|
| |
|
|
| |
llvm-svn: 298475
|
| |
|
|
|
|
|
| |
They are structurally the same, but now we need to distinguish them
because one record lives in the IPI stream and the other lives in TPI.
llvm-svn: 298474
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the behavior of IRTranslating intrinsics where we
now create VREG + G_CONSTANT for ConstantInt values. We already do this
for FloatingPoint values. This makes it easier for the backends to
select code and it won't have to de-duplicate creation+selection of
constants.
Reviewed by: ab
llvm-svn: 298473
|
| |
|
|
|
|
|
|
|
| |
If a register location can only be described by a complex expression
(i.e., multiple subregisters) it doesn't safely compose with another
complex expression. For example, it is not possible to apply a
DW_OP_deref operation to multiple DW_OP_pieces.
llvm-svn: 298472
|
| |
|
|
|
|
|
|
|
|
| |
until the rest of the expression is known.
This is still an NFC refactoring in preparation of a subsequent bugfix.
This reapplies r298388 with a bugfix for non-physical frame registers.
llvm-svn: 298471
|
| |
|
|
|
|
| |
and some other post-commit review feedback.
llvm-svn: 298470
|
| |
|
|
|
|
|
| |
It does not need it and causes mismatch after -ffp-contract=fast is turned
into an FMF.
llvm-svn: 298469
|
| |
|
|
|
|
|
| |
(I don't have powerpc enabled in my build and I am changing
how -ffp-contract=fast works.)
llvm-svn: 298468
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is compatible with MSVC link.exe.
Reviewers: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31224
llvm-svn: 298467
|
| |
|
|
|
|
|
|
|
|
|
| |
There are only two users of NativeRegisterContextRegisterInfo,
and both are in process plugins. Moving this code from Host
to Plugins/Process/Utility thus makes sense, and as it is the
only dependency from Host -> PluginProcessUtility, it also
breaks this cycle, reducing LLDB's overall cycle count from
45 to 44.
llvm-svn: 298466
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31129
llvm-svn: 298465
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This restores behavior pre-r230064 since after PCMCache work (r298278)
we don't reload PCMs from disk within the same compiler invocation.
Testcases from r230064 are still left around since they still guarantee
the correct behavior we're expecting.
rdar://problem/19889777
llvm-svn: 298464
|
| |
|
|
|
|
|
|
| |
This is a shorthand for Config->Wordsize == 8. So this is not strictly
necessary but seems handy. "Is 64 bit?" is easier to read than "Is
wordsize 8 byte?"
llvm-svn: 298463
|