summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
* [OpenCL][Sema] Improve address space support for blocksMarco Antognini2019-07-091-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch ensures that the following code is compiled identically with -cl-std=CL2.0 and -fblocks -cl-std=c++. kernel void test(void) { void (^const block_A)(void) = ^{ return; }; } A new test is not added because cl20-device-side-enqueue.cl will cover this once blocks are further improved for C++ for OpenCL. The changes to Sema::PerformImplicitConversion are based on the parts of Sema::CheckAssignmentConstraints on block pointer conversions. Reviewers: rjmccall, Anastasia Subscribers: yaxunl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64083 llvm-svn: 365500
* [OpenCL][Sema] Fix builtin rewritingMarco Antognini2019-07-091-2/+2
| | | | | | | | | | | This patch ensures built-in functions are rewritten using the proper parent declaration. Existing tests are modified to run in C++ mode to ensure the functionality works also with C++ for OpenCL while not increasing the testing runtime. llvm-svn: 365499
* Ignore trailing NullStmts in StmtExprs for GCC compatibility.Aaron Ballman2019-07-094-39/+51
| | | | | | | | Ignore trailing NullStmts in compound expressions when determining the result type and value. This is to match the GCC behavior which ignores semicolons at the end of compound expressions. Patch by Dominic Ferreira. llvm-svn: 365498
* [OPENMP]Fix the float point semantics handling on the device.Alexey Bataev2019-07-091-2/+10
| | | | | | | | | | The device should use the same float point representation as the host. Previous patch fixed the handling of the sizes of the float point types, but did not fixed the fp semantics. This patch makes target device to use the host fp semantics. this is required for the correct data transfer between host and device and correct codegen. llvm-svn: 365485
* [ItaniumMangle] Refactor long double/__float128 mangling and fix the mangled ↵Fangrui Song2019-07-094-27/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | code In gcc PowerPC, long double has 3 mangling schemes: -mlong-double-64: `e` -mlong-double-128 -mabi=ibmlongdouble: `g` -mlong-double-128 -mabi=ieeelongdouble: `u9__ieee128` (gcc <= 8.1: `U10__float128`) The current useFloat128ManglingForLongDouble() bisection is not suitable when we support -mlong-double-128 in clang (D64277). Replace useFloat128ManglingForLongDouble() with getLongDoubleMangling() and getFloat128Mangling() to allow 3 mangling schemes. I also deleted the `getTriple().isOSBinFormatELF()` check (the Darwin support has gone: https://reviews.llvm.org/D50988). For x86, change the mangled code of __float128 from `U10__float128` to `g`. `U10__float128` was wrongly copied from PowerPC. The test will be added to `test/CodeGen/x86-long-double.cpp` in D64277. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D64276 llvm-svn: 365480
* [Syntax] Move roles into a separate enumIlya Biryukov2019-07-093-12/+20
| | | | | | To align with reviewer's suggestions. llvm-svn: 365479
* [NFC] [X86] Fix scan-build complainingPengfei Wang2019-07-091-3/+2
| | | | | | | | | | | | | | | | | | Summary: Remove unused variable. This fixes bug: https://bugs.llvm.org/show_bug.cgi?id=42526 Signed-off-by: pengfei <pengfei.wang@intel.com> Reviewers: RKSimon, xiangzhangllvm, craig.topper Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64389 llvm-svn: 365473
* Reland r365355: [Syntax] Introduce syntax treesIlya Biryukov2019-07-094-0/+454
| | | | | | With a fix to a PS4 buildbot crash. llvm-svn: 365466
* Revert rL365355 : [Syntax] Introduce syntax treesSimon Pilgrim2019-07-094-454/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A tooling-focused alternative to the AST. This commit focuses on the memory-management strategy and the structure of the AST. More to follow later: - Operations to mutate the syntax trees and corresponding textual replacements. - Mapping between clang AST nodes and syntax tree nodes. - More node types corresponding to the language constructs. Reviewers: sammccall Reviewed By: sammccall Subscribers: llvm-commits, mgorny, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D61637 ........ Fixes buildbots which were crashing on SyntaxTests.exe llvm-svn: 365465
* [ASTImporter] Added visibility context check for EnumDecl.Balazs Keri2019-07-091-0/+2
| | | | | | | | | | | | | | | | | | | Summary: ASTImporter makes now difference between enums with same name in different translation units if these are not visible outside. ("Scoped enums" are not handled yet.) Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62484 llvm-svn: 365464
* [BPF] Preserve debuginfo array/union/struct type/access indexYonghong Song2019-07-095-4/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For background of BPF CO-RE project, please refer to http://vger.kernel.org/bpfconf2019.html In summary, BPF CO-RE intends to compile bpf programs adjustable on struct/union layout change so the same program can run on multiple kernels with adjustment before loading based on native kernel structures. In order to do this, we need keep track of GEP(getelementptr) instruction base and result debuginfo types, so we can adjust on the host based on kernel BTF info. Capturing such information as an IR optimization is hard as various optimization may have tweaked GEP and also union is replaced by structure it is impossible to track fieldindex for union member accesses. Three intrinsic functions, preserve_{array,union,struct}_access_index, are introducted. addr = preserve_array_access_index(base, index, dimension) addr = preserve_union_access_index(base, di_index) addr = preserve_struct_access_index(base, gep_index, di_index) here, base: the base pointer for the array/union/struct access. index: the last access index for array, the same for IR/DebugInfo layout. dimension: the array dimension. gep_index: the access index based on IR layout. di_index: the access index based on user/debuginfo types. If using these intrinsics blindly, i.e., transforming all GEPs to these intrinsics and later on reducing them to GEPs, we have seen up to 7% more instructions generated. To avoid such an overhead, a clang builtin is proposed: base = __builtin_preserve_access_index(base) such that user wraps to-be-relocated GEPs in this builtin and preserve_*_access_index intrinsics only apply to those GEPs. Such a buyin will prevent performance degradation if people do not use CO-RE, even for programs which use bpf_probe_read(). For example, for the following example, $ cat test.c struct sk_buff { int i; int b1:1; int b2:2; union { struct { int o1; int o2; } o; struct { char flags; char dev_id; } dev; int netid; } u[10]; }; static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr) = (void *) 4; #define _(x) (__builtin_preserve_access_index(x)) int bpf_prog(struct sk_buff *ctx) { char dev_id; bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id)); return dev_id; } $ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \ test.c >& log The generated IR looks like below: ... define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 { %2 = alloca %struct.sk_buff*, align 8 %3 = alloca i8, align 1 store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45 call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49 call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50 call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51 %4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45 %5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45 %6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs( %struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19 %7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons( [10 x %union.anon]* %6, i32 1, i32 5), !dbg !53 %8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons( %union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26 %9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53 %10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s( %struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34 %11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52 %12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55 %13 = sext i8 %12 to i32, !dbg !54 call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56 ret i32 %13, !dbg !57 } !19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20) !26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27) !34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35) Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index attached to instructions to provide struct/union debuginfo type information. For &ctx->u[5].dev.dev_id, . The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout. . The "%7 = ..." represents array subscript "5". . The "%8 = ..." represents union member "dev" with index 1 for DI layout. . The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout. Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and examining all preserve_*_access_index calls, the debuginfo struct/union/array access index can be achieved. The intrinsics also contain enough information to regenerate codes for IR layout. For array and structure intrinsics, the proper GEP can be constructed. For union intrinsics, replacing all uses of "addr" with "base" should be enough. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D61809 llvm-svn: 365438
* Revert "[BPF] Preserve debuginfo array/union/struct type/access index"Yonghong Song2019-07-095-99/+4
| | | | | | | | | This reverts commit r365435. Forgot adding the Differential Revision link. Will add to the commit message and resubmit. llvm-svn: 365436
* [BPF] Preserve debuginfo array/union/struct type/access indexYonghong Song2019-07-095-4/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For background of BPF CO-RE project, please refer to http://vger.kernel.org/bpfconf2019.html In summary, BPF CO-RE intends to compile bpf programs adjustable on struct/union layout change so the same program can run on multiple kernels with adjustment before loading based on native kernel structures. In order to do this, we need keep track of GEP(getelementptr) instruction base and result debuginfo types, so we can adjust on the host based on kernel BTF info. Capturing such information as an IR optimization is hard as various optimization may have tweaked GEP and also union is replaced by structure it is impossible to track fieldindex for union member accesses. Three intrinsic functions, preserve_{array,union,struct}_access_index, are introducted. addr = preserve_array_access_index(base, index, dimension) addr = preserve_union_access_index(base, di_index) addr = preserve_struct_access_index(base, gep_index, di_index) here, base: the base pointer for the array/union/struct access. index: the last access index for array, the same for IR/DebugInfo layout. dimension: the array dimension. gep_index: the access index based on IR layout. di_index: the access index based on user/debuginfo types. If using these intrinsics blindly, i.e., transforming all GEPs to these intrinsics and later on reducing them to GEPs, we have seen up to 7% more instructions generated. To avoid such an overhead, a clang builtin is proposed: base = __builtin_preserve_access_index(base) such that user wraps to-be-relocated GEPs in this builtin and preserve_*_access_index intrinsics only apply to those GEPs. Such a buyin will prevent performance degradation if people do not use CO-RE, even for programs which use bpf_probe_read(). For example, for the following example, $ cat test.c struct sk_buff { int i; int b1:1; int b2:2; union { struct { int o1; int o2; } o; struct { char flags; char dev_id; } dev; int netid; } u[10]; }; static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr) = (void *) 4; #define _(x) (__builtin_preserve_access_index(x)) int bpf_prog(struct sk_buff *ctx) { char dev_id; bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id)); return dev_id; } $ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \ test.c >& log The generated IR looks like below: ... define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 { %2 = alloca %struct.sk_buff*, align 8 %3 = alloca i8, align 1 store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45 call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49 call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50 call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51 %4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45 %5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45 %6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs( %struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19 %7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons( [10 x %union.anon]* %6, i32 1, i32 5), !dbg !53 %8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons( %union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26 %9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53 %10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s( %struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34 %11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52 %12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55 %13 = sext i8 %12 to i32, !dbg !54 call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56 ret i32 %13, !dbg !57 } !19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20) !26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27) !34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35) Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index attached to instructions to provide struct/union debuginfo type information. For &ctx->u[5].dev.dev_id, . The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout. . The "%7 = ..." represents array subscript "5". . The "%8 = ..." represents union member "dev" with index 1 for DI layout. . The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout. Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and examining all preserve_*_access_index calls, the debuginfo struct/union/array access index can be achieved. The intrinsics also contain enough information to regenerate codes for IR layout. For array and structure intrinsics, the proper GEP can be constructed. For union intrinsics, replacing all uses of "addr" with "base" should be enough. Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 365435
* [X86][PPC] Support -mlong-double-64Fangrui Song2019-07-094-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | -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
* clang-cl: Port cl.exe's C4659 to clang-clNico Weber2019-07-092-7/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D64349 llvm-svn: 365411
* [ObjC] Add a -Wtautological-compare warning for BOOLErik Pilkington2019-07-081-6/+30
| | | | | | | | | | | | On macOS, BOOL is a typedef for signed char, but it should never hold a value that isn't 1 or 0. Any code that expects a different value in their BOOL should be fixed. rdar://51954400 Differential revision: https://reviews.llvm.org/D63856 llvm-svn: 365408
* [cxx2a] P0624R2 fix: only lambdas with no lambda-capture are ↵David Blaikie2019-07-082-2/+3
| | | | | | | | | | | | | | default-constructible and assignable. This is a fix for rG864949 which only disabled default construction and assignment for lambdas with capture-defaults, where the C++2a draft disables them for lambdas with any lambda-capture at all. Patch by Logan Smith! Differential Revision: https://reviews.llvm.org/D64058 llvm-svn: 365406
* [Frontend] Explicitly include Bitstream/BitCodes.h and BitstreamWriter.hFrancis Visoiu Mistrih2019-07-081-0/+2
| | | | | | | | | | This fixes a modules issue: error: declaration of 'bitc' must be imported from module 'Clang_Serialization.ASTBitCodes' before it is required Stream.EmitRecord(llvm::bitc::BLOCKINFO_CODE_SETBID, Record); llvm-svn: 365405
* [Sanitizers] Don't use clang_rt.sancov_{begin,end} on SolarisRainer Orth2019-07-081-14/+0
| | | | | | | | | | | | | As explained in https://reviews.llvm.org/D63601, there's no point using clang_rt.sancov_{begin,end} on Solaris any longer. This companion patch to the above removes their use from the driver. Tested on amd64-pc-solaris2.11 Differential Revision: https://reviews.llvm.org/D63602 llvm-svn: 365396
* Add parentheses to silence warnings.Bill Wendling2019-07-081-6/+6
| | | | llvm-svn: 365395
* Revert [Sema] Resolve placeholder types before type deduction to silence ↵Reid Kleckner2019-07-083-38/+12
| | | | | | | | | | | | | | | | | | | | | | spurious `-Warc-repeated-use-of-weak` warnings This reverts r365382 (git commit 8b1becf2e31d9170ee356a19c7b6ea991d3a520f) Appears to regress this semi-reduced fragment of valid code from windows SDK headers: #define InterlockedIncrement64 _InterlockedIncrement64 extern "C" __int64 InterlockedIncrement64(__int64 volatile *Addend); #pragma intrinsic(_InterlockedIncrement64) unsigned __int64 InterlockedIncrement(unsigned __int64 volatile *Addend) { return (unsigned __int64)(InterlockedIncrement64)((volatile __int64 *)Addend); } Found on a buildbot here, but no mail was sent due to it already being red: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/48067 llvm-svn: 365393
* [Sema] Resolve placeholder types before type deduction to silenceAkira Hatanaka2019-07-083-12/+38
| | | | | | | | | | | | | | | | | | spurious `-Warc-repeated-use-of-weak` warnings The spurious -Warc-repeated-use-of-weak warnings are issued when an initializer expression uses a weak ObjC pointer. My first attempt to silence the warnings (r350917) caused clang to reject code that is legal in C++17. The patch is based on the feedback I received from Richard when the patch was reverted. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268945.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268943.html Differential Revision: https://reviews.llvm.org/D62645 llvm-svn: 365382
* [OPENMP]Improve error message for device unsupported types.Alexey Bataev2019-07-081-2/+3
| | | | | | | Provide more data to the user in the error message about unsupported type for device compilation. llvm-svn: 365374
* [Syntax] Introduce syntax treesIlya Biryukov2019-07-084-0/+454
| | | | | | | | | | | | | | | | | | | | | | | | Summary: A tooling-focused alternative to the AST. This commit focuses on the memory-management strategy and the structure of the AST. More to follow later: - Operations to mutate the syntax trees and corresponding textual replacements. - Mapping between clang AST nodes and syntax tree nodes. - More node types corresponding to the language constructs. Reviewers: sammccall Reviewed By: sammccall Subscribers: llvm-commits, mgorny, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D61637 llvm-svn: 365355
* [RISCV][NFC] Make use of Triple::isRISCVAlex Bradbury2019-07-082-7/+2
| | | | | | Use new helper introduced in rL365327. llvm-svn: 365329
* [ASTImporter] Fix import of lambda in function paramGabor Marton2019-07-081-11/+12
| | | | | | | | | | | | | | | | | | | | | Summary: The current import implementation fails to import the definition of a lambda class if the lambda class is defined in a function param. E.g., the lambda class below will be imported without any methods: ``` template <typename F> void f(F L = [](){}) {} ``` Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64073 llvm-svn: 365315
* [analyzer] Add analyzer option to limit the number of imported TUsEndre Fulop2019-07-081-3/+16
| | | | | | | | | | | | Summary: During CTU analysis of complex projects, the loaded AST-contents of imported TUs can grow bigger than available system memory. This option introduces a threshold on the number of TUs to be imported for a single TU in order to prevent such cases. Differential Revision: https://reviews.llvm.org/D59798 llvm-svn: 365314
* [RISCV] Specify registers used for exception handlingAlex Bradbury2019-07-081-0/+9
| | | | | | | | | Implements the handling of __builtin_eh_return_regno(). Differential Revision: https://reviews.llvm.org/D63417 Patch by Edward Jones. llvm-svn: 365305
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-062-129/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +inf] not as [-max, +max]. Summary: Prior to r329065, we used [-max, max] as the range of representable values because LLVM's `fptrunc` did not guarantee defined behavior when truncating from a larger floating-point type to a smaller one. Now that has been fixed, we can make clang follow normal IEEE 754 semantics in this regard and take the larger range [-inf, +inf] as the range of representable values. In practice, this affects two parts of the frontend: * the constant evaluator no longer treats floating-point evaluations that result in +-inf as being undefined (because they no longer leave the range of representable values of the type) * UBSan no longer treats conversions to floating-point type that are outside the [-max, +max] range as being undefined In passing, also remove the float-divide-by-zero sanitizer from -fsanitize=undefined, on the basis that while it's undefined per C++ rules (and we disallow it in constant expressions for that reason), it is defined by Clang / LLVM / IEEE 754. Reviewers: rnk, BillyONeal Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63793 llvm-svn: 365272
* [Rewrite] Extend to further accept CharSourceRangeJoel E. Denny2019-07-061-3/+6
| | | | | | | | | | | | | Some Rewrite functions are already overloaded to accept CharSourceRange, and this extends others in the same manner. I'm calling these in code that's not ready to upstream, but I figure they might be useful to others in the meantime. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D61467 llvm-svn: 365258
* Bitstream reader: Fix undefined behavior seen after rL364464Bjorn Pettersson2019-07-051-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After rL364464 the following tests started to fail when running the clang-doc tests with an ubsan instrumented build of clang-doc: Clang Tools :: clang-doc/single-file-public.cpp Extra Tools Unit Tests :: clang-doc/./ClangDocTests/BitcodeTest.emitEnumInfoBitcode Extra Tools Unit Tests :: clang-doc/./ClangDocTests/BitcodeTest.emitMethodInfoBitcode Extra Tools Unit Tests :: clang-doc/./ClangDocTests/BitcodeTest.emitRecordInfoBitcode Extra Tools Unit Tests :: clang-doc/./ClangDocTests/SerializeTest.emitInfoWithCommentBitcode We need to check that the read value is in range for being casted to the llvm::bitc::FixedAbbrevIDs enum, before the cast in ClangDocBitcodeReader::skipUntilRecordOrBlock. SerializedDiagnosticReader::skipUntilRecordOrBlock was updated in the same way. Reviewers: jfb Reviewed By: jfb Subscribers: Bigcheese, vsapsai, bruno, ilya-biryukov, dexonsmith, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64262 llvm-svn: 365239
* Add a comment explaining why a function existsNico Weber2019-07-051-0/+3
| | | | llvm-svn: 365212
* NFC: Add an explicit return for safety and consistencyHamza Sood2019-07-051-0/+2
| | | | | | | This case implicitly falls-through, which is fine now as it's at the end of the function, but it seems like an accident waiting to happen. llvm-svn: 365210
* [analyzer] Add a debug analyzer config to place an event for each tracked ↵Kristof Umann2019-07-052-0/+25
| | | | | | | | condition Differential Revision: https://reviews.llvm.org/D63642 llvm-svn: 365208
* [analyzer] Track terminator conditions on which a tracked expression dependsKristof Umann2019-07-051-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is a major part of my GSoC project, aimed to improve the bug reports of the analyzer. TL;DR: Help the analyzer understand that some conditions are important, and should be explained better. If an CFGBlock is a control dependency of a block where an expression value is tracked, explain the condition expression better by tracking it. if (A) // let's explain why we believe A to be true 10 / x; // division by zero This is an experimental feature, and can be enabled by the off-by-default analyzer configuration "track-conditions". In detail: This idea was inspired by the program slicing algorithm. Essentially, two things are used to produce a program slice (a subset of the program relevant to a (statement, variable) pair): data and control dependencies. The bug path (the linear path in the ExplodedGraph that leads from the beginning of the analysis to the error node) enables to analyzer to argue about data dependencies with relative ease. Control dependencies are a different slice of the cake entirely. Just because we reached a branch during symbolic execution, it doesn't mean that that particular branch has any effect on whether the bug would've occured. This means that we can't simply rely on the bug path to gather control dependencies. In previous patches, LLVM's IDFCalculator, which works on a control flow graph rather than the ExplodedGraph was generalized to solve this issue. We use this information to heuristically guess that the value of a tracked expression depends greatly on it's control dependencies, and start tracking them as well. After plenty of evaluations this was seen as great idea, but still lacking refinements (we should have different descriptions about a conditions value), hence it's off-by-default. Differential Revision: https://reviews.llvm.org/D62883 llvm-svn: 365207
* [analyzer][IDF] Add a control dependency calculator + a new debug checkerKristof Umann2019-07-051-6/+31
| | | | | | | | | | | | | | | | | | | | | | | I intend to improve the analyzer's bug reports by tracking condition expressions. 01 bool b = messyComputation(); 02 int i = 0; 03 if (b) // control dependency of the bug site, let's explain why we assume val 04 // to be true 05 10 / i; // warn: division by zero I'll detail this heuristic in the followup patch, strictly related to this one however: * Create the new ControlDependencyCalculator class that uses llvm::IDFCalculator to (lazily) calculate control dependencies for Clang's CFG. * A new debug checker debug.DumpControlDependencies is added for lit tests * Add unittests Differential Revision: https://reviews.llvm.org/D62619 llvm-svn: 365197
* Make joined instances of JoinedOrSeparate flags point to the unaliased args, ↵Nico Weber2019-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | like all other arg types do This fixes an 8-year-old regression. r105763 made it so that aliases always refer to the unaliased option – but it missed the "joined" branch of JoinedOrSeparate flags. (r162231 then made the Args classes non-virtual, and r169344 moved them from clang to llvm.) Back then, there was no JoinedOrSeparate flag that was an alias, so it wasn't observable. Now /U in CLCompatOptions is a JoinedOrSeparate alias in clang, and warn_slash_u_filename incorrectly used the aliased arg id (using the unaliased one isn't really a regression since that warning checks if the undefined macro contains slash or backslash and only then emits the warning – and no valid use will pass "-Ufoo/bar" or similar). Also, lld has many JoinedOrSeparate aliases, and due to this bug it had to explicitly call `getUnaliasedOption()` in a bunch of places, even though that shouldn't be necessary by design. After this fix in Option, these calls really don't have an effect any more, so remove them. No intended behavior change. (I accidentally fixed this bug while working on PR29106 but then wondered why the warn_slash_u_filename broke. When I figured it out, I thought it would make sense to land this in a separate commit.) Differential Revision: https://reviews.llvm.org/D64156 llvm-svn: 365186
* [CFG] Add a new function to get the proper condition of a CFGBlockKristof Umann2019-07-051-0/+24
| | | | | | | | | | | | | getTerminatorCondition() returned a condition that may be outside of the block, while the new function returns the proper one: if (A && B && C) {} Return C instead of A && B && C. Differential Revision: https://reviews.llvm.org/D63538 llvm-svn: 365177
* Silence gcc warning "control reaches end of non-void function" [NFCI]Mikael Holmen2019-07-051-0/+2
| | | | | | | | | | | | | | Without this fix gcc (7.4) complains with /data/repo/master/clang/lib/CodeGen/CGObjCMac.cpp: In member function 'std::__cxx11::string {anonymous}::CGObjCCommonMac::GetSectionName(llvm::StringRef, llvm::StringRef)': /data/repo/master/clang/lib/CodeGen/CGObjCMac.cpp:4944:1: error: control reaches end of non-void function [-Werror=return-type] } ^ All values in the ObjectFormatType enum are currently handled in the switch but gcc complains anyway. llvm-svn: 365174
* [NFC] Make some ObjectFormatType switches coveringHubert Tong2019-07-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch removes the `default` case from some switches on `llvm::Triple::ObjectFormatType`, and cases for the missing enumerators are then added. For `UnknownObjectFormat`, the action (`llvm_unreachable`) for the `default` case is kept. For the other unhandled cases, `report_fatal_error` is used instead. Reviewers: sfertile, jasonliu, daltenty Reviewed By: sfertile Subscribers: wuzish, aheejin, jsji, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63767 llvm-svn: 365160
* [modules] Add PP callbacks for entering and leaving a submodule.Vassil Vassilev2019-07-041-0/+12
| | | | llvm-svn: 365153
* [CTU] Add support for virtual functionsGabor Marton2019-07-041-1/+4
| | | | | | | | | | | | Reviewers: Szelethus, xazax.hun Subscribers: rnkovacs, dkrupp, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63920 llvm-svn: 365133
* [PowerPC] Support constraint code "ww"Fangrui Song2019-07-041-1/+2
| | | | | | | | | | | | | Summary: "ww" and "ws" are both constraint codes for VSX vector registers that hold scalar double data. "ww" is preferred for float while "ws" is preferred for double. Reviewed By: jsji Differential Revision: https://reviews.llvm.org/D64119 llvm-svn: 365106
* [analyzer] ReturnValueChecker: Model the guaranteed boolean return value of ↵Csaba Dabis2019-07-043-0/+174
| | | | | | | | | | | | | | | | | | | function calls Summary: It models the known LLVM methods paired with their class. Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus Reviewed By: NoQ Subscribers: dschuff, aheejin, mgorny, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63915 llvm-svn: 365103
* cmake: Add CLANG_LINK_CLANG_DYLIB optionTom Stellard2019-07-033-6/+15
| | | | | | | | | | | | | | | | Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092
* [Bitcode] Move Bitstream to a separate libraryFrancis Visoiu Mistrih2019-07-0316-17/+19
| | | | | | | | | | | | | | | | | | | | | | | | | This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/. This is needed to avoid a circular dependency when using the bitstream code for parsing optimization remarks. Since Bitcode uses Core for the IR part: libLLVMRemarks -> Bitcode -> Core and Core uses libLLVMRemarks to generate remarks (see IR/RemarkStreamer.cpp): Core -> libLLVMRemarks we need to separate the Bitstream and Bitcode part. For clang-doc, it seems that it doesn't need the whole bitcode layer, so I updated the CMake to only use the bitstream part. Differential Revision: https://reviews.llvm.org/D63899 llvm-svn: 365091
* Revert "[analyzer][CFG] Return the correct terminator condition"Kristof Umann2019-07-031-11/+59
| | | | | | | | This reverts commit 7a57118a6fcfa3770f984453543bbdfd0b233e84. Causes a bunch of crashes, I need to time to evaluate this. llvm-svn: 365037
* [analyzer][CFG] Return the correct terminator conditionKristof Umann2019-07-031-59/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the following terminator statement: if (A && B && C && D) The built CFG is the following: [B5 (ENTRY)] Succs (1): B4 [B1] 1: 10 2: j 3: [B1.2] (ImplicitCastExpr, LValueToRValue, int) 4: [B1.1] / [B1.3] 5: int x = 10 / j; Preds (1): B2 Succs (1): B0 [B2] 1: C 2: [B2.1] (ImplicitCastExpr, LValueToRValue, _Bool) T: if [B4.4] && [B3.2] && [B2.2] Preds (1): B3 Succs (2): B1 B0 [B3] 1: B 2: [B3.1] (ImplicitCastExpr, LValueToRValue, _Bool) T: [B4.4] && [B3.2] && ... Preds (1): B4 Succs (2): B2 B0 [B4] 1: 0 2: int j = 0; 3: A 4: [B4.3] (ImplicitCastExpr, LValueToRValue, _Bool) T: [B4.4] && ... Preds (1): B5 Succs (2): B3 B0 [B0 (EXIT)] Preds (4): B1 B2 B3 B4 However, even though the path of execution in B2 only depends on C's value, CFGBlock::getCondition() would return the entire condition (A && B && C). For B3, it would return A && B. I changed this the actual condition. Differential Revision: https://reviews.llvm.org/D63538 llvm-svn: 365036
* Fix -Wcast-qual const warning. NFCI.Simon Pilgrim2019-07-031-1/+1
| | | | llvm-svn: 365031
* Make a buildbot using a buggy gcc happyKristof Umann2019-07-031-3/+5
| | | | | | | | | When specializing a template in a namespace, it has to be in a namespace block, else gcc will get confused. Hopefully this fixes the issue. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480 llvm-svn: 365030
OpenPOWER on IntegriCloud