[llvm-bugs] [Bug 45656] New: Wrong alignment of load instruction when load vector cast from other pointer
https://bugs.llvm.org/show_bug.cgi?id=45656 Bug ID: 45656 Summary: Wrong alignment of load instruction when load vector cast from other pointer Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: ju...@linux.alibaba.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk see testcase in https://godbolt.org/z/Fz3vG4 we cast void* ptr to v8si*, and then read it. It seems clang generates the load instruction with alignment of vector type, not the element type which is wrong. when we build with march=core-avx2, llvm emits vmovdqa which may cause seg fault when ptr is not 32byte align. -- 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 45657] New: Bad comment indentation before ifdef after braceless if
https://bugs.llvm.org/show_bug.cgi?id=45657
Bug ID: 45657
Summary: Bad comment indentation before ifdef after braceless
if
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: h...@chromium.org
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Example input:
$ cat /tmp/a.cc
void f() {
if (foo)
bar();
// Comment
#if BAZ
baz();
#endif
}
Example output:
$ bin/clang-format < /tmp/a.cc
void f() {
if (foo)
bar();
// Comment
#if BAZ
baz();
#endif
}
Note that the comment is now overly indented. Inserting a new line after
"baz()" doesn't change it.
(I was using clang-format built from d254b50b2b5b22368780c6003c419ffa1e23fa93)
This was originally filed in Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=1074113
--
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 45656] Wrong alignment of load instruction when load vector cast from other pointer
https://bugs.llvm.org/show_bug.cgi?id=45656 Roman Lebedev changed: What|Removed |Added Resolution|--- |INVALID CC||lebedev...@gmail.com Status|NEW |RESOLVED --- Comment #1 from Roman Lebedev --- (In reply to JunMa from comment #0) > see testcase in https://godbolt.org/z/Fz3vG4 we cast void* ptr to v8si*, and > then read it. > > It seems clang generates the load instruction with alignment of vector type, > not the element type which is wrong. > > when we build with march=core-avx2, llvm emits vmovdqa which may cause seg > fault when ptr is not 32byte align. Yep, and that is UB. You may want to specify that the type is underaligned, e.g. https://godbolt.org/z/8kC6rt -- 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 42889] Sanitizer + -O3 stalls in LLVM backend
https://bugs.llvm.org/show_bug.cgi?id=42889 Dominik Strasser changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Dominik Strasser --- Works fine in clang 10. -- 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 45658] New: Linker error when using LTO with Fuzzer on Windos
https://bugs.llvm.org/show_bug.cgi?id=45658
Bug ID: 45658
Summary: Linker error when using LTO with Fuzzer on Windos
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: markus.boec...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
When using libFuzzer on Windows using clang-cl and LTO (both full and thin) the
linking stage later fails with undefined reference to __sancov_lowest_stack.
Tested cpp file:
#include
#include
extern "C" int LLVMFuzzerTestOneInput(const std::uint8_t* data, std::size_t
size)
{
std::string s(size,' ');
std::memcpy(s.data(),data,size);
std::cout << s;
return 0;
}
CMD:
Input: clang-cl /MT -fsanitize=fuzzer -fuse-ld=lld -flto test.cpp -std:c++17
lld-link: error: undefined symbol: __sancov_lowest_stack
>>> referenced by test.cpp
>>> C:\Users\Markus\AppData\Local\Temp\test-bae0e8.obj
clang-cl: error: linker command failed
with exit code 1 (use -v to see invocation)
--
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 45659] New: SingleSource/UnitTests/Vector/AVX512F/Vector-AVX512F-convert missing link symbol "llvm.x86.avx512.mask.vcvtph2ps.512.v16f32.v16i16.v16f32.i16.i32"
https://bugs.llvm.org/show_bug.cgi?id=45659 Bug ID: 45659 Summary: SingleSource/UnitTests/Vector/AVX512F/Vector-AVX512F-c onvert missing link symbol "llvm.x86.avx512.mask.vcvtph2ps.512.v16f32.v16i16.v16f 32.i16.i32" Product: Test Suite Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Programs Tests Assignee: unassignedb...@nondot.org Reporter: l...@meinersbur.de CC: craig.top...@gmail.com, ilia.tara...@intel.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk Using latest clang 500d378ee5064274ed397b2b904e34c7dae496dd. AFAIK, "llvm.x86.avx512.mask.vcvtph2ps.512.v16f32.v16i16.v16f32.i16.i32" is not supposed to emitted as a library symbol. $ bin/clang --version clang version 11.0.0 (/tmp/persistent/llvm-src/clang 500d378ee5064274ed397b2b904e34c7dae496dd) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /tmp/persistent/llvm-build/bin [1/2] Linking C executable SingleSource/UnitTests/Vector/AVX512F/Vector-AVX512F-convert FAILED: SingleSource/UnitTests/Vector/AVX512F/Vector-AVX512F-convert : && /tmp/runci_temp-iat6b73j/testsuite-build/tools/timeit --summary SingleSource/UnitTests/Vector/AVX512F/Vector-AVX512F-convert.link.time /tmp/persistent/llvm-install/bin/clang -O3 -DNDEBUG SingleSource/UnitTests/Vector/AVX512F/CMakeFiles/Vector-AVX512F-convert.dir/convert.c.o -o SingleSource/UnitTests/Vector/AVX512F/Vector-AVX512F-convert -lm && cd /tmp/runci_temp-iat6b73j/testsuite-build/SingleSource/UnitTests/Vector/AVX512F && /home/meinersbur/install/cmake/release/bin/cmake -E create_symlink /tmp/persistent/testsuite-src/SingleSource/UnitTests/Vector/AVX512F/convert.reference_output /tmp/runci_temp-iat6b73j/testsuite-build/SingleSource/UnitTests/Vector/AVX512F/convert.reference_output SingleSource/UnitTests/Vector/AVX512F/CMakeFiles/Vector-AVX512F-convert.dir/convert.c.o: In function `float16_converts': convert.c:(.text+0x268): undefined reference to `llvm.x86.avx512.mask.vcvtph2ps.512.v16f32.v16i16.v16f32.i16.i32' convert.c:(.text+0x2c9): undefined reference to `llvm.x86.avx512.mask.vcvtph2ps.512.v16f32.v16i16.v16f32.i16.i32' convert.c:(.text+0x324): undefined reference to `llvm.x86.avx512.mask.vcvtph2ps.512.v16f32.v16i16.v16f32.i16.i32' clang-11: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45660] New: [AMDGPU][MC][GFX9+] Encoding of op_sel_hi for VOP3P inline constants does not match sp3
https://bugs.llvm.org/show_bug.cgi?id=45660 Bug ID: 45660 Summary: [AMDGPU][MC][GFX9+] Encoding of op_sel_hi for VOP3P inline constants does not match sp3 Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org This issue has recently been found by Ilya Perminov. In short, sp3 and llvm encode op_sel_hi for VOP3P inline constants differently. For example, sp3 generates the same code for the following lines (gfx9): v_pk_fma_f16 v0, v1, -1.0, v3 // D38E4000 0C0DE701 v_pk_fma_f16 v0, v1, -1.0, v3 op_sel_hi:[1,1,1] // D38E4000 0C0DE701 v_pk_fma_f16 v0, v1, -1.0, v3 op_sel_hi:[1,0,1] // D38E4000 0C0DE701 In other words, it silently encodes op_sel_hi:[1,0,1] regardless of what has been specified in the code. All 3 cases result in the following computations: v0.hi = vi.hi * -1.0 + v3.hi v0.lo = vi.lo * -1.0 + v3.lo In contrast, llvm encodes op_sel_hi specified in the code. When omitted, it results in selection of high 16 bits of -1.0 inline constant for computation of high bits of the result. v_pk_fma_f16 v0, v1, -1.0, v3 ; [0x00,0x40,0x8e,0xd3,0x01,0xe7,0x0d,0x1c] v_pk_fma_f16 v0, v1, -1.0, v3 op_sel_hi:[1,1,1] ; [0x00,0x40,0x8e,0xd3,0x01,0xe7,0x0d,0x1c] v_pk_fma_f16 v0, v1, -1.0, v3 op_sel_hi:[1,0,1] ; [0x00,0x40,0x8e,0xd3,0x01,0xe7,0x0d,0x0c] The last case produces the same code that sp3 does. The first two cases result in computations different from sp3: v0.hi = vi.hi * 0.0 + v3.hi // Probably not what has been intended? v0.lo = vi.lo * -1.0 + v3.lo Note that sp3 uses a different op_sel syntax for gfx10 but this syntax does not allow to specify bits selection for inline constants. sp3 assembler always selects low bits for these. These differences between sp3 and llvm will confuse assembler users. We could correct llvm assembler to make it behave like sp3 (at least when op_sel_hi is omitted). What do you think? -- 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 45661] New: llvm-ar works wrong with thin archives containing object files of same name
https://bugs.llvm.org/show_bug.cgi?id=45661 Bug ID: 45661 Summary: llvm-ar works wrong with thin archives containing object files of same name Product: lld Version: unspecified Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: qwertyt...@gmail.com CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com For simplicity, I've prepared several bash files designed to be some sort of PoC. 0.prepare_object_files.sh ``` #!/bin/bash mkdir -p keyboard mkdir -p mouse touch keyboard/click.o touch mouse/click.o ``` 1.create_thin_archive.sh ``` #!/bin/bash # set 1st argument as binutil's ar or llvm-ar AR="$1" rm -f mouse/built-in.o rm -f keyboard/built-in.o rm -f built-in.o $AR -rcST mouse/built-in.o mouse/click.o \ && \ $AR -rcST keyboard/built-in.o keyboard/click.o \ && \ $AR -rcST built-in.o mouse/built-in.o keyboard/built-in.o \ && \ cat built-in.o ``` To prepare environment (.o files and folders) run: ``` ./0.prepare_object_files.sh ``` After this, run PoC with binutil's ar: ``` ./1.create_thin_archive.sh ar ``` we'll get following output: ``` ! // 34` mouse/click.o/ keyboard/click.o/ ... ``` After we run PoC with llvm-ar: ``` ./1.create_thin_archive.sh llvm-ar ``` we'll get following output: ``` ! // 18` click.o/ click.o/ ... ``` And here is a problem. Both click.o files located at the same directory level inside of thin archive, generated by llvm-ar. -- 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 21851 in oss-fuzz: llvm:clang-format-fuzzer: ASSERT: Shift >= 0
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 21851 by ClusterFuzz-External: llvm:clang-format-fuzzer: ASSERT: Shift >= 0 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21851#c1 ClusterFuzz testcase 5189049418776576 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202004230249:202004240246 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 21858 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::InnerLoopVectorizer::getOrCreateVectorValue
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-04-24 Type: Bug New issue 21858 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Null-dereference READ in llvm::InnerLoopVectorizer::getOrCreateVectorValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21858 Detailed Report: https://oss-fuzz.com/testcase?key=4917131507662848 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: llvm::InnerLoopVectorizer::getOrCreateVectorValue llvm::VPTransformState::get llvm::InnerLoopVectorizer::widenInstruction Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202004230249:202004240246 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4917131507662848 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 45510] Failure to optimize certain kind of always-true comparisons
https://bugs.llvm.org/show_bug.cgi?id=45510 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||e86eff0e82d1, 62da6ecea298 Status|NEW |RESOLVED --- Comment #4 from Sanjay Patel --- We settled on 2 different patches to solve this generally: https://reviews.llvm.org/rGe86eff0e82d1 https://reviews.llvm.org/rG62da6ecea298 So marking as fixed. However, there is a known regression with the 2nd patch as mentioned here: https://reviews.llvm.org/D78582 I'm still trying to repro that or figure out what went wrong from that diff. If we need to revert, then we should reopen this bug. -- 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 45662] New: FileCheck reports wrong directive on failure
https://bugs.llvm.org/show_bug.cgi?id=45662
Bug ID: 45662
Summary: FileCheck reports wrong directive on failure
Product: Test Suite
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: lit
Assignee: unassignedb...@nondot.org
Reporter: paul_robin...@playstation.sony.com
CC: dan...@zuster.org, llvm-bugs@lists.llvm.org
F:\scratch\Filecheck-bug>type test.txt
100
200
# A: {{1}}00
# B-NOT: {{2}}00
F:\scratch\Filecheck-bug>d:\upstream\nbuild\bin\FileCheck.exe test.txt
--input-file test.txt --check-prefixes=A,B
test.txt:4:10: error: A-NOT: excluded string found in input
# B-NOT: {{2}}00
^
test.txt:2:1: note: found here
200
^~~
Clearly the mismatch should report B-NOT rather than A-NOT.
This is with HEAD at de94715b64ba048728cb1c4ba88a5ac51066d61b
(last Friday).
--
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 45478] Incorrect transformation of minnum with nnan flag
https://bugs.llvm.org/show_bug.cgi?id=45478 Sanjay Patel changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||e4175ff5256 --- Comment #10 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rGe4175ff52561 -- 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 45663] New: C++20 template Constraints doesn't evaluate the current calling context
https://bugs.llvm.org/show_bug.cgi?id=45663 Bug ID: 45663 Summary: C++20 template Constraints doesn't evaluate the current calling context Product: clang Version: 10.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: sharkli...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 23399 --> https://bugs.llvm.org/attachment.cgi?id=23399&action=edit Self-describing source code copy, from godbolt.org link.Feel free to test the code When a template instantiation attempt occur, the compiler seems to cache the resulting instantiation attempt details. The contraints evaluation along with the template are not further evaluated correctly when further template instantiations are called, even if constraint argument's context has changed. This lead to valid constraint evaluation failure. And so, it fails to instantiate specialized template, or function template overload. The details of such context change evaluation failure can be seen on this link : https://godbolt.org/z/QMU6YC (This is MAtt Godbolt's website 'Compiler Explorer') or a copy code from that link below as an attachment. It explains step by step my testing context, and what I expected. This testing context focus on : - a concept testing inheritance (with pointer conversion requires), - a template class 'Zeta' with template constructor overload using this concept as a constraint, - two classes 'Alpha' and 'Beta' with inheritance relationship, but the 'Beta' derived class is forward declared, - some 'Ss' class definitions with a 'Zeta' data member, declaring two constructors using 'Zeta' and 'Zeta' as arguments, causing 'Zeta' constrained template constructor to be evaluated as a conversion constructor, while 'Beta' is still not defined, Note : 'Zeta' matching type argument copy-constructor is intended. - 'Beta' defined as derived from 'Alpha' and using 'Ss' class definition (so it need to be defined late), - valid 'Ss' constructors definition : using 'Zeta' to 'Zeta' constrained template conversion-constructor instantiation, as 'Beta' is now defined as inheriting 'Alpha'. Problem summary : - 'Beta' inheriting 'Alpha' Constraint evaluate to false, when 'Beta' is already defined as inheriting 'Alpha'. Expected : - 'Zeta' to 'Zeta' constrained conversion overload is selected, as constraints are satisfied. -- 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 41285] loop-extract-single makes function broken with "opt -loop-extract-single"
https://bugs.llvm.org/show_bug.cgi?id=41285 Ehud Katz changed: What|Removed |Added Status|NEW |RESOLVED CC||ehudk...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Ehud Katz --- *** This bug has been marked as a duplicate of bug 42451 *** -- 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 40900] opt cannot terminate with "opt -simplifycfg -loop-extract"
https://bugs.llvm.org/show_bug.cgi?id=40900 Ehud Katz changed: What|Removed |Added Status|NEW |RESOLVED CC||ehudk...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Ehud Katz --- *** This bug has been marked as a duplicate of bug 3082 *** -- 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 45659] SingleSource/UnitTests/Vector/AVX512F/Vector-AVX512F-convert missing link symbol "llvm.x86.avx512.mask.vcvtph2ps.512.v16f32.v16i16.v16f32.i16.i32"
https://bugs.llvm.org/show_bug.cgi?id=45659 Craig Topper changed: What|Removed |Added Fixed By Commit(s)||0ed5b0d517cb781d4949cc4bfa9 ||854bc276ee13a Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Craig Topper --- Should be fixed after 0ed5b0d517cb781d4949cc4bfa9854bc276ee13a -- 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 40950] opt cannot terminate with "opt -loop-rotate -loop-extract"
https://bugs.llvm.org/show_bug.cgi?id=40950 Ehud Katz changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||ehudk...@gmail.com --- Comment #1 from Ehud Katz --- *** This bug has been marked as a duplicate of bug 3082 *** -- 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 40937] opt cannot terminate with "opt -instcombine -structurizecfg -loop-extract -loop-rotate -newgvn -loop-versioning -loop-extract"
https://bugs.llvm.org/show_bug.cgi?id=40937 Ehud Katz changed: What|Removed |Added Status|NEW |RESOLVED CC||ehudk...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Ehud Katz --- *** This bug has been marked as a duplicate of bug 3082 *** -- 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 40938] opt crashes with "opt -newgvn -inline -licm -loop-extract -ipsccp -adce" : Assertion `CallSites.empty() && "Dangling pointers found in call sites map"' failed.
https://bugs.llvm.org/show_bug.cgi?id=40938 Ehud Katz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||ehudk...@gmail.com --- Comment #1 from Ehud Katz --- Fixed in LLVM 9.0.0 release (https://github.com/llvm-mirror/llvm c62b24f070c9a4bb1a76409e623042a740cac4cd) -- 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 41287] opt crashes with "opt -loop-extract-single -adce"
https://bugs.llvm.org/show_bug.cgi?id=41287 Ehud Katz changed: What|Removed |Added CC||ehudk...@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Ehud Katz --- Fixed in LLVM 9.0.0 release (https://github.com/llvm-mirror/llvm c62b24f070c9a4bb1a76409e623042a740cac4cd) -- 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 40895] Consuming too much memory for "opt -mergereturn -loop-extract"
https://bugs.llvm.org/show_bug.cgi?id=40895 Ehud Katz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||ehudk...@gmail.com --- Comment #1 from Ehud Katz --- *** This bug has been marked as a duplicate of bug 3082 *** -- 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 7829] -loop-extract crash "Invalid DominatorTree info!"
https://bugs.llvm.org/show_bug.cgi?id=7829 Ehud Katz changed: What|Removed |Added Status|NEW |RESOLVED CC||ehudk...@gmail.com 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 42016] opt crashes with "opt -early-cse -indvars -sroa -lowerswitch -loop-unswitch -licm -loop-extract-single -inline"
https://bugs.llvm.org/show_bug.cgi?id=42016 Ehud Katz changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||rL365660 CC||ehudk...@gmail.com -- 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 41697] loop-extract-single makes function broken with "opt -newgvn -loop-unswitch -licm -loop-extract-single"
https://bugs.llvm.org/show_bug.cgi?id=41697 Ehud Katz changed: What|Removed |Added CC||ehudk...@gmail.com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ehud Katz --- *** This bug has been marked as a duplicate of bug 42451 *** -- 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 40899] opt crashes with "opt -sroa -lcssa -indvars": Assertion `L->isRecursivelyLCSSAForm(*DT, *LI) && "Requested to preserve LCSSA, but it's already broken."' failed.
https://bugs.llvm.org/show_bug.cgi?id=40899 Ehud Katz changed: What|Removed |Added Status|NEW |RESOLVED CC||ehudk...@gmail.com Resolution|--- |FIXED --- Comment #2 from Ehud Katz --- Fixed in LLVM 9.0.0 release (https://github.com/llvm-mirror/llvm c62b24f070c9a4bb1a76409e623042a740cac4cd) -- 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 41321] Module Verifier crashes with "opt -ipsccp -loop-distribute": Instruction operands must be first-class values!
https://bugs.llvm.org/show_bug.cgi?id=41321 Ehud Katz changed: What|Removed |Added CC||ehudk...@gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ehud Katz --- Fixed in LLVM 9.0.0 release (https://github.com/llvm-mirror/llvm c62b24f070c9a4bb1a76409e623042a740cac4cd) -- 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 45664] New: Please merge e98f73a62907 into 10.0.1
https://bugs.llvm.org/show_bug.cgi?id=45664 Bug ID: 45664 Summary: Please merge e98f73a62907 into 10.0.1 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: alexandre.ga...@ubisoft.com CC: h...@chromium.org, llvm-bugs@lists.llvm.org Blocks: 45309 https://reviews.llvm.org/rGe98f73a629075ae3b9c4d5317bead5a122d69865 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=45309 [Bug 45309] [meta] 10.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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45666] New: [InstCombine] reduce icmp ult with or operand
https://bugs.llvm.org/show_bug.cgi?id=45666
Bug ID: 45666
Summary: [InstCombine] reduce icmp ult with or operand
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
define i1 @cmp_or_limit(i8 %x) {
%or = or i8 %x, 5
%cmp = icmp ult i8 %or, 43
ret i1 %cmp
}
This can reduce to:
define i1 @cmp_or_limit(i8 %x) {
%R = icmp ult i8 %x, 40
ret i1 %R
}
http://volta.cs.utah.edu:8080/z/k3sykE
I think there's some leading zeros + masking relationship for those constants
that we're not getting.
The old Alive lets us specify constant preconditions. Is there an equivalent
with Alive2?
--
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 21866 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-04-25 Type: Bug New issue 21866 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21866 Detailed Report: https://oss-fuzz.com/testcase?key=5711748507369472 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc5d2a9bd8 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202004210249:202004220553 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5711748507369472 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 45667] New: FoldBranchToCommonDest in SimplifyCFG can invalidate dbg.value operands
https://bugs.llvm.org/show_bug.cgi?id=45667
Bug ID: 45667
Summary: FoldBranchToCommonDest in SimplifyCFG can invalidate
dbg.value operands
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: ri...@rzhou.org
CC: llvm-bugs@lists.llvm.org
Reproduction case:
Compiling the following program (https://godbolt.org/z/y2nzqR):
```
int main(int argc, char** argv) {
bool a = false;
bool b = false;
bool c = false;
[&a, &b, &c] { b = true; }();
if (a || b || c) {
__builtin_debugtrap();
}
return 0;
}
```
with
```
clang++ -O1 -g -fno-exceptions -o test test.cc
```
produces incorrect DWARF debugging information for the "b" variable. This can
be seen by running the program in lldb and printing "b" at the breakpoint:
```
$ lldb ~/test
(lldb) target create ".../test"
Current executable set to '.../test' (x86_64).
(lldb) r
Process 90101 launched: '.../test' (x86_64)
Process 90101 stopped
* thread #1, name = 'test', stop reason = signal SIGTRAP
frame #0: 0x0040115a test`main(argc=,
argv=) at test.cc:12:1
9 }
10
11 return 0;
-> 12 }
(lldb) p b
(bool) $0 = false
```
The LLVM IR at the goldbolt link shows the issue. When "a", "b", and "c" are
initialized to 0, the original dbg.declare for these variables is replaced with
a dbg.value:
```
...
call void @llvm.dbg.value(metadata i8 0, metadata !18, metadata
!DIExpression()), !dbg !22
store i8 0, i8* %a, align 1, !dbg !24, !tbaa !25
call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull %b) #3, !dbg !29
call void @llvm.dbg.value(metadata i8 0, metadata !20, metadata
!DIExpression()), !dbg !22
store i8 0, i8* %b, align 1, !dbg !30, !tbaa !25
call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull %c) #3, !dbg !31
call void @llvm.dbg.value(metadata i8 0, metadata !21, metadata
!DIExpression()), !dbg !22
store i8 0, i8* %c, align 1, !dbg !32, !tbaa !25
... call to lambda ...
%4 = load i8, i8* %a, align 1, !dbg !36, !tbaa !25, !range !38
call void @llvm.dbg.value(metadata i8 %4, metadata !18, metadata
!DIExpression()), !dbg !22
%5 = load i8, i8* %b, align 1, !dbg !39
%6 = or i8 %5, %4, !dbg !40
%7 = load i8, i8* %c, align 1, !dbg !41
%8 = or i8 %6, %7, !dbg !40
...
```
when "a" is loaded after calling the lambda, we emit an updated dbg.value for
it. However, "b" and "c" do not get one.
I into where this breaks by compiling with `-mllvm -print-after-all -mllvm
-print-before-all`, and found that there were valid-looking dbg.value
intrinsics the loads of "b" and "c" a "Simplify the CFG" phase invalidated
them, replacing them with a call like this:
```
!2 = !{}
...
call void @llvm.dbg.value(metadata !2, metadata !20, metadata
!DIExpression()), !dbg !30
```
Then an "Early CSE w/ MemorySSA" phase discards these intrinsics entirely, as
they fail this test:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Utils/Local.cpp#L385
The transformation producing the invalidated dbg.value appears to be
SimplifyCFG rewriting:
```
if (a)
if (b)
if (c) ...
```
to
```
if (a || b || c) ...
```
Looking at the code that does this,
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Utils/SimplifyCFG.cpp#L2731-L2749
appears to clone some instructions into a different basic block.
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Utils/SimplifyCFG.cpp#L2868-L2870
then clones dbg intrinsics over, but does not update their operands to point to
the appropriate cloned values.
The following patch fixes up the dbg.value operands for me and causes
correct-looking debug info to be generated:
```
diff --git a/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
b/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
index be5a375a2cf..73db4728ef3 100644
--- a/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ b/llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -2898,9 +2898,14 @@ bool llvm::FoldBranchToCommonDest(BranchInst *BI,
MemorySSAUpdater *MSSAU,
// could replace PBI's branch probabilities with BI's.
// Copy any debug value intrinsics into the end of PredBlock.
-for (Instruction &I : *BB)
- if (isa(I))
-I.clone()->insertBefore(PBI);
+for (Instruction &I : *BB) {
+ if (isa(I)) {
+Instruction *NewI = I.clone();
+RemapInstruction(NewI, VMap,
+ RF_NoModuleLevelChanges | RF_IgnoreMissingLocals);
+NewI->insertBefore(PBI);
+ }
+}
return true;
}
```
Note that even with this patch, the generated DWARF information is not ideal.
"b" becomes "optimized out" at the breakpoint, even though it is on the stack.
It seems that replacing dbg.declare with dbg.value was counterproductive in
this case.
--
You are rec
