[llvm-bugs] [Bug 42910] New: Make dwarf assembly output more symbolic == editable
https://bugs.llvm.org/show_bug.cgi?id=42910 Bug ID: 42910 Summary: Make dwarf assembly output more symbolic == editable Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org, r...@google.com Currently, we go out of our way to print all constants in the dwarf we emit as literal constants. This probably speeds up codegen, but it probably hurts the readability, and definitely hurts editability (e.g., for producing test cases with "weird" dwarf for lldb or other tools) of the generated dwarf. Here's a non-exhaustive list of things we could do (probably guarded by -fverbose-asm) to improve this. It's roughly ordered according to the impact I estimate the changes would have on the readability/editability of the generated dwarf: - make all DIE cross-references in the debug_info section symbolic (e.g. from a variable DIE to it's type). Currently, we just emit these as integral constants, which is a problem, because pretty much any change to the debug info will upset these offsets. However, if these were emitted as something like ``` .byte 2 # Abbrev [2] 0x1e:0x15 DW_TAG_variable .long .Ltype47-.Lcu_start # DW_AT_type ... .Ltype47: .byte 3 # Abbrev [3] 0x33:0x7 DW_TAG_base_type ... ``` then one could freely add/remove dies or attributes and the references would remain valid. - make references from debug_info -> debug_abbrev symbolic. When adding or removing an attribute, one needs to make coordinated changes in the the abbreviation as well as in all DIEs that reference that abbreviation. This would make it easier to find all of them and jump between them. This could look something like: .section .debug_abbrev .set .Labbrev_DW_TAG_variable0, 0 .byte .Labbrev_DW_TAG_variable0 ... .section .debug_info .uleb128 .Labbrev_DW_TAG_variable0 - make all DWARF5 indexed section references (debug_str_offsets, etc.) symbolic. Ironically, these were introduced precisely to reduce the overhead of symbolic references in previous dwarf versions. However, they do make it hard to figure out what a particular (e.g.) DW_AT_name refers to as they show up as just a ".byte". This could work in a manner similar to .debug_abbrev above, but it is a lower priority because DWARF5 can be turned off. :) -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42907, which changed state. Bug 42907 Summary: wasm-ld crashes with both --shared-memory and --relocatable https://bugs.llvm.org/show_bug.cgi?id=42907 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 42907] wasm-ld crashes with both --shared-memory and --relocatable
https://bugs.llvm.org/show_bug.cgi?id=42907 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED CC||h...@chromium.org Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- Merged in r368137. 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 42899] X86MCCodeEmitter crashes when encoding a VPERMIL2P (XOP) with an invalid immediate
https://bugs.llvm.org/show_bug.cgi?id=42899 Andrea Di Biagio changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrea Di Biagio --- Thanks Craig! -- 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 42911] New: llvm\include\llvm\Support\Alignment.h(314) : warning C4723: potential divide by 0
https://bugs.llvm.org/show_bug.cgi?id=42911 Bug ID: 42911 Summary: llvm\include\llvm\Support\Alignment.h(314) : warning C4723: potential divide by 0 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: gchate...@google.com, llvm-bugs@lists.llvm.org [132/26/743/900] Building CXX object unittests\Support\CMakeFiles\SupportTests.dir\AlignmentTest.cpp.obj E:\llvm\llvm\include\llvm\Support\Alignment.h(314) : warning C4723: potential divide by 0 We're seeing this warning in MSVC llvm builds now, preventing us enabling Werror -- 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 42912] New: riscv inline assembly compilation failure
https://bugs.llvm.org/show_bug.cgi?id=42912
Bug ID: 42912
Summary: riscv inline assembly compilation failure
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: ronen.h...@wdc.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
riscv inline assembly input operand failure for the following code:
#define M_SET_ENTRY(func) asm volatile ("la x31, %0" : : "i"(func) : );
void my_func(void)
{
/*
* some code here
*/
}
void some_func(void)
{
/*
* some code here
*/
M_SET_ENTRY(my_func);
}
The failure I get:
./clang -o test.o -c -Os -ffunction-sections -fdata-sections -Wall -c
-fno-builtin-printf -include sys/cdefs.h -mabi=ilp32 -g3 -gdwarf-2
-march=rv32imac --gcc-toolchain=/home/work/bld-rv-linux-32/
--sysroot=/home/work/bld-rv-linux-32/riscv32-unknown-elf/ test.c
test.c:105:4: error: invalid operand in inline asm: 'la x31, $0'
M_SET_ENTRY(my_func);
^
test.c:91:41: note: expanded from macro 'M_SET_ENTRY'
#define M_SET_ENTRY(func) asm volatile ("la x31, %0" : : "i"(func) : );
^
test.c:105:4: error: unknown operand
test.c:91:41: note: expanded from macro 'M_SET_ENTRY'
#define M_SET_ENTRY(func) asm volatile ("la x31, %0" : : "i"(func) : );
^
:1:10: note: instantiated into assembly here
la x31,
^
2 errors generated.
--
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 18363] clang crashes on valid code at -O0 with -ftrapv (affecting all clang versions)
https://bugs.llvm.org/show_bug.cgi?id=18363 John Brawn changed: What|Removed |Added Resolution|--- |FIXED CC||john.br...@arm.com Status|REOPENED|RESOLVED --- Comment #7 from John Brawn --- It looks like this has been fixed since clang 3.8.0. We now consistently give no error at any optimization level (with or without -ftrapv). -- 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 16287 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Out-of-memory in llvm_llvm-isel-fuzzer--x86_64-O2
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 Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-08-07 Type: Bug New issue 16287 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: Out-of-memory in llvm_llvm-isel-fuzzer--x86_64-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16287 Detailed report: https://oss-fuzz.com/testcase?key=5658786148122624 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-isel-fuzzer--x86_64-O2 Sanitizer: memory (MSAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5658786148122624 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. -- 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 18374] Loop reroller fails to reroll loop with variable upper bound on 64-bit targets
https://bugs.llvm.org/show_bug.cgi?id=18374 John Brawn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||john.br...@arm.com --- Comment #10 from John Brawn --- This was fixed in LLVM 3.6.0, I think by https://llvm.org/svn/llvm-project/llvm/trunk@198425. -- 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 42909] X86ISelLowering.cpp:7692: llvm::SDValue EltsFromConsecutiveLoads(...): Assertion `EltBaseVT.getSizeInBits() == EltBaseVT.getStoreSizeInBits() && "Register/Memory size mismatch"
https://bugs.llvm.org/show_bug.cgi?id=42909 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||r368165 --- Comment #2 from Simon Pilgrim --- Fixed in rL368165 -- 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 42914] New: [AST] AutoType within AutoTypeLoc is missing deduced type.
https://bugs.llvm.org/show_bug.cgi?id=42914 Bug ID: 42914 Summary: [AST] AutoType within AutoTypeLoc is missing deduced type. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: sammcc...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk the program `auto x = 4;` has an AST that looks like: VarDecl type=T1 - typeloc type=T2 - integerliteral T1 is correctly an auto type that wraps int. However T2 is undeduced: it's ASTContext::getAutoDeductType(). This irregularity makes it harder/slower to write tools that (e.g.) care what an `auto` under the cursor expands to. -- 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 42915] New: ICE on lambdas returning lambdas 3 deep, when using move or fwd ref
https://bugs.llvm.org/show_bug.cgi?id=42915 Bug ID: 42915 Summary: ICE on lambdas returning lambdas 3 deep, when using move or fwd ref Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: llvmbugbj...@fahller.se CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22349 --> https://bugs.llvm.org/attachment.cgi?id=22349&action=edit Example code causing ICE The attached file crashes clang++-8.0.0, and trunk (367966). The crashes are on the lines with a comment '// E'. If those lines are commented out, it compiles. There are two ways to make it compile. Remove '= std::move(function)' under the comment '// 1' or remove the forwarding reference '&&' under the comment '// 2' godbolt link: https://gcc.godbolt.org/z/DXqN06 -- 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 42916] New: [clang-format] Possibility to narrow list of languages to guess from
https://bugs.llvm.org/show_bug.cgi?id=42916 Bug ID: 42916 Summary: [clang-format] Possibility to narrow list of languages to guess from Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: kyrylo.bohdane...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org So the idea is to have possibility to help clang-format with guessing language of a file by narrowing possible options list. For example, if a project (a directory) contains .clang-format and -style=file was selected, then limit options only to the languages described in that file. This could help in cases like 37433, 39216: if there is no configuration for ObjC, then do not consider ObjC. Other option would be to have an option in the configuration file and CLI to explicitly define a set of languages to choose from. This is pretty similar to what was proposed in 36468. -- 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 18082] Assert triggered by DependenceAnalysis
https://bugs.llvm.org/show_bug.cgi?id=18082 John Brawn changed: What|Removed |Added Status|NEW |RESOLVED CC||john.br...@arm.com Resolution|--- |FIXED --- Comment #2 from John Brawn --- Assert does not trigger in LLVM 3.8.0 and later. -- 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 42917] New: Missed vectorization for loop with MAX
https://bugs.llvm.org/show_bug.cgi?id=42917
Bug ID: 42917
Summary: Missed vectorization for loop with MAX
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
#define max(a,b) (((a) > (b))? (a) : (b))
unsigned p[512];
void vmax() {
for (int i = 0; i < 512; i+=2) {
p[i] = max(p[i], p[i+1]);
}
}
int main() {
for (int i = 0; i < 1000; ++i) {
vmax();
}
}
icc -O3 vmax.c -march=haswell
0m0,096s
clang -O3 vmax.c -march=haswell
0m1,518s
clang with #pragma clang loop vectorize(enable) interleave(enable)
0m1,096s
https://godbolt.org/z/5bjKUI
--
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 22813] AARCH32 asm("b %0":: "i" (3)) should issue a warning
https://bugs.llvm.org/show_bug.cgi?id=22813 John Brawn changed: What|Removed |Added CC||john.br...@arm.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from John Brawn --- Since LLVM 4.0.0 we now correctly give an error (for the non-multiple-of-4 in arm and non-multiple-of-2 in thumb). -- 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 42918] New: libc++ passes invalid values to pthread_equal
https://bugs.llvm.org/show_bug.cgi?id=42918 Bug ID: 42918 Summary: libc++ passes invalid values to pthread_equal Product: libc++ Version: unspecified Hardware: All OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: mclow.li...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com [ received from Ed Maste at FreeBSD ] We just had a FreeBSD bug submitted for a failure arising from libc++'s use of pthread_equal. FreeBSD's pthread_equal stub implementation (used in non-threaded programs) returns true unconditionally, since a non-threaded program cannot have two different threads. However, std::thread::id defines a special value that should not equal any real thread, and this is may be passed to pthread_equal. See FreeBSD PR 239550 for more details, and PR 239038 for the user-facing issue that prompted this. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239550 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239038 Now the most expedient fix is probably for us to make pthread_equal somewhat less of a stub, but for correctness it seems __libcpp_thread_id_equal would need to check for libc++'s special value before calling pthread_equal. -- 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 11593 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::DWARFFormValue::dump
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #7 on issue 11593 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Heap-buffer-overflow in llvm::DWARFFormValue::dump https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11593#c7 ClusterFuzz testcase 5634286556807168 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201908060313:201908070326 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 16128 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 16128 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16128#c1 ClusterFuzz testcase 5698535701348352 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201908060313:201908070326 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 14795 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_rotate: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #2 on issue 14795 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-loop_rotate: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14795#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37950] ExecutionContext::GetByteOrder() always returns endian::InlHostByteOrder()
https://bugs.llvm.org/show_bug.cgi?id=37950 Jonas Devlieghere changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED CC||jdevliegh...@apple.com --- Comment #5 from Jonas Devlieghere --- Fixed in r368181 -- 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 42919] New: Feature request: Two different indentation width options, one for code, one for pre-processor directives
https://bugs.llvm.org/show_bug.cgi?id=42919 Bug ID: 42919 Summary: Feature request: Two different indentation width options, one for code, one for pre-processor directives Product: clang Version: unspecified Hardware: All OS: All Status: NEW Keywords: missing-feature, new-feature Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: sebast...@pipping.org CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org It seems like option "IndentWidth" effects both C/C++ code indentation width as well as pre-processor indentation width. What I have seen a few times is that pre-processor indentation uses a single space per level while the C/C++ code in the same file uses 2 or 4 spaces. "IndentWidth" seems to affect both widths which also means that pre-processor code will look very noise when "IndentWidth" is more than 2. So it would be great to have two options, "IndentWidth" and a new one "IndentWidthPP"(?), thinking of existing "IndentPPDirectives". Would that be possible? Thanks in advance! -- 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 42920] New: LLDB fails to evaluate expression with template class type
https://bugs.llvm.org/show_bug.cgi?id=42920
Bug ID: 42920
Summary: LLDB fails to evaluate expression with template class
type
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: sfunkenhau...@google.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
LLDB fails to evaluate expressions with template class types.
Simple example:
template class foo
{
uint32_t data;
};
foo test;
int main() {
return 0;
}
I set a breakpoint on main and try to evaluate the following expression:
(lldb) p sizeof(foo)
error: implicit instantiation of undefined template 'foo'
template is declared here
The debug information is available (It's not being optimized out), and printing
'test' works just fine:
$ readelf --debug-dump a.out | grep foo
<41> DW_AT_name: (indirect string, offset: 0xa): foo
<49> DW_AT_name: (indirect string, offset: 0x0): foo
3f foo
Quoting Jim Ingham from a discussion on lldb-dev@
"LLDB uses clang as its expression parser, which when it sees foo
apparently wants to find a decl called "foo" first, which we don't really have
in the abstract."
--
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 42921] New: FileCheck linking with Z3 despite -DCLANG_ANALYZER_ENABLE_Z3_SOLVER=OFF
https://bugs.llvm.org/show_bug.cgi?id=42921 Bug ID: 42921 Summary: FileCheck linking with Z3 despite -DCLANG_ANALYZER_ENABLE_Z3_SOLVER=OFF Product: Build scripts Version: 9.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: bro...@freebsd.org CC: llvm-bugs@lists.llvm.org In LLVM 8.0.0, support was added for Z3. In the FreeBSD port (think package) we added -DCLANG_ANALYZER_ENABLE_Z3_SOLVER=OFF to the cmake arguments list to avoid requiring it. Somewhere between the 8.0 and 9.0 branch, that stopped being sufficient and libz3 is being found and FileCheck is being linked to it. On some of our platforms where our base compiler is still an ancient GCC, this is posing a bootstrapping challenge. Here's an example ldd output (it seems to me that FileCheck may simply be being overlinked): $ ldd work/stage/usr/local/bin/FileCheck90 work/stage/usr/local/bin/FileCheck90: libthr.so.3 => /lib/libthr.so.3 (0x80089d000) libz.so.6 => /lib/libz.so.6 (0x800ac5000) librt.so.1 => /usr/lib/librt.so.1 (0x800cdd000) libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x800ee3000) libncurses.so.8 => /lib/libncurses.so.8 (0x8010e6000) libm.so.5 => /lib/libm.so.5 (0x80133b000) libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80160) libc++.so.1 => /usr/lib/libc++.so.1 (0x802a9c000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x802d6a000) libc.so.7 => /lib/libc.so.7 (0x802f89000) libelf.so.2 => /lib/libelf.so.2 (0x803345000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80355c000) -- 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 42922] New: [X86] Cmov converter pass sinks volatile loads
https://bugs.llvm.org/show_bug.cgi?id=42922 Bug ID: 42922 Summary: [X86] Cmov converter pass sinks volatile loads Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com When the cmov converter pass expands a volatile load that has been folded with a cmov, it places the load only on the false path of the created control flow. But a volatile load should be executed unconditionally. The original cmov instruction would have always executed the load. -- 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 42923] New: conflicting types error when using '_com_ptr_t' on clang 9.0 RC
https://bugs.llvm.org/show_bug.cgi?id=42923
Bug ID: 42923
Summary: conflicting types error when using '_com_ptr_t' on
clang 9.0 RC
Product: clang
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: release blocker
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zachary.hen...@microsoft.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
clang 9.0 RC built with msvc version 19.22.27905 for x64. The attached example
compiles fine on clang 8.0.1 and on msvc.
An odd thing that I noticed is that -std=c++14 works fine, it's only -std=c++17
that causes these errors.
I've attached a fully preprocessed file in case an msvc installation & clang-cl
aren't handy. Run clang -c -Wno-everything -std=c++17 min_repro.cpp
D:\>clang -c -Wno-everything -std=c++17 D:\temp\min_repro.cpp
D:\temp\min_repro.cpp:67792:16: error: conflicting types for '_com_ptr_t'
template<> _com_ptr_t(Interface* pInterface) throw()
^
D:\temp\min_repro.cpp:68735:13: note: in instantiation of template class
'_com_ptr_t<_com_IIID >' requested here
IUnknownPtr Foo() {
^
D:\temp\min_repro.cpp:67792:16: note: previous declaration is here
template<> _com_ptr_t(Interface* pInterface) throw()
^
D:\temp\min_repro.cpp:67865:28: error: conflicting types for 'operator='
template<> _com_ptr_t& operator=(Interface* pInterface) throw()
^
D:\temp\min_repro.cpp:67865:28: note: previous declaration is here
D:\temp\min_repro.cpp:68011:21: error: conflicting types for 'operator=='
template<> bool operator==(const _com_ptr_t& p) const throw()
^
D:\temp\min_repro.cpp:68011:21: note: previous declaration is here
3 errors generated.
Optionally if an msvc command prompt is available:
D:\>type repro.cpp
#include
IUnknownPtr Foo() {
return nullptr;
}
D:\>clang-cl.exe -c -std:c++17 -TP -W0 repro.cpp
** Same Errors
--
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 42924] New: Address Sanitizer compilation time regression
https://bugs.llvm.org/show_bug.cgi?id=42924 Bug ID: 42924 Summary: Address Sanitizer compilation time regression Product: new-bugs Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ch...@detrino.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I have a large TU that used to take 8 minutes to compile with Clang 8.0 and now takes 1 hour and 20 minutes with Clang 9.0 RC1 when using -fsanitize=address. Using the new -ftime-trace flag showed that most of the time was going towards AddressSanitizerFunctionPass which is taking ~40ms for each function. As this is being compiled with -O1 nothing is being inlined and that 40ms times number of functions is adding up to more than an hour. Further profiling showed that all the time is being spent in memmove for copying a GlobalsMetadata type on the following line: https://github.com/llvm/llvm-project/blob/7f7ef0208b57a4d253cd8b07053460f40ad7cbc8/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp#L581 Git blame on that line points to https://reviews.llvm.org/D56470 and it has some discussion on copying the GlobalsMD struct. -- 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 42925] New: Assertion Failure ScalarEvolutionExpander.cpp:80: `SE.DT.dominates(Ret, &*BIP)' failed
https://bugs.llvm.org/show_bug.cgi?id=42925
Bug ID: 42925
Summary: Assertion Failure ScalarEvolutionExpander.cpp:80:
`SE.DT.dominates(Ret, &*BIP)' failed
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: warren_ris...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Created attachment 22355
--> https://bugs.llvm.org/attachment.cgi?id=22355&action=edit
reduced test-case
The attached test-case hits an assertion failure in Induction Variable
Simplification, when optimized at -O1:
$ opt -O1 test.ll -S -o -
opt: /llvm/lib/Analysis/ScalarEvolutionExpander.cpp:80:
llvm::Value* llvm::SCEVExpander::ReuseOrCreateCast(
llvm::Value*, llvm::Type*, llvm::Instruction::CastOps,
llvm::BasicBlock::iterator):
Assertion `SE.DT.dominates(Ret, &*BIP)' failed.
Stack dump:
0. Program arguments: opt -O1 test.ll -S -o -
1. Running pass 'CallGraph Pass Manager' on module 'test.ll'.
2. Running pass 'Loop Pass Manager' on function '@foo'
3. Running pass 'Induction Variable Simplification' on basic block '%do.body'
...
$
Bisecting shows that this problem first appeared with r320700, although that's
a valid commit, and it's clear that it just exposed a bug that was latent. It
still happens with ToT (tested with r368100).
FTR, the IR of the test-case contains code that clearly would deref a nullptr
at run-time if it were to be executed. Specifically, it contains:
define void @foo(i8* %arg) {
entry:
%stack_var = alloca i32, align 4
br label %do.body
do.body: ; preds = %do.body, %entry
%tmp3.0 = phi i32 [ 0, %entry ], [ %tmp2, %do.body ]
%tmp4.0 = phi i8* [ null, %entry ], [ %add.ptr, %do.body ]
%tmp1 = load i8, i8* %tmp4.0, align 1
...
}
I haven't been able to come up with a crashing test-case that's "clean" (in the
sense it does not have this nullptr deref problem). So maybe it's rooted in
that. For reference, the original test-case prior to reducing, had a formal
argument feeding into that PHI node in the definition of the full function,
rather than an explicit null. The problem as reported by the customer only
happened when LTO was on, and cross-module inlining exposed it. I tried
analyzing the callers in the original bitcode, to see whether I could determine
if a nullptr could be deduced to reach a call-site (and so there would be
Undefined Behavior at run-time), but I wasn't able to figure that out. My
guess is that that's what's happening. Regardless, of course a compile-time
crash isn't how we want to handle Undefined 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42832] -Wpessimizing-move and -Wredundant-move are applicable only when returned expression is id-expression
https://bugs.llvm.org/show_bug.cgi?id=42832 rtr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from rtr...@google.com --- This is fixed in r368237. The new fix-it will now suggest removing the initializer list braces along with the std::move call. -- 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 42926] New: Merge r366513 into 9.0
https://bugs.llvm.org/show_bug.cgi?id=42926 Bug ID: 42926 Summary: Merge r366513 into 9.0 Product: lldb Version: 9.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: h...@chromium.org Reporter: smee...@fb.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org, nat...@lanza.io Blocks: 42474 This fixes cross-compiling LLDB on 9.0. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=42474 [Bug 42474] [meta] 9.0.0 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42886] Add --strip-sections to llvm-strip
https://bugs.llvm.org/show_bug.cgi?id=42886 Wolfgang Pieb changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Wolfgang Pieb --- Implemented with r368241. -- 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 25744] Linux build breaks when both python 2 and python 3 are installed
https://bugs.llvm.org/show_bug.cgi?id=25744 Bug 25744 depends on bug 25866, which changed state. Bug 25866 Summary: Gentoo Linux build breaks in some scenarios when both Python 2 and Python 3 are present https://bugs.llvm.org/show_bug.cgi?id=25866 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- 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 25866] Gentoo Linux build breaks in some scenarios when both Python 2 and Python 3 are present
https://bugs.llvm.org/show_bug.cgi?id=25866 Jonas Devlieghere changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME CC||jdevliegh...@apple.com --- Comment #1 from Jonas Devlieghere --- LLDB is now fully compatible with Python 2 and Python 3, as well as SWIG 2 and later. -- 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 39459] Enum class variables can't be used as function arguments
https://bugs.llvm.org/show_bug.cgi?id=39459
Jonas Devlieghere changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #4 from Jonas Devlieghere ---
Seems like this is fixed.
$ lldb /tmp/a.out
(lldb) target create "/tmp/a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) b /breakpoint/
Breakpoint 1: where = a.out`main + 14 at main.cpp:11:12, address =
0x00010f9e
(lldb) r
Process 37979 launched: '/tmp/a.out' (x86_64)
Process 37979 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010f9e a.out`main at main.cpp:11:12
8
9int main() {
10 Foo foo = Foo::a;
-> 11 auto r = UseFoo(foo); // breakpoint
12 }
(lldb) p UseFoo(Foo::b)
(bool) $0 = true
(lldb) p UseFoo((Foo)Foo::b)
(bool) $1 = true
--
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 24828] test events: add "announce all tests that will run"
https://bugs.llvm.org/show_bug.cgi?id=24828 Jonas Devlieghere changed: What|Removed |Added CC||jdevliegh...@apple.com 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 16786] LIBRARY_PATH precedence
https://bugs.llvm.org/show_bug.cgi?id=16786 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Fangrui Song --- Fixed by https://reviews.llvm.org/D65880 r368245 -- 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 42927] New: clang-9.0.0-rc1 lit test failures due to spurious inreg added to function arguments
https://bugs.llvm.org/show_bug.cgi?id=42927
Bug ID: 42927
Summary: clang-9.0.0-rc1 lit test failures due to spurious
inreg added to function arguments
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: tstel...@redhat.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Blocks: 42474
I'm seeing a lot of lit test failures in the 9.0.1-rc1 release that look like
the one below. The test are failing because function arguments have the inreg
when the test wasn't expecting it. I think this may have something to do with
building with CLANG_LINK_CLANG_DYLIB=ON, but I'm still investigating this.
TEST 'Clang :: Sema/libbuiltins-ctype-powerpc64.c' FAILED
Script:
--
: 'RUN: at line 1'; /builddir/build/BUILD/cfe-9.0.0rc1.src/_build/bin/clang
-cc1 -internal-isystem
/builddir/build/BUILD/cfe-9.0.0rc1.src/_build/lib64/clang/9.0.0/include
-nostdsysteminc -triple powerpc64-unknown-linux-gnu -emit-llvm <
/builddir/build/BUILD/cfe-9.0.0rc1.src/test/Sema/libbuiltins-ctype-powerpc64.c
| /usr/bin/FileCheck
/builddir/build/BUILD/cfe-9.0.0rc1.src/test/Sema/libbuiltins-ctype-powerpc64.c
--
Exit Code: 1
Command Output (stderr):
--
/builddir/build/BUILD/cfe-9.0.0rc1.src/test/Sema/libbuiltins-ctype-powerpc64.c:19:12:
error: CHECK: expected string not found in input
// CHECK: call signext i32 @isalnum(i32 signext {{%[0-9]+}})
[[NUW_RO_CALL:#[0-9]+]]
^
:1:1: note: scanning from here
; ModuleID = '-'
^
:12:10: note: possible intended match here
%call = call signext i32 @isalnum(i32 inreg signext %0) #2
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=42474
[Bug 42474] [meta] 9.0.0 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42928] New: SEGV when compiling tests from cppcoro
https://bugs.llvm.org/show_bug.cgi?id=42928 Bug ID: 42928 Summary: SEGV when compiling tests from cppcoro Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: nazvyaches...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22358 --> https://bugs.llvm.org/attachment.cgi?id=22358&action=edit diagnostics Compiling test/recursive_generator_tests.cpp test/recursive_generator_tests.cpp:156:2: warning: control reaches end of non-void lambda [-Wreturn-type] }; ^ test/recursive_generator_tests.cpp:160:11: note: in instantiation of function template specialization '_DOCTEST_ANON_FUNC_16()::(anonymous class)::operator()<(lambda at test/recursive_generator_tests.cpp:148:11)>' requested here return f(n, f); ^ test/recursive_generator_tests.cpp:237:2: warning: control may reach end of non-void lambda [-Wreturn-type] }; ^ test/recursive_generator_tests.cpp:239:14: note: in instantiation of function template specialization '_DOCTEST_ANON_FUNC_20()::(anonymous class)::operator()<(lambda at test/recursive_generator_tests.cpp:219:11) &>' requested here auto gen = f(0, f); ^ test/recursive_generator_tests.cpp:297:2: warning: control may reach end of non-void lambda [-Wreturn-type] }; ^ test/recursive_generator_tests.cpp:299:14: note: in instantiation of function template specialization '_DOCTEST_ANON_FUNC_22()::(anonymous class)::operator()<(lambda at test/recursive_generator_tests.cpp:252:11) &>' requested here auto gen = f(1, f); ^ Stack dump: 0. Program arguments: /home/yozhek/llvm-build/bin/clang-9 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name recursive_generator_tests.cpp -mrelocation-model static -mthread-model posix -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 -coverage-notes-file /home/yozhek/cppcoro/build/linux_x64_clang9.0.0_optimised/test/obj/recursive_generator_tests.gcno -resource-dir /home/yozhek/llvm-build/lib/clang/9.0.0 -dependency-file /tmp/CakeGccDepRtzNfv -MT build/linux_x64_clang9.0.0_optimised/test/obj/recursive_generator_tests.o -sys-header-deps -D CPPCORO_RELEASE_OPTIMISED -I ./include -internal-isystem /home/yozhek/llvm-build/bin/../include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /home/yozhek/llvm-build/lib/clang/9.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -std=c++1z -fdeprecated-macro -fdebug-compilation-dir /home/yozhek/cppcoro -ferror-limit 19 -fmessage-length 0 -fcoroutines-ts -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -faddrsig -o build/linux_x64_clang9.0.0_optimised/test/obj/recursive_generator_tests.o -x c++ test/recursive_generator_tests.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. test/recursive_generator_tests.cpp:148:11: Generating code for declaration '_DOCTEST_ANON_FUNC_16()::(anonymous class)::operator()' #0 0x562dafb1beea llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/yozhek/llvm-project/llvm/lib/Support/Unix/Signals.inc:537:0 #1 0x562dafb19e04 llvm::sys::RunSignalHandlers() /home/yozhek/llvm-project/llvm/lib/Support/Signals.cpp:68:0 #2 0x562dafb19f42 SignalHandler(int) /home/yozhek/llvm-project/llvm/lib/Support/Unix/Signals.inc:385:0 #3 0x7f5f1443f890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x562db19fb615 clang::Expr::getExprLoc() const /home/yozhek/llvm-project/clang/lib/AST/Expr.cpp:216:0 #5 0x562dafd36a67 clang::CodeGen::ApplyDebugLocation::ApplyDebugLocation(clang::CodeGen::CodeGenFunction&, clang::Expr const*) /home/yozhek/llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp:123:0 #6 0x562daff7c06d clang::Stmt::getStmtClass() const /home/yozhek/llvm-project/clang/include/clang/AST/Stmt.h:1088:0 #7 0x562daff7c06d clang::BinaryOperator::classof(clang::Stmt const*) /home/yozhek/llvm-project/clang/include/clang/AST/Expr.h:3564:0 #8 0x562daff7c06d llvm::isa_impl::doit(clang::Stmt const&) /home/yozhek/llvm-project/llvm/include/llvm/Support/Casting.h:58:0 #9 0x562daff7c06d llvm::isa_impl_cl::doit(clang::Stmt const*) /home/yozhek/llvm-project/llvm/include/llvm/Support/Casting.h:106:0 #10 0x562daff7c06d llvm::isa_impl_wrap::doit(clang::Stmt const* const&) /home/yozhek/
