Currently the emscripten frontend driver injects this when building
with thread support. Moving this into the clang driver itself makes
the emscripten python driver less magical.
Differential Revision: https://reviews.llvm.org/D96171
Add powerpcle support to clang.
For FreeBSD, assume a freestanding environment for now, as we only need it in the first place to build loader, which runs in the OpenFirmware environment instead of the FreeBSD environment.
For Linux, recognize glibc and musl environments to match current usage in Void Linux PPC.
Adjust driver to match current binutils behavior regarding machine naming.
Adjust and expand tests.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D93919
Android has a handful of API levels relevant to developers described
here: https://developer.android.com/studio/build#module-level.
`__ANDROID_API__` is too vague and confuses a lot of people. Introduce
a new macro name that is explicit about which one it represents. Keep
the old name around because code has been using it for a decade.
Added support for the options mabi=vec-extabi and mabi=vec-default which are analogous to qvecnvol and qnovecnvol when using XL on AIX.
The extended Altivec ABI on AIX is enabled using mabi=vec-extabi in clang and vec-extabi in llc.
Reviewed By: Xiangling_L, DiggerLin
Differential Revision: https://reviews.llvm.org/D89684
Set the default alignment control variables for z/OS target and add test case for alignment rules on z/OS.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D88845
Set the default wchar_t type on z/OS, and unsigned as the default.
Reviewed By: hubert.reinterpretcast, fanbo-meng
Differential Revision: https://reviews.llvm.org/D87624
Aligned allocation is not supported on z/OS. This patch sets -faligned-alloc-unavailable as default in z/OS toolchain.
Reviewed By: abhina.sreeskantharajan, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D87611
This patch adds the z/OS target and defines macros as a stepping stone
towards enabling a native build on z/OS.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D85324
Implement AIX default `power` alignment rule by adding `PreferredAlignment` and
`PreferredNVAlignment` in ASTRecordLayout class.
The patchh aims at returning correct value for `__alignof(x)` and `alignof(x)`
under `power` alignment rules.
Differential Revision: https://reviews.llvm.org/D79719
This patch adds override to several overriding virtual functions that were missing the keyword within the clang/ directory. These were found by the new -Wsuggest-override.
This PR enables "XL" C++ ABI in frontend AST to IR codegen. And it is driven by
static init work. The current kind in Clang by default is Generic Itanium, which
has different behavior on static init with IBM xlclang compiler on AIX.
Differential Revision: https://reviews.llvm.org/D74015
Currently, it is a modified version of the Itanium ABI, with the only
change being that constructors and destructors return 'this'.
Differential Revision: https://reviews.llvm.org/D70575
make check-all currently fails on x86_64-pc-solaris2.11 when building with GCC 9:
Undefined first referenced
symbol in file
_ZN11__sanitizer14internal_lseekEimi SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
_ZN11__sanitizer23MapWritableFileToMemoryEPvmim SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
ld: fatal: symbol referencing errors
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [projects/compiler-rt/lib/sanitizer_common/tests/CMakeFiles/TSanitizer-i386-Test.dir/build.make:92: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-i386-Test] Error 1
While e.g. __sanitizer::internal_lseek is defined in sanitizer_solaris.cc, g++ 9
predefines _FILE_OFFSET_BITS=64 while clang++ currently does not.
This patch resolves this inconsistency by following the gcc lead, which allows
make check-all to finish successfully.
There's one caveat: gcc defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for C++ only, while clang has long been doing it for
all languages. I'd like to keep it this way because those macros do is to make
declarations of fseek/ftello (_LARGEFILE_SOURCE) resp. the 64-bit versions
of largefile functions (*64 with _LARGEFILE64_SOURCE) visible additionally.
However, _FILE_OFFSET_BITS=64 changes all affected functions to be largefile-aware.
I'd like to restrict this to C++, just like gcc does.
To avoid a similar inconsistence with host compilers that don't predefine _FILE_OFFSET_BITS=64
(e.g. clang < 9, gcc < 9), this needs a compantion patch https://reviews.llvm.org/D64483.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64482
llvm-svn: 367305
These macro definitions don't depend on the template parameter, so they
don't need to be part of the template. Move them to a .cpp file.
llvm-svn: 365556
error: 'error' diagnostics expected but not seen:
File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: initializing wide char array with non-wide string literal
error: 'error' diagnostics seen but not expected:
File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 20: array initializer must be an initializer list
File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: array initializer must be an initializer list
It turns out the definition is wrong, as can be seen in GCC's gcc/config/sol2.h:
/* wchar_t is called differently in <wchar.h> for 32 and 64-bit
compilations. This is called for by SCD 2.4.1, p. 6-83, Figure 6-65
(32-bit) and p. 6P-10, Figure 6.38 (64-bit). */
#undef WCHAR_TYPE
#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int")
The following patch implements this, and at the same time corrects the wint_t
definition which is the same:
/* Same for wint_t. See SCD 2.4.1, p. 6-83, Figure 6-66 (32-bit). There's
no corresponding 64-bit definition, but this is what Solaris 8
<iso/wchar_iso.h> uses. */
#undef WINT_TYPE
#define WINT_TYPE (TARGET_64BIT ? "int" : "long int")
Clang :: Preprocessor/wchar_t.c and Clang :: Sema/format-strings.c need to
be adjusted to account for that.
Tested on i386-pc-solaris2.11, x86_64-pc-solaris2.11, and x86_64-pc-linux-gnu.
Differential Revision: https://reviews.llvm.org/D62944
llvm-svn: 363612
Summary:
- This patch checks the AIX version and defines the appropriate macros.
- Follow up to a comment on D59048.
Author: andusy
Reviewers: hubert.reinterpretcast, jasonliu, sfertile, xingxue
Reviewed By: sfertile
Subscribers: jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61530
llvm-svn: 360900
Darwin if the version of libc++abi isn't new enough to include the fix
in r319123
This patch resurrects r264998, which was committed to work around a bug
in libc++abi that was causing _cxa_allocate_exception to return a memory
that wasn't double-word aligned.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160328/154332.html
In addition, this patch makes clang issue a warning if the type of the
thrown object requires an alignment that is larger than the minimum
guaranteed by the target C++ runtime.
rdar://problem/49864414
Differential Revision: https://reviews.llvm.org/D61667
llvm-svn: 360404
The Emscripten OS provides a definition of __EMSCRIPTEN__, and also that it
supports iprintf optimizations.
Also define small_printf optimizations, which is a printf with float support
but not long double (which in wasm can be useful since long doubles are 128
bit and force linking of float128 emulation code). This part is based on
sunfish's https://reviews.llvm.org/D57620 (which can't land yet since
the WASI integration isn't ready yet).
Differential Revision: https://reviews.llvm.org/D60167
llvm-svn: 357552
llvm-svn 356197 relanded previously failing test case max_align.c.
This commit will reland the rest of llvm-svn 356060 commit.
Differential Revision: https://reviews.llvm.org/D59048
llvm-svn: 356208
Summary:
A first pass over platform-specific properties of the C API/ABI
on AIX for both 32-bit and 64-bit modes.
This is a continuation of D18360 by Andrew Paprocki and further work by Wu Zhao.
Patch by Andus Yu
Reviewers: apaprocki, chandlerc, hubert.reinterpretcast, jasonliu,
xingxue, sfertile
Reviewed by: hubert.reinterpretcast, apaprocki, sfertile
Differential Revision: https://reviews.llvm.org/D59048
llvm-svn: 356060
This adds a `__wasi__` macro for the wasi OS, similar to `__linux__` etc. for
other OS's.
Differential Revision: https://reviews.llvm.org/D57155
llvm-svn: 352105
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
The Darwin targets use `int64_t` and `uint64_t` to define the `int_least64_t`
and `int_fast64_t` types. The underlying type is actually a `long long`. Match
the types to allow the printf specifiers to work properly and have the compiler
vended macros match the implementation on the target.
llvm-svn: 348939
This patch addresses a compilation error with clang when
running in Haiku being unable to compile code using
float128 (throws compilation error such as 'float128 is
not supported on this target').
Patch by kallisti5 (Alexander von Gluck IV)
Differential Revision: https://reviews.llvm.org/D54901
llvm-svn: 348368
As of rev. 268898, clang supports __float128 on SystemZ. This seems to
have been in error. GCC has never supported __float128 on SystemZ,
since the "long double" type on the platform is already IEEE-128. (GCC
only supports __float128 on platforms where "long double" is some other
data type.)
For compatibility reasons this patch removes __float128 on SystemZ
again. The test case is updated accordingly.
llvm-svn: 348247
This adds Hurd toolchain support to Clang's driver in addition
to handling translating the triple from Hurd-compatible form to
the actual triple registered in LLVM.
(Phabricator was stripping the empty files from the patch so I
manually created them)
Patch by sthibaul (Samuel Thibault)
Differential Revision: https://reviews.llvm.org/D54379
llvm-svn: 347833
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
Windows uses `unsigned short` for `wint_t`. Correct the type definition as
vended by the compiler. This type is defined in corecrt.h and is
unconditionally typedef'ed. cl does not have an equivalent to `__WINT_TYPE__`
which is why this was never detected.
llvm-svn: 342557
Adding __attribute__((aligned(32))) to __m256 breaks the implementation
of _mm256_loadu_ps on Windows. On Windows, alignment attributes have
higher precedence than packing attributes.
We also might want to carefully consider the consequences of changing
our vector typedefs, since many users copy them and invent their own
new, non-Intel specific vector type names.
llvm-svn: 333958
This fixes two major problems:
- We were not capping vector alignment as desired on 32-bit ARM.
- We were using different alignments based on the AVX settings on
Intel, so we did not have a consistent ABI.
This is an ABI break, but we think we can get away with it because
vectors tend to be used mostly in inline code (which is why not having
a consistent ABI has not proven disastrous on Intel).
Intel's AVX types are specified as having 32-byte / 64-byte alignment,
so align them explicitly instead of relying on the base ABI rule.
Note that this sort of attribute is stripped from template arguments
in template substitution, so there's a possibility that code templated
over vectors will produce inadequately-aligned objects. The right
long-term solution for this is for alignment attributes to be
interpreted as true qualifiers and thus preserved in the canonical type.
llvm-svn: 333791
When looking at lib/Basic/Targets/OSTargets.h, I noticed that _REENTRANT is defined
unconditionally on Solaris, unlike all other targets and what either Studio cc (only define
it with -mt) or gcc (only define it with -pthread) do.
This patch follows that lead.
Differential Revision: https://reviews.llvm.org/D41241
llvm-svn: 332343
When rebasing https://reviews.llvm.org/D40898 with GCC 5.4 on Solaris 11.4, I ran
into a few instances of
In file included from /vol/llvm/src/compiler-rt/local/test/asan/TestCases/Posix/asan-symbolize-sanity-test.cc:19:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/string:40:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/char_traits.h:39:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:64:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/stl_pair.h:59:
In file included from /usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/bits/move.h:57:
/usr/gcc/5/lib/gcc/x86_64-pc-solaris2.11/5.4.0/../../../../include/c++/5.4.0/type_traits:311:39: error: __float128 is not supported on this target
struct __is_floating_point_helper<__float128>
^
during make check-all. The line above is inside
#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_FLOAT128)
template<>
struct __is_floating_point_helper<__float128>
: public true_type { };
#endif
While the libstdc++ header indicates support for __float128, clang does not, but
should. The following patch implements this and fixed those errors.
Differential Revision: https://reviews.llvm.org/D41240
llvm-svn: 330572
Jon Roelofs