[llvm-bugs] [Bug 37101] New: [x86] Failure to use both div and mod results of one IDIV in a prime-factor loop while(n%i==0) { n/=i; }
https://bugs.llvm.org/show_bug.cgi?id=37101
Bug ID: 37101
Summary: [x86] Failure to use both div and mod results of one
IDIV in a prime-factor loop while(n%i==0) { n/=i; }
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: performance
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: pe...@cordes.ca
CC: llvm-bugs@lists.llvm.org
Near-identical code-gen to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85366
for this loop. From
https://codereview.stackexchange.com/questions/191792/find-prime-factors-in-c/191801#191801,
simplified to use a pointer instead of returning std::vector:
void find_prime_factors_ptr(int n, int *p)
{
// inefficient to test even numbers > 2, but that's a separate missed
optimization.
for (int i = 2; i <= n; i++) {
while (n % i == 0) {
*p++ = i;
n /= i; // reordering the loop body doesn't help
}
}
}
https://godbolt.org/g/GLycMM
clang version 7.0.0 (trunk 329780)
find_prime_factors_ptr(int, int*):
movl%edi, %ecx
cmpl$2, %edi
jl .LBB0_6
movl$2, %edi # why not keep n in EDI, and use ECX for
i?
.LBB0_2:# =>This Loop Header: Depth=1
movl%ecx, %eax
cltd
idivl %edi
testl %edx, %edx
jne .LBB0_5
.LBB0_3:# Parent Loop BB0_2 Depth=1
movl%edi, (%rsi)
movl%ecx, %eax
cltd
idivl %edi
movl%eax, %ecx
cltd
idivl %edi
addq$4, %rsi
testl %edx, %edx
je .LBB0_3
.LBB0_5:# in Loop: Header=BB0_2 Depth=1
leal1(%rdi), %eax# this compare-latency optimization
cmpl%ecx, %edi # doesn't seem worth it
movl%eax, %edi # 4 uops instead of 2 from defeating
macro-fusion
jl .LBB0_2 # vs. inc %rdi / cmp %ecx,%edi / jle
.LBB0_6:
retq
Using idiv twice inside the loop body is totally pointless. At either way of
reaching .LBB0_3 (fall through or loop), n/i is in EAX, but LLVM ignores it.
The inner loop can be optimized by dropping movl %ecx, %eax / cltd / idiv with
no other changes.
.LBB0_3:
movl%edi, (%rsi)
addq$4, %rsi
movl%eax, %ecx# n = tmp
cltd
idivl %edi # eax = tmp = n/i
testl %edx, %edx
je .LBB0_3
Unlike for gcc, changing the inner loop like this didn't help:
int tmp;
while (tmp = n/i, n % i == 0) {
*p++ = i;
n = tmp;
}
(see the linked gcc bug report for an interesting version that jumps into the
inner loop instead of hoisting the run-zero-times check out of the loop before
the first iteration.)
I think one of the versions on the godbolt link did manage to optimize better
with clang, but I haven't investigated further. (I think it was one of the
versions using `vector.push_back` inside the loop.)
--
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 37102] New: [LLVM-COV] Wrong coverage with the comparison of extern function pointer and NULL
https://bugs.llvm.org/show_bug.cgi?id=37102
Bug ID: 37102
Summary: [LLVM-COV] Wrong coverage with the comparison of
extern function pointer and NULL
Product: Runtime Libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org
$ cat small.c
#include
extern int (*_Unwind_RaiseException) (void *) __attribute__((weak));
int main(void)
{
if (&_Unwind_RaiseException != NULL)
return 0;
return 1;
}
$ clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov; cat small.gcov
1| |#include
2| |
3| |extern int (*_Unwind_RaiseException) (void *)
__attribute__((weak));
4| |
5| |int main(void)
6| 1|{
7| 1| if (&_Unwind_RaiseException != NULL)
8| 1|return 0;
9| 1| return 1;
10| 1|}
Line #8 is wrongly marked as executed.
--
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 37103] New: [LLVM-COV] Wrong coverage when label is after other statements at the same code line
https://bugs.llvm.org/show_bug.cgi?id=37103
Bug ID: 37103
Summary: [LLVM-COV] Wrong coverage when label is after other
statements at the same code line
Product: Runtime Libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 7.0.0- (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8.0.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat small.c
int a = 0;
void foo() { a++; }
void bar() { a++; }
int main()
{
foo(); goto lbl2; lbl1: bar ();
lbl2:
if (a == 1)
goto lbl1;
}
$ clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov; cat small.gcov
1| |int a = 0;
2| |
3| 1|void foo() { a++; }
4| 1|void bar() { a++; }
5| |
6| |int main()
7| 1|{
8| 1| foo(); goto lbl2; lbl1: bar ();
9| 1|
10| 2| lbl2:
11| 2|if (a == 1)
12| 1| goto lbl1;
13| 1|}
Line #8 is wrongly marked as executed once. However, since got lbl1 is
executed, the correct mark of Line #8 should be "2", i.e., Line #8 should
executed twice.
--
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] New: Backend should be able to unfold masked merge
https://bugs.llvm.org/show_bug.cgi?id=37104 Bug ID: 37104 Summary: Backend should be able to unfold masked merge Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org Moving the disscussion from https://bugs.llvm.org/show_bug.cgi?id=6773#c9 That ^ will introduce IR canonicalization, which is likely suboptimal for the final assembly. I'm guessing the backend (what specifically?) should be able to undo it: https://rise4fun.com/Alive/HqI https://godbolt.org/g/skwsvY -- 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 35427] clang-format is misbehaving with [[attributes]]
https://bugs.llvm.org/show_bug.cgi?id=35427 Manuel Klimek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Manuel Klimek --- Yep, should be fixed now. -- 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 37105] New: [LLVM-COV] goto label and a label is wrongly
https://bugs.llvm.org/show_bug.cgi?id=37105
Bug ID: 37105
Summary: [LLVM-COV] goto label and a label is wrongly
Product: Runtime Libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 7.0.0- (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8.0.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat small.c
int test_goto (int f)
{
for (int i = 0; i < 10; i++)
if (i == f)
goto lab;
return 0;
lab:
return 1;
}
int main()
{
test_goto (3);
return 0;
}
$ clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov; cat small.gcov
1| |int test_goto (int f)
2| 1|{
3| 4| for (int i = 0; i < 10; i++)
4| 4|if (i == f)
5| 1| goto lab;
6| 1| return 0;
7| 1|lab:
8| 1| return 1;
9| 0|}
10| |
11| |int main()
12| 1|{
13| 1| test_goto (3);
14| 1| return 0;
15| 1|}
Line #6 is wrongly marked as executed
--
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 37106] New: DataFlowSanitizer works wrong when snprintf use char-array as argument
https://bugs.llvm.org/show_bug.cgi?id=37106
Bug ID: 37106
Summary: DataFlowSanitizer works wrong when snprintf use
char-array as argument
Product: libraries
Version: 5.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Miscellaneous Instrumentation passes
Assignee: unassignedb...@nondot.org
Reporter: 3n4t...@gmail.com
CC: llvm-bugs@lists.llvm.org
1. the code:
#include
void fun()
{
char buf[1000] ;
char h[100] ;
h[1] = 'a' ;
h[0] = '\0' ;
snprintf(buf, sizeof(buf), "%s", h) ;
}
2. the compile command:
clang -O3 -fsanitize=dataflow 1.c
unless you use -O0, you would got a clang crash
3. the crash
Wrong types for attribute: byval inalloca nest noalias nocapture nonnull
readnone readonly sret dereferenceable(1) dereferenceable_or_null(1)
%12 = call i32 (i8*, i64, i8*, i16, i16, i16, i16*, i16*, ...)
@__dfsw_snprintf(i8* nonnull %0, i64 1000, i8* getelementptr inbounds ([3 x
i8], [3 x i8]* @.str, i64 0, i64 0), i16 nonnull zeroext 0, i16 zeroext 0, i16
zeroext 0, i16* %11, i16* %labelreturn, i8* %1) #5
fatal error: error in backend: Broken function found, compilation aborted!
clang-5.0: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /wangchu_data/LLVM5_Install/bin
clang-5.0: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-5.0: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-5.0: note: diagnostic msg: /tmp/dfsan_bug-0cbaaf.c
clang-5.0: note: diagnostic msg: /tmp/dfsan_bug-0cbaaf.sh
clang-5.0: note: diagnostic msg:
4.
$clang --version
clang version 5.0.1 (tags/RELEASE_501/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
I guess, it could be caused by some wrong inserted IR which generated by
DataFlowSanitizer PASS when use snprintf with char-array argument.
DFSan is great tool, please fix it :)
--
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 37039] [PowerPC, bisected] miscompilation in rust crate "futures"
https://bugs.llvm.org/show_bug.cgi?id=37039 Nemanja Ivanovic changed: What|Removed |Added Status|RESOLVED|REOPENED Blocks||36649 Resolution|FIXED |--- --- Comment #7 from Nemanja Ivanovic --- Thanks Hans. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=36649 [Bug 36649] [meta] 6.0.1 Release Blockers -- 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 36649] [meta] 6.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=36649 Bug 36649 depends on bug 37039, which changed state. Bug 37039 Summary: [PowerPC, bisected] miscompilation in rust crate "futures" https://bugs.llvm.org/show_bug.cgi?id=37039 What|Removed |Added Status|RESOLVED|REOPENED 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] [Bug 37107] New: [LLVM-COV] Wrong coverage with label in if statement
https://bugs.llvm.org/show_bug.cgi?id=37107
Bug ID: 37107
Summary: [LLVM-COV] Wrong coverage with label in if statement
Product: Runtime Libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libprofile library
Assignee: unassignedb...@nondot.org
Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 7.0.0- (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8.0.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8.0.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ cat small.c
void foo(int a)
{
if (a > 0)
L:
for(int i = 0; i<10; i++)
;
}
int main()
{
foo(1);
return 0;
}
$ clang -O0 -g -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c; ./a.out; llvm-profdata merge small.profraw -o small.profdata; llvm-cov
show a.out -instr-profile=small.profdata small.c > small.gcov; cat small.gcov
1| |void foo(int a)
2| 1|{
3| 1| if (a > 0)
4| 2|L:
5| 11| for(int i = 0; i<10; i++)
6| 10|;
7| 1|}
8| |
9| |int main()
10| 1|{
11| 1| foo(1);
12| 1| return 0;
13| 1|}
Line #4 is wrongly marked as executed twice.
--
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 7604 in oss-fuzz: llvm/clang-proto-fuzzer: Null-dereference READ in llvm::SSAUpdaterBulk::RewriteAllUses
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-04-12 Type: Bug New issue 7604 by ClusterFuzz-External: llvm/clang-proto-fuzzer: Null-dereference READ in llvm::SSAUpdaterBulk::RewriteAllUses https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7604 Detailed report: https://oss-fuzz.com/testcase?key=5561606936199168 Project: llvm Fuzzer: libFuzzer_llvm_clang-proto-fuzzer Fuzz target binary: clang-proto-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x0011 Crash State: llvm::SSAUpdaterBulk::RewriteAllUses llvm::JumpThreadingPass::ThreadEdge llvm::JumpThreadingPass::ProcessThreadableEdges Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201804110524:201804120529 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5561606936199168 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 37109] New: operator new with throw() omits NULL check at -O1 and higher
https://bugs.llvm.org/show_bug.cgi?id=37109
Bug ID: 37109
Summary: operator new with throw() omits NULL check at -O1 and
higher
Product: clang
Version: 5.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: mattmill...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
I tested this example in various compilers on godbolt using "-fno-exceptions"
and
various -O levels.
https://godbolt.org/g/egWwC2
---
#include
extern void * operator new(size_t sz) throw();
class Foo {
public:
Foo(int i) : _i(i) {}
private:
int _i;
};
void *
test_new() {
Foo *f = new Foo(5);
return f;
}
---
The expectation is if the operator new has a throw() keyword, there
will be a NULL check before initialization is done and no NULL check if the
throw() keyword is omitted.
This expectation is based on [expr.new]p13 that I find in this copy
of the standard:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf
[Note: unless an allocation function is declared with an empty
exception-specification (15.4), throw(), it indicates
failure to allocate storage by throwing a bad_alloc exception (clause 15,
18.4.2.1); it returns a non-null pointer otherwise.
If the allocation function is declared with an empty exception-specification,
throw(), it returns null to indicate failure
to allocate storage and a non-null pointer otherwise. — end note ] If the
allocation function returns null, initialization
shall not be done, the deallocation function shall not be called, and the value
of the new-expression shall be null.
The results I got for various permutations of compiler this code in godbolt
are:
1. gcc (any version/any -O/new declaration w/ throw()): NULL check before
constructor init.
2. gcc (any version/any -O/new declaration w/o throw()): no NULL check before
constructor init.
3. clang (any version/any -O/new declaration w/o throw()): no NULL check before
constructor init.
4. clang (3.3 and prior/any -O/new declaration w/ throw()): NULL check before
constructor init.
5. clang (3.4.1 and later/-O0/new declaration w/ throw()): NULL check before
constructor init.
6. clang (3.4.1 and later/-O1 and higher/new declaration w/ throw()): no NULL
check before constructor init.
7. clang (3.4.1 and later/-O0/new declaration w/ throw()): NULL check before
constructor init.
E.g., below is the x86_64 assembly for clang 3.3 vs. 5.0.0 with -O3:
clang 3.3, -O3 -fno-exceptions
---
test_new(): # @test_new()
push RAX
mov EDI, 4
call operator new(unsigned long)
test RAX, RAX
je .LBB0_1
mov DWORD PTR [RAX], 5
pop RDX
ret
.LBB0_1:
xor EAX, EAX
pop RDX
ret
---
clang 5.0.0, -O3 -fno-exceptions
---
test_new(): # @test_new()
push rax
mov edi, 4
call operator new(unsigned long)
mov dword ptr [rax], 5
pop rcx
ret
---
We believe there may be a bug here where clang should be doing the NULL check
before initialization here regardless of the optimization level to be standard
compliant.
--
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 24380] ObjC: cannot disable clang-format on class declaration parameterized with lightweight generics
https://bugs.llvm.org/show_bug.cgi?id=24380 Ben Hamilton changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||bhamilto...@gmail.com --- Comment #1 from Ben Hamilton --- I believe this was fixed with https://reviews.llvm.org/D45185 / https://reviews.llvm.org/rC329298: % echo "/* clang-format off */ @interface MyClass>@end /* clang-format on */" | clang-format /* clang-format off */ @interface MyClass>@end /* clang-format on */ -- 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 30595] extraneous const qualifier allowed in malformed conversion function
https://bugs.llvm.org/show_bug.cgi?id=30595 Aaron Ballman changed: What|Removed |Added CC||aa...@aaronballman.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Aaron Ballman --- Fixed in r329924. -- 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 7627 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: NULL
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Unreproducible Engine-libfuzzer Proj-llvm Reported-2018-04-12 Type: Bug New issue 7627 by ClusterFuzz-External: llvm/llvm-special-case-list-fuzzer: NULL https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7627 Detailed report: https://oss-fuzz.com/testcase?key=5673900735201280 Project: llvm Fuzzer: libFuzzer_llvm_llvm-special-case-list-fuzzer Fuzz target binary: llvm-special-case-list-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: NULL Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5673900735201280 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 37110] New: [Formatter/ObjC] Line break between exclamation mark ! and method call if line length = ColumnLimit+1
https://bugs.llvm.org/show_bug.cgi?id=37110
Bug ID: 37110
Summary: [Formatter/ObjC] Line break between exclamation mark !
and method call if line length = ColumnLimit+1
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: da...@dzhang.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Line breaking behavior for lines of length ColumnLimit+1 of the form ![obj
methodCall] chooses to break the line between the bang/not operator and the
method call, which is undesirable.
input.m:
- (void)test {
// these three with variables wrap as expected
if
(!someLongBooleanVariableNameUsedInAnIf01234567801234567801234567801234567890123456789)
return;
if (someLongBooleanVariableNameUsedInAnIf ||
!aDifferentLongBooleanVariable11)
return;
if (someLongBooleanVariableNameUsedInAnIf ||
!aDifferentLongBooleanVariable111)
return;
// these two with method calls wrap badly
if ([self someLongMethodThatReturnsBoolean] || ![self
aDifferentBooleanMethod])
return;
if (![self
someLongMethodThatReturnsBoolean0123456780123456780123456780123456])
return;
}
$ clang-format -style=llvm input.m
- (void)test {
// these three with variables wrap as expected
if
(!someLongBooleanVariableNameUsedInAnIf01234567801234567801234567801234567890123456789)
return;
if (someLongBooleanVariableNameUsedInAnIf ||
!aDifferentLongBooleanVariable11)
return;
if (someLongBooleanVariableNameUsedInAnIf ||
!aDifferentLongBooleanVariable111)
return;
// these two with method calls wrap badly
if ([self someLongMethodThatReturnsBoolean] || !
[self
aDifferentBooleanMethod])
return;
if (!
[self
someLongMethodThatReturnsBoolean0123456780123456780123456780123456])
return;
}
$ clang-format --version
clang-format version 7.0.0 (tags/google/stable/2018-01-11)
Notice that if I use variables, they wrap as expected when the lines are 80 and
81 chars long, but when using method calls ending at column 81, the formatter
causes bad line breaking.
I have not been able to find a combination of config options that avoids this
behavior.
--
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 37111] New: [Formatter/ObjC] @selector(method:arg:) tends to be line-wrapped around the ( rather than :
https://bugs.llvm.org/show_bug.cgi?id=37111
Bug ID: 37111
Summary: [Formatter/ObjC] @selector(method:arg:) tends to be
line-wrapped around the ( rather than :
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: da...@dzhang.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
clang-format binds method argument : tighter than @selector(, resulting in the
following odd formatting.
See also: https://bugs.chromium.org/p/chromium/issues/detail?id=711737
input.m:
- (void)test {
if ([object
respondsToSelector:@selector(selectorNameThatIsReallyLong:param1:param2:)])
return;
}
$ clang-format -style=llvm input.m
- (void)test {
if ([object respondsToSelector:@selector
(selectorNameThatIsReallyLong:param1:param2:)])
return;
}
$ clang-format --version
clang-format version 7.0.0 (tags/google/stable/2018-01-11)
The @selector and its ( should remain together
I have not been able to find a combination of config options that avoids this
behavior.
--
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 37112] New: Missed optimization: many "switch-like" IFs could use bit-array instead of jump table
https://bugs.llvm.org/show_bug.cgi?id=37112
Bug ID: 37112
Summary: Missed optimization: many "switch-like" IFs could use
bit-array instead of jump table
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: kobalicek.p...@gmail.com
CC: llvm-bugs@lists.llvm.org
Problem
---
I'm comparing how various compilers optimize the following code:
bool testChar(unsigned x) noexcept {
return x == A ? true :
x == B ? true :
x == C ? true :
x == D ? true :
... (continues) ...
x == Z ? true : false
}
And I'm wondering why clang is using a jump table for such case, which turns
out to be suboptimal when the range for `true` or `false` cases is very
restricted, let's say to 0-255 (byte) or even smaller range.
Testing Code
I wrote the following code to test a naive implementation and an implementation
that uses bit-array trick:
#include
#include
#include
// BitArray builders, no idea how to do this better, this works...
template
struct BinaryLUT_ByteMask {
enum : uint32_t {
kValue = (uint32_t(Predicate::test(Index + 0)) << 0)
| (uint32_t(Predicate::test(Index + 1)) << 1)
| (uint32_t(Predicate::test(Index + 2)) << 2)
| (uint32_t(Predicate::test(Index + 3)) << 3)
| (uint32_t(Predicate::test(Index + 4)) << 4)
| (uint32_t(Predicate::test(Index + 5)) << 5)
| (uint32_t(Predicate::test(Index + 6)) << 6)
| (uint32_t(Predicate::test(Index + 7)) << 7)
};
};
template
struct BinaryLUT_UInt32Mask {
enum : uint32_t {
kValue = ((BinaryLUT_ByteMask::kValue) << 0)
| ((BinaryLUT_ByteMask::kValue) << 8)
| ((BinaryLUT_ByteMask::kValue) << 16)
| ((BinaryLUT_ByteMask::kValue) << 24)
};
};
template
struct BinaryLUT {
// Just to prevent having multiple tables emitted in
// case a different type for `Index` was used, not
// sure this is really required...
static inline bool testInternal(size_t index) noexcept {
static const uint32_t lut[256 / 32] = {
BinaryLUT_UInt32Mask::kValue,
BinaryLUT_UInt32Mask::kValue,
BinaryLUT_UInt32Mask::kValue,
BinaryLUT_UInt32Mask::kValue,
BinaryLUT_UInt32Mask::kValue,
BinaryLUT_UInt32Mask::kValue,
BinaryLUT_UInt32Mask::kValue,
BinaryLUT_UInt32Mask::kValue
};
return bool((lut[index / 32U] >> (index % 32U)) & 0x1);
}
template
static inline bool test(const T& value) noexcept {
typedef typename std::make_unsigned::type U;
return testInternal(size_t(U(value)));
}
};
struct AllowedPostScriptChars {
static constexpr bool test(uint32_t i) noexcept {
return i < 33 ? false :
i > 126 ? false :
i == '[' ? false :
i == ']' ? false :
i == '(' ? false :
i == ')' ? false :
i == '{' ? false :
i == '}' ? false :
i == '<' ? false :
i == '>' ? false :
i == '/' ? false :
i == '%' ? false : true;
}
};
bool testNaive(uint32_t uc) {
return AllowedPostScriptChars::test(uc);
}
bool testLUT(uint32_t uc) {
return BinaryLUT::test(uc);
}
testNaive:
lea eax, [rdi - 33]
cmp eax, 93
jbe .LBB1_2
xor eax, eax
ret
.LBB1_2:
add edi, -37
cmp edi, 88
ja .LBB1_4
xor eax, eax
jmp qword ptr [8*rdi + .LJTI1_0]
.LBB1_5:
ret
.LBB1_4:
mov al, 1
ret
.LJTI1_0:
!!! (... skipped almost 90 entries in a jump-table ...) !!!
testLUT:
mov eax, edi
shr eax, 5
mov eax, dword ptr [4*rax +
BinaryLUT::testInternal(unsigned long)::lut]
bt eax, edi
setb al
ret
BinaryLUT::testInternal(unsigned long)::lut: # The
actual LUT generated.
.long 0 # 0x0
.long 2952756446 # 0xafff7cde
.long 3623878655 # 0xd7ff
.long 1476395007 # 0x57ff
.long 0 # 0x0
.long 0 # 0x0
.long 0 # 0x0
.long 0 # 0x0
Notes
-
I would like to mention that I know that the two functions are not completely
identical. The `testLUT` function does not do range checks as I have a
restricted input from 0..255 so I didn't bother with that, but I think that
this fact should not really matter as I'm talking about the approach and not
range checking. In addition, I think that even my optimization is not really
optimal in cases when there would be a lot of zeros in the table (maybe range
check would be better, and also the mask could be 64-bit long on 64-bit
platforms, I didn't do this for simplicity).
Strangely enough, if I restrict the input to `uint8_t` clang doesn't generate
jump-table anymore, it would generate the following code instead:
testNaive:
mov eax, edi
add al, -33
cmp al, 94
setb al
cmp dil, 91
setne cl
cmp dil, 93
s
[llvm-bugs] [Bug 32954] -Wthread-safety try_acquire_capability is broken?
https://bugs.llvm.org/show_bug.cgi?id=32954 Aaron Ballman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Aaron Ballman --- Fixed in r329930. -- 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 37113] New: No -Wtautological-compare warning issued
https://bugs.llvm.org/show_bug.cgi?id=37113
Bug ID: 37113
Summary: No -Wtautological-compare warning issued
Product: clang
Version: 6.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: ri...@synopsys.com
CC: llvm-bugs@lists.llvm.org
For the following simple test case, clang fails to issue a
-Wtautological-compare warning. gcc 6.2 issues this warning.
If there was no pointer deference (and there was a self compare on a simple
int), then clang would issue the warning as expected. The pointed memory is not
volatile and clang -O1 optimizes away the two comparisons that would always
evaluate to false. So it is reasonable to expect that it should warn about them
as well.
struct Foo {
int a;
};
int cmp(const Foo* x, const Foo* y);
int cmp(const Foo* x, const Foo* y)
{
if (x->a < x->a) {
return -1;
} else if (y->a > y->a) {
return 1;
}
return 0;
}
--
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 7091 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-irce: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-irce
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 7091 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-irce: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-irce https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7091#c2 ClusterFuzz testcase 4935656305328128 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 6924 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-strength_reduce
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 6924 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-strength_reduce: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-strength_reduce https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6924#c2 ClusterFuzz testcase 4964208518103040 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 6920 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unroll
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 6920 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unroll https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6920#c2 ClusterFuzz testcase 5068383318966272 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 6941 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-licm: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-licm
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 6941 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-licm: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-licm https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6941#c2 ClusterFuzz testcase 5674965039841280 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 37114] New: Seg fault when running clang-format
https://bugs.llvm.org/show_bug.cgi?id=37114 Bug ID: 37114 Summary: Seg fault when running clang-format Product: clang Version: 6.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: t...@harness.io CC: dgre...@apple.com, llvm-bugs@lists.llvm.org i get the following dump: #0 0x00424e64 PrintStackTraceSignalHandler(void*) (/opt/clang/bin/clang-format+0x424e64) #1 0x00425146 SignalHandler(int) (/opt/clang/bin/clang-format+0x425146) #2 0x7faa6e276390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390) #3 0x004342e4 clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const (/opt/clang/bin/clang-format+0x4342e4) #4 0x00432e82 clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) (/opt/clang/bin/clang-format+0x432e82) #5 0x0048a91b clang::Rewriter::overwriteChangedFiles() (/opt/clang/bin/clang-format+0x48a91b) #6 0x00408beb clang::format::format(llvm::StringRef) (/opt/clang/bin/clang-format+0x408beb) #7 0x00406e85 main (/opt/clang/bin/clang-format+0x406e85) #8 0x7faa6d20e830 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20830) #9 0x00406949 _start (/opt/clang/bin/clang-format+0x406949) xargs: /opt/clang/bin/clang-format: terminated by signal 11 this is while running on AWS EC2 instance it's running on Amazon Linux AMI (ie centos) this is on Java code -- 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 6918 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-guard_widening: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-guard_widening
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 6918 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-guard_widening: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-guard_widening https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6918#c2 ClusterFuzz testcase 6022654722048000 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 7172 in oss-fuzz: llvm/llvm-demangle-fuzzer: Out-of-memory in llvm_llvm-demangle-fuzzer
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 7172 by ClusterFuzz-External: llvm/llvm-demangle-fuzzer: Out-of-memory in llvm_llvm-demangle-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7172#c2 ClusterFuzz testcase 6321313888075776 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 37097] COFF/section.test failing stage 2 check on clang-with-thin-lto-windows
https://bugs.llvm.org/show_bug.cgi?id=37097 Robbert Haarman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Robbert Haarman --- This is no longer happening. -- 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 37115] New: Clang miscompiles with -O0.
https://bugs.llvm.org/show_bug.cgi?id=37115
Bug ID: 37115
Summary: Clang miscompiles with -O0.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: vsevolod.livins...@frtk.ru
CC: llvm-bugs@lists.llvm.org
Clang miscompiles testcase with -O0.
Reproducer:
>$ cat repr.cpp
#include
struct struct_1 {
int a : 17;
bool b;
static int stat_memb;
};
int struct_1::stat_memb;
struct_1 struct_obj_1 = {42, false};
struct_1 struct_obj_2 = {42, false};
int var;
void tf_3_foo() {
struct_obj_2.stat_memb = unsigned(~0) > 0;
var = -((-9223372036854775807L - 1) * struct_obj_1.stat_memb /
(-9223372036854775807L - 1)) * struct_obj_1.a;
}
int main() {
tf_3_foo();
printf("%d\n", var);
}
Error:
>$ clang++ -O0 repr.cpp ; ./a.out
42
>$ clang++ -O1 repr.cpp ; ./a.out
-42
GCC also gives -42 as an answer.
LLVM version:
>$ clang++ -v
clang version 7.0.0 (trunk 329789)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /llvm/bin-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
--
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 36991] LLD-linked binary segfaults at runtime on alpine linux
https://bugs.llvm.org/show_bug.cgi?id=36991 Rui Ueyama changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Rui Ueyama --- My fix was submitted as https://reviews.llvm.org/rL329960. -- 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 28335] Correctly handle weak references to DSO symbols which do not appear in DT_NEEDED because of --as-needed
https://bugs.llvm.org/show_bug.cgi?id=28335 Rui Ueyama changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||r...@google.com --- Comment #3 from Rui Ueyama --- My fix was submitted as https://reviews.llvm.org/rL329960. -- 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 37116] New: arm64 apt repo
https://bugs.llvm.org/show_bug.cgi?id=37116 Bug ID: 37116 Summary: arm64 apt repo Product: Packaging Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: ibob...@gmail.com CC: llvm-bugs@lists.llvm.org There are apt repos for LLVM project: * https://apt.llvm.org/ Currently they only provide packages for i386 and amd64: * http://apt.llvm.org/stretch/dists/llvm-toolchain-stretch-6.0/main/ There are also pre-built binaries for arm64 (aarch64): * http://releases.llvm.org/6.0.0/clang+llvm-6.0.0-aarch64-linux-gnu.tar.xz I propose to provide arm64 apt packages 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] [Bug 37117] New: -Wunreachable-code warning not issued when a macro is used
https://bugs.llvm.org/show_bug.cgi?id=37117
Bug ID: 37117
Summary: -Wunreachable-code warning not issued when a macro is
used
Product: clang
Version: 6.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: ri...@synopsys.com
CC: llvm-bugs@lists.llvm.org
Reported by Martin Galvin on cfe-dev:
This code triggers the warning:
int main()
{
return 0;
int a = 42;
}
while this doesn't:
#define A 42
int main()
{
return 0;
int a = A;
}
This happens on clang++-6.0. I'm not using any options other than
-Wunreachable-code
--
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 37118] New: [Formatter/ObjC] BinPackArguments causes extra line breaks in blocks with protocol parameter types
https://bugs.llvm.org/show_bug.cgi?id=37118
Bug ID: 37118
Summary: [Formatter/ObjC] BinPackArguments causes extra line
breaks in blocks with protocol parameter types
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: da...@dzhang.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
The second parameter (b) in these examples should not be on the next line.
input.m:
- (void)method {
[self doSomething:^(BOOL a, id b, NSString *c)];
void (^blockName)(BOOL *a, id b, NSString *c);
}
$ clang-format -style='{BinPackArguments: false, ColumnLimit: 40}' clang-bug.m
- (void)method {
[self doSomething:^(BOOL a,
id
b,
NSString *c)];
void (^blockName)(BOOL *a,
id
b,
NSString *c);
}
$ clang-format --version
clang-format version 7.0.0 (tags/google/stable/2018-01-11)
--
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 37066] Allow selecting which XRay modes to link through flags
https://bugs.llvm.org/show_bug.cgi?id=37066 Dean Michael Berris changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Dean Michael Berris --- Fixed by r329772. -- 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 36926] Add a flag to disable emitting the custom event instrumentation points
https://bugs.llvm.org/show_bug.cgi?id=36926 Dean Michael Berris changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Dean Michael Berris --- Fixed by r329985. -- 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 32274] XRay should not use C++ standard libraries internally
https://bugs.llvm.org/show_bug.cgi?id=32274 Dean Michael Berris changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Dean Michael Berris --- Unfortunately, we're still relying on some C++ specific functionality, some of which are provided by libcxxabi, but I'd like to explore the possibility of removing those first/instead. This came up in a discussion with why we're failing to link C programs with XRay instrumentation. Reopening this bug so that we can address this in either the runtime, or even in Clang. -- 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
