| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 299203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
closing and instead directly prevent closing of STD* file descriptors.
We do not want to close STDOUT as there may have been several uses of it
such as the case: llc %s -o=- -pass-remarks-output=- -filetype=asm
which cause multiple closes of STDOUT_FILENO and/or use-after-close of it.
Using dup() in getFD doesn't work as we end up with original STDOUT_FILENO
open anyhow.
reviewed by Rafael Espindola
Differential Revision: https://reviews.llvm.org/D31505
llvm-svn: 299098
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 299066
|
|
|
|
|
|
|
| |
Based on post-commit review comments by Chandler Carruth on
https://reviews.llvm.org/D31236. Thanks!
llvm-svn: 299062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 299060
|
|
|
|
|
|
| |
previous line. NFC
llvm-svn: 298900
|
|
|
|
| |
llvm-svn: 298899
|
|
|
|
|
|
| |
the tc functions. NFCI
llvm-svn: 298898
|
|
|
|
|
|
| |
APInt tc functions. This is more consistent with the rest of the codebase. NFC
llvm-svn: 298897
|
|
|
|
| |
llvm-svn: 298894
|
|
|
|
|
|
|
|
| |
used with small constants that the compiler can optimize.
While there recognize that we only need to clearUnusedBits on the single word case.
llvm-svn: 298881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several static functions from the signal API can be invoked
simultaneously; RemoveFileOnSignal for instance can be called indirectly
by multiple parallel loadModule() invocations, which might lead to
the assertion:
Assertion failed: (NumRegisteredSignals < array_lengthof(RegisteredSignalInfo) && "Out of space for signal handlers!"),
function RegisterHandler, file /llvm/lib/Support/Unix/Signals.inc, line 105.
RemoveFileOnSignal calls RegisterHandlers(), which isn't currently
mutex protected, leading to the behavior above. This potentially affect
a few other users of RegisterHandlers() too.
rdar://problem/30381224
llvm-svn: 298871
|
|
|
|
|
|
|
|
| |
words.
This method is pretty new and probably isn't use much in the code base so this should have a negligible size impact. The OR and XOR operators are already inline.
llvm-svn: 298870
|
|
|
|
|
|
| |
This is more consistent with what we do for other operations. This shrinks the opt binary on my build by ~72k.
llvm-svn: 298858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It should return <0, 0, or >0 for less-than, equal, and greater-than like
strcmp() (according to the history, it used to be implemented with
strcmp()) but it actually returned 0, or 1 for not-equal and equal.
Reviewers: qcolombet
Reviewed By: qcolombet
Subscribers: qcolombet, llvm-commits
Differential Revision: https://reviews.llvm.org/D30996
llvm-svn: 298844
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31110
llvm-svn: 298326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 298322
|
|
|
|
|
|
|
|
|
|
| |
This is a safeguard against data loss if the user specifies a directory
that is not a cache directory. Teach the existing cache pruning clients
to create files with appropriate names.
Differential Revision: https://reviews.llvm.org/D31109
llvm-svn: 298271
|
|
|
|
|
|
| |
As discussed on D31074, use MutableArrayRef for destination integer buffers to help assert before stack overflows happen.
llvm-svn: 298253
|
|
|
|
| |
llvm-svn: 298247
|
|
|
|
|
|
|
|
|
|
| |
initSlowCase and other init methods.
I'm not sure if zeroing VAL before writing pVal is really necessary, but at least one other place did it in code.
But by taking the store out of line, this reduces the opt binary by about 20k on my local x86-64 build.
llvm-svn: 298233
|
|
|
|
|
|
|
|
|
|
| |
Go back to behavior pre-r231309 and reduce the timeout from 8 to ~1.5
min now that we have (a) PCMCache mechanism (r298165) and (b) timeout
that doesn't cause a failure, but actually build the module (r298175).
rdar://problem/30297862
llvm-svn: 298176
|
|
|
|
| |
llvm-svn: 298007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 298004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implement sys::fs::set/getPermissions to work with them
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
llvm-svn: 297945
|
|
|
|
| |
llvm-svn: 297928
|
|
|
|
|
|
|
|
|
| |
The idea is that the policy string fully specifies the policy and is portable
between clients.
Differential Revision: https://reviews.llvm.org/D31020
llvm-svn: 297927
|
|
|
|
|
|
|
|
|
| |
Change the function that implements the pruning into a free function that
takes the policy as a struct argument.
Differential Revision: https://reviews.llvm.org/D31009
llvm-svn: 297907
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we did not have support for writing detailed
module information for each module, as well as the symbol
records. This patch adds support for this, and in doing
so enables the ability to construct minimal PDBs from
just a few lines of YAML. A test is added to illustrate
this functionality.
llvm-svn: 297900
|
|
|
|
|
|
|
|
|
| |
Previously, if you attempted to write a key/value pair and the
value was equal to the key's default value, we would not output
the value. Sometimes it is useful to be able to see this value
in the output anyway.
llvm-svn: 297864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ParseCommandLineOptions when ignoring errors.
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
llvm-svn: 297810
|
|
|
|
|
|
|
|
|
|
| |
Previously, it created a temporary directory and then failed when
FileOutputBuffer tried to rename that file to the destination file
(which is actually a directory name).
Differential Revision: https://reviews.llvm.org/D30912
llvm-svn: 297679
|
|
|
|
|
|
| |
The issues was just a missing REQUIRES in the test.
llvm-svn: 297661
|
|
|
|
|
|
|
| |
This reverts commit r297624.
It was failing on the bots.
llvm-svn: 297657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 297624
|
|
|
|
|
|
| |
http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/49970
llvm-svn: 297618
|
|
|
|
|
|
|
|
| |
sys::fs::permissions to set them.
Patch by James Henderson.
llvm-svn: 297617
|
|
|
|
|
|
|
|
|
|
|
| |
In openFileForRead, we would not previously return an error
if real_path resolution failed. After a recent patch, we
started propagating this error up. This caused a failure
in clang when trying to call openFileForRead("nul"). This
patch restores the previous behavior of not propagating this
error up.
llvm-svn: 297488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 297483
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently have to insert bits via a temporary variable of the same size as the target with various shift/mask stages, resulting in further temporary variables, all of which require the allocation of memory for large APInts (MaskSizeInBits > 64).
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::insertBits() helper method which avoids the temporary memory allocation and masks/inserts the raw bits directly into the target.
Differential Revision: https://reviews.llvm.org/D30780
llvm-svn: 297458
|
|
|
|
| |
llvm-svn: 297379
|
|
|
|
| |
llvm-svn: 297378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 297314
|
|
|
|
|
|
|
|
|
|
| |
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
object that knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
The problem with the previous commit appears to have been that TableGen was including CodeGen/LowLevelType.h instead of Support/LowLevelTypeImpl.h.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297241
|
|
|
|
|
|
|
|
| |
Move the __try/__except block outside of the set_thread_name function to avoid a conflict with object unwinding due to the use of the llvm::Storage.
Differential Revision: https://reviews.llvm.org/D30707
llvm-svn: 297192
|
|
|
|
|
|
|
|
|
|
| |
More module problems. This time it only showed up in the stage 2 compile of
clang-x86_64-linux-selfhost-modules-2 but not the stage 1 compile.
Somehow, this change causes the build to need Attributes.gen before it's been
generated.
llvm-svn: 297188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297177
|
|
|
|
| |
llvm-svn: 297167
|