[llvm-bugs] Issue 11483 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: VT.isInteger() && "Cannot create FP integer constant!"
Comment #2 on issue 11483 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: VT.isInteger() && "Cannot create FP integer constant!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11483#c2 ClusterFuzz has detected this issue as fixed in range 201811210235:201811220237. Detailed report: https://oss-fuzz.com/testcase?key=5673377847574528 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: VT.isInteger() && "Cannot create FP integer constant!" llvm::SelectionDAG::getConstant llvm::TargetLowering::SimplifyDemandedBits Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811200233:201811210235 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811210235:201811220237 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5673377847574528 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11416 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Comment #1 on issue 11416 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11416#c1 ClusterFuzz has detected this issue as fixed in range 201811210235:201811220237. Detailed report: https://oss-fuzz.com/testcase?key=5768488824602624 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: 0x7ffc07dbbfa0 Crash State: clang::Lexer::LexTokenInternal clang::Lexer::Lex clang::Preprocessor::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811140257:201811150254 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811210235:201811220237 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5768488824602624 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39749] New: Headers containing just #error harm __has_include
https://bugs.llvm.org/show_bug.cgi?id=39749 Bug ID: 39749 Summary: Headers containing just #error harm __has_include Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: bme...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com It looks like the latest version of (https://llvm.org/svn/llvm-project/libcxx/trunk/include/experimental/optional) consists only of a #error to tell the user that it isn't supported anymore. While a helpful error, it will presumably(*) break any code that uses __has_include to detect whether this header is supported (as recommended by N4480). The same applies to , and I'm guessing others although I haven't checked. (*) I haven't yet got my own build of libc++ trunk to verify experimentally, so if there is some compiler magic to know that __has_include should be 0 for these special cases then I'm less worried. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11483 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: VT.isInteger() && "Cannot create FP integer constant!"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 11483 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: VT.isInteger() && "Cannot create FP integer constant!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11483#c3 ClusterFuzz testcase 5673377847574528 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11416 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11416 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11416#c2 ClusterFuzz testcase 5768488824602624 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39750] New: lldb built with cmake on macOS fails to debug applications
https://bugs.llvm.org/show_bug.cgi?id=39750 Bug ID: 39750 Summary: lldb built with cmake on macOS fails to debug applications Product: lldb Version: 7.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: alexandru.croi...@qt.io CC: llvm-bugs@lists.llvm.org Created attachment 21141 --> https://bugs.llvm.org/attachment.cgi?id=21141&action=edit lldb stacktrace Hi, I'm trying to build lldb master from sources using cmake on macOS 10.14.1, and the build finishes successfully, but debugging does not work. Using the same sources with xcodebuild, lldb can successfully debug applications. Initially I thought the issue might be due to code signing, but then I saw that the xcodebuild lldb is not code signed at all (although the debugserver is) Nevertheless I tried building both with -DLLDB_CODESIGN_IDENTITY="" and DLLDB_CODESIGN_IDENTITY="lldb_codesign", but it didn't make a difference. I also have SIP and gatekeeper disabled, and I followed the steps for creating a code sign cert from the docs. The issue specifically is that after running $ lldb ./my-app (lldb) r the application is not launched, and lldb freezes. If I press Ctrl-C 3 times, lldb quits, and the application gets launched. Attaching the stacktrace of lldb, as well as the log file. Judging from the log and trace, it looks like lldb expects some event to happen when launching the app, but it doesn't. lldb version 8.0.0 (http://llvm.org/git/lldb.git revision 0d6a8ba20fb9eb76c7cce62f18a9764c743f4e52) clang revision 2d5099826365b50ff253e48c0832255600e68202 llvm revision 498b7f9b57123ce661e075ae584876be72852506 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39751] New: "opt -globalopt" crashes with Assertion `isa(Elt->getType()) && "Index must be an integer"' failed.
https://bugs.llvm.org/show_bug.cgi?id=39751 Bug ID: 39751 Summary: "opt -globalopt" crashes with Assertion `isa(Elt->getType()) && "Index must be an integer"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 21144 --> https://bugs.llvm.org/attachment.cgi?id=21144&action=edit reproducer Running opt -o - -S bbi-21289.ll -globalopt gives opt: ../lib/IR/Constants.cpp:355: llvm::Constant *llvm::Constant::getAggregateElement(llvm::Constant *) const: Assertion `isa(Elt->getType()) && "Index must be an integer"' failed. Stack dump: 0. Program arguments: build-all/bin/opt -o - -S bbi-21289.ll -globalopt 1. Running pass 'Global Variable Optimizer' on module 'bbi-21289.ll'. #0 0x023d5534 PrintStackTraceSignalHandler(void*) (build-all/bin/opt+0x23d5534) #1 0x023d3660 llvm::sys::RunSignalHandlers() (build-all/bin/opt+0x23d3660) #2 0x023d5898 SignalHandler(int) (build-all/bin/opt+0x23d5898) #3 0x7fc571e38330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7fc570a27c37 gsignal /build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7fc570a2b028 abort /build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7fc570a20bf6 __assert_fail_base /build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0 #7 0x7fc570a20ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x01d20ac5 llvm::Constant::getAggregateElement(llvm::Constant*) const (build-all/bin/opt+0x1d20ac5) #9 0x0178e61a llvm::ConstantFoldLoadThroughGEPConstantExpr(llvm::Constant*, llvm::ConstantExpr*) (build-all/bin/opt+0x178e61a) #10 0x01eb6be6 CleanupConstantGlobalUsers(llvm::Value*, llvm::Constant*, llvm::DataLayout const&, llvm::TargetLibraryInfo*) (build-all/bin/opt+0x1eb6be6) #11 0x01eb2ae8 processInternalGlobal(llvm::GlobalVariable*, llvm::GlobalStatus const&, llvm::TargetLibraryInfo*, llvm::function_ref) (build-all/bin/opt+0x1eb2ae8) #12 0x01eb23e3 processGlobal(llvm::GlobalValue&, llvm::TargetLibraryInfo*, llvm::function_ref) (build-all/bin/opt+0x1eb23e3) #13 0x01eafc75 optimizeGlobalsInModule(llvm::Module&, llvm::DataLayout const&, llvm::TargetLibraryInfo*, llvm::function_ref, llvm::function_ref, llvm::function_ref) (build-all/bin/opt+0x1eafc75) #14 0x01eb1569 (anonymous namespace)::GlobalOptLegacyPass::runOnModule(llvm::Module&) (build-all/bin/opt+0x1eb1569) #15 0x01de58ba llvm::legacy::PassManagerImpl::run(llvm::Module&) (build-all/bin/opt+0x1de58ba) #16 0x007acc8b main (build-all/bin/opt+0x7acc8b) #17 0x7fc570a12f45 __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0 #18 0x0079219d _start (build-all/bin/opt+0x79219d) Abort The problem seems to be that llvm::ConstantFoldLoadThroughGEPConstantExpr in ConstantFolding.cpp called from CleanupConstantGlobalUsers in GlobalOpt.cpp can't handle GEPs with vector indices. When it crashes GEP is %0 = getelementptr inbounds [2 x i16], [2 x i16]* @a, i32 0, <2 x i32> and CE is <2 x i16*> getelementptr inbounds ([2 x i16], [2 x i16]* @a, <2 x i64> zeroinitializer, <2 x i64> ) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #15 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c15 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-2f7cf77e-aa89-461f-b0e9-41751185b2d1.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34904] Linking fails on C programs with xray instrumentation enabled
https://bugs.llvm.org/show_bug.cgi?id=34904 Roman Lebedev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Roman Lebedev --- Looks like it was fixed in 7. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39752] New: [DebugInfo] Location list entries expressed in caller-saved registers are incompatible for unwinding with GDB
https://bugs.llvm.org/show_bug.cgi?id=39752
Bug ID: 39752
Summary: [DebugInfo] Location list entries expressed in
caller-saved registers are incompatible for unwinding
with GDB
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
(This might be a known issue.)
Consider the following example:
int global;
__attribute__((noinline)) void fn3(int p3) {
global = p3;
/* Thrash parameter register. */
__asm volatile ("movl $999, %%edi" : : : "%edi");
}
__attribute__((noinline)) int fn2(int p2) {
global = p2;
fn3(p2);
return 0;
}
__attribute__((noinline)) int fn1(int p1) {
global = p1;
fn2(p1);
return 0;
}
int main() {
return fn1(111);
}
compiled using:
clang -target x86_64 -O3 -g test.c -o test.out
For fn2 we emit the following assembly:
(gdb) disas fn2
Dump of assembler code for function fn2:
0x00400500 <+0>: push %rbp
0x00400501 <+1>: mov%rsp,%rbp
0x00400504 <+4>: mov%edi,0x200b2a(%rip)#
0x601034
0x0040050a <+10>:callq 0x4004e0
0x0040050f <+15>:xor%eax,%eax
0x00400511 <+17>:pop%rbp
0x00400512 <+18>:retq
End of assembler dump.
and the following location list for p2:
(gdb) info addr p2
Symbol "p2" is multi-location:
Range 0x400500-0x40050f: a variable in $rdi
As seen, we say that p2 is valid during the call. The same situation holds for
fn1 and p1.
When unwinding with GDB, which (at least for x86-64) relies on the DWARF
information to tell if a register is caller-saved, we will print invalid values
for the unwound p1 and p2 variables after we have thrashed $edi in fn3:
(gdb) disas
Dump of assembler code for function fn3:
0x004004e0 <+0>: push %rbp
0x004004e1 <+1>: mov%rsp,%rbp
0x004004e4 <+4>: mov%edi,0x200b4a(%rip)#
0x601034
0x004004ea <+10>:mov$0x3e7,%edi
=> 0x004004ef <+15>:pop%rbp
0x004004f0 <+16>:retq
End of assembler dump.
(gdb) bt
#0 fn3 (p3=) at test.c:11
#1 0x0040050f in fn2 (p2=999) at test.c:15
#2 0x0040052f in fn1 (p1=999) at test.c:21
#3 0x0040054e in main () at test.c:26
This is not an issue with LLDB, as it is ABI-aware, and does not print out any
caller-saved registers in outer frames.
When unwinding, GDB and LLDB assume that the address is (return_address - 1)
when printing variables, etc. GCC seems to utilize this fact to get the
location expression correct for the caller-saved described variable, by ending
the location list entry right before that:
GCC 5.4.0 output:
(gdb) disas fn2
Dump of assembler code for function fn2:
0x00400500 <+0>: mov%edi,0x200b2e(%rip)#
0x601034
0x00400506 <+6>: callq 0x4004f0
0x0040050b <+11>:xor%eax,%eax
0x0040050d <+13>:retq
End of assembler dump.
(gdb) info addr p2
Symbol "p2" is multi-location:
Range 0x400500-0x40050a: a variable in $rdi
Range 0x40050a-0x40050e: a complex DWARF expression:
0: DW_OP_GNU_entry_value
2: DW_OP_reg5 [$rdi]
3: DW_OP_stack_value
As seen, the first address after the call is 0x40050b, but the (exclusive)
ending address for p2 in the location list entry is 0x40050a.
Would it make sense to adapt LLVM to this behavior to be GDB compatible? Or is
it an acceptable incompatibility?
If we instead want to go the CFI route, maybe the compiler could emit
DW_CFA_undefined for caller-saved registers when they are clobbered?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39753] New: Merge r343369 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=39753 Bug ID: 39753 Summary: Merge r343369 into the 7.0 branch Product: new-bugs Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 39106 r343369 "[cxx2a] Fix warning triggered by r343285" This is a warning fix without which, compiling LLVM with recent Clang versions causes warnings. Not critical, but it would be nice to get in. I think it's ABI-safe, since it's removing functions that couldn't be called before as they were implicitly deleted. (Note that the commit spans multiple modules in the repository.) Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39106 [Bug 39106] [meta] 7.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39754] New: Mingw-w64 runtime failure
https://bugs.llvm.org/show_bug.cgi?id=39754 Bug ID: 39754 Summary: Mingw-w64 runtime failure Product: clang Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: eldlistmaili...@tropicsoft.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 21145 --> https://bugs.llvm.org/attachment.cgi?id=21145&action=edit Program to compile and link illustrating the bug. In testing the Boost Parameter library using clang-7.0 32-bit targeting mingw-w64/gcc on Windows I ran into a mingw-w64 runtime failure when attempting to run the final command-line executable program. The full message is: "Mingw-w64 runtime failure: Unknown pseudo relocation protocol version 65536. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information." Using clang-6.0 32-bit targeting mingw-w64/gcc on Windows the command-line executable program runs correctly. Using mingw-w64/gcc-8.1, which is the backend I am using with clang-7.0, on Windows the command-line program runs correctly. Nor does it matter what mingw-w64/gcc version I use as the backend for clang-7.0, the runtime failure persists. There is a bug report at https://sourceforge.net/p/mingw-w64/bugs/769/, which points to a bug report at https://sourceware.org/bugzilla/show_bug.cgi?id=23872, with a fix at https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d, which it was suggested to me on the mingw-w64 mailing list might fix the problem I encountered. However I am unable to figure out how to build the gcc linker for mingw-w64, ld.exe, so I am reporting these problem here as a clang-7.0 bug. The program illustrating the bug is called test_clang7.cpp and attached. The compile line is: clang++ -c -x c++ -m32 -O0 -fno-inline -w -g -target i686-pc-windows-gnu -march=i686 -I"E:\Utilities\Boost\boost_1_68_0" -o test_clang7.obj test_clang7.cpp In place of the -I"E:\Utilities\Boost\boost_1_68_0" parameter in that line please use the path to whatever recent release of Boost you have on your machine under Windows. The link line is: clang++ -o test_clang7.exe -Wl,--start-group test_clang7.obj -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -m32 -g -target i686-pc-windows-gnu -march=i686 This will create the test_clang.exe. If you then try to run the test_clang.exe you will get the failure mentioned above. I have not tried this when building the program as 64-bit executable, but I suspect that the bug might occur there also. The operating system I am running this on is Windows 8.1. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39755] New: [DebugInfo@O2][Dexter] dbg.value's of isel vreg's can be accidentally dropped
https://bugs.llvm.org/show_bug.cgi?id=39755
Bug ID: 39755
Summary: [DebugInfo@O2][Dexter] dbg.value's of isel vreg's can
be accidentally dropped
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: CONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: jeremy.morse.l...@gmail.com
CC: chackz0...@gmail.com, greg.bedw...@sony.com,
international.phan...@gmail.com,
llvm-bugs@lists.llvm.org, paul.robin...@am.sony.com
Blocks: 38754, 38768
This bug is spun out of bug 38754 to represent a regression I saw there; using
llvm/clang r346686 with options "-O2 -g -fno-inline", and with CodeGenPrepare's
placeDbgValues function disabled, the "blah" variable in the code below does
not get a location. (It does if placeDbgValues is enabled).
8<
struct faces {
unsigned bar : 15;
unsigned baz : 15;
unsigned qux : 1;
unsigned wat;
};
void forks(faces *foo, bool cond, int someval) {
foo->wat = foo->bar;
if (someval == 4) {
unsigned blah = foo->bar;
foo->baz = 3;
if (cond)
blah |= 4;
else
blah |= 8;
foo->bar = blah;
}
}
int
main()
{
volatile int foo = 4;
bool cond = foo == 4;
faces spoon;
spoon.bar = 0;
spoon.baz = 0;
forks(&spoon, cond, foo);
return spoon.bar;
}
>8
The IR for the start of the outer conditional block in the 'forks' function,
where !24 is the DIVariable for "blah":
8<
if.then: ; preds = %entry
%1 = bitcast %struct.faces* %foo to i32*
call void @llvm.dbg.value(metadata i32 %bf.clear, metadata !24, [...])
%bf.clear4 = and i32 %bf.load, -1073741824
call void @llvm.dbg.value(metadata i32 undef, metadata !24, [...])
%blah.0 = select i1 %cond, i32 98308, i32 98312
>8
Some facts:
* The inner condition has been optimised into a single select instruction
* The stores to foo->baz and foo->bar gets merged into a single store
* The read of foo->bar at the start of the function makes the field live
in the %bf.clear SSA register, the whole memory word lives in %bf.load
* The middle line (the "and" instruction) survives into the object file
With the IR above, I would expect that "blah" would have a location on the
"and" instruction, and to then lose it afterwards. The dbg.value(undef) comes
from the merged stores getting instcombined with the logic insns, leaving no
single value for "blah".
Unfortunately, the first dbg.value dangles because %bf.clear isn't read until a
few insns further down the IR BB, and the dbg.value(undef) then causes the
first one to get dropped. That feature [0] is to avoid emitting spurious
DBG_VALUEs after a new valuation is available; in this circumstance we end up
dropping a legitimate dbg.value because we didn't know it was _going_ to be
legitimate yet.
IMHO, in the theme of this WIP [1] patch, we need to distinguish what's a
read/write of a VReg from general SDNodes. The value being referred to (in a
VReg) is already available and the DBG_VALUE could be emitted without
generating spurious code, we just don't recognise it.
There's also the matter that the value of "blah" could probably be recovered
from the instcombined Value, but is instead marked as undef, however that's
probably a different ticket.
[0]
https://github.com/llvm-mirror/llvm/blob/5018f6ea8fcd1c655d36a2ae1900e0ccee906b96/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp#L1121
[1] https://reviews.llvm.org/D54715
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=38754
[Bug 38754] [DebugInfo@O2][Dexter] Illegal value appears in variable when
conditional blocks folded
https://bugs.llvm.org/show_bug.cgi?id=38768
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39756] New: PPCTLSDynamicCallPass needs to be preceded by LiveVariables otherwise stage 2 clang build fails
https://bugs.llvm.org/show_bug.cgi?id=39756 Bug ID: 39756 Summary: PPCTLSDynamicCallPass needs to be preceded by LiveVariables otherwise stage 2 clang build fails Product: libraries Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: stef...@ca.ibm.com CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com Currently in PPCTargetMachine.cpp we have the pass PPCTLSDynamicCallPass preceded by LiveVariables. If the LiveVariables pass is removed then stage 2 clang fails to build. The dependency should not be required. Should investigate the failure to find out where the bug comes from and possibly remove the dependency. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39757] New: ASTContext::getRawCommentForDeclNoCache() ignores enum value decls, returns wrong comment
https://bugs.llvm.org/show_bug.cgi?id=39757
Bug ID: 39757
Summary: ASTContext::getRawCommentForDeclNoCache() ignores enum
value decls, returns wrong comment
Product: clang
Version: 6.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: djee...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
When using ASTContext::getRawCommentForDeclNoCache() to get the comment
associated with a Decl, the high-level algorithm is as follow:
- Find the location of the Decl,
- Find if a trailing comment follows the Decl, if so return it,
- Otherwise find the previous comment, located before the Decl,
- Check that no other Decl exists between that comment and the target Decl.
The last step is implemented with a fast but brittle string compare:
// There should be no other declarations or preprocessor directives between
// comment and declaration.
if (Text.find_first_of(";{}#@") != StringRef::npos)
return nullptr;
Unfortunately, for enum value decls, the separator is a comma ',' which means
that all the value decls following a comment will return that same comment:
enum class MyEnum
{
/// Comment1
One = 1,
Two = 2, /// Comment2
Three = 3,
Four = 4,
Five = 5,
};
Here the enum value decl "One" gets "Comment1" as expected, but for all other 4
decls getRawCommentForDeclNoCache() returns "Comment2", even though I would
expect only the second value has a comment.
A possible fix is to add the comma ',' to the list of tested characters, though
I am not sure if that can break something else. Any opinion?
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39657] suboptimal shift+logic transform ('not' ops are better for analysis and codegen)
https://bugs.llvm.org/show_bug.cgi?id=39657 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||347478 --- Comment #2 from Sanjay Patel --- We can let bug 32706 continue to track doing this in IR. Codegen should be fixed (and therefore, the source example shown here should always be improved) after: https://reviews.llvm.org/rL347478 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39759] New: Instantiated local in inner and outer scopes
https://bugs.llvm.org/show_bug.cgi?id=39759
Bug ID: 39759
Summary: Instantiated local in inner and outer scopes
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: mikhail.strelni...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
int main() {
auto f = [](auto a) { a(42); };
f([&](auto) {f([&](auto) {});});
}
"C:/Program Files/LLVM/bin/clang++.exe" -c -o "f.obj" f.cpp
Assertion failed: Current->LocalDecls.find(D) == Current->LocalDecls.end() &&
"Instantiated local in inner and outer scopes", file
C:\src\llvm_package_346630\llvm\tools\clang\lib\Sema\SemaTemplateInstantiate.cpp,
line 2957
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39760] New: static constexpr member definition not emitted with c++14
https://bugs.llvm.org/show_bug.cgi?id=39760 Bug ID: 39760 Summary: static constexpr member definition not emitted with c++14 Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: andrew...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Accessing the address of a static constexpr member variable does not cause a definition to be emitted when using modules. Repro: https://reviews.llvm.org/differential/diff/175074/ -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39761] New: Support "workspace/symbol" for static functions defined in a source file
https://bugs.llvm.org/show_bug.cgi?id=39761 Bug ID: 39761 Summary: Support "workspace/symbol" for static functions defined in a source file Product: clang-tools-extra Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: clangd Assignee: unassignedclangb...@nondot.org Reporter: zeratul...@hotmail.com CC: llvm-bugs@lists.llvm.org, simon.mar...@polymtl.ca "workspace/symbol" appears to only find functions defined in a header file, not static functions defined in a source file. It would be good to support the latter as well, since "workspace/symbol" is often the fastest way to navigate to such functions. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39762] New: OCaml binding Llvm.value_name always returns empty string
https://bugs.llvm.org/show_bug.cgi?id=39762
Bug ID: 39762
Summary: OCaml binding Llvm.value_name always returns empty
string
Product: libraries
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: taquangtrun...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
I followed the tutorial https://www.wzdftpd.net/blog/ocaml-llvm-02.html to
build an analyzer for LLVM bitcode.
However, the OCaml binding function Llvm.value_name always returns an empty
string. This is unexpected since the function Llvm.string_of_llvalue returns
the correct string-representation of an Llvm value.
I'm using LLVM 6.0 and test with two versions of OCaml: 4.06.1 and 4.07.0.
Here are the steps to reproduce the bug:
1. Create a file hello.c
#include
int main(int arg) {
int x = arg;
if (x>1)
return 1;
else
return 2;
assert(1>2);
}
2. Compile it to bitcode: clang -c hello.c -emit-llvm
3. Here is my OCaml code to print the value name of the bitcode file hello.bc
let print_bitcode file =
let llctx = Llvm.global_context () in
let llmem = Llvm.MemoryBuffer.of_file file in
let llm = Llvm_bitreader.parse_bitcode llctx llmem in
Llvm.iter_functions (fun func ->
Llvm.iter_blocks (fun blk ->
Llvm.iter_instrs(fun inst ->
print_endline ("Value Name: '" ^ (Llvm.value_name inst) ^ "'");
print_endline ("Value Str: '" ^ (Llvm.string_of_llvalue inst) ^
"'\n");
) blk
) func
) llm
4. Here is the output:
Value Name: ''
Value Str: ' %2 = alloca i32, align 4'
Value Name: ''
Value Str: ' %3 = alloca i32, align 4'
Value Name: ''
Value Str: ' %4 = alloca i32, align 4'
Value Name: ''
Value Str: ' store i32 0, i32* %2, align 4'
Value Name: ''
Value Str: ' store i32 %0, i32* %3, align 4'
Value Name: ''
Value Str: ' %5 = load i32, i32* %3, align 4'
Value Name: ''
Value Str: ' store i32 %5, i32* %4, align 4'
Value Name: ''
Value Str: ' %6 = load i32, i32* %4, align 4'
Value Name: ''
Value Str: ' %7 = icmp sgt i32 %6, 1'
Value Name: ''
Value Str: ' br i1 %7, label %8, label %9'
Value Name: ''
Value Str: ' store i32 1, i32* %2, align 4'
Value Name: ''
Value Str: ' br label %10'
Value Name: ''
Value Str: ' store i32 2, i32* %2, align 4'
Value Name: ''
Value Str: ' br label %10'
Value Name: ''
Value Str: ' %11 = load i32, i32* %2, align 4'
Value Name: ''
Value Str: ' ret i32 %11'
5. As can be seen above, all the Value Name is empty.
So, I wonder if this is a bug of the binding function Llvm.value_name,
or did I make some mistakes in my code?
Thank you!
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
