[llvm-bugs] [Bug 42054] New: Could NOT find Z3: Found unsuitable version "0.0.0", but required is at least "4.7.1"
https://bugs.llvm.org/show_bug.cgi?id=42054 Bug ID: 42054 Summary: Could NOT find Z3: Found unsuitable version "0.0.0", but required is at least "4.7.1" Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: jerker.b...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 22041 --> https://bugs.llvm.org/attachment.cgi?id=22041&action=edit cmake configure script cmake configuration of llvm on Windows 10 using Visual Studio 2019 x64 and cmake-3.14.4-win64-x64 cmake configure fails with -- Could NOT find Z3: Found unsuitable version "0.0.0", but required is at least "4.7.1" (found F:/dev/compilers/z3/bin/libz3.lib) CMake Error at CMakeLists.txt:395 (message): Z3 >= 4.7.1 has not been found in LLVM_Z3_INSTALL_DIR: F:/dev/compilers/z3. I have installed the latest Z3 (Version 4.8.4) from official github download. To me, it seems "Microsoft.Z3.dll" is the only versioned binary (4.8.4.0). libz3.lib as a static library (or import library) is certainly not versioned. z3.exe reports upon execution z3.exe --version Z3 version 4.8.4 - 64 bit - build hashcode d6df51951f4c I think it is the following instruction in llvm/CMakeLists.txt that fails CMakeLists.txt(391):find_package(Z3 4.7.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 42055] New: Invalid register allocation for AVX512 gather
https://bugs.llvm.org/show_bug.cgi?id=42055
Bug ID: 42055
Summary: Invalid register allocation for AVX512 gather
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: benny@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Created attachment 22042
--> https://bugs.llvm.org/attachment.cgi?id=22042&action=edit
reduced test case
While chasing a SIGILL I came across this. Intrinsics were generated by
LoopVectorizer. Manual says: "If any pair of the index, mask, or destination
registers are the same, this instruction results a UD fault."
$ cat t.ll
define void @reduced() #0 {
%wide.masked.gather38 = call <16 x float>
@llvm.masked.gather.v16f32.v16p0f32(<16 x float*> undef, i32 4, <16 x i1> ,
<16 x float> undef)
%1 = fadd fast <16 x float> %wide.masked.gather38, zeroinitializer
call void @llvm.masked.store.v16f32.p0v16f32(<16 x float> %1, <16 x float>*
undef, i32 4, <16 x i1> )
ret void
}
; Function Attrs: nounwind readonly
declare <16 x float> @llvm.masked.gather.v16f32.v16p0f32(<16 x float*>, i32
immarg, <16 x i1>, <16 x float>) #1
; Function Attrs: argmemonly nounwind
declare void @llvm.masked.store.v16f32.p0v16f32(<16 x float>, <16 x float>*,
i32 immarg, <16 x i1>) #2
attributes #0 = { "unsafe-fp-math"="true" }
attributes #1 = { nounwind readonly }
attributes #2 = { argmemonly nounwind }
$ llc -mcpu=skx < t.ll | llvm-mc
:10:2: warning: index and destination registers should be distinct
vgatherqps (,%zmm0), %ymm0 {%k1}
^
--
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 15022 in oss-fuzz: llvm/llvm-microsoft-demangle-fuzzer: Out-of-memory in llvm_llvm-microsoft-demangle-fuzzer
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2019-05-29 Type: Bug New issue 15022 by ClusterFuzz-External: llvm/llvm-microsoft-demangle-fuzzer: Out-of-memory in llvm_llvm-microsoft-demangle-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15022 Detailed report: https://oss-fuzz.com/testcase?key=5735693009027072 Project: llvm Fuzzer: libFuzzer_llvm_llvm-microsoft-demangle-fuzzer Fuzz target binary: llvm-microsoft-demangle-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-microsoft-demangle-fuzzer Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201901070410:201901080410 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5735693009027072 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md 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. -- 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 42056] New: missing warning diagnosis for empty expression statement
https://bugs.llvm.org/show_bug.cgi?id=42056
Bug ID: 42056
Summary: missing warning diagnosis for empty expression
statement
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: tangyix...@mail.dlut.edu.cn
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Clang does not warn to remove the empty expression statement with the warning
flag [-Wextra-semi].
For the following example, Clang does not warn to remove the empty expression
statement with the warning flag [-Wextra-semi].
$ cat s.c
int main()
{
int a = 0;
;
return 0;
}
$ clang --version
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -Wextra-semi s.c
No warning generated.
Under the same workstation:
$ clang-8.0 --Wextra-semi-stmt s.c
s.c:4:5: warning: empty expression statement has no effect; remove unnecessary
';' to silence this warning [-Wextra-semi-stmt]
;
^
1 warning generated.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42057] New: Invalid std::function syntax in struct causes segfault
https://bugs.llvm.org/show_bug.cgi?id=42057 Bug ID: 42057 Summary: Invalid std::function syntax in struct causes segfault Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: stan.vaes...@prodrive-technologies.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22043 --> https://bugs.llvm.org/attachment.cgi?id=22043&action=edit CodeExample Having invalid std::function syntax inside a struct causes a segfault in clang-tidy-8 (See attachments) -- Version info clang-tidy-8 --version LLVM (http://llvm.org/): LLVM version 8.0.1 Optimized build. Default target: x86_64-pc-linux-gnu Host CPU: skylake-avx512 gcc --version gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. cat /etc/debian_version 9.9 cat /proc/version Linux version 4.20.17-pd-4.20.y (mdg@lnxdevrm01) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #20190430 SMP Tue Apr 30 22:38:36 CEST 2019 -- 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 42058] New: missing warning diagnosis of implicit conversion from 'double' to 'float'
https://bugs.llvm.org/show_bug.cgi?id=42058
Bug ID: 42058
Summary: missing warning diagnosis of implicit conversion from
'double' to 'float'
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: tangyix...@mail.dlut.edu.cn
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
For the following example, clang 6.0 misses the warning diagnosis of implicit
conversion from 'double' to 'float'.
$ cat s.c
int main(){
double w[2]={1.0,2.0},z[2]={2.0,4.0};
float b[2];
for(int j=1;j<2;j++){
b[j]+=z[j]/w[j];
}
return 0;
}
$ clang --version
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -Wconversion s.c
No warning generated.
Under the same workstation:
$ clang-7.0 -Wconversion s.c
s.c:5:13: warning: implicit conversion when assigning computation result loses
floating-point precision: 'double' to 'float' [-Wconversion]
b[j]+=z[j]/w[j];
~^
1 warning generated.
$ clang-8.0 -Wimplicit-float-conversion s.c
s.c:5:13: warning: implicit conversion when assigning computation result loses
floating-point precision: 'double' to 'float' [-Wimplicit-float-conversion]
b[j]+=z[j]/w[j];
~^
1 warning generated.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42059] New: "member access into incomplete type" after r361670
https://bugs.llvm.org/show_bug.cgi?id=42059 Bug ID: 42059 Summary: "member access into incomplete type" after r361670 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: richard.towns...@arm.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk When running the attached reproducer (from Chromium) clang currently fails with an "access into incomplete type" message: ../../base/memory/scoped_refptr.h:291:6: error: member access into incomplete type 'const blink::SecurityOrigin' ptr->AddRef(); ^ ../../base/memory/scoped_refptr.h:177:7: note: in instantiation of member function 'scoped_refptr::AddRef' requested here AddRef(ptr_); ^ ../../third_party/blink/renderer/platform/bindings/dom_wrapper_world.h:50:7: note: forward declaration of 'blink::SecurityOrigin' class SecurityOrigin; ^ 1 error generated. Bisection indicates that SVN ID 361670 (git: https://github.com/llvm/llvm-project/commit/de47d66191e50e8a741ed551c25d60bbf86da5e4) is the first bad commit. -- 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 14664 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Comment #2 on issue 14664 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14664#c2 ClusterFuzz has detected this issue as fixed in range 201905280209:201905290205. Detailed report: https://oss-fuzz.com/testcase?key=5698683162591232 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::object::XCOFFObjectFile::isSectionVirtual llvm::DWARFContext::create Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201903270300:201904052014 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201905280209:201905290205 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5698683162591232 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 14664 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 14664 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14664#c3 ClusterFuzz testcase 5698683162591232 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 14909 in oss-fuzz: llvm/clang-format-fuzzer: NULL
Comment #2 on issue 14909 by ClusterFuzz-External: llvm/clang-format-fuzzer: NULL https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14909#c2 ClusterFuzz has detected this issue as fixed in range 201905280209:201905290205. Detailed report: https://oss-fuzz.com/testcase?key=5705701118181376 Project: llvm Fuzzer: libFuzzer_llvm_clang-format-fuzzer Fuzz target binary: clang-format-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x745d6ff8 Crash State: NULL Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201904110259:201904111857 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201905280209:201905290205 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5705701118181376 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42060] New: Placement new operator in OpenCL C++
https://bugs.llvm.org/show_bug.cgi?id=42060
Bug ID: 42060
Summary: Placement new operator in OpenCL C++
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: dr...@jwdt.org
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
Using a placement new operator yields an error "'default new' is not supported
in OpenCL C++". I see the problem for "new" and for "operator new", but
placement new should simply call the constructor upon the memory that already
exists. So I think this should be allowed. Test case:
class foo
{
int a = 0;
int b = 0;
};
__kernel void test()
{
foo x;
new(&x) foo;
}
--
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 42059] "member access into incomplete type" after r361670
https://bugs.llvm.org/show_bug.cgi?id=42059 Richard Townsend changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Townsend --- Closing after creating a more compact reproducer, GCC 7.3 also fails to compile this file, so the issue is actually in Chromium. -- 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 14909 in oss-fuzz: llvm/clang-format-fuzzer: NULL
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 14909 by ClusterFuzz-External: llvm/clang-format-fuzzer: NULL https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14909#c3 ClusterFuzz testcase 5705701118181376 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42061] New: Math function conflict when using clang++
https://bugs.llvm.org/show_bug.cgi?id=42061
Bug ID: 42061
Summary: Math function conflict when using clang++
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: csda...@lbl.gov
CC: llvm-bugs@lists.llvm.org
I encounter a math function conflict issue when using clang++. The conflict
does not happen when using clang. I am using LLVM/Clang/OpenMP commits from
today, 29 May 2019. Please see below
csdaley@cgpu03:~/llvm> cat hello.c
#include
#include
int main()
{
printf("hello\n");
return 0;
}
csdaley@cgpu03:~/llvm> clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda
hello.c -o hello && ./hello
hello
csdaley@cgpu03:~/llvm> clang++ -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda
hello.c -o hello && ./hello
clang-9: warning: treating 'c' input as 'c++' when in C++ mode, this behavior
is deprecated [-Wdeprecated]
In file included from hello.c:2:
In file included from /opt/gcc/7.3.0/snos/include/g++/stdlib.h:36:
In file included from /opt/gcc/7.3.0/snos/include/g++/cstdlib:77:
/opt/gcc/7.3.0/snos/include/g++/bits/std_abs.h:70:3: error: declaration
conflicts with target of using declaration already in scope
abs(double __x)
^
/project/projectdirs/m1759/csdaley/software/cgpu/llvm/9.0.0-git_20190529/lib/clang/9.0.0/include/__clang_cuda_math_forward_declares.h:50:25:
note: target of using declaration
__DEVICE__ const double abs(const double);
^
/opt/gcc/7.3.0/snos/include/g++/bits/std_abs.h:52:11: note: using declaration
using ::abs;
^
/opt/gcc/7.3.0/snos/include/g++/bits/std_abs.h:74:3: error: declaration
conflicts with target of using declaration already in scope
abs(float __x)
^
/project/projectdirs/m1759/csdaley/software/cgpu/llvm/9.0.0-git_20190529/lib/clang/9.0.0/include/__clang_cuda_math_forward_declares.h:51:24:
note: target of using declaration
__DEVICE__ const float abs(const float);
^
/opt/gcc/7.3.0/snos/include/g++/bits/std_abs.h:52:11: note: using declaration
using ::abs;
^
2 errors generated.
csdaley@cgpu03:~/llvm> clang++ -v
clang version 9.0.0 (https://github.com/llvm-mirror/clang
e420b2015caea78d84601f697fbc33b6116ec622) (https://github.com/llvm-mirror/llvm
36c062c0837bba4d6fc18b4132ab3df6a8cc4113)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir:
/project/projectdirs/m1759/csdaley/software/cgpu/llvm/9.0.0-git_20190529/bin
Found candidate GCC installation:
/opt/gcc/7.3.0/snos/lib/gcc/x86_64-suse-linux/7.3.0
Selected GCC installation: /opt/gcc/7.3.0/snos/lib/gcc/x86_64-suse-linux/7.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found CUDA installation: /global/common/cori/software/cuda/9.2, version 9.2
I have been in discussion with Doru and Johannes about this bug. They confirmed
that it is a bug and suggested putting the bug in bugzilla. The latest response
from Doru is
"The fix would be to remove the const float and const double variants of the
abs functions. This unfortunately will break the inclusion of the "random"
header.
I'm not sure how to reconcile those two errors, it looks like those two fixes
cannot coexist. Maybe I'm missing something."
Thanks,
Chris
--
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 42037] C++2a std::midpoint's "Constraints" are not implemented
https://bugs.llvm.org/show_bug.cgi?id=42037 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marshall Clow (home) --- Fixed in revision 361970. -- 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 42062] New: tail call causes to run out of registers during register allocation
https://bugs.llvm.org/show_bug.cgi?id=42062
Bug ID: 42062
Summary: tail call causes to run out of registers during
register allocation
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: diogo.samp...@arm.com
Reporter: diogo.samp...@arm.com
CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org,
ties.st...@arm.com
llc in the code:
--
target triple = "thumbv8m.base-arm-none-eabi"
@foo = external global i8
declare i32 @bar(i8* nocapture, i32, i32, i8* nocapture)
define void @food(i8* %a) #0 {
entry:
%0 = tail call i32 @bar(i8* %a, i32 8, i32 1, i8* nonnull @foo)
%1 = tail call i32 @bar(i8* %a, i32 9, i32 0, i8* nonnull @foo)
%2 = tail call i32 @bar(i8* %a, i32 7, i32 2, i8* nonnull @foo)
ret void
}
attributes #0 = { minsize "target-cpu"="cortex-m23" }
--
will produce an error: ran out of registers during register allocation
running --disable-tail-calls won't
In thumb there are only 8 registers. In this particular case, the register
allocator could move the bar address, stored in r6 to register r7 and allow the
register r4, r5, r6 to be restored. But he does not.
--
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 40755] Compile error occurs when -stdlib=libc++ is specified
https://bugs.llvm.org/show_bug.cgi?id=40755 Louis Dionne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||ldio...@apple.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 42063] New: LTO: GEP is not of right type for indices!
https://bugs.llvm.org/show_bug.cgi?id=42063 Bug ID: 42063 Summary: LTO: GEP is not of right type for indices! Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: lto Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: llvm-bugs@lists.llvm.org We're getting the following error when trying to build BoringSSL with LTO using lld: GEP is not of right type for indices! %1410 = getelementptr inbounds %"class.bssl::internal::StackAllocated.1896", %"class.bssl::internal::StackAllocated.1896"* %116, i64 0, i32 0, i32 0, !dbg !342099 %"type 0x86cc630"*in function _ZN25EVPExtraTest_Ed25519_Test8TestBodyEv LLVM ERROR: Broken function found, compilation aborted! Reproducer is at https://storage.googleapis.com/fuchsia-build/reproducer/lld-lto-failure.tar.bz2 -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41927, which changed state. Bug 41927 Summary: Please backport r353700 & r353701 to 8.0 https://bugs.llvm.org/show_bug.cgi?id=41927 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41934] Please backport r361114 to 8.0
https://bugs.llvm.org/show_bug.cgi?id=41934 Bug 41934 depends on bug 41927, which changed state. Bug 41927 Summary: Please backport r353700 & r353701 to 8.0 https://bugs.llvm.org/show_bug.cgi?id=41927 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41927] Please backport r353700 & r353701 to 8.0
https://bugs.llvm.org/show_bug.cgi?id=41927 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|r353700 r353701 |r353700 r353701 r362016 ||r362017 Resolution|--- |FIXED --- Comment #3 from Tom Stellard --- Merged: r362016 r362017 -- 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 42064] New: Optimized 128-bit atomic compare-and-swap can generate incorrect code on msvc target
https://bugs.llvm.org/show_bug.cgi?id=42064 Bug ID: 42064 Summary: Optimized 128-bit atomic compare-and-swap can generate incorrect code on msvc target Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: cerick...@curedev.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22047 --> https://bugs.llvm.org/attachment.cgi?id=22047&action=edit Example source code When compiling the attached source with: clang --target=x86_64-pc-windows-msvc -march=sandybridge -O2 it appears that the generated code tries to use rbx as both an input for cmpxchg16b and as a stack pointer: mov rbx, rsp ... movabs rax, 1393743441367457520 mov rdx, rax mov rcx, rax mov rbx, rax lockcmpxchg16b xmmword ptr [r8] vxorps xmm0, xmm0, xmm0 vmovaps xmmword ptr [rbx + 128], xmm0 // rbx is garbage at this point The example C++ code is a bit silly because it is as reduced as I could get it and still have the problem occur. The same issue occurs whether using _InterlockedCompareExchange128() or __sync_val_compare_and_swap(). For convenience, here is the example on godbolt: https://godbolt.org/z/C64_VH I ran into this issue in clang 7.0.0 but it seems to still be there in trunk (according to godbolt). -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41974, which changed state. Bug 41974 Summary: Backport r359606 to 8.0 https://bugs.llvm.org/show_bug.cgi?id=41974 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41974] Backport r359606 to 8.0
https://bugs.llvm.org/show_bug.cgi?id=41974 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|r359606 |r359606 r362024 Resolution|--- |FIXED --- Comment #5 from Tom Stellard --- Merged: r362024 -- 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 42065] New: Use after free (in DenseMap) in InstCombine when built with GCC
https://bugs.llvm.org/show_bug.cgi?id=42065 Bug ID: 42065 Summary: Use after free (in DenseMap) in InstCombine when built with GCC Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: llvm-bugs@lists.llvm.org Created attachment 22048 --> https://bugs.llvm.org/attachment.cgi?id=22048&action=edit Small testcase InstCombine contains the following construct: DenseMap NewInsts; ... NewInsts[CI] = NewInsts[CI->getOperand(0)]; When built with GCC, this can trigger use after free. First the right hand side is evaluated by calling operator[], which returns a reference. Then the left hand side is evaluated, which also calls operator[], which triggers a call to grow(), which reallocates the DenseMap, invalidating the right hand side reference. After both sides have been evaluated, the right hand side reference is dereferenced, which now points to freed memory. When built with Clang, this isn't an issue because the reference is dereferenced before evaluating the left hand side. A small testcase that can illustrate the issue is attached. If built with GCC with address sanitizer, running the testcase ends up with the following backtrace: ==30663==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000f8 at pc 0x5624235f0ccc bp 0x7ffc8e824b40 sp 0x7ffc8e824b30 READ of size 8 at 0x619000f8 thread T0 #0 0x5624235f0ccb in copy(void*, void*) /home/martin/code/llvm/build/densemap.cpp:45 #1 0x5624235f0ccb in main /home/martin/code/llvm/build/densemap.cpp:59 #2 0x7f33b744bb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #3 0x5624235f1089 in _start (/home/martin/code/llvm/build/densemap+0x4089) 0x619000f8 is located 120 bytes inside of 1024-byte region [0x61900080,0x61900480) freed by thread T0 here: #0 0x7f33b78fc2d0 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe12d0) #1 0x5624235f069f in llvm::DenseMap, llvm::detail::DenseMapPair >::grow(unsigned int) ../include/llvm/ADT/DenseMap.h:812 #2 0x5624235f069f in llvm::DenseMapBase, llvm::detail::DenseMapPair >, void*, void*, llvm::DenseMapInfo, llvm::detail::DenseMapPair >::grow(unsigned int) ../include/llvm/ADT/DenseMap.h:533 #3 0x5624235f069f in llvm::detail::DenseMapPair* llvm::DenseMapBase, llvm::detail::DenseMapPair >, void*, void*, llvm::DenseMapInfo, llvm::detail::DenseMapPair >::InsertIntoBucketImpl(void* const&, void* const&, llvm::detail::DenseMapPair*) ../include/llvm/ADT/DenseMap.h:577 #4 0x5624235f069f in llvm::detail::DenseMapPair* llvm::DenseMapBase, llvm::detail::DenseMapPair >, void*, void*, llvm::DenseMapInfo, llvm::detail::DenseMapPair >::InsertIntoBucket(llvm::detail::DenseMapPair*, void* const&) ../include/llvm/ADT/DenseMap.h:543 #5 0x5624235f069f in llvm::DenseMapBase, llvm::detail::DenseMapPair >, void*, void*, llvm::DenseMapInfo, llvm::detail::DenseMapPair >::FindAndConstruct(void* const&) ../include/llvm/ADT/DenseMap.h:322 #6 0x5624235f069f in llvm::DenseMapBase, llvm::detail::DenseMapPair >, void*, void*, llvm::DenseMapInfo, llvm::detail::DenseMapPair >::operator[](void* const&) ../include/llvm/ADT/DenseMap.h:326 #7 0x5624235f069f in copy(void*, void*) /home/martin/code/llvm/build/densemap.cpp:45 #8 0x5624235f069f in main /home/martin/code/llvm/build/densemap.cpp:59 The testcase also can be tweaked (by changing ValueType to LargeValue instead of void*) to trigger the same issue when built with Clang as well, and can be tweaked to test two different workarounds for the issue, one that helps for Clang and one that helps for both. A fix proposal has been submitted at https://reviews.llvm.org/D62624. -- 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 37198] WebAssembly start component should be emitted with definition of the start function
https://bugs.llvm.org/show_bug.cgi?id=37198 Andrew Kelley changed: What|Removed |Added Resolution|WONTFIX |--- CC||and...@ziglang.org Status|RESOLVED|REOPENED --- Comment #12 from Andrew Kelley --- Hi, I'd like to please re-open this issue for consideration. I represent the Zig project (https://ziglang.org/) which supports WebAssembly. Our goal is to produce wasm executables which have the start function as specified by the WebAssembly specification. Zig has no constructors, so this is not an issue. What we want is for the "start function" of the wasm file to call _start (actually don't care what LLD wants it to be, and would be happy with an explicit flag). Since this is a feature of WebAssembly, it seems to me there should be a way to produce a wasm file which uses this feature, and it does fit nicely into the Zig language. Thanks for consideration. -- 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 42066] New: clang-cl with /P and /Brepro fails with a cryptic error message
https://bugs.llvm.org/show_bug.cgi?id=42066 Bug ID: 42066 Summary: clang-cl with /P and /Brepro fails with a cryptic error message Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: brucedaw...@chromium.org CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Bug https://bugs.llvm.org/show_bug.cgi?id=38508 reported a host of errors when preprocessing a file in the context of the Chromium build. Most of those errors were fixed but one remains. I started with the repro steps from the previous bug but I managed to reduce it greatly. c:\src\chromium3\src\out\release>type test.cpp int x; c:\src\chromium3\src\out\release>..\..\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe /P /Brepro /c test.cpp clang-cl: warning: argument unused during compilation: '-mno-incremental-linker-compatible' [-Wunused-command-line-argument] That's it. I don't know *why* /Brepro triggers this error message, but it does. Preprocessing files is a valuable investigative technique so getting this to work again would be great. -- 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 41615] clang-cl: codeview debug info written by clang isn't sufficient for natvis files that reference static members
https://bugs.llvm.org/show_bug.cgi?id=41615 Amy Huang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Amy Huang --- S_CONSTANTs are now being written for static data members in https://reviews.llvm.org/rL362038. I'm also adding the other S_CONSTANTS for global constants and enums. -- 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 42057] Invalid std::function syntax in struct causes segfault
https://bugs.llvm.org/show_bug.cgi?id=42057
Richard Smith changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #2 from Richard Smith ---
Standalone testcase:
template struct function;
struct Foo { function(void()) test; };
Thanks for the report. This is already fixed for clang 9.
--
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 37198] WebAssembly start component should be emitted with definition of the start function
https://bugs.llvm.org/show_bug.cgi?id=37198 Andrew Kelley changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #14 from Andrew Kelley --- Thank you for the clarification Sam. After reading the linked GitHub issue and your comment, it is now my belief that the Zig project has no need for this feature, as I now understand it. What I thought it was was the equivalent of the ELF _start symbol, which calls main(). In Zig there are several ways to create a build artifact: build-obj - creates a relocatable object file build-lib - creates a library build-exe - creates an executable Since Zig has no constructors (global variables & constants must be initialized with constant data), no "init" hooks are needed. I only wanted to make sure that the build artifact produced with `build-exe` would have the concept of an entry point. If there is no concept of an entry point then perhaps the correct thing to do when build-exe is invoked with the wasm32-freestanding target is to print an error such as "web assembly does not support an entry point function; you must create a library". I will put this issue back into the state that I found it in, which was RESOLVED-WONTFIX. Thanks for your time. -- 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 42058] missing warning diagnosis of implicit conversion from 'double' to 'float'
https://bugs.llvm.org/show_bug.cgi?id=42058 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Richard Smith --- We don't provide patch releases for Clang 6 any more, and even if we did, this wouldn't qualify for porting to a patch release. There's not really anything we can do about this. -- 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 42002] output binary crash with clang/llvm 8.0.0 and -fembed-bitcode option
https://bugs.llvm.org/show_bug.cgi?id=42002 Fangrui Song changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Fangrui Song --- Fixed by D62509/r362052 The change will be included in clang 9.0.0 -- 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
