[llvm-bugs] [Bug 44260] New: Unreachable triggered when parsing DWARF V5 line table with unsupported FORM
https://bugs.llvm.org/show_bug.cgi?id=44260 Bug ID: 44260 Summary: Unreachable triggered when parsing DWARF V5 line table with unsupported FORM Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com I ran into this when writing some llvm-dwarfdump tests. If a DWARF V5 .debug_line table header includes a file name or directory entry type with an unsupported FORM value, and llvm-dwarfdump is used to dump the said line table, an llvm_unreachable is triggered when parsing that field. // example assembly .section .debug_line,"",@progbits .long .Lunit0_end - .Lunit0_begin # unit_length .Lunit0_begin: .short 5 ## version .byte 8 ## address_size .byte 0 ## segment_selector_size .long .Lheader0_end - .Lheader0_begin ## header_length .Lheader0_begin: .byte 1 ## minimum_instruction_length .byte 1 ## maximum_operations_per_instruction .byte 1 ## default_is_stmt .byte -5 ## line_base .byte 7 ## line_range .byte 13 ## opcode_base .byte 0, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 1 ## standard_opcode_lengths .byte 1 ## directory_entry_format_count .byte 0x1, 0x7F ## DW_LNCT_path, unknown form .byte 1 ## directories_count .byte 0 ## directory entry 0 .asciz "dir1/dir2" .byte 1 ## file_name_entry_format_count .byte 0x1, 0xB ## DW_LNCT_path, DW_FORM_string .byte 0x2, 0x5 ## DW_LNCT_directory_index, DW_FORM_data1 .byte 2 ## file_names_count .byte 0 ## file name entry 0 .asciz "file1.c" .byte 1 ## file name entry 1 .long 0x12345678 .Lheader0_end: .Lunit0_end: C:\Work> llvm-dwarfdump --debug-line test.o test.o: file format ELF64-x86-64 .debug_line contents: debug_line[0x] unsupported form UNREACHABLE executed at C:\llvm\llvm-project\llvm\lib\DebugInfo\DWARF\DWARFFormValue.cpp:350! The unreachable has an associated comment which seems to imply that the extractValue code was written for parsing .debug_info, and as such unsupported DW_FORM_* values are not handled (because they should be handled earlier). Clearly the code needs updating to allow for DW_FORM_* values coming from .debug_line. It's probably reasonable to abort parsing of the line table when an unsupported DW_FORM_* is hit, since it's impossible to know how to handle the file/directory table in this case. -- 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 35540] Clang crash for OpenCL local void** arithmetic
https://bugs.llvm.org/show_bug.cgi?id=35540
Sven van Haastregt changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||sven.vanhaastr...@arm.com
Resolution|--- |WORKSFORME
--- Comment #1 from Sven van Haastregt ---
Cannot reproduce on a recent master (f3e6a612326 ("[OpenCL] Handle address
space conversions for constexpr (PR44177)", 2019-12-09)).
It probably has been fixed in the meantime. Please reopen if you still hit the
issue.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44261] New: Print value to adjust by rather than final line value for verbose DW_LNS_advance_line
https://bugs.llvm.org/show_bug.cgi?id=44261 Bug ID: 44261 Summary: Print value to adjust by rather than final line value for verbose DW_LNS_advance_line Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-dwarfdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org Currently, when llvm-dwarfdump prints the debug line table with --verbose, any DW_LNS_advance_line opcodes are printed as: : 03 DW_LNS_advance_line () I think this should be changed to: : 03 DW_LNS_advance_line () This would be in keeping with the various operations that change the PC value, e.g. DW_LNS_advance_pc, which print the value to adjust by. This inconsistency can easily lead to confusion. Additionally, nothing really is lost: the next time a line is emitted using e.g. DW_LNS_copy or a special opcode, the new line value is printed there. Without this change, there is no direct way of seeing what is actually written in the line program, which is the point of verbose printing. -- 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 44262] New: variable templates in expressions cause lldb to crash
https://bugs.llvm.org/show_bug.cgi?id=44262 Bug ID: 44262 Summary: variable templates in expressions cause lldb to crash Product: lldb Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org (lldb) expr --top-level -- template T aaa = 1; (lldb) expr -- aaa lldb: clang/lib/AST/Type.cpp:2106: bool clang::Type::isConstantSizeType() const: Assertion `!isDependentType() && "This doesn't make sense for dependent types"' failed. -- 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 44263] New: false positive memory leak
https://bugs.llvm.org/show_bug.cgi?id=44263 Bug ID: 44263 Summary: false positive memory leak Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: rgerha...@hq.adiscon.com CC: dcough...@apple.com, llvm-bugs@lists.llvm.org I think I have found a false positive and am reporting it as suggested. Build report is here: http://ubuntu16.rsyslog.com/19-12-10_14-18-34/2019-12-10-141929-8930-1/report-611563.html#EndPath The same happens also with version 9. It was undetected by version 5 (the one I used previously). Not sure about 6 and 7. I and a co-worker double checked, we do not see anything that is wrong. Especially as the missing free is on the next line. The code is from the rsyslog project, related PR with all code at https://github.com/rsyslog/rsyslog/pull/4025 If it is not a false positive, a hint to what is wrong would be appreciated. Thx, Rainer -- 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 44264] New: m[ft]ppr instruction aliases not implemented
https://bugs.llvm.org/show_bug.cgi?id=44264 Bug ID: 44264 Summary: m[ft]ppr instruction aliases not implemented Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: colin.samp...@gmail.com CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com Created attachment 22924 --> https://bugs.llvm.org/attachment.cgi?id=22924&action=edit patch to implement aliases The mfppr and mtppr instruction aliases are not implemented in LLVM, but they are in GCC and xlC. m[ft]ppr32 and quite a number of other m[tf]spr aliases are also not implemented in LLVM. I stumbled across this when trying to use the `_mm_pause` function `clang/lib/Headers/ppc_wrappers/xmmintrin.h`, which uses these instructions in its implementation. The attached patch adds the instructions. AFAICT, the PPR was introduced in POWER6, so this patch checks for that, although it seems like a bit much just to implement an instruction alias. Another option would be to just change the implementation in `xmmintrin.h` to use `mfspr Rx,896`. Thoughts? -- 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 44124] ICF merges PLT entries and then merges wrongly conflated PLT callers
https://bugs.llvm.org/show_bug.cgi?id=44124 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Fangrui Song --- Fixed by D71163/llvmorg-10-init-11574-gcd0ab2428ff -- 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 6912] Possible QoI request: Warn when running the analyzer without the core checkers
https://bugs.llvm.org/show_bug.cgi?id=6912 Artem Dergachev changed: What|Removed |Added Status|NEW |RESOLVED CC||noqnoq...@gmail.com Resolution|--- |FIXED --- Comment #14 from Artem Dergachev --- Since https://reviews.llvm.org/D66042 scan-build automatically "silences" core checkers without disabling them when the user asks to disable 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] Issue 19315 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 OS-Linux Proj-llvm Reported-2019-12-10 Type: Bug New issue 19315 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBasebool>::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19315 Detailed Report: https://oss-fuzz.com/testcase?key=5831514587922432 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc13d37fa0 Crash State: clang::StmtVisitorBasebool>::Visit ComplexExprEvaluator::VisitBinaryOperator Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=201912090440 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5831514587922432 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing 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. Comments on individual Monorail issues are not monitored. -- 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 44265] New: LLD does not implement INPUT_SECTION_FLAGS, but parses them as if it does
https://bugs.llvm.org/show_bug.cgi?id=44265
Bug ID: 44265
Summary: LLD does not implement INPUT_SECTION_FLAGS, but parses
them as if it does
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: peter.sm...@linaro.org
CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org
LLD doesn't implement the INPUT_SECTION_FLAGS feature
(https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html)
yet it seems to parse INPUT_SECTION_FLAGS as if it were a file name, hence
ignoring it.
Consider the following example:
SECTIONS {
.foo : { INPUT_SECTION_FLAGS (SHF_WRITE) *(.foo) }
.foo2 : { INPUT_SECTION_FLAGS (!SHF_WRITE) *(.foo) }
}
with obj1.o containing:
.section .foo, "wa", %progbits
.global d1
d1:
.word 0
and obj2.o containing:
.section .foo, "a", %progbits
.global d2
d2:
.word 0
The INPUT_SECTION_FLAGS are supposed to constrain the match, so .foo from
obj1.o goes into OutputSection .foo, and .foo from obj2.o goes into
OutuptSection .foo2
This feature can be very useful to filter sections by flag when it is not known
what the names are. Until we support it we should fault INPUT_SECTION_FLAGS if
we see it as a filename in an InputSectionDescription.
--
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 44190] wrong code with #pragma pack(1)
https://bugs.llvm.org/show_bug.cgi?id=44190 yaxun@amd.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from yaxun@amd.com --- https://reviews.llvm.org/rG21b43885b81a6180e7231e575b5433202582f2fb -- 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 44266] New: Function resolution should follow the same rule in global context as function body.
https://bugs.llvm.org/show_bug.cgi?id=44266
Bug ID: 44266
Summary: Function resolution should follow the same rule in
global context as function body.
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: michael.hl...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 22925
--> https://bugs.llvm.org/attachment.cgi?id=22925&action=edit
resolution under function gets the correct host function
In the following sample code
```
__device__ float fn(int);
__host__ float fn(float);
float gvar = fn(1);
```
clang failed to find the correct candidate of `fn`. But, if we modify that to
resolve `fn` under a function body. The correct one is used.
```
__device__ float fn(int);
__host__ float fn(float);
float gfunc() {
return fn(1);
}
```
For function resolution in (host-side) global initializers, we should follow
the same rule as the one under a function body.
--
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 43753] incorrect fix-it for clang-diagnostic-documentation-deprecated-sync const functions
https://bugs.llvm.org/show_bug.cgi?id=43753 Mark de Wever changed: What|Removed |Added Status|CONFIRMED |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 44267] New: Escaping symbols written to pre-escaped stack regions
https://bugs.llvm.org/show_bug.cgi?id=44267
Bug ID: 44267
Summary: Escaping symbols written to pre-escaped stack regions
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: xazax@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
The problem in the title was partially solved in
https://github.com/llvm/llvm-project/commit/f3a28202ef58551db15818f8f51afd21e0f3e231
So we do not warn on:
void save_ptr(int **);
void delete_saved();
void store_to_escaped_region() {
int *p;
save_ptr(&p);
p = new int;
delete_saved();
} // no-warning
The reason why we decided to revert this change for now because we have not
found out a good way introduce this concept to the checkers. The pre-escape
happens in the analyzer core and the checker has no control over it. If the
checker is not interestd in a pre-escape it would need to do additional work on
each escape to check if the escaped symbol is originated from an
"uninteresting" pre-escaped memory region. In order to keep the checker API
simple we abandoned this solution for 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44268] New: Assertion `is() && "Invalid accessor called"' failed.
https://bugs.llvm.org/show_bug.cgi?id=44268
Bug ID: 44268
Summary: Assertion `is() && "Invalid accessor called"'
failed.
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: caij2...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 22928
--> https://bugs.llvm.org/attachment.cgi?id=22928&action=edit
Code to reproduce the issue.
We have been testing new LLVM version (4e8231b5cf0) on ChromeOS, and is
currently blocked by http://crbug.com/1032828. Essentially all our builds with
the new LLVM version being tested failed to build net-libs/libproxy:
libproxy-0.4.13-r2: clang-10:
/var/tmp/portage/sys-devel/llvm-10.0_pre370808_p20191029-r6/work/llvm-10.0_pre370808_p20191029/llvm/include/llvm/ADT/PointerUnion.h:195:
T llvm::PointerUnion::get() const [PTs = , T = const clang::Expr *]: Assertion `is() &&
"Invalid accessor called"' failed.
Call stack is as follows,
libproxy-0.4.13-r2: 1. ../../libproxy-0.4.13/libproxy/url.cpp:81:10
: current parser token
')'
libproxy-0.4.13-r2: 2. ../../libproxy-0.4.13/libproxy/url.cpp:78:63: parsing
function body 'copyaddr'
libproxy-0.4.13-r2: 3. ../../libproxy-0.4.13/libproxy/url.cpp:78:63: in
compound statement ('{}')
libproxy-0.4.13-r2: 4. ../../libproxy-0.4.13/libproxy/url.cpp:79:26: in
compound statement ('{}')
libproxy-0.4.13-r2: #0 0x0420f3a8
llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/clang-10+0x420f3a8)
libproxy-0.4.13-r2: #1 0x0420ce70 llvm::sys::RunSignalHandlers()
(/usr/bin/clang-10+0x420ce70)
libproxy-0.4.13-r2: #2 0x0420fa8f (/usr/bin/clang-10+0x420fa8f)
libproxy-0.4.13-r2: #3 0x7f5bd5c5f540 __restore_rt
(/lib64/libpthread.so.0+0x12540)
libproxy-0.4.13-r2: #4 0x7f5bd5153d31 raise (/lib64/libc.so.6+0x35d31)
libproxy-0.4.13-r2: #5 0x7f5bd5155a41 abort (/lib64/libc.so.6+0x37a41)
libproxy-0.4.13-r2: #6 0x7f5bd514c437 (/lib64/libc.so.6+0x2e437)
libproxy-0.4.13-r2: #7 0x7f5bd514c4e2 (/lib64/libc.so.6+0x2e4e2)
libproxy-0.4.13-r2: #8 0x06907e30 (/usr/bin/clang-10+0x6907e30)
libproxy-0.4.13-r2: #9 0x069513ad (/usr/bin/clang-10+0x69513ad)
libproxy-0.4.13-r2: #10 0x069015b9 (/usr/bin/clang-10+0x69015b9)
libproxy-0.4.13-r2: #11 0x06935295 (/usr/bin/clang-10+0x6935295)
libproxy-0.4.13-r2: #12 0x069015b9 (/usr/bin/clang-10+0x69015b9)
libproxy-0.4.13-r2: #13 0x06905328
clang::Expr::EvaluateWithSubstitution(clang::APValue&, clang::ASTContext&,
clang::FunctionDecl const*, llvm::ArrayRef, clang::Expr
const*) const (/usr/bin/clang-10+0x6905328)
libproxy-0.4.13-r2: #14 0x063aa2ad
clang::Sema::diagnoseArgDependentDiagnoseIfAttrs(clang::FunctionDecl const*,
clang::Expr const*, llvm::ArrayRef, clang::SourceLocation)
(/usr/bin/clang-10+0x63aa2ad)
libproxy-0.4.13-r2: #15 0x05e34acd
clang::Sema::checkCall(clang::NamedDecl*, clang::FunctionProtoType const*,
clang::Expr const*, llvm::ArrayRef, bool,
clang::SourceLocation, clang::SourceRange, clang::Sema::VariadicCallType)
(/usr/bin/clang-10+0x5e34acd)
libproxy-0.4.13-r2: #16 0x05e35d88
clang::Sema::CheckFunctionCall(clang::FunctionDecl*, clang::CallExpr*,
clang::FunctionProtoType const*) (/usr/bin/clang-10+0x5e35d88)
libproxy-0.4.13-r2: #17 0x06141b05
clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*,
clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation,
clang::Expr*, bool, clang::CallExpr::ADLCallKind) (/usr/bin/clang-10+0x6141b05)
libproxy-0.4.13-r2: #18 0x063be598 (/usr/bin/clang-10+0x63be598)
libproxy-0.4.13-r2: #19 0x063bdc61
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool,
bool) (/usr/bin/clang-10+0x63bdc61)
libproxy-0.4.13-r2: #20 0x0612468a
clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation,
llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool)
(/usr/bin/clang-10+0x612468a)
libproxy-0.4.13-r2: #21 0x0613fa28
clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation,
llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*)
(/usr/bin/clang-10+0x613fa28)
libproxy-0.4.13-r2: #22 0x05cdeb39
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) (/usr/bin/clang-10+0x5cdeb39)
libproxy-0.4.13-r2: #23 0x05ce0e6f
clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState, bool) (/usr/bin/clang-10+0x5ce0e6f)
libproxy-0.4.13-r2: #24 0x05cdda9b
clang::Parser::ParseCastExpression
[llvm-bugs] Issue 19317 in oss-fuzz: llvm:clang-fuzzer: Segv on unknown address in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-High Reported-2019-12-11 Type: Bug-Security New issue 19317 by ClusterFuzz-External: llvm:clang-fuzzer: Segv on unknown address in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19317 Detailed Report: https://oss-fuzz.com/testcase?key=5639537548328960 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Segv on unknown address Crash Address: Crash State: llvm::llvm_unreachable_internal clang::Sema::ActOnComment ActionCommentHandler::HandleComment Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201911200438:201911230451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5639537548328960 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing 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. Comments on individual Monorail issues are not monitored. -- 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 44269] New: please backport https://reviews.llvm.org/D71302 to 9.x
https://bugs.llvm.org/show_bug.cgi?id=44269 Bug ID: 44269 Summary: please backport https://reviews.llvm.org/D71302 to 9.x Product: clang Version: 9.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Tooling Assignee: unassignedclangb...@nondot.org Reporter: raj.k...@gmail.com CC: llvm-bugs@lists.llvm.org This patch enabled building multilib clang SDKs -- 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 44270] New: clang 9.0.0 crashes with -fopenmp
https://bugs.llvm.org/show_bug.cgi?id=44270 Bug ID: 44270 Summary: clang 9.0.0 crashes with -fopenmp Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: igor.shevche...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 22929 --> https://bugs.llvm.org/attachment.cgi?id=22929&action=edit code sample clang 9.0.0 crashes when trying to compile pytorch-dev checkout as of 10/Dec/2019. Trimmed down to a very simple case, see attachment. cli: clang++ f2.cc -of2 -fopenmp -- 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
