[llvm-bugs] [Bug 46071] New: Linker out of memory with CMake and Visual Studio Generator
https://bugs.llvm.org/show_bug.cgi?id=46071 Bug ID: 46071 Summary: Linker out of memory with CMake and Visual Studio Generator Product: clang Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: vincenzo.ferrazz...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk I have a VS project that I have been migrating to CMAKE in order to be able to compile with MSVC and ClangCL. If I use Ninja as generator everything works fine, but when I switch to Visual Studio 19, I obtain the following error: -- Building Custom Rule C:/sw_source/SEM.Maeve/test/GCoreTest/CMakeLists.txt C:\sw_source\SEM.Maeve\out\build\VS-Clang-Release\EXEC : LLVM error : out of memory Stack dump: 0. Program arguments: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\bin\clang-cl.exe -cc1 -triple x86_64-pc-windows-msvc19.26.28805 -emit-obj -mincremental-linker-compatible -disable-free -disable-llvm-verifier -discard-value-names -main-file-name BaseActionGeneratorTest.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames -stack-protector 2 -fcxx-exceptions -fexceptions -fexternc-nounwind -fms-volatile -fdefault-calling-conv=cdecl -fdiagnostics-format msvc -gcodeview -debug-info-kind=limited -ffunction-sections -resource-dir C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\lib\clang\10.0.0 -include-pch C:/sw_source/SEM.Maeve/out/build/VS-Clang-Release/test/GCoreTest/GCoreTest.dir/RelWithDebInfo/cmake_pch.pch -pch-through-header=C:/sw_source/SEM.Maeve/out/build/VS-Clang-Release/test/GCoreTest/CMakeFiles/GCoreTest.dir/RelWithDebInfo/cmake_pch.hxx -include C:/sw_source/SEM.Maeve/out/build/VS-Clang-Release/test/GCoreTest/CMakeFiles/GCoreTest.dir/RelWithDebInfo/cmake_pch.hxx -I C:\sw_source\SEM.Maeve\deps\googletest\googletest\include -I C:\sw_source\SEM.Maeve\deps\nlohmann\include -I C:\sw_source\SEM.Maeve\deps\armadillo\include -I C:\sw_source\SEM.Maeve\deps\libdivide -I C:\sw_source\SEM.Maeve\src\MaeveAPI -I C:\sw_source\SEM.Maeve\src\MaeveAPI\api -I C:\sw_source\SEM.Maeve\deps\protobuf\src -I C:\sw_source\SEM.Maeve\src\MaeveCoreCpp -I C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019\windows\mkl\include -D WIN32 -D _WINDOWS -D NDEBUG -D CMAKE_INTDIR="RelWithDebInfo" -D _MBCS -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\lib\clang\10.0.0\include -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\atlmfc\include -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\VS\include -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\VS\UnitTest\include -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\winrt -internal-isystem C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\cppwinrt -internal-isystem C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\Include\um -O2 -WCL4 -Werror -fdeprecated-macro -fdebug-compilation-dir C:\sw_source\SEM.Maeve\out\build\VS-Clang-Release\test\GCoreTest -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.26.28805 -std=c++17 -fdelayed-template-parsing -finline-hint-functions -fobjc-runtime=gcc -fno-caret-diagnostics -fdiagnostics-show-option -vectorize-loops -vectorize-slp -fopenmp -faddrsig -o GCoreTest.dir\RelWithDebInfo\BaseActionGeneratorTest.obj -x c++ C:\sw_source\SEM.Maeve\test\GCoreTest\BaseActionGeneratorTest.cpp 1.parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'C:\sw_source\SEM.Maeve\test\GCoreTest\BaseActionGeneratorTest.cpp'. 4. Running pass 'X86 Assembly Printer' on function '@"??0?$LinearActionGenerator@$01$04$00N@actions@maeve@@QEAA@V?$shared_ptr@V?$BaseGrid@$01$04N@grid@maeve@@@std@@_KN1@Z"'
[llvm-bugs] [Bug 46072] New: access to scope enum through variable not possible
https://bugs.llvm.org/show_bug.cgi?id=46072
Bug ID: 46072
Summary: access to scope enum through variable not possible
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: tobias.l...@steag.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following code does not compile on trunk (using godbolt.org)
When "enum class test" is replaced by "enum test" it works fine!
///
class aa{
public:
enum class test{
d,f,g
};
};
int main(){
aa aa_;
aa::test test_ = aa_.test::f;
}
//
:14:32: error: 'aa::test::f' is not a member of class 'aa'
aa::test test_ = aa_.test::f;
~~^
1 error generated.
Compiler returned: 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41588] Assertion failure: StaticAnalyzer/Core/RangeConstraintManager.cpp:63: const llvm::APSInt &clang::ento::RangeSet::getMinValue() const: Assertion `!isEmp ty()' failed.
https://bugs.llvm.org/show_bug.cgi?id=41588 Denys Petrov changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Denys Petrov --- Fix landed. -- 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 40502] Failure to merge repeated blend shuffles
https://bugs.llvm.org/show_bug.cgi?id=40502 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||9fa58d1bf2f8 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Simon Pilgrim --- (In reply to Simon Pilgrim from comment #1) > Candidate DAG patch: https://reviews.llvm.org/D79003 This landed at rG9fa58d1bf2f8, more complex/deeper chains might still cause a problem but basic cases like this (and what SLP's AltOpcode mechanism will generate) should now be handled. -- 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 45465] Feature request: Add capability to emulate earlier versions
https://bugs.llvm.org/show_bug.cgi?id=45465 MyDeveloperDay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from MyDeveloperDay --- The more I think about this the more I think the only changes we add version to version that would change the layout tends to be bug fixes, we are pretty strict about not changing tests so we expect the code to be stable as much as possible. And we are NOT going to emulate bug fixes when a better solution is for individual users to have control over which versions of clang-format they use My advice is live at trunk, always upgrade clang-format to the latest version, take the hit of doing a clang-format every time you upgrade (much as you have to take a hit when you upgrade a compiler that comes with a whole load more warnings) I'm also pretty sure git has a mechanism to ignore certain revisions, which means I believe you can exclude your "clang-format all the things" type commits and they won't show up in the blame history. blame.ignoreRevsFile https://reviews.llvm.org/D67145 -- 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 46073] New: Missing calling convention support for vector types
https://bugs.llvm.org/show_bug.cgi?id=46073 Bug ID: 46073 Summary: Missing calling convention support for vector types Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: Sparc Assignee: unassignedb...@nondot.org Reporter: jo...@netbsd.org CC: llvm-bugs@lists.llvm.org Created attachment 23531 --> https://bugs.llvm.org/attachment.cgi?id=23531&action=edit Minimal test case Try compiling the attached code, it will assert in SparcTargetLowering::LowerCall_32 respectively LowerCall_64 due to the missing lowering for 16x16 vector types. -- 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 22524 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: (UserVF || isPowerOf2_32(MaxVF)) && "MaxVF must be a power of 2"
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-05-26 Type: Bug New issue 22524 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: (UserVF || isPowerOf2_32(MaxVF)) && "MaxVF must be a power of 2" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22524 Detailed Report: https://oss-fuzz.com/testcase?key=5640099684679680 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (UserVF || isPowerOf2_32(MaxVF)) && "MaxVF must be a power of 2" llvm::LoopVectorizationCostModel::computeMaxVF llvm::LoopVectorizationPlanner::plan Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202005250248:202005260248 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5640099684679680 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 46074] New: Wrong Line Information at Og
https://bugs.llvm.org/show_bug.cgi?id=46074
Bug ID: 46074
Summary: Wrong Line Information at Og
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: massare...@diag.uniroma1.it
CC: ditali...@apple.com, jdevliegh...@apple.com,
keith.wal...@arm.com, llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Line 8 should not be hit.
$ cat a.c
typedef int int32_t;
int a, b, c;
static int32_t d;
static char e;
char(f)(char g) { return g >> a; }
int main() {
for (; d < 9; ++d) {
int32_t l_273[2][4][1];
c = 0;
for (; c < 4; c++)
l_273[0][c][0] = 0;
b = f(e--);
l_273[0][3][0] |= b;
}
}
$ clang -v
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
268fa40daa151d3b4bff1df12b62e5dae94685d7)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
$ lldb -v
lldb version 11.0.0
clang revision 268fa40daa151d3b4bff1df12b62e5dae94685d7
llvm revision 268fa40daa151d3b4bff1df12b62e5dae94685d7
$ clang -Og -g -o opt a.c
$ lldb opt
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b main
Breakpoint 1: where = opt`main + 7 at a.c:7:3, address = 0x00400497
(lldb) r
Process 65 launched: 'opt' (x86_64)
Process 65 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
frame #0: 0x00400497 opt`main at a.c:7:3
4static char e;
5char(f)(char g) { return g >> a; }
6int main() {
-> 7 for (; d < 9; ++d) {
8int32_t l_273[2][4][1];
9c = 0;
10 for (; c < 4; c++)
(lldb) s
Process 65 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004b0 opt`main at a.c:8:5
5char(f)(char g) { return g >> a; }
6int main() {
7 for (; d < 9; ++d) {
-> 8int32_t l_273[2][4][1];
9c = 0;
10 for (; c < 4; c++)
11 l_273[0][c][0] = 0;
(lldb) di
opt`main:
0x400490 <+0>: pushq %r14
0x400492 <+2>: pushq %rbx
0x400493 <+3>: subq $0x28, %rsp
0x400497 <+7>: cmpb $0x0, 0x200b92(%rip) ; a + 3
0x40049e <+14>: jne0x4004ef ; <+95> at a.c:15:1
0x4004a0 <+16>: movzbl 0x200b90(%rip), %r14d ; e
0x4004a8 <+24>: xorl %ebx, %ebx
0x4004aa <+26>: nopw (%rax,%rax)
-> 0x4004b0 <+32>: leal (%r14,%rbx), %eax
0x4004b4 <+36>: xorps %xmm0, %xmm0
0x4004b7 <+39>: movaps %xmm0, (%rsp)
0x4004bb <+43>: movl $0x4, 0x200b6f(%rip) ; d
0x4004c5 <+53>: movsbl %al, %edi
0x4004c8 <+56>: callq 0x400480 ; f at a.c:5
0x4004cd <+61>: movsbl %al, %eax
0x4004d0 <+64>: movl %eax, 0x200b66(%rip) ; b
0x4004d6 <+70>: addl $-0x1, %ebx
0x4004d9 <+73>: cmpl $-0x9, %ebx
0x4004dc <+76>: jne0x4004b0 ; <+32> at a.c:8:5
0x4004de <+78>: addl %ebx, %r14d
0x4004e1 <+81>: movb %r14b, 0x200b50(%rip) ; e
0x4004e8 <+88>: movb $0x1, 0x200b41(%rip) ; a + 3
0x4004ef <+95>: xorl %eax, %eax
0x4004f1 <+97>: addq $0x28, %rsp
0x4004f5 <+101>: popq %rbx
0x4004f6 <+102>: popq %r14
0x4004f8 <+104>: retq
(lldb) s
Process 65 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004b4 opt`main at a.c:11:22
8int32_t l_273[2][4][1];
9c = 0;
10 for (; c < 4; c++)
-> 11 l_273[0][c][0] = 0;
12 b = f(e--);
13 l_273[0][3][0] |= b;
14 }
(lldb) s
Process 65 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004c5 opt`main at a.c:12:9
9c = 0;
10 for (; c < 4; c++)
11 l_273[0][c][0] = 0;
-> 12 b = f(e--);
13 l_273[0][3][0] |= b;
14 }
15 }
--
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 45076] ASAN lit test fails when linked with LLD on PowerPC64 and run with ASLR enabled.
https://bugs.llvm.org/show_bug.cgi?id=45076 Nemanja Ivanovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 46075] New: Failure to produce vxorps to avoid latency on AVX operations
https://bugs.llvm.org/show_bug.cgi?id=46075
Bug ID: 46075
Summary: Failure to produce vxorps to avoid latency on AVX
operations
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
double f(double x, int i)
{
return x * i;
}
With `-O3 -mavx2`, Clang produces this :
f(double, int): # @f(double, int)
vcvtsi2sd xmm1, xmm1, edi
vmulsd xmm0, xmm1, xmm0
ret
GCC produces this :
f(double, int):
vmovsd xmm1, xmm0, xmm0
vxorps xmm0, xmm0, xmm0
vcvtsi2sd xmm0, xmm0, edi
vmulsd xmm0, xmm0, xmm1
ret
According to GCC developers on here :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954, using `vxorps` avoids a
latency which is caused by non-zeroing an AVX register before using it. This
seems to affect literally all X86 processors (as GCC uses `vxorps` for them
all) and Clang uses `vxorps` for none.
--
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 45926] [AMDGPU][MC][GFX8+] Instructions v_sub_u16_e64, v_subrev_u16_e64 and v_add_u16_e64 do not support clamp modifier
https://bugs.llvm.org/show_bug.cgi?id=45926 Dmitry changed: What|Removed |Added Fixed By Commit(s)||77aec3b Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46076] New: arm64be fails with -fsanitize=shadow-call-stack
https://bugs.llvm.org/show_bug.cgi?id=46076 Bug ID: 46076 Summary: arm64be fails with -fsanitize=shadow-call-stack Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: a...@linaro.org CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Building the Linux kernel with the newly added support for -fsanitize=shadow-call-stack fails on big-endian platforms with: clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux' I have submitted a workaround for the kernel, but this is likely a bug in clang and there may be no technical reason to prevent the combination. -- 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 22539 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::report_bad_alloc_error
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-05-26 Type: Bug New issue 22539 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::report_bad_alloc_error https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22539 Detailed Report: https://oss-fuzz.com/testcase?key=4827812417765376 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::report_bad_alloc_error llvm::SmallVectorBase::grow_pod llvm::Error llvm::object::Decompressor::resizeAndDecompresshttps://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201807110801:201807230239 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4827812417765376 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 46077] New: __builtin_isnan/__builtin_isfinite should not produce poison with -ffinite-math-only
https://bugs.llvm.org/show_bug.cgi?id=46077
Bug ID: 46077
Summary: __builtin_isnan/__builtin_isfinite should not produce
poison with -ffinite-math-only
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: matthew.arsena...@amd.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
With -ffinite-math-only, I would intuitively expect __builtin_isnan to always
return false, and __builtin_isfinite to always return true. This would allow
compiling a fast and slow version of the same math library sources, where the
special case paths are naturally optimized out in the fast variant of the
library.
However, if I look at the IR produced and reading the LangRef, I believe these
will currently return poison.
For these basic test functions:
bool test_isnan(float x) {
return __builtin_isnan(x);
}
bool test_isfinite(float x) {
return __builtin_isfinite(x);
}
I currently get this IR:
define hidden zeroext i1 @test_isnan(float %0) #0 {
%2 = alloca float, align 4, addrspace(5)
store float %0, float addrspace(5)* %2, align 4, !tbaa !5
%3 = load float, float addrspace(5)* %2, align 4, !tbaa !5
%4 = fcmp nnan ninf uno float %3, %3
ret i1 %4
}
define hidden zeroext i1 @test_isfinite(float %0) #0 {
%2 = alloca float, align 4, addrspace(5)
store float %0, float addrspace(5)* %2, align 4, !tbaa !5
%3 = load float, float addrspace(5)* %2, align 4, !tbaa !5
%4 = call nnan ninf float @llvm.fabs.f32(float %3) #2
%5 = fcmp nnan ninf one float %4, 0x7FF0
ret i1 %5
}
The description for fast math flags states that the return value is poison if
an input is a nan/inf with the corresponding flag. This is trivially violated
in the isfinite case since a compare to a constant infinity.
I think the correct solution is to not emit the nnan/ninf flags when emitting
these builtins.
--
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 46078] New: out-of-tree build can't find runtime/config.h
https://bugs.llvm.org/show_bug.cgi?id=46078 Bug ID: 46078 Summary: out-of-tree build can't find runtime/config.h Product: flang Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Build System Assignee: unassignedb...@nondot.org Reporter: tke...@nvidia.com CC: david.tr...@arm.com, jper...@nvidia.com, llvm-bugs@lists.llvm.org, sscalp...@nvidia.com In an in-tree build, config.h is generated in /tools/flang/runtime/config.h. runtime/io-error.cpp is compiled with -Itools/flang/runtime so it config.h is found okay. In an out-of-tree build, config.h is generated in /runtime/config.h but runtime/io-error.cpp is compiled with -I../../include -Iinclude so config.h is not found. -- 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 46079] New: Failure to use vfmadd132sd when appropriate
https://bugs.llvm.org/show_bug.cgi?id=46079
Bug ID: 46079
Summary: Failure to use vfmadd132sd when appropriate
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
double f(double a, double b, double c)
{
return a * b + c;
}
When compiled with `-O3 -mavx512f`, GCC produces this :
f(double, double, double):
vfmadd132sd xmm0, xmm2, xmm1
ret
Clang produces this :
f(double, double, double): # @f(double, double, double)
vmulsd xmm0, xmm0, xmm1
vaddsd xmm0, xmm0, xmm2
ret
--
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 44506] [PowerPC] Assertion failed: ((N->getSimpleValueType(0) == MVT::i64 || N->getSimpleValueType(0) == MVT::i32) && "Expecting either i64 or i32 here."), function mayUseP9Setb
https://bugs.llvm.org/show_bug.cgi?id=44506 Justin Hibbits changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Justin Hibbits --- (In reply to Nemanja Ivanovic from comment #2) > This should have been fixed with the fix to > https://bugs.llvm.org/show_bug.cgi?id=45448 > (5fe2809447398dd53ef6179e8c551356600296fc) > > Can you please confirm? Looks like it's fixed now, thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 22549 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::NumericLiteralParser::GetFloatValue
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-05-26 Type: Bug New issue 22549 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::NumericLiteralParser::GetFloatValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22549 Detailed Report: https://oss-fuzz.com/testcase?key=5663159666081792 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd63e54d68 Crash State: clang::NumericLiteralParser::GetFloatValue BuildFloatingLiteral clang::Sema::ActOnNumericConstant Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202005220247:202005230248 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5663159666081792 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 46080] New: Cannot build with -mavx512f at all
https://bugs.llvm.org/show_bug.cgi?id=46080 Bug ID: 46080 Summary: Cannot build with -mavx512f at all Product: compiler-rt Version: 10.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: meldaproduct...@gmail.com CC: llvm-bugs@lists.llvm.org In the LLVM coming with the newest XCode I cannot use -mavx512f (or any AVX512 set for that matter), because the compiler freezes otherwise - it ends up in some sort of deadlock and "compiles" forever. Recently I reported similar thing for Windows, where it was crashing instead and adding AVX512BW fixed it for now, but it doesn't seem to do the trick here. -- 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 45186] DAGCombiner::Run infinite loop / memory leak
https://bugs.llvm.org/show_bug.cgi?id=45186 Nemanja Ivanovic changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||https://reviews.llvm.org/rG ||099a875f28d0131a6ae85af91b9 ||eb8627917fbbe -- 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 46081] New: Consecutive and adjacent calls to memcpy are not merged.
https://bugs.llvm.org/show_bug.cgi?id=46081 Bug ID: 46081 Summary: Consecutive and adjacent calls to memcpy are not merged. Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: peter.ford...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk In this example memcpy is called 1024 times with consequtive calls to directly adjacent ememory locations. This could be reduce to a single call to memcpy. https://godbolt.org/z/taKi4G Replacing the assignment in the loop with std::copy, here https://godbolt.org/z/H3DsN9 correctly only calls memcpy once. -- 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 46082] New: Consequtive calls to memset with adjacent ranges aren't merged.
https://bugs.llvm.org/show_bug.cgi?id=46082 Bug ID: 46082 Summary: Consequtive calls to memset with adjacent ranges aren't merged. Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: peter.ford...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk In this example metset is called twice with consequtive calls to directly adjacent ememory locations. This could be reduced to a single call to memset. https://godbolt.org/z/zjHf2i -- 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 46083] New: Missed instcombine OR optimization due to ordering of OR operands
https://bugs.llvm.org/show_bug.cgi?id=46083
Bug ID: 46083
Summary: Missed instcombine OR optimization due to ordering of
OR operands
Product: tools
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: dorit.nuz...@intel.com
CC: llvm-bugs@lists.llvm.org
Created attachment 23532
--> https://bugs.llvm.org/attachment.cgi?id=23532&action=edit
Input ll which Instcombine can't optimize
The only difference between the attached inputs is the order of operands in the
OR instruction.
With the "good" ordering ("or <16 x i1> %9, %6") instcombine is able to
optimize away the OR and creates this much simplified IR:
%5 = icmp ult <16 x i32> %vec.ind,
call void @llvm.masked.store.v16i8.p3v16i8(<16 x i8> %wide.masked.load, <16 x
i8> addrspace(3)* %9, i32 1, <16 x i1> %5)
With the "bad" ordering ("or <16 x i1> %6, %9") instcombine does nothing, and
we remain with all this mask logic:
%1 = icmp ugt <16 x i32> %vec.ind,
%2 = icmp slt <16 x i32> %vec.ind, %broadcast.splat
%3 = and <16 x i1> %1, %2
%5 = icmp ult <16 x i32> %vec.ind,
%6 = and <16 x i1> %3, %5
%.demorgan = and <16 x i1> %1, %2
%8 = xor <16 x i1> %.demorgan,
%9 = and <16 x i1> %5, %8
%13 = or <16 x i1> %6, %9
call void @llvm.masked.store.v16i8.p3v16i8(<16 x i8> %wide.masked.load, <16 x
i8> addrspace(3)* %14, i32 1, <16 x i1> %13)
--
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 46084] New: clang crashes in CodeGen::CodeGenModule::getNaturalTypeAlignment with __builtin_neon_vld1q_v
https://bugs.llvm.org/show_bug.cgi?id=46084
Bug ID: 46084
Summary: clang crashes in
CodeGen::CodeGenModule::getNaturalTypeAlignment with
__builtin_neon_vld1q_v
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: samitolva...@google.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
ndesaulni...@google.com, neeil...@live.com,
richard-l...@metafoo.co.uk
Building the arm64 Linux kernel with allyesconfig crashes clang when generating
code for crypto_aegis128_init_neon in crypto/aegis128-neon-inner.c. creduce
generates the following reproducer:
$ cat repro.c
#define a(b) __builtin_neon_vld1q_v(b, 48)
c;
d(void) { a(c); }
$ clang-11 -cc1 -triple aarch64-unknown-linux-gnu -emit-llvm-bc -x c repro.c
...
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang-11 -cc1 -triple aarch64-unknown-linux-gnu
-emit-llvm-bc -x c repro.c
1. parser at end of file
2. repro.c:3:1: LLVM IR generation of declaration 'd'
3. repro.c:3:1: Generating code for declaration 'd'
#0 0x027b6274 PrintStackTraceSignalHandler(void*) (clang-11+0x27b6274)
#1 0x027b3f8e llvm::sys::RunSignalHandlers() (clang-11+0x27b3f8e)
#2 0x027b657c SignalHandler(int) (clang-11+0x27b657c)
#3 0x7fa1a2d3c110 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x14110)
#4 0x02b24fe1
clang::CodeGen::CodeGenModule::getNaturalTypeAlignment(clang::QualType,
clang::CodeGen::LValueBaseInfo*, clang::CodeGen::TBAAAccessInfo*, bool)
(clang-11+0x2b24fe1)
#5 0x02d37fde
clang::CodeGen::CodeGenFunction::EmitAArch64BuiltinExpr(unsigned int,
clang::CallExpr const*, llvm::Triple::ArchType) (clang-11+0x2d37fde)
#6 0x02cd2e2d
clang::CodeGen::CodeGenFunction::EmitBuiltinExpr(clang::GlobalDecl, unsigned
int, clang::CallExpr const*, clang::CodeGen::ReturnValueSlot)
(clang-11+0x2cd2e2d)
#7 0x02b9ee03
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) (clang-11+0x2b9ee03)
#8 0x02c29339 (anonymous
namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*)
(clang-11+0x2c29339)
#9 0x02c19b8f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool)
(clang-11+0x2c19b8f)
#10 0x02b861f5
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*)
(clang-11+0x2b861f5)
#11 0x02c3d437 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt
const*, llvm::ArrayRef) (clang-11+0x2c3d437)
#12 0x02c47910
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot) (clang-11+0x2c47910)
#13 0x02b79395
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*)
(clang-11+0x2b79395)
#14 0x02b79e91
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (clang-11+0x2b79e91)
#15 0x02b1dd4c
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (clang-11+0x2b1dd4c)
#16 0x02b17b3d
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (clang-11+0x2b17b3d)
#17 0x02b20d2e
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*)
(clang-11+0x2b20d2e)
#18 0x030f037f (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef)
(clang-11+0x30f037f)
#19 0x030ee1c2
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef)
(clang-11+0x30ee1c2)
#20 0x03d60bb4 clang::ParseAST(clang::Sema&, bool, bool)
(clang-11+0x3d60bb4)
#21 0x0304a5b5 clang::FrontendAction::Execute() (clang-11+0x304a5b5)
#22 0x02fa9451
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(clang-11+0x2fa9451)
#23 0x030e99fb
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (clang-11+0x30e99fb)
#24 0x01648d30 cc1_main(llvm::ArrayRef, char const*,
void*) (clang-11+0x1648d30)
#25 0x016470e1 ExecuteCC1Tool(llvm::SmallVectorImpl&)
(clang-11+0x16470e1)
#26 0x01646ea6 main (clang-11+0x1646ea6)
#27 0x7fa1a12a2e0b __libc_start_main
/build/glibc-M65Gwz/glibc-2.30/csu/../csu/libc-start.c:342:3
#28 0x0164402a _start (clang-11+0x164402a)
...
--
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 45831] fsanitize-coverage=trace-pc incompatible with -fsanitze=bounds and -fsanitize=thread
https://bugs.llvm.org/show_bug.cgi?id=45831 Marco Elver changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Marco Elver --- Fix committed: https://github.com/llvm/llvm-project/commit/14de6e29b1315e9abe61d71e3e13f75bff80e1be -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 45831, which changed state. Bug 45831 Summary: fsanitize-coverage=trace-pc incompatible with -fsanitze=bounds and -fsanitize=thread https://bugs.llvm.org/show_bug.cgi?id=45831 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46085] New: Missing row-major support for llvm.matrix.transpose
https://bugs.llvm.org/show_bug.cgi?id=46085 Bug ID: 46085 Summary: Missing row-major support for llvm.matrix.transpose Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ajc...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org The LowerMatrixIntrinsics::LowerTranspose() method asserts on assert(InputMatrix.isColumnMajor() && "Row-major code-gen not supported yet!"); when trying to lower the intrinsic for row-major support. For completeness, this lowering should be implemented as well, similar to some of the other matrix intrinsics. -- 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 46047] New: inconsistent behaviors at -O3
https://bugs.llvm.org/show_bug.cgi?id=46047
Bug ID: 46047
Summary: inconsistent behaviors at -O3
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -O3 -g small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 11
Breakpoint 1: where = a.out`main + 79 at small.c:11:3, address =
0x0040117f
(lldb) r
Process 565482 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 565482 exited with status = 0 (0x)
(lldb)
/
As showed above, Line 11 is not hit by LLDB when setting breakpoint at Line 11.
However, Line 11 is hit by LLDB when using step-i.
/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 1 at small.c:6:10, address =
0x00401131
(lldb) r
Process 565440 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 565440 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401131 a.out`main at small.c:6:10
3
4int main() {
5 for (int e=0; e<10; e++)
-> 6d[e] = 1;
7 if (d[0])
8c = a = (b == 0 || 1 % b);
9 if (a != 1)
(lldb) si -c 10
Process 565440 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x00401197 a.out`main at small.c:11:3
8c = a = (b == 0 || 1 % b);
9 if (a != 1)
10 abort();
-> 11 return 0;
12 }
(lldb)
$ cat small.c
#include
int a, b, c, d[10];
int main() {
for (int e=0; e<10; e++)
d[e] = 1;
if (d[0])
c = a = (b == 0 || 1 % b);
if (a != 1)
abort();
return 0;
}
--- Comment #1 from Yibiao Yang (杨已彪) ---
Created attachment 23535
--> https://bugs.llvm.org/attachment.cgi?id=23535&action=edit
the binary
--
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 46049] New: inconsistent behaviors at -O2
https://bugs.llvm.org/show_bug.cgi?id=46049
Bug ID: 46049
Summary: inconsistent behaviors at -O2
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: yangyib...@hust.edu.cn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
$ clang --version
clang version 11.0.0 (/home/yibiao/.cache/yay/llvm-git/llvm-project
871beba234a83a2a02da9dedbd59b91a1bfbd7af)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 11.0.0
clang revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
llvm revision 871beba234a83a2a02da9dedbd59b91a1bfbd7af
$ clang -g -O2 small.c
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b 6
Breakpoint 1: where = a.out`main + 29 at small.c:6:7, address =
0x0040112d
(lldb) r
Process 578366 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 578366 exited with status = 0 (0x)
(lldb)
/
As showed above, Line 6 is not hit by lldb when setting breakpoint.
However, it was hit by lldb when using step-i
*/
$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/home/yibiao/Debugger/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main at small.c:4:7, address = 0x00401110
(lldb) r
Process 578410 launched: '/home/yibiao/Debugger/a.out' (x86_64)
Process 578410 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401110 a.out`main at small.c:4:7
1int a, b, d=1;
2
3int main() {
-> 4 if (d)
5a = b==0;
6 if (a!=1)
7return 1;
(lldb) si -c 7
Process 578410 stopped
* thread #1, name = 'a.out', stop reason = instruction step into
frame #0: 0x00401133 a.out`main at small.c:6:8
3int main() {
4 if (d)
5a = b==0;
-> 6 if (a!=1)
7return 1;
8 return 0;
9}
(lldb)
$ cat small.c
int a, b, d=1;
int main() {
if (d)
a = b==0;
if (a!=1)
return 1;
return 0;
}
--- Comment #1 from Yibiao Yang (杨已彪) ---
Created attachment 23536
--> https://bugs.llvm.org/attachment.cgi?id=23536&action=edit
the binary
--
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 46086] New: LiveDebugValues crashes on valid code on (anonymous namespace)::LiveDebugValues::accumulateFragmentMap(
https://bugs.llvm.org/show_bug.cgi?id=46086 Bug ID: 46086 Summary: LiveDebugValues crashes on valid code on (anonymous namespace)::LiveDebugValues::accumulateFragmentMap( Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: ditali...@apple.com CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com Created attachment 23537 --> https://bugs.llvm.org/attachment.cgi?id=23537&action=edit MIR before LiveDebugValues $ ./llc -run-pass=livedebugvalues foo.mir PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: ./llc -run-pass=livedebugvalues foo.mir 1. Running pass 'Function Pass Manager' on module 'foo.mir'. 2. Running pass 'Live DEBUG_VALUE analysis' on function '@_Z3barii' 0 llc 0x00010e83a23a llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 58 1 llc 0x00010e83a779 PrintStackTraceSignalHandler(void*) + 25 2 llc 0x00010e83869b llvm::sys::RunSignalHandlers() + 123 3 llc 0x00010e83c4e9 SignalHandler(int) + 249 4 libsystem_platform.dylib 0x7fff7223355d _sigtramp + 29 5 llc 0x00010d1c1475 llvm::SmallPtrSet::~SmallPtrSet() + 21 6 llc 0x00010da82aaf llvm::DILocation::getRawInlinedAt() const + 31 7 llc 0x00010da8f765 llvm::DILocation::getInlinedAt() const + 21 8 llc 0x00010cfe5934 (anonymous namespace)::LiveDebugValues::accumulateFragmentMap(llvm::MachineInstr&, llvm::DenseMap >, llvm::DenseMapInfo, llvm::detail::DenseMapPair > > >&, llvm::DenseMap, llvm::SmallVector, llvm::DenseMapInfo >, llvm::detail::DenseMapPair, llvm::SmallVector > >&) + 84 9 llc 0x00010cfe4655 (anonymous namespace)::LiveDebugValues::ExtendRanges(llvm::MachineFunction&) + 965 10 llc 0x00010cfe2359 (anonymous namespace)::LiveDebugValues::runOnMachineFunction(llvm::MachineFunction&) + 265 11 llc 0x00010d18df6d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 541 12 llc 0x00010d95fe4c llvm::FPPassManager::runOnFunction(llvm::Function&) + 700 13 llc 0x00010d960445 llvm::FPPassManager::runOnModule(llvm::Module&) + 117 14 llc 0x00010d960bc4 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 772 15 llc 0x00010d9606e8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 296 16 llc 0x00010d9611f1 llvm::legacy::PassManager::run(llvm::Module&) + 33 17 llc 0x00010a6954ee compileModule(char**, llvm::LLVMContext&) + 6670 18 llc 0x00010a693227 main + 1447 19 libdyld.dylib0x7fff72026259 start + 1 zsh: segmentation fault ./llc -run-pass=livedebugvalues foo.mir -- 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 46087] New: AllowShortBlocksOnASingleLine fails on ForEachMacros
https://bugs.llvm.org/show_bug.cgi?id=46087
Bug ID: 46087
Summary: AllowShortBlocksOnASingleLine fails on ForEachMacros
Product: clang
Version: 10.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: zjs...@163.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
.clang-format:
ForEachMacros: ['rng']
AllowShortBlocksOnASingleLine: Never
Before:
rng (i, 0, 10) {
std::cout << i;
}
After:
rng (i, 0, 10) { std::cout << i; }
Expect:
rng (i, 0, 10) {
std::cout << 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] [Bug 46088] New: llvm-objdump print wrong function symbol of b instruction
https://bugs.llvm.org/show_bug.cgi?id=46088 Bug ID: 46088 Summary: llvm-objdump print wrong function symbol of b instruction Product: new-bugs Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: 499537...@qq.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org llvm-objdump print wrong symbol of b instruction(or other b instructions): $ cat testb.s .syntax unified .section .text, "ax",%progbits .globl _start .type _start,%function _start: b func .global func .type func,%function func = 0x2000 llvm-mc -arm-add-build-attributes -filetype=obj -triple=armv7a-none-linux-gnueabi testb.s -o testb.o $ llvm-objdump -d testb.o testb.o:file format ELF32-arm-little Disassembly of section .text: _start: 0: fe 07 00 ea b #8184 <_start+0x2000> but it's wrong when adding triple: llvm-objdump -d -triple=thumbv7a-linux-gnueabihf testb.o testb.o:file format ELF32-arm-little Disassembly of section .text: _start: 0: fe 07 00 ea b #8184 <_start+0x1ffc> -- 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 46089] New: Clang can not detect binding to null pointer
https://bugs.llvm.org/show_bug.cgi?id=46089
Bug ID: 46089
Summary: Clang can not detect binding to null pointer
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: haoxi...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This simple case test.cc
#include
int main(){
int &x = *(int *)nullptr; // Error: null reference
std::cout << "ok" << std::endl;
return 0;
}
In clang-trunk, clang-10, clang-9 can not detect runtime error, while clang-8
and lower version does.
$clang++-trunk -fsanitize=null test.cc ; ./a.out
test.cc:4:14: warning: binding dereferenced null pointer to reference has
undefined behavior [-Wnull-dereference]
int &x = *(int *)nullptr;
^~~
1 warning generated.
ok
$clang++-8 -w -fsanitize=null test.cc ; ./a.out
test.cc:4:14: warning: binding dereferenced null pointer to reference has
undefined behavior [-Wnull-dereference]
int &x = *(int *)nullptr;
^~~
1 warning generated.
test.cc:4:14: runtime error: reference binding to null pointer of type 'int'
ok
My clang-trunk version is
$clang++-trunk --version
clang version 11.0.0 (https://github.com/llvm/llvm-project
210616bd38d589020b45f8cbbf9f9ef1296f2729)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/haoxin/compilers/llvm-clang/llvm-project/build/bin
Is clang delete runtime error message when "-fsanitize=null" is used in new
recent versions after clang-8? If not, I think there something wrong with the
above case.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46090] New: Add "Make LLVM_APPEND_VC_REV=OFF affect > clang, lld, and lldb as well." for 10.0.1 release
https://bugs.llvm.org/show_bug.cgi?id=46090 Bug ID: 46090 Summary: Add "Make LLVM_APPEND_VC_REV=OFF affect > clang, lld, and lldb as well." for 10.0.1 release Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: sedat.di...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk, tstel...@redhat.com Blocks: 45309 Tom suggested me to file a bug to include the following patch in 10.0.1 release: "Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and lldb as well." Unsure if I have selected the right Product (clang) and Component (frontend). But hope that is changeable afterwards. Please change if I am wrong. Unsure how to mark this BR to "45309 - [meta] 10.0.1 Release Blockers" correctly. I used "Blocks: 45309". I dropped "Severity: release blocker" and used "normal". Please change if I am wrong. For details please see [1] and [2]. Thanks, - Sedat - [1] https://lists.llvm.org/pipermail/llvm-dev/2020-May/141815.html [2] https://github.com/llvm/llvm-project/commit/fb5fafb23cc2d8613f8be2487afe94d8594a88ce 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
