This shares detection logic with ARM(32), since AArch64 capable CPUs may
also run in 32-bit system mode.
We observe weird /proc/cpuinfo output for MSM8992 and MSM8994, where
they report all CPU cores as one single model, depending on which CPU
core the kernel is running on. As a workaround, we hardcode the known
CPU part name for these SoCs.
For big.LITTLE systems, this patch would only return the part name of
the first core (usually the little core). Proper support will be added
in a follow-up change.
Differential Revision: D31675
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299458 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r299062, which caused build failures on Windows.
It also reverts the attempts to fix the windows builds in r299064 and r299065.
The introduction of namespace llvm::sys::detail makes MSVC, and seemingly also
mingw, complain about ambiguity with the existing namespace llvm::detail.
E.g.:
C:\b\slave\sanitizer-windows\llvm\include\llvm/Support/MathExtras.h(184): error C2872: 'detail': ambiguous symbol
C:\b\slave\sanitizer-windows\llvm\include\llvm/Support/PointerLikeTypeTraits.h(31): note: could be 'llvm::detail'
C:\b\slave\sanitizer-windows\llvm\include\llvm/Support/Host.h(80): note: or 'llvm::sys::detail'
In r299064 and r299065 I tried to fix these ambiguities, based on the errors
reported in the log files. It seems however that the build stops early when
this kind of error is encountered, and many build-then-fix-iterations on
Windows may be needed to fix this. Therefore reverting r299062 for now to
get the build working again on Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299066 91177308-0d34-0410-b5e6-96231b3b80d8
This refactors getHostCPUName so that for the architectures that get the
host cpu info on linux from /proc/cpuinfo, the /proc/cpuinfo parsing
logic is present in the build, even if it wasn't built on a linux system
for that architecture.
Since the code is present in the build, we can then test that code also
on other systems, i.e. we don't need to have buildbots setup for all
architectures on linux to be able to test this. Instead, developers will
test this as part of the regression test run.
As an example, a few unit tests are added to test getHostCPUName for ARM
running linux. A unit test is preferred over a lit-based test, since the
expectation is that in the future, the functionality here will grow over
what can be tested with "llc -mcpu=native".
This is a preparation step to enable implementing the range of
improvements discussed on PR30516, such as adding AArch64 support,
support for big.LITTLE systems, reducing code duplication.
Differential Revision: https://reviews.llvm.org/D31236
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299060 91177308-0d34-0410-b5e6-96231b3b80d8
It's possible (albeit strange) for $HOME to intentionally
point somewhere other than the user's home directory as
reported by the password database. Our test shouldn't fail
in this case. This patch updates the test to pull directly
from the password database before unsetting $HOME, rather
than comparing the return value of home_directory() to the
original value of the environment variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298514 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298513 91177308-0d34-0410-b5e6-96231b3b80d8
In doing so, clean up the MD5 interface a little. Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface. Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.
Differential Revision: https://reviews.llvm.org/D31105
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298322 91177308-0d34-0410-b5e6-96231b3b80d8
Previously which path syntax we supported dependend on what
platform we were compiling LLVM on. While this is normally
desirable, there are situations where we need to be able to
handle a path that we know was generated on a remote host.
Remote debugging, for example, or parsing debug info.
99% of the code in LLVM for handling paths was platform
agnostic and literally just a few branches were gated behind
pre-processor checks, so this changes those sites to use
runtime checks instead, and adds a flag to every path
API that allows one to override the host native syntax.
Differential Revision: https://reviews.llvm.org/D30858
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298004 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds support for functions to set and get file permissions, in a similar manner to the C++17 permissions() function in <filesystem>. The setter uses chmod on Unix systems and SetFileAttributes on Windows, setting the permissions as passed in. The getter simply uses the existing status() function.
Prior to this change, status() would always return an unknown value for the permissions on a Windows file, making it impossible to test the new function on Windows. I have therefore added support for this as well. On Linux, prior to this change, the permissions included the file type, which should actually be accessed via a different member of the file_status class.
Note that on Windows, only the *_write permission bits have any affect - if any are set, the file is writable, and if not, the file is read-only. This is in common with what MSDN describes for their behaviour of std::filesystem::permissions(), and also what boost::filesystem does.
The motivation behind this change is so that we can easily test behaviour on read-only files in LLVM unit tests, but I am sure that others may find it useful in some situations.
Reviewers: zturner, amccarth, aaron.ballman
Differential Revision: https://reviews.llvm.org/D30736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297945 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, ParseCommandLineOptions returns false and ignores error messages
when IgnoreErrors. It would be useful to also return error messages if users
decide to check parsing result instead of having the program exit on error.
Reviewers: chandlerc, mehdi_amini, rnk
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30893
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297810 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a unit test to the file system tests to verify the behavior of
the directory iterator and recursive directory iterator with broken symlinks.
This test is Unix only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297669 91177308-0d34-0410-b5e6-96231b3b80d8
If raw_fd_ostream is constructed with the path of "-", it claims
ownership of the stdout file descriptor. This means that it closes
stdout when it is destroyed. If there are multiple users of
raw_fd_ostream wrapped around stdout, then a crash can occur because
of operations on a closed stream.
An example of this would be running something like "clang -S -o - -MD
-MF - test.cpp". Alternatively, using outs() (which creates a local
version of raw_fd_stream to stdout) anywhere combined with such a
stream usage would cause the crash.
The fix duplicates the stdout file descriptor when used within
raw_fd_ostream, so that only that particular descriptor is closed when
the stream is destroyed.
Patch by James Henderson!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297624 91177308-0d34-0410-b5e6-96231b3b80d8
r297310 began inserting red zones around allocations under ASan, which
perturbs the alignment of subsequent allocations. Deliberately specify
this in two places where it matters.
Fixes failures when these tests are run under ASan and UBSan together.
Reviewed by Duncan Exon Smith.
rdar://problem/30980047
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297540 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM already has real_path like functionality, but it is
cumbersome to use and involves clean up after (e.g. you have
to call openFileForRead, then close the resulting FD).
Furthermore, on Windows it doesn't work for directories since
opening a directory and opening a file require slightly
different flags.
So I add a simple function `real_path` which works for all
paths on all platforms and has a simple to use interface.
In doing so, I add the ability to opt in to resolving tilde
expressions (e.g. ~/foo), which are normally handled by
the shell.
Differential Revision: https://reviews.llvm.org/D30668
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297483 91177308-0d34-0410-b5e6-96231b3b80d8
We already have a function create_directories() which can create
an entire tree, and remove() which can remove an empty directory,
but we do not have remove_directories() which can remove an entire
tree. This patch adds such a function.
Because removing a directory tree can have dangerous consequences
when the tree contains a directory symlink, the patch here updates
the existing directory_iterator construct to optionally not follow
symlinks (previously it would always follow symlinks). The delete
algorithm uses this flag so that for symlinks, only the links are
removed, and not the targets.
On Windows this is implemented with SHFileOperation, which also
does not recurse into symbolic links or junctions.
Differential Revision: https://reviews.llvm.org/D30676
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297314 91177308-0d34-0410-b5e6-96231b3b80d8
rL295768 introduced this test that fails if LLVM is built and tested on
an NFS share. Delete the test as discussed on the corresponing commit
thread. The only feasible solution would have been to introduce
environment variables and to en/disable the test conditionally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297260 91177308-0d34-0410-b5e6-96231b3b80d8
Windows does not treat `~` as a reference to home directory, so the call
to `llvm::sys::path::native` on, say, `~/somedir` produces `~\somedir`,
which has different meaning than the original path. With this change
tilde is expanded on Windows to user profile directory. Such behavior
keeps original meaning of the path and is consistent with the algorithm
of `llvm::sys::path::home_directory`.
Differential Revision: https://reviews.llvm.org/D27527
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296590 91177308-0d34-0410-b5e6-96231b3b80d8
fallible functions.
Some fallible functions (those returning Error or Expected<T>) may only fail
for a subset of their inputs. For example, a "safe" square root function will
succeed for all finite positive inputs:
Expected<double> safeSqrt(double d) {
if (d < 0 && !isnan(d) && !isinf(d))
return make_error<...>("Cannot sqrt -ve values, nans or infs");
return sqrt(d);
}
At a safe callsite for such a function, checking the error return value is
redundant:
if (auto ValOrErr = safeSqrt(42.0)) {
// use *ValOrErr.
} else
llvm_unreachable("safeSqrt should always succeed for +ve values");
The cantFail function wraps this check and extracts the contained value,
simplifying control flow:
double Result = cantFail(safeSqrt(42.0));
This function should be used with care: it is a programmatic error to wrap a
call with cantFail if it can in fact fail. For debug builds this will
result in llvm_unreachable being called. For release builds the behavior is
undefined.
Use of this function is likely to be rare in library code, but more common
for tool and unit-test code where inputs and mock functions may be known to be
safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296384 91177308-0d34-0410-b5e6-96231b3b80d8
is_local can't pass on some our buildbots as some of our buildbots use network
shares for building and testing LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295840 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is achieved by generalizing the expression selecting the StringRef
format_provider. Now, anything that can be converted to a StringRef will
use it's formatter.
Reviewers: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29898
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295064 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294690 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for padded SLEB128 values, and support for writing SLEB128
values to buffers rather than to ostreams, similar to the existing
ULEB128 support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294675 91177308-0d34-0410-b5e6-96231b3b80d8
Gcc supports target armv7ve which is armv7-a with virtualization
extensions. This change adds support for this in llvm for gcc
compatibility.
Also remove redundant FeatureHWDiv, FeatureHWDivARM for a few models as
this is specified automatically by FeatureVirtualization.
Patch by Manoj Gupta.
Differential Revision: https://reviews.llvm.org/D29472
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294661 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The formatter has three knobs:
- the user can choose which time unit to use for formatting (default: whatever is the unit of the input)
- he can choose whether the unit gets displayed (default: yes)
- he can affect the way the number itself is formatted via standard number formatting options (default:default)
Reviewers: zturner, inglorion
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29481
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294326 91177308-0d34-0410-b5e6-96231b3b80d8
If LLVM was configured with an x86_64-apple-macosx host triple, this
test would fail, as the API works but the triple isn't in the whitelist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293990 91177308-0d34-0410-b5e6-96231b3b80d8
Add both cores to the target parser and TableGen. Test that eabi
attributes are set correctly for both cores. Additionally, test the
absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively.
Committed on behalf of Sanne Wouda.
Reviewers : rengolin, olista01.
Differential Revision: https://reviews.llvm.org/D29073
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293761 91177308-0d34-0410-b5e6-96231b3b80d8
The test fails when there is a symlink on the path because then the path
returned by current_path will not match the one we have set. Instead of
doing a string match check the unique id of the two files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292916 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds a cross-platform way of setting the current working directory
analogous to the existing current_path() function used for retrieving
it. The function will be used in lldb.
Reviewers: rafael, silvas, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29035
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292907 91177308-0d34-0410-b5e6-96231b3b80d8
Enable an ELFObjectFile to read the its arm build attributes to
produce a target triple with a specific ARM architecture.
llvm-objdump now uses this functionality to automatically produce
a more accurate target.
Differential Revision: https://reviews.llvm.org/D28769
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292366 91177308-0d34-0410-b5e6-96231b3b80d8
No any changes, will follow up with D28807 commit containing APLi change for clang
to fix build issues happened.
Original commit message:
[Support/Compression] - Change zlib API to return Error instead of custom status.
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292226 91177308-0d34-0410-b5e6-96231b3b80d8
