[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
