[llvm-bugs] [Bug 48082] New: LLVM ERROR: Broken function found, compilation aborted! with "-simplifycfg -sroa -jump-threading -lcssa -loop-unroll"
https://bugs.llvm.org/show_bug.cgi?id=48082
Bug ID: 48082
Summary: LLVM ERROR: Broken function found, compilation
aborted! with "-simplifycfg -sroa -jump-threading
-lcssa -loop-unroll"
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: suochen...@163.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
union a {
short b;
short c;
};
int d=1, e=1;
long f=1L, g=1L;
long (h)() {
return 0;
}
int i() {
union a j;
j.c=1;
for (;; j.c = h()) {
long k[4][3][4] = {g};
k[3][0][1] = g;
d = 0;
for (; d >= 0;)
return 0;
for (;;) {
if (j.c)
;
else {
int l=2;
int *m = &l;
int **n = &m;
for (; f;) {
for (; e;)
k[3][0][1];
&n == &n;
return 0;
}
}
if (j.b)
break;
}
}
return 0;
}
int main() {
return 0;
}
***
clang version:
$ clang -v
clang version 12.0.0 (/home/suocy/src/llvm-dev/llvm-project/llvm/tools/clang
4455f3ce72ba2bb0276200f6f29629afca8812d4)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/suocy/bin/llvm-dev/bin
Found candidate GCC installation:
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation:
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
***
Command Lines:
$ clang -c -emit-llvm -O3 -mllvm -disable-llvm-optzns a.c -o a.bc
a.c:31:22: warning: expression result unused [-Wunused-value]
k[3][0][1];
~~~ ~^
a.c:32:14: warning: equality comparison result unused [-Wunused-comparison]
&n == &n;
~~~^
2 warnings generated.
$ opt -simplifycfg -sroa -jump-threading -lcssa -loop-unroll a.bc -o a.opt.bc
PHI nodes must have at least one entry. If the block is dead, the PHI should
be removed!
%retval.3 = phi i32
in function i
LLVM ERROR: Broken function found, compilation aborted!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: /home/suocy/bin/llvm-dev/bin/opt -simplifycfg -sroa
-jump-threading -lcssa -loop-unroll a.bc -o a.opt.bc
1. Running pass 'Function Pass Manager' on module 'a.bc'.
2. Running pass 'Module Verifier' on function '@i'
#0 0x02a110fc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2a110fc)
#1 0x02a0f0a4 llvm::sys::RunSignalHandlers()
(/home/suocy/bin/llvm-dev/bin/opt+0x2a0f0a4)
#2 0x02a0f203 SignalHandler(int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2a0f203)
#3 0x7f0ed8fb3630 __restore_rt (/lib64/libpthread.so.0+0xf630)
#4 0x7f0ed7ba1387 raise (/lib64/libc.so.6+0x36387)
#5 0x7f0ed7ba2a78 abort (/lib64/libc.so.6+0x37a78)
#6 0x02984b24 llvm::report_fatal_error(llvm::Twine const&, bool)
(/home/suocy/bin/llvm-dev/bin/opt+0x2984b24)
#7 0x02984c58 (/home/suocy/bin/llvm-dev/bin/opt+0x2984c58)
#8 0x022de51f (anonymous
namespace)::VerifierLegacyPass::runOnFunction(llvm::Function&)
(/home/suocy/bin/llvm-dev/bin/opt+0x22de51f)
#9 0x02263bd8 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2263bd8)
#10 0x02264679 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2264679)
#11 0x02263483 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2263483)
#12 0x007235ab main (/home/suocy/bin/llvm-dev/bin/opt+0x7235ab)
#13 0x7f0ed7b8d555 __libc_start_main (/lib64/libc.so.6+0x22555)
#14 0x007d7185 _start (/home/suocy/bin/llvm-dev/bin/opt+0x7d7185)
Aborted
--
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 48084] New: PassAnalysisSupport.h:239: AnalysisType& llvm::Pass::getAnalysisID(llvm::AnalysisID) const [with AnalysisType = llvm::BasicAAWrapperPass; llvm::AnalysisID = const void*]:
https://bugs.llvm.org/show_bug.cgi?id=48084
Bug ID: 48084
Summary: PassAnalysisSupport.h:239: AnalysisType&
llvm::Pass::getAnalysisID(llvm::AnalysisID) const
[with AnalysisType = llvm::BasicAAWrapperPass;
llvm::AnalysisID = const void*]: Assertion `ResultPass
&& "getAnalysis*() called on an analysis that was not
" "'requ
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: suochen...@163.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
int main() {return 0;}
***
clang version:
$ clang -v
clang version 12.0.0 (/home/suocy/src/llvm-dev/llvm-project/llvm/tools/clang
4455f3ce72ba2bb0276200f6f29629afca8812d4)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/suocy/bin/llvm-dev/bin
Found candidate GCC installation:
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/4.8.5
Selected GCC installation:
/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
***
Command Lines:
$ clang -O3 -mllvm -disable-llvm-optzns -c -emit-llvm a.c -o a.bc
$ opt -memoryssa -gvn -licm -float2int -slp-vectorizer a.bc -o a.opt.bc
opt:
/home/suocy/src/llvm-dev/llvm-project/llvm/include/llvm/PassAnalysisSupport.h:239:
AnalysisType& llvm::Pass::getAnalysisID(llvm::AnalysisID) const [with
AnalysisType = llvm::BasicAAWrapperPass; llvm::AnalysisID = const void*]:
Assertion `ResultPass && "getAnalysis*() called on an analysis that was not "
"'required' by pass!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: /home/suocy/bin/llvm-dev/bin/opt -memoryssa -gvn
-licm -float2int -slp-vectorizer a.bc -o a.opt.bc
1. Running pass 'Function Pass Manager' on module 'a.bc'.
2. Running pass 'Function Alias Analysis Results' on function '@main'
#0 0x02a110fc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2a110fc)
#1 0x02a0f0a4 llvm::sys::RunSignalHandlers()
(/home/suocy/bin/llvm-dev/bin/opt+0x2a0f0a4)
#2 0x02a0f203 SignalHandler(int)
(/home/suocy/bin/llvm-dev/bin/opt+0x2a0f203)
#3 0x7f740e6e6630 __restore_rt (/lib64/libpthread.so.0+0xf630)
#4 0x7f740d2d4387 raise (/lib64/libc.so.6+0x36387)
#5 0x7f740d2d5a78 abort (/lib64/libc.so.6+0x37a78)
#6 0x7f740d2cd1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
#7 0x7f740d2cd252 (/lib64/libc.so.6+0x2f252)
#8 0x019685a5
llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&)
(/home/suocy/bin/llvm-dev/bin/opt+0x19685a5)
#9 0x02263bd8 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2263bd8)
#10 0x02264679 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2264679)
#11 0x02263483 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/suocy/bin/llvm-dev/bin/opt+0x2263483)
#12 0x007235ab main (/home/suocy/bin/llvm-dev/bin/opt+0x7235ab)
#13 0x7f740d2c0555 __libc_start_main (/lib64/libc.so.6+0x22555)
#14 0x007d7185 _start (/home/suocy/bin/llvm-dev/bin/opt+0x7d7185)
Aborted
--
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 48085] New: Compiling infinite goto loop with -O2 takes clang into an infinite loop
https://bugs.llvm.org/show_bug.cgi?id=48085 Bug ID: 48085 Summary: Compiling infinite goto loop with -O2 takes clang into an infinite loop Product: new-bugs Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: david.cortes.riv...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24137 --> https://bugs.llvm.org/attachment.cgi?id=24137&action=edit Source code that produces the bug I’ve come across an issue in which, when some C code contains an infinite loop in the form of a ‘goto’ with the exit condition blocked by another goto, compiling it with clang will take clang into an infinite loop during compilation, making it get stuck until eventually running out of memory. Attached is a screenshot of the source code that gave the problem (the original file is this: https://github.com/david-cortes/cmfrec/blob/master/src/collective.c). I’m additionally attaching a very small reproducible example in which the issue is reproducible, but only with -O2 and higher. Steps to reproduce: - Download the attached source code file - Compile it with -O2 - e.g.: clang -O2 infinite_loop.c Expected behavior: Should compile the source code into an executable, regardless of whether it has an infinite loop or not. Ideally should warn about the infinite loop. Actual behavior: Compiler gets stuck into an infinite loop trying to optimize that code, until eventually running out of memory. -- 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 48087] New: Incorrect usage of DW_OP_constXXX on 32-bit targets
https://bugs.llvm.org/show_bug.cgi?id=48087
Bug ID: 48087
Summary: Incorrect usage of DW_OP_constXXX on 32-bit targets
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: lab...@google.com
CC: dblai...@gmail.com, jdevliegh...@apple.com,
keith.wal...@arm.com, llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Dwarf says (section 2.5.1.1. Literal Encodings of DWARF v5):
Operations other than DW_OP_const_type push a value with the generic type, and
if the value of a constant in one of these operations is larger than can be
stored in a
single stack element, the value is truncated to the element size and the
low-order bits are pushed on the stack.
[ In 2.5.1., "generic type" is defined as "an integral type that has the size
of an address on the target machine and unspecified signedness" ]
If we take this code:
void g(long long);
void f() {
long long x = 0x4247;
g(x);
x = 0x474247424742ull;
g(x);
}
And compile it (with optimizations) with clang for a 32-bit target, we get the
following location list for "x":
[0x, 0x000f): DW_OP_consts +16967,
DW_OP_stack_value
[0x000f, 0x0025): DW_OP_consts +78349988939586,
DW_OP_stack_value)
This usage is incorrect, because the result of DW_OP_consts should be truncated
to 4 bytes (size of an address). For the first expression, that's mostly fine,
but for the second value, this garbles/truncates the expression value.
gdb will display the truncated (wrong) value for x. lldb will display the
correct value, but only because it's handling of DW_OP_constXX opcodes is
non-conforming (I was about to fix it to make it conforming, before I
discovered this problem). I haven't checked what other consumers do.
gcc deals with this problem by using DW_OP_implicit_value for this variable:
[0x, 0x001b): DW_OP_implicit_value 0x8 0x47
0x42 0x00 0x00 0x00 0x00 0x00 0x00
[0x001b, 0x0031): DW_OP_implicit_value 0x8 0x42
0x47 0x42 0x47 0x42 0x47 0x00 0x00)
I guess llvm should do the same?
We can keep the symmetrical lldb bug for a while for backwards compatibility,
but it would be good to fix that one day
--
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 48072] Assertion `&*ALI == *AAI && "Not the same accesses in the same order"' failed.
https://bugs.llvm.org/show_bug.cgi?id=48072 Florian Hahn changed: What|Removed |Added Fixed By Commit(s)||be0578f0b44d Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Florian Hahn --- Should be fixed by https://reviews.llvm.org/rGbe0578f0b44d -- 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 48088] New: [AArch64] UnwindInfo cannot be emitted if inline asm with align or fill are used
https://bugs.llvm.org/show_bug.cgi?id=48088
Bug ID: 48088
Summary: [AArch64] UnwindInfo cannot be emitted if inline asm
with align or fill are used
Product: libraries
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: MC
Assignee: unassignedb...@nondot.org
Reporter: rixr...@gmail.com
CC: llvm-bugs@lists.llvm.org
For more info see FIXME in ARM64EmitUnwindInfo (llvm/lib/MC/MCWin64EH.cpp)
https://github.com/llvm/llvm-project/blob/f69e090/llvm/lib/MC/MCWin64EH.cpp#L918-L943
Reproducible example:
void test() { __asm__(".balign 1");
Compiling with:
clang.exe --target=x86_64-pc-windows -c test.cpp
Gives no error, however, compiling with
clang.exe --target=aarch64-pc-windows -c test.cpp
Crashes:
fatal error: error in backend: Failed to evaluate function length in SEH unwind
info
Stack dump:
0. Program arguments: clang.exe --target=aarch64-pc-windows -c test.cpp
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'test.cpp'.
4. Running pass 'AArch64 Assembly Printer' on function '@"?test@@YAXXZ"'
Related bug report: https://bugs.llvm.org/show_bug.cgi?id=41581
--
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 48089] New: FileCheck with multiple check prefixes prints the wrong prefix for failing -dag checks
https://bugs.llvm.org/show_bug.cgi?id=48089 Bug ID: 48089 Summary: FileCheck with multiple check prefixes prints the wrong prefix for failing -dag checks Product: new-bugs Version: trunk 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 For example: $ cat /tmp/x BAR-DAG: world FOO-DAG: Hello $ echo Hello world | bin/FileCheck --check-prefix=FOO --check-prefix=BAR /tmp/x (all good) $ echo Hello LLVM | bin/FileCheck --check-prefix=FOO --check-prefix=BAR /tmp/x /tmp/x:1:10: error: FOO-DAG: expected string not found in input BAR-DAG: world ^ :1:1: note: scanning from here Hello LLVM ^ Input file: Check file: /tmp/x -dump-input=help explains the following input dump. Input was: << 1: Hello LLVM dag:1 X~ error: no match found >> Note that the error says "FOO-DAG: expected string not found in input" even though it's really BAR-DAG that's failing. -- 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 48090] New: Non-type template argument parse error
https://bugs.llvm.org/show_bug.cgi?id=48090
Bug ID: 48090
Summary: Non-type template argument parse error
Product: clang
Version: trunk
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: oleg-dereven...@yandex.ru
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Consider the following code:
namespace BitOp
{
enum Op
{
Copy
};
};
template
class Bits
{
public:
template
static T& bitop(T& dst, T src) {
if (op == BitOp::Copy)
dst = src;
return dst;
};
};
template
struct Bitmap3D
{
template
void exportBits(T* bits) const
{
Bits::bitop(bits[0], bits[0]);
};
};
int main(int, char *[])
{
Bitmap3D bm3d;
int *bits;
bm3d.exportBits(bits);
}
It fails to compile with the following error:
:27:18: error: reference to overloaded function could not be resolved;
did you mean to call it?
Bits::bitop(bits[0], bits[0]);
~^
:36:10: note: in instantiation of function template specialization
'Bitmap3D::exportBits' requested here
bm3d.exportBits(bits);
^
:14:15: note: possible target for call
static T& bitop(T& dst, T src) {
^
1 error generated.
This code compiles just fine with MSVC 19.27 though:
https://godbolt.org/z/KqMKnv
It seems that clang parser interprets "Bits::bitop::bitop, op), but it's just a guess.
--
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 26988 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26988 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26988#c1 ClusterFuzz testcase 6225110262087680 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011040615:202011050602 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 26018 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26018 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26018#c1 ClusterFuzz testcase 4823385979486208 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011040615:202011050602 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 27005 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-11-05 Type: Bug New issue 27005 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase:: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27005 Detailed Report: https://oss-fuzz.com/testcase?key=5716316457271296 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe8301d4c0 Crash State: clang::StmtVisitorBase:: ScalarExprEmitter::EmitBinOps Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011040615:202011050602 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5716316457271296 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 24416] "expr/x $eax" fails on FreeBSD after r244308
https://bugs.llvm.org/show_bug.cgi?id=24416 ema...@freebsd.org changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #2 from ema...@freebsd.org --- I can no longer reproduce this (lldb) expr/x $eax (unsigned int) $0 = 0x002095f0 -- 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 48090] Non-type template argument parse error
https://bugs.llvm.org/show_bug.cgi?id=48090 Oleg Derevenetz changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Oleg Derevenetz --- This will be fixed by adding "template" keyword like this: Bits::template bitop(bits[0], bits[0]); Sorry for troubling. -- 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 47604] Assertion failed: Index >= End && "Unexpected parser error."
https://bugs.llvm.org/show_bug.cgi?id=47604 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||f55247456e219bb64521c3a73c6 ||18267d5bf671c Status|NEW |RESOLVED --- Comment #4 from Reid Kleckner --- f55247456e219bb64521c3a73c618267d5bf671c -- 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 48091] New: [DebugInfo@O2] Filtering out-of-scope variables drops many legitimate locations
https://bugs.llvm.org/show_bug.cgi?id=48091 Bug ID: 48091 Summary: [DebugInfo@O2] Filtering out-of-scope variables drops many legitimate locations Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: jeremy.morse.l...@gmail.com CC: llvm-bugs@lists.llvm.org The VarLoc based LiveDebugValues implementation has a filter in the 'join' method, to cease propagating variable locations that have gone out of scope. I believe the aim of this is to prevent LiveDebugValues needlessly computing the location of every variable for every instruction, even those that are only in scope for a few instructions. Clearly this is effective at moderating compile times, however it also seems to damage location coverage too. Specifically: if you have, say, an X86 CMOV64 instruction: CMP64rr $rbx, $rcx, implicit-def $eflags $rbx = CMOV64rr $rbx (tied-def 0), $rcx, 7, implicit $eflags, debug-location !1 Then occasionally the X86 backend will implement this with control flow: CMP64rr $rbx, $rcx, implicit-def $eflags JCC_1 %bb.2, 7, debug-location !1 bb.1: $rbx = COPY $rcx, debug-location !1 bb.2: ... Unfortunately, this effectively becomes a notch filter for variables that are in scope for DILocation !1. Any variables that aren't in scope in bb.1 will be dropped, and subsequently cause the same variables to be dropped from bb.2 onwards. That means any LLVM-IR select instruction can potentially lead to neighbouring variable locations being dropped, depending on their scopes. In terms of impact, here's llvm-locstats for a clang-3.4 build with and without the out-of-scope filter. With filter: = cov% samples percentage(~) - 0% 765406 22% (0%,10%) 451791% [10%,20%) 516991% [20%,30%) 520441% [30%,40%) 469051% [40%,50%) 482921% [50%,60%) 613421% [60%,70%) 583151% [70%,80%) 698482% [80%,90%) 819372% [90%,100%) 1013842% 100%2032034 59% = -the number of debug variables processed: 3414385 -PC ranges covered: 61% - -total availability: 64% = Without: = cov% samples percentage(~) - 0% 765357 22% (0%,10%) 451681% [10%,20%) 515841% [20%,30%) 519111% [30%,40%) 465691% [40%,50%) 479781% [50%,60%) 603561% [60%,70%) 530711% [70%,80%) 560181% [80%,90%) 791312% [90%,100%) 1036643% 100%2059075 60% = -the number of debug variables processed: 3419882 -PC ranges covered: 61% - -total availability: 65% = Importantly, there are an additional ~27k variables in the 100% range bucket, mostly moved up from the 60-99% ranges. Presumably these are long lived variables that have their lifetimes artificially interrupted by the scope filter. A similar amount of improvement occurs for InstrRefBasedLDV. IMO, this is eminently solvable in InstrRefBasedLDV -- as it deals with things in terms of transfer functions, we should be able to invent transfer functions between isolated segments of particular scopes using dominance information. -- 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 48092] New: assembly emission fails to escape symbols starting with a digit
https://bugs.llvm.org/show_bug.cgi?id=48092
Bug ID: 48092
Summary: assembly emission fails to escape symbols starting
with a digit
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Support Libraries
Assignee: unassignedb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org
Testcase:
$ echo 'int n asm("9") = 0;' | clang -x c - -c -fno-integrated-as
/tmp/--9c2337.s: Assembler messages:
/tmp/--9c2337.s:3: Error: Missing symbol name in directive
/tmp/--9c2337.s:3: Error: unrecognized symbol type "9"
[...]
This works fine without -fno-integrated-as. The problem appears to be that the
symbol name is written directly to the output assembly file:
.text
.file "-"
.type 9,@object # @"9"
.bss
.globl 9
.p2align2
9:
.long 0 # 0x0
.size 9, 4
... instead of being enclosed in double-quotes.
--
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 48093] New: --save-temps generates invalid command lines when reading from stdin or files whose names start with hyphens
https://bugs.llvm.org/show_bug.cgi?id=48093
Bug ID: 48093
Summary: --save-temps generates invalid command lines when
reading from stdin or files whose names start with
hyphens
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Testcase:
$ echo 'int main() {}' | clang -x c++ - -o tmp.o --save-temps
error: unknown argument: '-.ii'
It looks like the driver is not properly escaping filenames that might be
confused for command-line arguments to subtools.
Similarly:
$ touch -- -.c
$ clang ./-.c --save-temps
error: unknown argument: '-.i'
--
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 27014 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::APValue::operator=
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-11-06 Type: Bug New issue 27014 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::APValue::operator= https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27014 Detailed Report: https://oss-fuzz.com/testcase?key=5723353090097152 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff65fcc998 Crash State: clang::APValue::operator= IntExprEvaluator::Success clang::StmtVisitorBase::Visit Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011040615:202011050602 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5723353090097152 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] Issue 27016 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: !isEmpty() && "Nothing selected"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Unreproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-11-06 Type: Bug New issue 27016 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: !isEmpty() && "Nothing selected" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27016 Detailed Report: https://oss-fuzz.com/testcase?key=5732244047265792 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-guard_widening Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !isEmpty() && "Nothing selected" llvm::IRMutationStrategy::mutate llvm::IRMutator::mutateModule Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202005250248 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5732244047265792 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. * UNREPRODUCIBLE * Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days, we've been seeing this crash frequently. It may be possible to reproduce by trying the following options: - Run testcase multiple times for a longer duration. - Run fuzzing without testcase argument to hit the same crash signature. If it still does not reproduce, try a speculative fix based on the crash stacktrace and verify if it works by looking at the crash statistics in the report. We will auto-close the bug if the crash is not seen for 14 days. ** When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you 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 48095] New: Stack memory object managed by a unique_ptr in GCNIterativeScheduler::OverrideLegacyStrategy
https://bugs.llvm.org/show_bug.cgi?id=48095 Bug ID: 48095 Summary: Stack memory object managed by a unique_ptr in GCNIterativeScheduler::OverrideLegacyStrategy Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: alansnape3...@gmail.com CC: llvm-bugs@lists.llvm.org In function GCNIterativeScheduler::scheduleLegacyMaxOccupancy of file llvm/lib/Target/AMDGPU/GCNIterativeScheduler.cpp on line 492, a "stack memory object managed by a unique_ptr" is reported by my clang static analyzer fork. A local variable of GCNMaxOccupancySchedStrategy is created on line 512, then its address is managed by a unique_ptr through the call to the constructor of OverrideLegacyStrategy on line 520 and the call to unique_ptr::reset on line 193. Although the managed local address is released from the unique_ptr on line 202 in the destructor of OverrideLegacyStrategy, it would be better to replace the local variable with a heap memory object, as smart pointers without customized deleters are not originally designed for non-heap memory objects. --- The reported execution path: In function GCNIterativeScheduler::scheduleLegacyMaxOccupancy 512 GCNMaxOccupancySchedStrategy LStrgy(Context); --> Local variable 'LStrgy' is defined. 520 OverrideLegacyStrategy Ovr(*R, LStrgy, *this); --> Local address of variable 'LStrgy' is taken as a reference when calling the constructor of OverrideLegacyStrategy. In function GCNIterativeScheduler::OverrideLegacyStrategy::OverrideLegacyStrategy 193 Sch.SchedImpl.reset(&OverrideStrategy); --> Assign the address of the local variable 'LStrgy' to a unique_ptr. --- Suggested fix: Replace the local variable on line 512 with a unique_ptr or a new-ed memory object. -- 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
