[llvm-bugs] [Bug 37534] New: Dead movs are not eliminated
https://bugs.llvm.org/show_bug.cgi?id=37534 Bug ID: 37534 Summary: Dead movs are not eliminated Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Keywords: performance Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: lidija.bes...@rt-rk.com CC: llvm-bugs@lists.llvm.org, mips3...@gmail.com While I was going through some code compiled for ARM32 I noticed a number of what seam to be unneeded movs in code. I will give an example: typedef struct k { int m; int n; } str_k; extern int bar2(str_k *, int); int foo(str_k *a, int b){ if(a == NULL && b < 0) return 0; bar2(a, b); return b-a->n; } For this clang generated: : 0: e92d4830push{r4, r5, fp, lr} 4: e28db008add fp, sp, #8 8: e1a04001mov r4, r1 c: e1a05000mov r5, r0 10: e350cmp r0, #0 14: 1a04bne 2c 18: e3a0mov r0, #0 1c: e354cmp r4, #0 20: aa01bge 2c 24: e8bd4830pop {r4, r5, fp, lr} 28: e12fff1ebx lr 2c: e1a5mov r0, r5 30: e1a01004mov r1, r4 34: ebfebl 0 38: e5950004ldr r0, [r5, #4] 3c: e044sub r0, r4, r0 40: e8bd4830pop {r4, r5, fp, lr} 44: e12fff1ebx lr Line: 30:e1a01004mov r1, r4 is unneeded but is generated for both -O3 and -Os optimizations, when removed tests give expected results. I had a look further into this problem and think it has something to do with Machine Copy Propagation Pass (MachineCopyPropagation.cpp to be more exact function CopyPropagateBlock) where cases like this should be handled but are not. Reason behind that appears to be that those copy instructions that become movs are in different blocks and checking is done only on block bases. Same function is making unneeded movs on the end of function when saving values by moving it to other registers which are never used and poped at the end. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37535] New: Dead condition left after removal of branch that used it
https://bugs.llvm.org/show_bug.cgi?id=37535 Bug ID: 37535 Summary: Dead condition left after removal of branch that used it Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Keywords: performance Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: lidija.bes...@rt-rk.com CC: llvm-bugs@lists.llvm.org, mips3...@gmail.com I have been looking into some code compiled for ARM32 using LLVM and I noticed that in some cases -O3 and -Os optimizations leave excess instructions. I have made a mini example where that can be seen: typedef union df_union { int*set; int state; } df; int n; df *d; int foo1(int index){ if ((n && !d[index].set) || (!n && !d[index].state)) { return --index; } return 0; } For this clang generated: : 0: e59f1024ldr r1, [pc, #36] ; 2c 4: e59f2024ldr r2, [pc, #36] ; 30 8: e5922000ldr r2, [r2] c: e5911000ldr r1, [r1] 10: e352cmp r2, #0 14: e7912100ldr r2, [r1, r0, lsl #2] 18: e3a01000mov r1, #0 1c: e352cmp r2, #0 20: 02401001subeq r1, r0, #1 24: e1a1mov r0, r1 28: e12fff1ebx lr cmp and loads that it uses are excess and when removed function continues to give expected result. I had a look into it and it appears to be caused by merging of basic blocks and removal of conditional branch whose condition is computed using excess instructions which are left behind. This happens in Control Flow Optimizes pass in BranchFolding.cpp in function OptimizeBlock where ARM's removeBranch is called, none of them removes condition calculation. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37266] Performance regression 4.0 to 6.0 due to unrolling the first trip through an SSE2 ASCII validation loop
https://bugs.llvm.org/show_bug.cgi?id=37266 Henri Sivonen changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #5 from Henri Sivonen --- This was fixed in rustc by cherrypicking https://github.com/llvm-mirror/llvm/commit/4c64dfea37812732f39e68ca444b2eb809d78dcc into the copy of LLVM used by rustc. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37536] New: -fopenmp-simd incorrectly defines _OPENMP
https://bugs.llvm.org/show_bug.cgi?id=37536 Bug ID: 37536 Summary: -fopenmp-simd incorrectly defines _OPENMP Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: steffen.seck...@tum.de CC: llvm-bugs@lists.llvm.org clang incorrectly defines _OPENMP if -fopenmp-simd is specified. This should only happen if full openmp support is available: this shows, whether _OPENMP has been defined, based on different parameters: > clang -fopenmp-simd -dM -E - < /dev/null | grep -i openmp #define _OPENMP 201511 (this should not be defined here) > clang -fno-openmp -fopenmp-simd -dM -E - < /dev/null | grep -i openmp #define _OPENMP 201511 (this should not be defined here) > clang -fopenmp -dM -E - < /dev/null | grep -i openmp #define _OPENMP 201107 (ok, should be defined) > clang -fopenmp-simd -fopenmp -dM -E - < /dev/null | grep -i openmp #define _OPENMP 201107 (ok, should be defined) The openmp standard provides a reference style to check for openmp support, that is checking for the definition of _OPENMP, e.g. example from openmp standard (https://www.openmp.org/wp-content/uploads/openmp-4.5.pdf, page 35): > #ifdef _OPENMP > iam = omp_get_thread_num() + &index > #endif This simple example code breaks if -fopenmp-simd is defined and -fopenmp is not. build environment: clang version: 6.0.1-svn331815-1~exp1~20180510082943.84 comparison with other compilers: g++ 7.3.0: > g++ -fopenmp-simd -dD -E - < /dev/null | grep -i openmp (empty, _OPENMP not defined) > g++ -fopenmp-simd -fopenmp -dD -E - < /dev/null | grep -i openmp #define _OPENMP 201511 icpc 16.0.4: > icpc -dD -E -qopenmp-simd - icpc -dD -E -qopenmp -qopenmp-simd - icpc -dD -E -qopenmp-simd - icpc -dD -E -qopenmp -qopenmp-simd - ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37537] New: lldb gets confused by two structs with the same name
https://bugs.llvm.org/show_bug.cgi?id=37537 Bug ID: 37537 Summary: lldb gets confused by two structs with the same name Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org The simplest such example is: struct sbar { void foo(); }; void sbar::foo() {} void ffbar() { struct sbar { void foo() {} }; sbar a; a.foo(); } lldb will fail to parse the inner struct sbar, presumably because it has the same name as the outer one (the problem goes away if I rename one of them). This results in the "foo" method of the inner struct being incorrectly classified (so e.g., "breakpoint set --method foo" will ignore it), but it probably has other consequences as well. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37538] New: [ELF] - Something is wrong with sh_info of .rela.plt it seems
https://bugs.llvm.org/show_bug.cgi?id=37538 Bug ID: 37538 Summary: [ELF] - Something is wrong with sh_info of .rela.plt it seems Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: gri...@accesssoftek.com CC: llvm-bugs@lists.llvm.org I linked chromium with LLD and noticed that readelf 2.28 complains: [10] .rela.dyn RELA 00a3f978 00a3f978 00d1a420 0018 A 2 0 8 readelf: Warning: [11]: Info field (0) should index a relocatable section. [11] .rela.plt RELA 01759d98 01759d98 8190 0018 A 2 0 8 I did not dig deeper, seems we should assign sh_info to something for .rela.plt. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37426] Loop vectorization generates poor code for simple integer loop
https://bugs.llvm.org/show_bug.cgi?id=37426 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||332832 --- Comment #5 from Simon Pilgrim --- Fixed v4i32 rotations in rL332832 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37539] New: Segmentation fault in NaryReassociate pass
https://bugs.llvm.org/show_bug.cgi?id=37539 Bug ID: 37539 Summary: Segmentation fault in NaryReassociate pass Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: karl-johan.karls...@ericsson.com CC: llvm-bugs@lists.llvm.org When running the testcase: - ; RUN: opt < %S -nary-reassociate -S -o /dev/null define void @f1() { br label %bb1 bb1: ; preds = %bb1, %0 %1 = phi i16 [ 0, %0 ], [ %3, %bb1 ] %2 = phi i16 [ 0, %0 ], [ %4, %bb1 ] %scevgep.offs = add i16 2, 0 %3 = add i16 %1, %scevgep.offs %scevgep.offs5 = add i16 2, 0 %4 = add i16 %2, %scevgep.offs5 br i1 false, label %bb1, label %bb7 bb7: ; preds = %bb1 ret void } - you end up with a segv. $ ./opt -nary-reassociate -S -o - foo.ll Stack dump: 0. Program arguments: ./opt -nary-reassociate -S -o - foo.ll 1. Running pass 'Function Pass Manager' on module 'foo.ll'. 2. Running pass 'Nary reassociation' on function '@f1' #0 0x02186074 PrintStackTraceSignalHandler(void*) (./opt+0x2186074) #1 0x02184350 llvm::sys::RunSignalHandlers() (./opt+0x2184350) #2 0x021863d8 SignalHandler(int) (./opt+0x21863d8) #3 0x7f707bea5330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x02037ecd llvm::NaryReassociatePass::doOneIteration(llvm::Function&) (./opt+0x2037ecd) #5 0x0203ac08 (anonymous namespace)::NaryReassociateLegacyPass::runOnFunction(llvm::Function&) (./opt+0x203ac08) #6 0x01c19928 llvm::FPPassManager::runOnFunction(llvm::Function&) (./opt+0x1c19928) #7 0x01c19b68 llvm::FPPassManager::runOnModule(llvm::Module&) (./opt+0x1c19b68) #8 0x01c1a045 llvm::legacy::PassManagerImpl::run(llvm::Module&) (./opt+0x1c1a045) #9 0x0077658c main (./opt+0x77658c) #10 0x7f707aa7ff45 __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0 #11 0x0075fabd _start (./opt+0x75fabd) Segmentation fault (core dumped) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37540] New: [NewGVN] Miscompile with nonnull metadata
https://bugs.llvm.org/show_bug.cgi?id=37540 Bug ID: 37540 Summary: [NewGVN] Miscompile with nonnull metadata Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org NewGVN optimizes: define i1 @test({}** %arg, i1 %arg2) { br i1 %arg2, label %bb1, label %bb2 bb1: %load1 = load {}*, {}** %arg %cmp1 = icmp eq {}* %load1, null ret i1 %cmp1 bb2: %load2 = load {}*, {}** %arg, !nonnull !1 %cmp2 = icmp eq {}* %load2, null ret i1 %cmp2 } !1 = !{} into: define i1 @test({}** %arg, i1 %arg2) { br i1 %arg2, label %bb1, label %bb2 bb1: ; preds = %0 ret i1 false bb2: ; preds = %0 ret i1 false } The reason is that %load1 and %load2 are found congruent with %load2 chosen as leader. Thus %cmp1 in bb1 calls SimplifyCmp with icmp eq {}* %load2, null, which is simplified to i1 false based on the !nonnull metadata of %load2. However, this metadata is not applicable in this branch. This bug prevents bootstrapping of rustc under newgvn. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37541] New: [NewGVN] assumes are optimized away
https://bugs.llvm.org/show_bug.cgi?id=37541 Bug ID: 37541 Summary: [NewGVN] assumes are optimized away Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: nikita@gmail.com CC: llvm-bugs@lists.llvm.org Just to make sure this is documented, NewGVN optimizes define {}* @test({}* %arg) { %cmp = icmp ne {}* %arg, null call void @llvm.assume(i1 %cmp) ret {}* %arg } declare void @llvm.assume(i1) into define {}* @test({}* %arg) { %cmp = icmp ne {}* %arg, null call void @llvm.assume(i1 true) ret {}* %arg } declare void @llvm.assume(i1) That is, assumes will usually be reduced to "i1 true" (unless no predicate info is inserted). This should be prevented. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33586] clang fails to compile linux head_32 (integrated-as)
https://bugs.llvm.org/show_bug.cgi?id=33586 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Nirav Dave --- Landed in r332741. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 33586, which changed state. Bug 33586 Summary: clang fails to compile linux head_32 (integrated-as) https://bugs.llvm.org/show_bug.cgi?id=33586 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6577 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: !isEmpty() && "Nothing selected"
Updates: Labels: Deadline-Approaching Comment #2 on issue 6577 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: !isEmpty() && "Nothing selected" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6577#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6554 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-indvars: ASSERT: Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"
Updates: Labels: Deadline-Approaching Comment #2 on issue 6554 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-indvars: ASSERT: Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6554#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6587 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isStatepoint(Token)
Updates: Labels: Deadline-Approaching Comment #2 on issue 6587 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isStatepoint(Token) https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6587#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6592 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unswitch: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unswitch
Updates: Labels: Deadline-Approaching Comment #2 on issue 6592 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-loop_unswitch: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unswitch https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6592#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37542] New: [X86] mstackrealign takes up extra register
https://bugs.llvm.org/show_bug.cgi?id=37542 Bug ID: 37542 Summary: [X86] mstackrealign takes up extra register Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: pir...@google.com CC: llvm-bugs@lists.llvm.org Filing issue https://github.com/android-ndk/ndk/issues/693 reported against the Android NDK. -mstackrealign causes the register allocator to run out of registers for inline assembly. Is this expected? Here's a smaller reproducer produced with CReduce: $ cat > test.c #define a(b, c, d, f, e, h, g, j, i, byte, end, l, k, n, m) "" # 1 "" 3 p, o, q, r, s, t; u() { __asm__(a(, , , , , , , , , , , , , , ) a(, , , , , , , , , , , , , , ) : "=&q"(r), "+m"(o), "+&r"(t), "=&r"(q), "+&r"(t), "=&r"(s) : "m"(p)); } $ clang "-cc1" "-triple" "i686-none-linux-android" "-emit-obj" "-mstackrealign" "-x" "c" test.c :3:11: error: inline assembly requires more registers than available __asm__(a(, , , , , , , , , , , , , , ) a(, , , , , , , , , , , , , , ) ^ h264_cabac-21c918.c:1:61: note: expanded from macro 'a' #define a(b, c, d, f, e, h, g, j, i, byte, end, l, k, n, m) "" ^ 1 error generated. $ clang "-cc1" "-triple" "i686-none-linux-android" "-emit-obj" "-x" "c" test.c -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37536] -fopenmp-simd incorrectly defines _OPENMP
https://bugs.llvm.org/show_bug.cgi?id=37536 Alexey Bataev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Alexey Bataev --- Fixed in r332852 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37542] [X86] mstackrealign takes up extra register
https://bugs.llvm.org/show_bug.cgi?id=37542 Reid Kleckner changed: What|Removed |Added Resolution|--- |WONTFIX CC||r...@google.com Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- Yes, it is known. It uses EBP, ESP, ESI on i686. This is unlikely to change soon. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37543] New: Provide a way to avoid ADRP instructions to make code 100% position independent.
https://bugs.llvm.org/show_bug.cgi?id=37543 Bug ID: 37543 Summary: Provide a way to avoid ADRP instructions to make code 100% position independent. Product: clang Version: 6.0 Hardware: DEC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: ericg...@gmail.com CC: llvm-bugs@lists.llvm.org For environments where code will be executed and cannot meet the page alignment requirements of ADRP, it would be nice to be able to tell the compiler that emitting ADRP instructions are not necessary. A good option might be to implement 'tiny' for mcmodel The primary goal is for 100% position independent code. Please see http://lists.llvm.org/pipermail/llvm-dev/2018-May/123465.html for a discussion of this issue. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37526] [InstCombine] MinMax patterns produce an infinite loop within InstCombine.
https://bugs.llvm.org/show_bug.cgi?id=37526 Alexey Bataev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexey Bataev --- Fixed in r332855 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37544] New: Add llvm.experimental.constrained.* conversion intrinsics
https://bugs.llvm.org/show_bug.cgi?id=37544 Bug ID: 37544 Summary: Add llvm.experimental.constrained.* conversion intrinsics Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: efrie...@codeaurora.org, hfin...@anl.gov, llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com As discussed on https://reviews.llvm.org/D46863, we need to add rounding conversion intrinsics (int->float, float->int, double->float) for FENV_ACCESS modes. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37545] New: asan global instrumentation broken for interposed global variables
https://bugs.llvm.org/show_bug.cgi?id=37545 Bug ID: 37545 Summary: asan global instrumentation broken for interposed global variables Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: llvm-bugs@lists.llvm.org Situation: main binary contains a weak definition of global symbol foo foo.so contains a strong definition of global symbol foo ASan instruments the strong definition but not the weak one: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L1661 Now, after dynamic linking, the program has only one definition of foo (the one from the main binary) but still has the global registration code from foo.so, which tries to register that global symbol. In my test case, the registration fails because the weak definition is underaligned for a sanitized global, and ASan reports a bogus ODR violation error. If the alignment happens to match, ASan would presumably instead mark a bogus region of the address space as being global redzone. As of r332028, Clang creates the above situation for entirely valid code: // main.cc #include struct A; auto &x = typeid(A*); void use_foo(); int main() { use_foo(); } // foo.cc struct A { virtual void f(); }; void A::f() {} void use_foo() {} $ clang++ foo.cc -shared -o /tmp/foo.so -fsanitize=address $ clang++ /tmp/foo.so main.cc -o /tmp/main -fsanitize=address $ /tmp/main ==211158==The following global variable is not properly aligned. ==211158==This may happen if another global with the same name ==211158==resides in another non-instrumented module. ==211158==Or the global comes from a C file built w/o -fno-common. ==211158==In either case this is likely an ODR violation bug, ==211158==but AddressSanitizer can not provide more details. = ==211158==ERROR: AddressSanitizer: odr-violation (0x0050a1d6): [1] size=3 'typeinfo name for A' - [2] size=3 'typeinfo name for A' - These globals were registered at these points: [1]: #0 0x42dcfe in __asan_register_globals[...]/compiler-rt/lib/asan/asan_globals.cc:358:3 #1 0x7f32dfe18a70 in asan.module_ctor (/tmp/foo.so+0xa70) [2]: #0 0x42dcfe in __asan_register_globals [...]/compiler-rt/lib/asan/asan_globals.cc:358:3 #1 0x7f32dfe18a70 in asan.module_ctor (/tmp/foo.so+0xa70) ==211158==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0 SUMMARY: AddressSanitizer: odr-violation: global 'typeinfo name for A' at - ==211158==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24476] LLD's PE symbol tables are corrupted by mt.exe
https://bugs.llvm.org/show_bug.cgi?id=24476 Reid Kleckner changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Reid Kleckner --- r332880 Realistically, I don't think there's anything more LLD can do to make mt.exe handle the mingw style symbol tables. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37466] MC should support writing two object files for split dwarf
https://bugs.llvm.org/show_bug.cgi?id=37466 Peter Collingbourne changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Peter Collingbourne --- This was fixed in a long series of commits that ended in r332885. echristo: Thanks for the quick review! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37104] Backend should be able to unfold masked merge
https://bugs.llvm.org/show_bug.cgi?id=37104 Roman Lebedev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Roman Lebedev --- r332904 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37546] New: wasm32: Invalid wasm file generated at O0 on call signature
https://bugs.llvm.org/show_bug.cgi?id=37546 Bug ID: 37546 Summary: wasm32: Invalid wasm file generated at O0 on call signature Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: a...@crichton.co CC: dan433...@gmail.com, llvm-bugs@lists.llvm.org, s...@chromium.org Created attachment 20328 --> https://bugs.llvm.org/attachment.cgi?id=20328&action=edit IR Originally reported at https://github.com/rustwasm/wasm-bindgen/issues/199 this bug then transitioned into https://github.com/rust-lang/rust/issues/50869 where I've been able to reduce this a bit to hopefully be in a reportable state for LLVM itself. The attached IR, when run through `llc` at O0, will generate a wasm object file which fails to pass `wasm-validate`: $ llc foo.ll -O0 -filetype=obj -o foo.o $ wasm-validate --enable-mutable-globals foo.o --ignore-custom-section-errors tmp.o:b36: error: type mismatch in call, expected [i32, i32] but got [i32] I think this appears to be the root cause for causing the final linked module to become invalid as well. Note that the attached IR is also reduced via bugpoint so it may look a little odd. If there's any questions about this though, please feel free to let me know! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37547] New: StackAddressEscape doesn't properly lifetime extend temporaries bound to static variables
https://bugs.llvm.org/show_bug.cgi?id=37547 Bug ID: 37547 Summary: StackAddressEscape doesn't properly lifetime extend temporaries bound to static variables Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: george.burgess...@gmail.com CC: llvm-bugs@lists.llvm.org Test-case: $ cat /tmp/f.cpp struct Foo { Foo(); ~Foo(); int i; }; const void *foo() { static const Foo &f = {}; return &f; } $ clang-tidy -checks=clang-analyzer-core.StackAddressEscape /tmp/f.cpp -- 2 warnings generated. /tmp/f.cpp:9:3: warning: Address of stack memory associated with temporary object of type 'Foo' returned to caller [clang-analyzer-core.StackAddressEscape] return &f; ^ /tmp/f.cpp:9:3: note: Address of stack memory associated with temporary object of type 'Foo' returned to caller /tmp/f.cpp:10:1: warning: Address of stack memory associated with temporary object of type 'Foo' is still referred to by the static variable 'f' upon returning to the caller. This will be a dangling reference [clang-analyzer-core.StackAddressEscape] } ^ /tmp/f.cpp:10:1: note: Address of stack memory associated with temporary object of type 'Foo' is still referred to by the static variable 'f' upon returning to the caller. This will be a dangling reference Reading the C++ standard, however, it appears that temporary lifetime extension extends the lifetime of temporaries to live as long as the reference they're being bound to. So, since `f` is static, the temporary being bound to it gets to live until the program dies: https://godbolt.org/g/snsWA7 (please note the atexit dtor call and extra global `_ZGRZ3foovE1f_`) For added fun, this appears to apply to struct fields, too: https://godbolt.org/g/NdV7jW (FWIW, the struct fields example is a reduced version of how I found this. When I first saw it, I thought the code was broken, too. :) ) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3236 in oss-fuzz: llvm: Abrt in llvm::report_bad_alloc_error
Comment #14 on issue 3236 by k...@google.com: llvm: Abrt in llvm::report_bad_alloc_error https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3236#c14 Matt (mascasa@), please check what's going on here. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37546] wasm32: Invalid wasm file generated at O0 on call signature
https://bugs.llvm.org/show_bug.cgi?id=37546 Dan Gohman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dan Gohman --- Fixed in r332947. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37548] New: [MergeICmps] should not emit memcmp in`-fno-builtin`mode.
https://bugs.llvm.org/show_bug.cgi?id=37548 Bug ID: 37548 Summary: [MergeICmps] should not emit memcmp in`-fno-builtin`mode. Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: cour...@google.com CC: llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37529] Invalid "conflicting types for" in header
https://bugs.llvm.org/show_bug.cgi?id=37529 Ethan Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Ethan Smith --- >The fix is to add > >struct timeval; > >prior to your declaration of 'difference'. I've done this as a work around. It seems MSVC has different scoping rules or resolves structs differently. Thank you for the assistance. I'm guessing clang-cl doesn't intend to support this weirdness, so I'll go ahead and close the issue. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs