Summary:
The MSVCRT deliberately sends main() code-page specific characters.
This isn't too useful to LLVM as we end up converting the arguments to
UTF-16 and subsequently attempt to use the result as, for example, a
file name. Instead, we need to have the ability to access the Unicode
command line and transform it to UTF-8.
This has the distinct advantage over using the MSVC-specific wmain()
function as our entry point because:
- It doesn't work on cygwin.
- It only work on MinGW with caveats and only then on certain versions.
- We get to keep our entry point as main(). :)
N.B. This patch includes fixes to other parts of lib/Support/Windows
s.t. we would be able to take advantage of getting the Unicode paths.
E.G. clang spawning clang -cc1 would want to give it Unicode arguments.
Reviewers: aaron.ballman, Bigcheese, rnk, ruiu
Reviewed By: rnk
CC: llvm-commits, ygao
Differential Revision: http://llvm-reviews.chandlerc.com/D1834
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192069 91177308-0d34-0410-b5e6-96231b3b80d8
project's autoconf. This is the last of the missing optional checks used
by libSupport that seemed to be missing from the sample project, but
I could easily have missed some as this was done by inspection when
Craig asked me to add the terminfo support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188618 91177308-0d34-0410-b5e6-96231b3b80d8
Recent versions of the OS X linker support this but follow the existing
OS X linker convention of using an underscore in the option name, i.e.,
-export_dynamic. Rather than changing our configure scripts to check for
that alternate spelling, it is simpler to just use the compiler's -rdynamic
option and let it deal with translating that to the appropriate linker
option. One potential disadvantage of this approach is that the compiler
will typically ignore -rdynamic on platforms where it is not supported, so
the HAVE_LINK_EXPORT_DYNAMIC in config.h will not necessarily show whether
that option has any effect or not. I don't see any in-tree uses of that
macro, so I'm assuming it is OK.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187686 91177308-0d34-0410-b5e6-96231b3b80d8
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187179 91177308-0d34-0410-b5e6-96231b3b80d8
This patch finally enables the SystemZ target in the default build
(with --enable-targets=all).
Patch by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181209 91177308-0d34-0410-b5e6-96231b3b80d8
This patch wires up the SystemZ target in configure, so that it can now be
built using --enable-targets=systemz. It is not yet included in the default
build (--enable-targets=all); this will be done by a follow-up patch.
Patch by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181208 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for AArch64 (ARM's 64-bit architecture) to
LLVM in the "experimental" category. Currently, it won't be built
unless requested explicitly.
This initial commit should have support for:
+ Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions
(except the late addition CRC instructions).
+ CodeGen features required for C++03 and C99.
+ Compilation for the "small" memory model: code+static data <
4GB.
+ Absolute and position-independent code.
+ GNU-style (i.e. "__thread") TLS.
+ Debugging information.
The principal omission, currently, is performance tuning.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174054 91177308-0d34-0410-b5e6-96231b3b80d8
The new target machines are:
nvptx (old ptx32) => 32-bit PTX
nvptx64 (old ptx64) => 64-bit PTX
The sources are based on the internal NVIDIA NVPTX back-end, and
contain more functionality than the current PTX back-end currently
provides.
NV_CONTRIB
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156196 91177308-0d34-0410-b5e6-96231b3b80d8
Clang builds. The detection logic for compilers that support the warning
isn't working. Rafael is going to investigate it, but didn't want people
to have to wade through build spam until then.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151649 91177308-0d34-0410-b5e6-96231b3b80d8
that just uses the new toolchain probing logic. This fixes linking with -m32 on
64 bit systems (the /32 dir was not being added to the search).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149651 91177308-0d34-0410-b5e6-96231b3b80d8
Get back getHostTriple.
For JIT compilation, use the host triple instead of the default
target: this fixes some JIT testcases that used to fail when the
compiler has been configured as a cross compiler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147542 91177308-0d34-0410-b5e6-96231b3b80d8
- This currently just moves over all of the behavior from LLVM. Eventually all of the configure checks that are directly needed by the LLVM build setup should probably go away, and the project should manage their own configuration checks if necessary.
- This is the 1st half of this work, the actual Makefile.common hasn't moved over yet. I've tried to stage this in such a way that incremental builds will properly reconfigure for most active developers (the Makefiles don't handle reconfiguring in a perfectly reliable way, and I haven't found an easy way to make them do so).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142456 91177308-0d34-0410-b5e6-96231b3b80d8
