[llvm-bugs] Issue 13244 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-earlycse: ASSERT: !FoundVal && "Key already in new map?"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-21 Type: Bug New issue 13244 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-earlycse: ASSERT: !FoundVal && "Key already in new map?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13244 Detailed report: https://oss-fuzz.com/testcase?key=5730570645012480 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-earlycse Fuzz target binary: llvm-opt-fuzzer--x86_64-earlycse Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !FoundVal && "Key already in new map?" llvm::DenseMapBasellvm::ScopedHashTableVal llvm::DenseMapBasellvm::ScopedHashTableVal Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5730570645012480 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40547, which changed state. Bug 40547 Summary: Clang fails to pass validation when compiled with gcc-9 in release build. https://bugs.llvm.org/show_bug.cgi?id=40547 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40547] Clang fails to pass validation when compiled with gcc-9 in release build.
https://bugs.llvm.org/show_bug.cgi?id=40547 sguel...@redhat.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from sguel...@redhat.com --- Patch merged, thanks Hans! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40470] CMake config checks lead to invalid output wasm
https://bugs.llvm.org/show_bug.cgi?id=40470 Sam Clegg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13243 in oss-fuzz: llvm/clang-fuzzer: Timeout in llvm_clang-fuzzer
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-21 Type: Bug New issue 13243 by ClusterFuzz-External: llvm/clang-fuzzer: Timeout in llvm_clang-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13243 Detailed report: https://oss-fuzz.com/testcase?key=5641829305810944 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: llvm_clang-fuzzer Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5641829305810944 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40797] New: Undefined reference with -fsanitize-coverage=trace-pc
https://bugs.llvm.org/show_bug.cgi?id=40797
Bug ID: 40797
Summary: Undefined reference with -fsanitize-coverage=trace-pc
Product: clang
Version: 7.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: drmin...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
I faced issue when compile with -fsanitize-coverage=trace-pc.
test for this:
cov.cc
#include
__attribute__((noinline))
void foo() { printf("foo\n"); }
int main(int argc, char **argv) {
if (argc == 2)
foo();
printf("main");
}
vmx@vmx-virtual-machine:~/Documents/clang$ clang++-7 -g cov.cc
-fsanitize=address -fsanitize-coverage=trace-pc -v
clang version 7.0.0-3~ubuntu0.18.04.1 (tags/RELEASE_700/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
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.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
"/usr/lib/llvm-7/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj
-mrelax-all -disable-free -disable-llvm-verifier -discard-value-names
-main-file-name cov.cc -mrelocation-model static -mthread-model posix
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -v -resource-dir
/usr/lib/llvm-7/lib/clang/7.0.0 -internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0
-internal-isystem
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward
-internal-isystem /usr/include/clang/7.0.0/include/ -internal-isystem
/usr/local/include -internal-isystem /usr/lib/llvm-7/lib/clang/7.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir /home/vmx/Documents/clang
-ferror-limit 19 -fmessage-length 210 -fsanitize-coverage-type=3
-fsanitize-coverage-trace-pc -fsanitize=address
-fsanitize-blacklist=/usr/lib/llvm-7/lib/clang/7.0.0/share/asan_blacklist.txt
-fsanitize-address-use-after-scope -fno-assume-sane-operator-new
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cov-a15c76.o -x c++ cov.cc -faddrsig
clang -cc1 version 7.0.0 based upon LLVM 7.0.0 default target
x86_64-pc-linux-gnu
ignoring nonexistent directory "/include"
ignoring duplicate directory
"/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0"
ignoring duplicate directory "/usr/include/clang/7.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward
/usr/include/clang/7.0.0/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
"/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o a.out
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crt1.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crti.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/crtbegin.o
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../..
-L/usr/lib/llvm-7/bin/../lib -L/lib -L/usr/lib --whole-archive
/usr/lib/llvm-7/lib/clang/7.0.0/lib/linux/libclang_rt.asan-x86_64.a
--no-whole-archive
--dynamic-list=/usr/lib/llvm-7/lib/clang/7.0.0/lib/linux/libclang_rt.asan-x86_64.a.syms
--whole-archive
/usr/lib/llvm-7/lib/clang/7.0.0/lib/linux/libclang_rt.asan_cxx-x86_64.a
--no-whole-archive
[llvm-bugs] [Bug 40796] New: -pthread should pass -lpthread to the linker
https://bugs.llvm.org/show_bug.cgi?id=40796 Bug ID: 40796 Summary: -pthread should pass -lpthread to the linker Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mh+l...@glandium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Apparently something changed in clang 9, that made -pthread not do anything during linkage, per https://gn.googlesource.com/gn/+/082fbe397d5217dc21b01c63c7f20eb6b77a3093%5E%21/#F0 : clang-9: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument] ld.lld: error: undefined symbol: pthread_create >>> referenced by worker_pool.cc >>> util/worker_pool.o:(WorkerPool::WorkerPool(unsigned long)) in archive gn_lib.a However, -pthread *is* meant to add -lpthread during linkage, per GCC documentation: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options -pthread Link with the POSIX threads library. This option is supported on GNU/Linux targets, most other Unix derivatives, and also on x86 Cygwin and MinGW targets. On some targets this option also sets flags for the preprocessor, so it should be used consistently for both compilation and linking. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40795] New: clang generates wrong debug information at -O3
https://bugs.llvm.org/show_bug.cgi?id=40795
Bug ID: 40795
Summary: clang generates wrong debug information at -O3
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: qrzh...@gatech.edu
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
It also affects clang 7.0.
The correct output should be "l_34 = -5".
$ clang-trunk -v
clang version 9.0.0 (trunk 354437)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ cat abc.c
volatile int a;
unsigned b = 6;
int main() {
int l_34 = -5;
5 >= b && (l_34 = 0, a);
optimize_me_not();
}
$ cat outer.c
optimize_me_not() {}
$ cat cmds
b 6
r
p l_34
kill
q
$ clang-trunk abc.c outer.c -g
$ lldb-trunk -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/absozero/projects/LLDB-testing/reduce/cmds'.
(lldb) b 6
Breakpoint 1: where = a.out`main + 76 at abc.c:6:3, address =
0x004004cc
(lldb) r
Process 2483 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004004cc a.out`main at abc.c:6:3
3int main() {
4 int l_34 = -5;
5 5 >= b && (l_34 = 0, a);
-> 6 optimize_me_not();
7}
Process 2483 launched: '/home/absozero/projects/LLDB-testing/reduce/a.out'
(x86_64)
(lldb) p l_34
(int) $0 = -5
(lldb) kill
Process 2483 exited with status = 9 (0x0009)
(lldb) q
$ clang-trunk abc.c outer.c -g -O3
$ lldb-trunk -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/absozero/projects/LLDB-testing/reduce/cmds'.
(lldb) b 6
Breakpoint 1: where = a.out`main + 16 at abc.c:6:3, address =
0x00400490
(lldb) r
Process 3094 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400490 a.out`main at abc.c:6:3
3int main() {
4 int l_34 = -5;
5 5 >= b && (l_34 = 0, a);
-> 6 optimize_me_not();
7}
Process 3094 launched: '/home/absozero/projects/LLDB-testing/reduce/a.out'
(x86_64)
(lldb) p l_34
(int) $0 = 0
(lldb) kill
Process 3094 exited with status = 9 (0x0009)
(lldb) q
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32433] [X86] Failure to use HADDPS for partial register result
https://bugs.llvm.org/show_bug.cgi?id=32433 Sanjay Patel changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Sanjay Patel --- Reopening because the change was reverted due to an LTO build failure and perf regressions: https://reviews.llvm.org/rL354434 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40787] New: [llvm-exegesis] All benchmarks of the same opcode should be within eps of eachanother.
https://bugs.llvm.org/show_bug.cgi?id=40787
Bug ID: 40787
Summary: [llvm-exegesis] All benchmarks of the same opcode
should be within eps of eachanother.
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: llvm-exegesis
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: clement.cour...@gmail.com, gchate...@google.com,
llvm-bugs@lists.llvm.org
A follow up for https://bugs.llvm.org/show_bug.cgi?id=40715
I'm not sure if this is working as intended or not, but the current clustering
code may still end up clustering together benchmark points that are different.
I.e. after clustering, given a cluster, the points within that cluster may
be more offset from each another than the `-analysis-epsilon=`.
This might be a bug in itself Is it?
If not, i believe i will need to introduce an early stabilization sweep,
i.e. go through all the points, create a [opcode]=>{p0, ...} mapping,
and then go through each opcode in that map, and if there is more than one
point for an opcode, verify that every combination (every 2 points)
of these points is `isNeighbour()`. If not, add all these points for
this opcode into a new unstable cluster.
Thus, the normal clustering logic will skip them.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40783] r316591 breaks x32
https://bugs.llvm.org/show_bug.cgi?id=40783 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from H.J. Lu --- Fixed by revision 354451. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40786] New: obj2yaml symbol output missing section index for SHN_ABS and SHN_COMMON symbols
https://bugs.llvm.org/show_bug.cgi?id=40786 Bug ID: 40786 Summary: obj2yaml symbol output missing section index for SHN_ABS and SHN_COMMON symbols Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org If you run obj2yaml on an object containing absolute and/or common symbols, the yaml output contains no section index for them, resulting in them being undefined symbols, if yaml2obj were run on the output. We should fix this! Example failing test: # RUN: yaml2obj %s > %t # RUN: obj2yaml %t | FileCheck %s # CHECK: Symbols: # CHECK-NEXT: Global: # CHECK-NEXT: - Name:absolute1 # CHECK-NEXT: Index: SHN_ABS<--- Missing # CHECK-NEXT: - Name:absolute2 # CHECK-NEXT: Index: SHN_ABS<--- Missing # CHECK-NEXT: - Name:common1 # CHECK-NEXT: Index: SHN_COMMON <--- Missing # CHECK-NEXT: - Name:common2 # CHECK-NEXT: Index: SHN_COMMON <--- Missing # CHECK-NEXT: - Name:valid_index # CHECK-NEXT: Section: .text !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_EXEC Machine: EM_X86_64 Sections: - Name: .text Type: SHT_PROGBITS Symbols: Global: - Name: absolute1 Index:SHN_ABS Value:0x1234 - Name: absolute2 Index:0xfff1 Value:0x4321 - Name: common1 Index:SHN_COMMON - Name: common2 Index:0xfff2 - Name: valid_index Index:0x1 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13091 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 13091 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13091#c3 ClusterFuzz testcase 5770217924329472 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13145 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::APValue::swap
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 13145 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::APValue::swap https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13145#c2 ClusterFuzz testcase 5724867062661120 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40789] New: for Microsoft compatibility, #include from stddef.h etc
https://bugs.llvm.org/show_bug.cgi?id=40789
Bug ID: 40789
Summary: for Microsoft compatibility, #include from
stddef.h etc
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: mib.bugzi...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I have received a dll from a 3rd party along with a header file. The .h file
compiles OK with the Microsoft compiler, but it fails with clang. This is
because the clang compiler uses a different version of stddef.h than the
Microsoft compiler. The Microsoft version brings in e.g. which
introduces a lot of names including Microsoft's file.
Of course I can add a #include to make the compile successful, but I'd like to
know if you would consider allowing modifications to the clang version so that
that change isn't necessary.
I could preprocess all the clang headers to find the other headers that should
be brought in. Microsoft headers are pretty complex so it's not immediately
obvious which #include's to include, for example their headers accomodate the
"RC" compiler, I assume we wouldn't want the includes specific to RC to be
added.
Here's an example,
clang -c struct.cpp
struct.cpp:9:31: error: unknown type name '_Out_opt_cap_'
virtual int QueryLastError(_Out_opt_cap_(cbErrMax) char szError[cbErrMax]) ;
^
struct.cpp:9:55: error: expected ')'
virtual int QueryLastError(_Out_opt_cap_(cbErrMax) char szError[cbErrMax]) ;
^
struct.cpp:9:30: note: to match this '('
virtual int QueryLastError(_Out_opt_cap_(cbErrMax) char szError[cbErrMax]) ;
^
2 errors generated.
ksh-3.2$ cat struct.cpp
// interface for error reporting
#include
enum Report_Consts {
cbErrMax = 1024,
};
typedef struct Report_Error {
virtual int QueryLastError(_Out_opt_cap_(cbErrMax) char szError[cbErrMax])
};
#endif
Report_Error;
Would you consider allowing changes like this,
diff --git a/lib/Headers/stddef.h b/lib/Headers/stddef.h
index 7354996711..686a79168d 100644
--- a/lib/Headers/stddef.h
+++ b/lib/Headers/stddef.h
@@ -34,6 +34,11 @@
#if !__has_feature(modules)
#define __STDDEF_H
#endif
+#if defined(_MSC_VER)
+#include
+#endif // defined(_MSC_VER)
--Melanie Blower
(I work for Intel on the C++ compiler)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13091 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Comment #2 on issue 13091 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13091#c2 ClusterFuzz has detected this issue as fixed in range 201902190429:201902200434. Detailed report: https://oss-fuzz.com/testcase?key=5770217924329472 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe22239ee0 Crash State: clang::Lexer::LexTokenInternal clang::Lexer::Lex clang::Preprocessor::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201812220356:201812230356 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201902190429:201902200434 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5770217924329472 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40788] New: Use section name for section symbol names in llvm-readobj
https://bugs.llvm.org/show_bug.cgi?id=40788 Bug ID: 40788 Summary: Use section name for section symbol names in llvm-readobj Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org llvm-readobj + llvm-readelf print an empty string for section symbols. This is technically correct, in the section symbols typically have no name, but it is not particularly useful and makes the symbol table dump harder to interpret (you have to lookup the section index and inspect the section header table to map the symbol to its corresponding section). This is similar to bug 39995, where section names are now being used for symbol names for ELF STT_SECTION symbols. However, whereas that bug brought llvm-nm closer to GNU nm's output, the same is not the case here. It is worth noting that GNU objdump's -t output also uses the section names for such symbols. I think we should do the same here. In all likelihood it won't hurt any parsers, since the name is at the end of the line, and would be an improvement over GNU readelf. I think we should do it for both GNU and LLVM style output as GNU style is more compact and more familiar to many developers. Current output: C:\llvm\llvm\test\tools\llvm-readobj> c:\llvm\build\debug\bin\llvm-readobj.exe "--symbols" "C:\llvm\llvm\test\tools\llvm-readobj/Inputs/relocs.obj.elf-x86_64" "--elf-output-style=GNU" Symbol table '.symtab' contains 6 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT3 3: 0 SECTION LOCAL DEFAULT4 4: 0 NOTYPE GLOBAL DEFAULT UND _GLOBAL_OFFSET_TABLE_ 5: 0 TLS GLOBAL DEFAULT UND sym Proposal: C:\llvm\llvm\test\tools\llvm-readobj> c:\llvm\build\debug\bin\llvm-readobj.exe "--symbols" "C:\llvm\llvm\test\tools\llvm-readobj/Inputs/relocs.obj.elf-x86_64" "--elf-output-style=GNU" Symbol table '.symtab' contains 6 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 .text 2: 0 SECTION LOCAL DEFAULT3 .data 3: 0 SECTION LOCAL DEFAULT4 .bss 4: 0 NOTYPE GLOBAL DEFAULT UND _GLOBAL_OFFSET_TABLE_ 5: 0 TLS GLOBAL DEFAULT UND sym -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13145 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::APValue::swap
Comment #1 on issue 13145 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::APValue::swap https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13145#c1 ClusterFuzz has detected this issue as fixed in range 201902190429:201902200434. Detailed report: https://oss-fuzz.com/testcase?key=5724867062661120 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe119b9f58 Crash State: clang::APValue::swap Evaluate IntExprEvaluator::VisitCastExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201902150428:201902160424 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201902190429:201902200434 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5724867062661120 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40790] New: Crash when compiling template specialization with auto return type
https://bugs.llvm.org/show_bug.cgi?id=40790
Bug ID: 40790
Summary: Crash when compiling template specialization with auto
return type
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: de...@ukr.net
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
At least the version 5.0 and all version upwards are affected.
Here is a small test case example:
template
T foo(int payload);
struct Bar
{ };
template <>
auto foo(int payload)
{
Bar result;
return result;
}
Yes, this code has an error but the compiler should emit an error message
instead of crashing.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40791] New: Crash in template code that
https://bugs.llvm.org/show_bug.cgi?id=40791 Bug ID: 40791 Summary: Crash in template code that Product: new-bugs Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dapa...@mozilla.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21496 --> https://bugs.llvm.org/attachment.cgi?id=21496=edit Build log with crash stack Unfortunately, I haven't been able to reproduce this crash with a small test case and it comes from building a "unified source file" (ie many files smooshed together) from the Firefox code base so its not small. I have isolated the crash to a method A that passes a method pointer P to another method B, where B's signature pulls apart the method's components (return type, class type, arguments). Method A is in a templated class's templated (specialized) inner-class. One of method A's templates is the type of the method-pointer P. Those are the properties that I would have guessed were relevant to the crash but, as I said, I can't seem to get a smaller version to crash. So I really have no idea what the cause is. I just know that removing these method calls eliminates the crash. In the attached source file, the method A's (they are two related methods) are on lines 1277373 and 1277382. The are called by the DEFINE_METHOD_DISPATCHER just below them and that macro is instantiated at line 1282214. >From the crash log: 0:56.32 Wrote crash dump file "C:\Users\DAVIDP~1\AppData\Local\Temp\clang-cl.exe-121290.dmp" 0:56.85 LLVMSymbolizer: error reading file: PDB Error: Unable to load PDB. Make sure the file exists and is readable. Calling loadDataForExe 0:56.85 LLVMSymbolizer: error reading file: PDB Error: Unable to load PDB. Make sure the file exists and is readable. Calling loadDataForExe 0:56.86 #0 0x7ff7f216ffe0 clang::CallExpr::getCallReturnType(class clang::ASTContext const &)const (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x266ffe0) 0:56.86 #1 0x7ff7f0caed0d clang::CodeGen::CodeGenFunction::EmitCheckedInBoundsGEP(class llvm::Value *,class llvm::ArrayRef,bool,bool,class clang::SourceLocation,class llvm::Twine const &) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x11aed0d) 0:56.86 #2 0x7ff7f0c9fc81 clang::CodeGen::CodeGenFunction::EmitScalarExpr(class clang::Expr const *,bool) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x119fc81) 0:56.86 #3 0x7ff7f0c5687c clang::CodeGen::CodeGenFunction::EmitReturnStmt(class clang::ReturnStmt const &) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x115687c) 0:56.86 #4 0x7ff7f0c53831 clang::CodeGen::CodeGenFunction::EmitStmt(class clang::Stmt const *,class llvm::ArrayRef) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x1153831) 0:56.86 #5 0x7ff7f0c5c595 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(class clang::CompoundStmt const &,bool,class clang::CodeGen::AggValueSlot) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x115c595) 0:56.86 #6 0x7ff7f0b895ce clang::CodeGen::CodeGenFunction::EmitFunctionBody(class clang::CodeGen::FunctionArgList &,class clang::Stmt const *) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x10895ce) 0:56.86 #7 0x7ff7f0b89e9f clang::CodeGen::CodeGenFunction::GenerateCode(class clang::GlobalDecl,class llvm::Function *,class clang::CodeGen::CGFunctionInfo const &) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x1089e9f) 0:56.86 #8 0x7ff7f0a2caab clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(class clang::GlobalDecl,class llvm::GlobalValue *) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0xf2caab) 0:56.86 #9 0x7ff7f0a272d7 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(class clang::GlobalDecl,class llvm::GlobalValue *) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0xf272d7) 0:56.86 #10 0x7ff7f0a1eed3 clang::CodeGen::CodeGenModule::EmitDeferred(void) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0xf1eed3) 0:56.86 #11 0x7ff7f0a1e1f1 clang::CodeGen::CodeGenModule::Release(void) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0xf1e1f1) 0:56.86 #12 0x7ff7f24f3655 clang::CreateLLVMCodeGen(class clang::DiagnosticsEngine &,class llvm::StringRef,class clang::HeaderSearchOptions const &,class clang::PreprocessorOptions const &,class clang::CodeGenOptions const &,class llvm::LLVMContext &,class clang::CoverageSourceInfo *) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x29f3655) 0:56.86 #13 0x7ff7f24f1854 clang::BackendConsumer::HandleTranslationUnit(class clang::ASTContext &) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x29f1854) 0:56.86 #14 0x7ff7f17802d4 clang::ParseAST(class clang::Sema &,bool,bool) (c:\Users\DAVIDP~1\MOZBUI~1\clang\bin\clang-cl.exe+0x1c802d4) 0:56.86 #15
[llvm-bugs] [Bug 40792] New: cannot convert initializer list argument to std::slice_array
https://bugs.llvm.org/show_bug.cgi?id=40792
Bug ID: 40792
Summary: cannot convert initializer list argument to
std::slice_array
Product: clang
Version: 8.0
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: y...@tsoft.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The test.c below fails in clang-8, but works with gcc-8.
It is natural that a slice array of equal size is initialized using the
initializer list.
It probably shouldn't fail, and implicitly use this operator: void
std::slice_array::operator=(const std::valarray& val_arr).
FreeBSD 11.2
Yuri
---test.cpp---
#include
void f() {
typedef std::valarray matrix;
matrix m;
m[std::slice(2, 3, 3)] = {0.,0.,0.};
}
---message.txt---
valarray-ilist.cpp:6:26: error: no viable overloaded '='
m[std::slice(2, 3, 3)] = {0.,0.,0.};
~~ ^ ~~
/usr/include/c++/v1/valarray:1258:24: note: candidate function not viable:
cannot convert initializer list argument to 'const
std::__1::slice_array'
const slice_array& operator=(const slice_array& __sa) const;
^
/usr/include/c++/v1/valarray:1261:10: note: candidate function not viable:
cannot convert initializer list argument to 'const
std::__1::slice_array::value_type'
(aka 'const double')
void operator=(const value_type& __x) const;
^
/usr/include/c++/v1/valarray:1165:5: note: candidate template ignored: couldn't
infer template argument '_Expr'
operator=(const _Expr& __v) const;
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40793] New: X86 ISel gets stuck in infinite loop
https://bugs.llvm.org/show_bug.cgi?id=40793 Bug ID: 40793 Summary: X86 ISel gets stuck in infinite loop Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: and...@scheidecker.net CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Created attachment 21498 --> https://bugs.llvm.org/attachment.cgi?id=21498=edit IR that triggers bug Using SVN revision 354401 (from 2019/02/19), llc gets stuck in a loop on the attached input, when run with the command-line: llc llvm-lock.ll -mcpu=skylake-avx512 Using llc from the LLVM 6.0 release does not get stuck in a loop. Running it with e.g. -mcpu=skylake also does not get stuck in a loop. Based on this, I've assumed this is an X86/AVX512 target specific bug. Passing -debug prints the following in a loop: Promoting t1036: i16 = and t46, Constant:i16<15> Creating new node: t1038: i32 = any_extend t46 Creating constant: t1039: i32 = Constant<15> Creating new node: t1040: i32 = and t1038, Constant:i32<15> Creating new node: t1041: i16 = truncate t1040 Replacing.1 t1036: i16 = and t46, Constant:i16<15> With: t1041: i16 = truncate t1040 and 0 other values Combining: t1037: i32 = srl Constant:i32<32733>, t1041 Creating new node: t1042: i16 = and t46, Constant:i16<15> Creating new node: t1043: i32 = srl Constant:i32<32733>, t1042 ... into: t1043: i32 = srl Constant:i32<32733>, t1042 Combining: t39: i32 = Constant<32733> Combining: t43: i64 = any_extend t1043 Combining: t1043: i32 = srl Constant:i32<32733>, t1042 Combining: t1042: i16 = and t46, Constant:i16<15> Breaking into the debugger shows this call stack: `anonymous namespace'::DAGCombiner::CombineTo `anonymous namespace'::DAGCombiner::CombineTo `anonymous namespace'::DAGCombiner::PromoteIntBinOp `anonymous namespace'::DAGCombiner::combine `anonymous namespace'::DAGCombiner::Run llvm::SelectionDAG::Combine llvm::SelectionDAGISel::CodeGenAndEmitDAG llvm::SelectionDAGISel::SelectBasicBlock llvm::SelectionDAGISel::SelectAllBasicBlocks llvm::SelectionDAGISel::runOnMachineFunction `anonymous namespace'::X86DAGToDAGISel::runOnMachineFunction llvm::MachineFunctionPass::runOnFunction llvm::FPPassManager::runOnFunction llvm::FPPassManager::runOnModule -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40472] error in backend: Prototypeless function used with conflicting signatures
https://bugs.llvm.org/show_bug.cgi?id=40472 Sam Clegg changed: 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40412] Unconvertable type leads to invalid WebAssembly
https://bugs.llvm.org/show_bug.cgi?id=40412 Sam Clegg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Sam Clegg --- Fixed in https://reviews.llvm.org/D57909 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40794] New: LLVM fence lowering is not supported
https://bugs.llvm.org/show_bug.cgi?id=40794 Bug ID: 40794 Summary: LLVM fence lowering is not supported Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: ahee...@gmail.com CC: llvm-bugs@lists.llvm.org LLVM's 'fence' instruction lowering is not supported in WebAssembly even with -mattr=+atomics option on. A CL (https://reviews.llvm.org/D50277) has been proposed, but we have not yet reached a decision on what should we lower them to. This is a tracking bug for this. Previous discussion thread: https://github.com/WebAssembly/tool-conventions/issues/59 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37436] Support for llvm-ar P modifier
https://bugs.llvm.org/show_bug.cgi?id=37436 Jordan Rupprecht changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||https://reviews.llvm.org/rL ||354044 Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13242 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-21 Type: Bug New issue 13242 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13242 Detailed report: https://oss-fuzz.com/testcase?key=5710927142322176 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: CastInst::castIsValid(Instruction::BitCast, C, DstTy) && "Invalid constantexpr b llvm::ConstantExpr::getBitCast FoldBitCast Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201802050757:201802060728 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5710927142322176 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40715] [llvm-exegesis] If the same instruction lies in multiple clusters, it's noise
https://bugs.llvm.org/show_bug.cgi?id=40715 Roman Lebedev changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||354441 Resolution|--- |FIXED --- Comment #5 from Roman Lebedev --- r354441, thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40511, which changed state. Bug 40511 Summary: [AArch64] Linux/name_to_handle_at.cc fails https://bugs.llvm.org/show_bug.cgi?id=40511 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40511] [AArch64] Linux/name_to_handle_at.cc fails
https://bugs.llvm.org/show_bug.cgi?id=40511 Diana Picus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Diana Picus --- Seems fine now, thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40785] New: Print unknown st_other value if present in GNU output
https://bugs.llvm.org/show_bug.cgi?id=40785 Bug ID: 40785 Summary: Print unknown st_other value if present in GNU output Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org llvm-readelf, when printing an unknown st_other value, simply prints "DEFAULT", and doesn't list the actual value, unlike readelf: C:\Work>readelf test.o --dyn-syms Symbol table '.dynsym' contains 2 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 NOTYPE LOCAL DEFAULT [: 4] UND other C:\Work>llvm-readelf test.o --dyn-syms Symbol table '.dynsym' contains 2 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 NOTYPE LOCAL DEFAULT UND other We can, and should do better, although I don't think we necessarily have to match GNU's output here, we should at least print the relevant value somehow. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13229 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !getMember(0)->mayWriteToMemory() && "Group should have been invalidated"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-02-20 Type: Bug New issue 13229 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !getMember(0)->mayWriteToMemory() && "Group should have been invalidated" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13229 Detailed report: https://oss-fuzz.com/testcase?key=5713358093811712 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !getMember(0)->mayWriteToMemory() && "Group should have been invalidated" llvm::LoopVectorizationCostModel::interleavedAccessCanBeWidened llvm::LoopVectorizationCostModel::setCostBasedWideningDecision Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=201810170227:20181623 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5713358093811712 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 need to contact the OSS-Fuzz team with a question, concern, or any other feedback, 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
