summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic/TargetInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Prune include of DataLayout.h from include/clang/Basic/TargetInfo.h. NFCBjorn Pettersson2019-10-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: Use a forward declaration of DataLayout instead of including DataLayout.h in clangs TargetInfo.h. This reduces include dependencies toward DataLayout.h (and other headers such as DerivedTypes.h, Type.h that is included by DataLayout.h). Needed to move implemantation of TargetInfo::resetDataLayout from TargetInfo.h to TargetInfo.cpp. Reviewers: rnk Reviewed By: rnk Subscribers: jvesely, nhaehnle, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69262 llvm-svn: 375438
* Add SVE opaque built-in typesRichard Sandiford2019-08-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the SVE built-in types defined by the Procedure Call Standard for the Arm Architecture: https://developer.arm.com/docs/100986/0000 It handles the types in all relevant places that deal with built-in types. At the moment, some of these places bail out with an error, including: (1) trying to generate LLVM IR for the types (2) trying to generate debug info for the types (3) trying to mangle the types using the Microsoft C++ ABI (4) trying to @encode the types in Objective C (1) and (2) are fixed by follow-on patches but (unlike this patch) they deal mostly with target-specific LLVM details, so seemed like a logically separate change. There is currently no spec for (3) and (4), so reporting an error seems like the correct behaviour for now. The intention is that the types will become sizeless types: http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html The main purpose of the sizeless type extension is to diagnose impossible or dangerous uses of the types, such as any that would require sizeof to have a meaningful defined value. Until then, the patch sets the alignments of the types to the values specified in the link above. It also sets the sizes of the types to zero, which is chosen to be consistently wrong and shouldn't affect correctly-written code (i.e. code that would compile even with the sizeless type extension). The patch adds the common subset of functionality needed to test the sizeless type extension on the one hand and to provide SVE intrinsic functions on the other. After this patch, the two pieces of work are essentially independent. The patch is based on one by Graham Hunter: https://reviews.llvm.org/D59245 Differential Revision: https://reviews.llvm.org/D62960 llvm-svn: 368413
* [X86][PowerPC] Support -mlong-double-128Fangrui Song2019-07-121-4/+9
| | | | | | | | | | | | | | | This patch makes the driver option -mlong-double-128 available for X86 and PowerPC. The CC1 option -mlong-double-128 is available on all targets for users to test on unsupported targets. On PowerPC, -mlong-double-128 uses the IBM extended double format because we don't support -mabi=ieeelongdouble yet (D64283). Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D64277 llvm-svn: 365866
* [X86][PPC] Support -mlong-double-64Fangrui Song2019-07-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | -mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}). On many other targets, there will be an error: error: unrecognized command line option '-mlong-double-64' This patch makes the driver option -mlong-double-64 available for x86 and ppc. The CC1 option -mlong-double-64 is available on all targets for users to test on unsupported targets. LongDoubleSize is added as a VALUE_LANGOPT so that the option can be shared with -mlong-double-128 when we support it in clang. Also, make powerpc*-linux-musl default to use 64-bit long double. It is currently the only supported ABI on musl and is also how people configure powerpc*-linux-musl-gcc. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D64067 llvm-svn: 365412
* Use llvm::is_contained. NFCFangrui Song2019-02-101-1/+1
| | | | llvm-svn: 353635
* [HIP] Fix size_t for MSVC environmentYaxun Liu2019-01-301-0/+6
| | | | | | | | | | | In 64 bit MSVC environment size_t is defined as unsigned long long. In single source language like HIP, data layout should be consistent in device and host compilation, therefore copy data layout controlling fields from Aux target for AMDGPU target. Differential Revision: https://reviews.llvm.org/D56318 llvm-svn: 352620
* Disable _Float16 for non ARM/SPIR TargetsErich Keane2019-01-251-0/+1
| | | | | | | | | | | | | | As Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html There are problems exposing the _Float16 type on architectures that haven't defined the ABI/ISel for the type yet, so we're temporarily disabling the type and making it opt-in. Differential Revision: https://reviews.llvm.org/D57188 Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736 llvm-svn: 352221
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Emit ASM input in a constant contextBill Wendling2018-12-181-0/+2
| | | | | | | | | | | | | | | | | Summary: Some ASM input constraints (e.g., "i" and "n") require immediate values. At O0, very few code transformations are performed. So if we cannot resolve to an immediate when emitting the ASM input we shouldn't delay its processing. Reviewers: rsmith, efriedma Reviewed By: efriedma Subscribers: rehana, efriedma, craig.topper, jyknight, cfe-commits Differential Revision: https://reviews.llvm.org/D55616 llvm-svn: 349561
* [Android] Increase default new alignment for AndroidPirama Arumuga Nainar2018-08-011-2/+3
| | | | | | | | | | | | | | Summary: Android's memory allocators also guarantee 8-byte alignment for 32-bit architectures and 16-byte alignment for 64-bit. Reviewers: rsmith Subscribers: cfe-commits, srhines, enh Differential Revision: https://reviews.llvm.org/D50112 llvm-svn: 338603
* [Fixed Point Arithmetic] Rename `-fsame-fbits` flagLeonard Chan2018-06-291-2/+2
| | | | | | | | | | | - Rename the `-fsame-fbits` flag to `-fpadding-on-unsigned-fixed-point` - Move the flag from a driver option to a cc1 option - Rename the `SameFBits` member in TargetInfo to `PaddingOnUnsignedFixedPoint` - Updated descriptions Differential Revision: https://reviews.llvm.org/D48727 llvm-svn: 335993
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-201-3/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* [Fixed Point Arithmetic] Addition of the remaining fixed point types and ↵Leonard Chan2018-06-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | their saturated equivalents This diff includes changes for the remaining _Fract and _Sat fixed point types. ``` signed short _Fract s_short_fract; signed _Fract s_fract; signed long _Fract s_long_fract; unsigned short _Fract u_short_fract; unsigned _Fract u_fract; unsigned long _Fract u_long_fract; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; short _Fract short_fract; _Fract fract; long _Fract long_fract; // Saturated fixed point types _Sat signed short _Accum sat_s_short_accum; _Sat signed _Accum sat_s_accum; _Sat signed long _Accum sat_s_long_accum; _Sat unsigned short _Accum sat_u_short_accum; _Sat unsigned _Accum sat_u_accum; _Sat unsigned long _Accum sat_u_long_accum; _Sat signed short _Fract sat_s_short_fract; _Sat signed _Fract sat_s_fract; _Sat signed long _Fract sat_s_long_fract; _Sat unsigned short _Fract sat_u_short_fract; _Sat unsigned _Fract sat_u_fract; _Sat unsigned long _Fract sat_u_long_fract; // Aliased saturated fixed point types _Sat short _Accum sat_short_accum; _Sat _Accum sat_accum; _Sat long _Accum sat_long_accum; _Sat short _Fract sat_short_fract; _Sat _Fract sat_fract; _Sat long _Fract sat_long_fract; ``` This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. Differential Revision: https://reviews.llvm.org/D46911 llvm-svn: 334718
* This diff includes changes for supporting the following types.Leonard Chan2018-06-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches. The tests included are for asserting that we can declare these types. Fixed the test that was failing by not checking for dso_local on some targets. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333923
* Revert "This diff includes changes for supporting the following types."Leonard Chan2018-06-021-3/+0
| | | | | | | This reverts commit r333814, which fails for a test checking the bit width on ubuntu. llvm-svn: 333815
* This diff includes changes for supporting the following types.Leonard Chan2018-06-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | ``` // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; ``` This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches. The tests included are for asserting that we can declare these types. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333814
* This patch aims to match the changes introducedAlexander Ivchenko2018-05-181-0/+13
| | | | | | | | | | | | | | | | | in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html. The -mibt feature flag is being removed, and the -fcf-protection option now also defines a CET macro and causes errors when used on non-X86 targets, while X86 targets no longer check for -mibt and -mshstk to determine if -fcf-protection is supported. -mshstk is now used only to determine availability of shadow stack intrinsics. Comes with an LLVM patch (D46882). Patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D46881 llvm-svn: 332704
* [ObjC++] Make parameter passing and function return compatible with ObjCAkira Hatanaka2018-03-281-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjC and ObjC++ pass non-trivial structs in a way that is incompatible with each other. For example: typedef struct { id f0; __weak id f1; } S; // this code is compiled in c++. extern "C" { void foo(S s); } void caller() { // the caller passes the parameter indirectly and destructs it. foo(S()); } // this function is compiled in c. // 'a' is passed directly and is destructed in the callee. void foo(S a) { } This patch fixes the incompatibility by passing and returning structs with __strong or weak fields using the C ABI in C++ mode. __strong and __weak fields in a struct do not cause the struct to be destructed in the caller and __strong fields do not cause the struct to be passed indirectly. Also, this patch fixes the microsoft ABI bug mentioned here: https://reviews.llvm.org/D41039?id=128767#inline-364710 rdar://problem/38887866 Differential Revision: https://reviews.llvm.org/D44908 llvm-svn: 328731
* [ARM] Pass half or i16 types for NEON intrinsicsSjoerd Meijer2018-03-191-0/+1
| | | | | | | | | | | | | | | For generating NEON intrinsics, this determines the NEON data type, and whether it should be a half type or an i16 type. I.e., we always pass a half type for AArch64, this hasn't changed, but now also for ARM but only when FullFP16 is enabled, and i16 otherwise. This is intended to be non-functional change, but together with the backend work in D44538 which adds support for f16 vectors, this enables adding the AArch32 FP16 (vector) intrinsics. Differential Revision: https://reviews.llvm.org/D44561 llvm-svn: 327836
* [OpenCL] Fix layering violation by getOpenCLTypeAddrSpaceSven van Haastregt2017-12-061-16/+5
| | | | | | | | | | | | Commit 7ac28eb0a5 / r310911 ("[OpenCL] Allow targets to select address space per type", 2017-08-15) made Basic depend on AST, introducing a circular dependency. Break this dependency by adding the OpenCLTypeKind enum in Basic and map from AST types to this enum in ASTContext. Differential Revision: https://reviews.llvm.org/D40838 llvm-svn: 319883
* [MS] Increase default new alignment for win64 and test itReid Kleckner2017-11-211-1/+1
| | | | | | | | | | | | | | | | | | Summary: This raises __STDCPP_DEFAULT_NEW_ALIGNMENT__ from 8 to 16 on Win64. This matches platforms that follow the usual `2 * sizeof(void*)` alignment requirement for malloc. We might want to consider making that the default rather than relying on long double alignment. Fixes PR35356 Reviewers: STL_MSFT, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40277 llvm-svn: 318723
* [OpenMP] Show error if VLAs are not supportedJonas Hahnfeld2017-11-181-0/+1
| | | | | | | | | | | | | | Some target devices (e.g. Nvidia GPUs) don't support dynamic stack allocation and hence no VLAs. Print errors with description instead of failing in the backend or generating code that doesn't work. This patch handles explicit uses of VLAs (local variable in target or declare target region) or implicitly generated (private) VLAs for reductions on VLAs or on array sections with non-constant size. Differential Revision: https://reviews.llvm.org/D39505 llvm-svn: 318601
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* Driver: hoist the `wchar_t` handling to the driverSaleem Abdulrasool2017-10-061-2/+10
| | | | | | | | | | | | | | | | Move the logic for determining the `wchar_t` type information into the driver. Rather than passing the single bit of information of `-fshort-wchar` indicate to the frontend the desired type of `wchar_t` through a new `-cc1` option of `-fwchar-type` and indicate the signedness through `-f{,no-}signed-wchar`. This replicates the current logic which was spread throughout Basic into the `RenderCharacterOptions`. Most of the changes to the tests are to ensure that the frontend uses the correct type. Add a new test set under `test/Driver/wchar_t.c` to ensure that we calculate the proper types for the various cases. llvm-svn: 315126
* [OpenCL] Allow targets to select address space per typeSven van Haastregt2017-08-151-0/+25
| | | | | | | | | | | | | Generalize getOpenCLImageAddrSpace into getOpenCLTypeAddrSpace, such that targets can select the address space per type. No functional changes intended. Initial patch by Simon Perretta. Differential Revision: https://reviews.llvm.org/D33989 llvm-svn: 310911
* [inline asm][gcc-compatiblity] "=i" output constraint supportMarina Yatsina2017-06-261-0/+5
| | | | | | | | Ignore ‘i’,’n’,’E’,’F’ as output constraints in inline assembly (gcc compatibility) Differential Revision: https://reviews.llvm.org/D31383 llvm-svn: 306297
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-031-0/+2
| | | | llvm-svn: 304652
* Move setting of LangOpts based on target flags out of CompilerInstanceEric Christopher2017-03-221-2/+3
| | | | | | | | | 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
* [inline-asm]No error for conflict between inputs\outputs and clobber listMarina Yatsina2016-12-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict. for example: const long double a = 0.0; int main() { char b; double t1 = a; __asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)"); return 0; } This should conflict with the output - t1 which is st, and st which is st aswell. The patch fixes it. Commit on behald of Ziv Izhar. Differential Revision: https://reviews.llvm.org/D15075 llvm-svn: 290539
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-12/+12
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, weRichard Smith2016-09-301-0/+10
| | | | | | | | | assume that ::operator new provides no more alignment than is necessary for any primitive type, except when we're on a GNU OS, where glibc's malloc guarantees to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit systems. This can be controlled by the command-line -fnew-alignment flag. llvm-svn: 282974
* OpenCL: Defining __ENDIAN_LITTLE__ and fix target endiannessMatt Arsenault2016-09-071-1/+1
| | | | | | | | | OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets. The default for targets was also apparently big endian, so AMDGPU was incorrectly reported as big endian. Set this from the triple so targets don't have another place to set the endianness. llvm-svn: 280787
* Re-commit [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-191-2/+3
| | | | | | There was a premature cast to pointer type in emitPointerArithmetic which caused assertion in tests with assertion enabled. llvm-svn: 279206
* Revert [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-181-3/+2
| | | | | | due to regressions in test/CodeGen/exprs.c on certain platforms. llvm-svn: 279127
* [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-181-2/+3
| | | | | | | | Pointers of certain GPUs in AMDGCN target in private address space is 32 bit but pointers in other address spaces are 64 bit. size_t type should be defined as 64 bit for these GPUs so that it could hold pointers in all address spaces. Also fixed issues in pointer arithmetic codegen by using pointer specific intptr type. Differential Revision: https://reviews.llvm.org/D23361 llvm-svn: 279121
* Adjust coercion of aggregates on RenderScriptPirama Arumuga Nainar2016-07-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In RenderScript, the size of the argument or return value emitted in the IR is expected to be the same as the size of corresponding qualified type. For ARM and AArch64, the coercion performed by Clang can change the parameter or return value to a type whose size is different (usually larger) than the original aggregate type. Specifically, this can happen in the following cases: - Aggregate parameters of size <= 64 bytes and return values smaller than 4 bytes on ARM - Aggregate parameters and return values smaller than bytes on AArch64 This patch coerces the cases above to an integer array that is the same size and alignment as the original aggregate. A new field is added to TargetInfo to detect a RenderScript target and limit this coercion just to that case. Tests added to test/CodeGen/renderscript.c Reviewers: rsmith Subscribers: aemerson, srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D22822 llvm-svn: 276904
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-0/+5
| | | | | | | | | | | | | | | | | | This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
* [X86] Add -malign-double supportReid Kleckner2016-05-041-0/+4
| | | | | | | | | | | | | | | | | The -malign-double flag causes i64 and f64 types to have alignment 8 instead of 4. On x86-64, the behavior of -malign-double is enabled by default. Rebases and cleans phosek's work here: http://reviews.llvm.org/D12860 Patch by Sean Klein Reviewers: rnk Subscribers: rnk, jfb, dschuff, phosek Differential Revision: http://reviews.llvm.org/D19734 llvm-svn: 268473
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-4/+0
| | | | | | | | | | Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-0/+4
| | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
* Make TargetInfo store an actual DataLayout instead of a string.James Y Knight2016-03-041-2/+0
| | | | | | | | | | | | | | Use it to calculate UserLabelPrefix, instead of specifying it (often incorrectly). Note that the *actual* user label prefix has always come from the DataLayout, and is handled within LLVM. The main thing clang's TargetInfo::UserLabelPrefix did was to set the #define value. Having these be different from each-other is just silly. Differential Revision: http://reviews.llvm.org/D17183 llvm-svn: 262737
* Do not honor explicit alignment attribute on fields for PS4.Sunil Srivastava2016-02-051-0/+1
| | | | | | | | This change reverts r257462 for PS4 triple. Differential Revision: http://reviews.llvm.org/D16788 llvm-svn: 259916
* Revert "Change of UserLabelPrefix default value from "_" to """James Y Knight2016-01-271-1/+1
| | | | | | | | | | | | | This reverts commit r258504. This commit breaks (at least) sparc-rtems -- the OS (RTEMS) used to override UserLabelPrefix to "", despite the arch (SPARC) having set it to "_". Now, the OS doesn't override anymore, but the arch sets it to "_", resulting in the wrong value. I expect this probably breaks other OSes that overrode to "" before, as well. (Clearly we have some missing test cases, here...) llvm-svn: 258894
* Change of UserLabelPrefix default value from "_" to ""Andrey Bokhanko2016-01-221-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D16295 llvm-svn: 258504
* Use StringRef instead of calling c_str and doing pointer math before ↵Craig Topper2015-10-211-2/+2
| | | | | | eventually creating a StringRef. NFC llvm-svn: 250902
* Use range-based for loops. NFC.Craig Topper2015-10-211-24/+18
| | | | llvm-svn: 250881
* Use std::find instead of a manual loop.Craig Topper2015-10-211-4/+2
| | | | llvm-svn: 250880
* Parse into an unsigned type instead of a signed type and then checking for ↵Craig Topper2015-10-211-5/+4
| | | | | | positive and casting to unsigned. Since we know the string starts with a digit it couldn't be negative anyway. NFCI llvm-svn: 250879
* Fix bad indentation.Craig Topper2015-10-211-1/+1
| | | | llvm-svn: 250878
* Use ArrayRef and MutableArrayRef instead of a pointer and size. NFCCraig Topper2015-10-211-8/+7
| | | | llvm-svn: 250876
OpenPOWER on IntegriCloud