[llvm-bugs] [Bug 32386] New: [InsnCombine] (fptrunc (floor x)) -> (floor (fptrunc x))
https://bugs.llvm.org/show_bug.cgi?id=32386
Bug ID: 32386
Summary: [InsnCombine] (fptrunc (floor x)) -> (floor (fptrunc
x))
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: shiva0...@gmail.com
CC: llvm-bugs@lists.llvm.org
The test case fail due to instruction combine cast from floor to floorf
which make precision lost and get wrong floor value.
double d = 1024.0 - 1.0 / 32768.0;
extern double floor(double);
extern float floorf(float);
extern void abort();
int main() {
float f1 = (float)floor(d);
if ((int)f1 != 1023)
abort ();
return 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32386] [InsnCombine] (fptrunc (floor x)) -> (floor (fptrunc x))
https://bugs.llvm.org/show_bug.cgi?id=32386 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED CC||dav...@freebsd.org 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32387] New: string::size() use of uninitialized memory (MSan)
https://bugs.llvm.org/show_bug.cgi?id=32387
Bug ID: 32387
Summary: string::size() use of uninitialized memory (MSan)
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The following MWE produces a MemorySanitizer error:
MWE:
#include
#include
int main()
{
auto vec = std::vector{{"a"}, {"b"}, {"c"}};
auto it = std::find(std::begin(vec), std::end(vec), "b");
assert(it2 == vec.begin() + 1);
}
Error:
==25671==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x49a8ca in std::__1::basic_string,
std::__1::allocator >::size() const
/home/gonzalo/pool/msan/include/c++/v1/string:894:17
#1 0x49a8ca in bool std::__1::operator==,
std::__1::allocator >(std::__1::basic_string, std::__1::allocator > const&, char const*)
/home/gonzalo/pool/msan/include/c++/v1/string:3581
#2 0x49a8ca in std::__1::__wrap_iter, std::__1::allocator >*>
std::__1::find, std::__1::allocator >*>, char
[2]>(std::__1::__wrap_iter, std::__1::allocator >*>,
std::__1::__wrap_iter,
std::__1::allocator >*>, char const (&) [2])
/home/gonzalo/pool/msan/include/c++/v1/algorithm:891
#3 0x49a8ca in main test.cpp:7
#4 0x7f220bb66b04 in __libc_start_main (/lib64/libc.so.6+0x21b04)
#5 0x42384e in _start
/home/abuild/rpmbuild/BUILD/glibc-2.19/csu/../sysdeps/x86_64/start.S:122
SUMMARY: MemorySanitizer: use-of-uninitialized-value
/home/gonzalo/pool/msan/include/c++/v1/string:894:17 in
std::__1::basic_string,
std::__1::allocator >::size() const
Exiting
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32388] New: False Positive CloneChecker
https://bugs.llvm.org/show_bug.cgi?id=32388 Bug ID: 32388 Summary: False Positive CloneChecker Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: xiangzha...@gmail.com CC: llvm-bugs@lists.llvm.org Hi LLVM developers, CloneChecker is very useful: * Potential copy-paste error; did you really mean to use 'track' here? https://pbs.twimg.com/media/C7l0Ze7UwAAEP5e.jpg * Duplicate code detected https://pbs.twimg.com/media/C7l0bHzUwAAuvFj.jpg It is able to detect Copy-paste issue as Coverity scan https://github.com/KDE/k3b/commit/79da513fdfffbbe3a32daa928088b6ce3dc85707 but too much False Positives! https://pbs.twimg.com/media/C7l0x78V4AAnpUw.jpg I will deep into it then try to fix :) Regards, Leslie Zhai -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32389] New: array may have zero size
http://bugs.llvm.org/show_bug.cgi?id=32389 Bug ID: 32389 Summary: array may have zero size Product: clang Version: 4.0 Hardware: PC OS: Windows 2000 Status: NEW Severity: release blocker Priority: P Component: C++14 Assignee: unassignedclangb...@nondot.org Reporter: powerch...@web.de CC: llvm-bugs@lists.llvm.org The following is NO error in clang 4.0.0 (and 5.0.0 based upon LLVM 5.0.0-r295586) / Visual Studio 2017: int i[0]; But the C++14 standard says in 8.3.4.1: " If the constant-expression (5.19) is present, it shall be a converted constant expression of type std::size_t and its value shall be greater than zero." -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32390] New: version list clang_rt.asan-dynamic-arm.vers isn't generated
https://bugs.llvm.org/show_bug.cgi?id=32390
Bug ID: 32390
Summary: version list clang_rt.asan-dynamic-arm.vers isn't
generated
Product: compiler-rt
Version: 4.0
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: mod...@mail.ru
CC: llvm-bugs@lists.llvm.org
Created attachment 18151
--> https://bugs.llvm.org/attachment.cgi?id=18151&action=edit
full log of configuration and building
I'm building branch release_40 of compiler-rt using Clang 4.0.0 for ARM.
Configuration is done without errors. At the end of building linker cannot find
clang_rt.asan-dynamic-arm.vers, though version list for armhf has been
generated (see below). Here are the last lines of building output (full log is
attached):
-
[ 84%] Built target RTAsan_dynamic.arm
[ 84%] Generating version list for clang_rt.asan-dynamic-armhf
Scanning dependencies of target RTAsan_dynamic_version_script_dummy.arm
[ 84%] Building CXX object
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic_version_script_dummy.arm.dir/dummy.cc.o
[ 84%] Built target RTAsan_dynamic_version_script_dummy.arm
Scanning dependencies of target clang_rt.asan-dynamic-arm
[ 84%] Linking CXX shared library
../../../../lib/clang/4.0.0/lib/linux/libclang_rt.asan-arm.so
/home/mode/llvm/install/bin/ld.lld: error: cannot open
/home/mode/llvm/build-compiler-rt/projects/compiler-rt/lib/asan/clang_rt.asan-dynamic-arm.vers:
No such file or directory
clang-4.0: error: linker command failed with exit code 1 (use -v to see
invocation)
make[3]: ***
[projects/compiler-rt/lib/asan/CMakeFiles/clang_rt.asan-dynamic-arm.dir/build.make:245:
lib/clang/4.0.0/lib/linux/libclang_rt.asan-arm.so] Error 1
make[2]: *** [CMakeFiles/Makefile2:8316:
projects/compiler-rt/lib/asan/CMakeFiles/clang_rt.asan-dynamic-arm.dir/all]
Error 2
make[1]: *** [CMakeFiles/Makefile2:5960:
projects/compiler-rt/CMakeFiles/compiler-rt.dir/rule] Error 2
make: *** [Makefile:1822: compiler-rt] Error 2
-
Here is my workaround:
-
diff --git a/lib/asan/CMakeLists.txt b/lib/asan/CMakeLists.txt
index 5ac5708..a4bcb6a 100644
--- a/lib/asan/CMakeLists.txt
+++ b/lib/asan/CMakeLists.txt
@@ -168,9 +168,9 @@ else()
EXTRA asan.syms.extra)
set(VERSION_SCRIPT_FLAG
-Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/clang_rt.asan-dynamic-${arch}.vers)
- set_source_files_properties(
+ set_property(SOURCE
${CMAKE_CURRENT_BINARY_DIR}/dummy.cc
-PROPERTIES
+APPEND PROPERTY
OBJECT_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/clang_rt.asan-dynamic-${arch}.vers)
else()
set(VERSION_SCRIPT_FLAG)
-
Looks like set_source_files_properties() adds only one dependency even when
multiple architectures supported. That's why only armhf version is generated.
That's why I replaced it with set_property() which allows append strings to
property keeping previous content.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32387] string::size() use of uninitialized memory (MSan)
https://bugs.llvm.org/show_bug.cgi?id=32387 Gonzalo BG changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Gonzalo BG --- My LD_LIBRARY_PATH was overriding rpath and linking against a non sanitized libc++ at run-time, producing this issue. Using a sanitized libc++ "resolves" this. Sorry for the noise. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32391] New: Optimization flag -O2 gives wrong results for SSE2 and AVX intrinsics
https://bugs.llvm.org/show_bug.cgi?id=32391 Bug ID: 32391 Summary: Optimization flag -O2 gives wrong results for SSE2 and AVX intrinsics Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: daniel.ar...@iwr.uni-heidelberg.de CC: llvm-bugs@lists.llvm.org Created attachment 18152 --> https://bugs.llvm.org/attachment.cgi?id=18152&action=edit Failing test case The attached code in 'symmetric_tensor_39_reduced.cc' gives wrong output if optimization flags are used. The expected output is B[0][0][0]: 6 B[0][0][1]: 7 B[0][1][0]: 6 B[0][1][1]: 7 B[0][2][0]: 0 B[0][2][1]: 0 B[1][0][0]: 6 B[1][0][1]: 7 B[1][1][0]: 6 B[1][1][1]: 7 B[1][2][0]: 0 B[1][2][1]: 0 B[2][0][0]: 0 B[2][0][1]: 0 B[2][1][0]: 0 B[2][1][1]: 0 B[2][2][0]: 6 B[2][2][1]: 7 while the failing output is B[0][0][0]: 0 B[0][0][1]: 0 B[0][1][0]: 0 B[0][1][1]: 0 B[0][2][0]: 0 B[0][2][1]: 0 B[1][0][0]: 0 B[1][0][1]: 0 B[1][1][0]: 0 B[1][1][1]: 0 B[1][2][0]: 0 B[1][2][1]: 0 B[2][0][0]: 0 B[2][0][1]: 0 B[2][1][0]: 0 B[2][1][1]: 0 B[2][2][0]: 0 B[2][2][1]: 0 It fails with -O2 for -clang version 5.0.0 (trunk 295600) -clang 4.0.0 rc2 -clang 3.9.1 -clang 3.7.1 -clang 3.6.0 while working with -O1 and -O3. Fails on -clang 3.5.0 with -O2 and -O3 -clang 3.4 with -O2 and -O3 while working with -O1 Works for -O1, -O2 and -O3 on -clang 3.8.1 -clang 3.3 -clang 3.2 -clang 3.1 If SymmetricTensor<4,dim,VectorizedArray> I; SymmetricTensor<2,dim,VectorizedArray> A; SymmetricTensor<2,dim,VectorizedArray> B; is changed to SymmetricTensor<4,dim,double> I; SymmetricTensor<2,dim,double> A; SymmetricTensor<2,dim,double> B; and the loops over v are omitted (symmetric_tensor_39_double.cc), the output is the same for -O1, -O2 and -O3 on clang-4.0.0rc2. Hence, it seems related to vector intrinsics. If A is filled in a separate function, there is no difference as well. Some detective work can also be found at https://github.com/dealii/dealii/pull/4058. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32392] New: Power i32/i64 atomic acquire load lowers to lwsync, not isync
http://bugs.llvm.org/show_bug.cgi?id=32392 Bug ID: 32392 Summary: Power i32/i64 atomic acquire load lowers to lwsync, not isync Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: timshe...@gmail.com CC: llvm-bugs@lists.llvm.org GCC lowers acquire load of i32/i64 to isync, but llvm lowers them to lwsync. Here's the explanation: http://www.rdrop.com/~paulmck/scalability/paper/N2745r.2011.03.04a.html A casually written benchmark also shows that isync approach is faster: GCC: Benchmark Time(ns)CPU(ns) Iterations - BM_Acquire32/threads:12.74 2.74 256555796 BM_Acquire32/threads:21.40 2.80 228185266 BM_Acquire32/threads:41.25 4.98 124786836 BM_Acquire32/threads:176 0.240 8.1778115312 BM_Acquire64/threads:15.42 5.41 166593868 BM_Acquire64/threads:22.47 4.07 199450866 BM_Acquire64/threads:41.17 3.22 182357912 BM_Acquire64/threads:176 0.209 6.7694368384 LLVM: Benchmark Time(ns)CPU(ns) Iterations - BM_Acquire32/threads:18.45 8.4470487873 BM_Acquire32/threads:22.75 5.4993091058 BM_Acquire32/threads:45.56 22.2 31810768 BM_Acquire32/threads:176 1.14 37.4 1760 BM_Acquire64/threads:16.71 6.71 1 BM_Acquire64/threads:24.01 8.0063776730 BM_Acquire64/threads:45.57 22.2 31363992 BM_Acquire64/threads:176 1.41 36.9 1760 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32380] structured binding, crash: "Support for this Decl not implemented." ExprEngine.cpp:2006
https://bugs.llvm.org/show_bug.cgi?id=32380 Alexander Kornienko changed: What|Removed |Added Product|clang-tools-extra |clang Component|clang-tidy |Static Analyzer CC||llvm-bugs@lists.llvm.org Assignee|unassignedclangbugs@nondot. |kreme...@apple.com |org | --- Comment #1 from Alexander Kornienko --- Seems like this is coming from the Static Analyzer. Moving there. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32393] New: segfault while compiling libobjc2
https://bugs.llvm.org/show_bug.cgi?id=32393 Bug ID: 32393 Summary: segfault while compiling libobjc2 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: andr...@fink.org CC: llvm-bugs@lists.llvm.org Created attachment 18154 --> https://bugs.llvm.org/attachment.cgi?id=18154&action=edit source files Crash while compiling libobjc2 runtime of Gnustep with latest clang from trunk repository for Debian 8 Was following these instructions: https://github.com/andreasfink/ulib/blob/master/doc/README-LINUX.txt which used to work on many other debian 8 VM's before This is on a clean fresh install of a VM. So either gnustep's code or clangs code changed in the meantime creating a segfault this throws a stacktrace #0 0x7f20fcbb931a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1+0x85e31a) #1 0x7f20fcbb76ae llvm::sys::RunSignalHandlers() (/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1+0x85c6ae) #2 0x7f20fcbb77ea (/usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1+0x85c7ea) #3 0x7f20ff51f890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf890) #4 0x018155d7 clang::Decl::getTranslationUnitDecl() (/usr/lib/llvm-5.0/bin/clang+0x18155d7) #5 0x01815619 clang::Decl::getASTContext() const (/usr/lib/llvm-5.0/bin/clang+0x1815619) #6 0x01808e4c clang::RecordDecl::mayInsertExtraPadding(bool) const (/usr/lib/llvm-5.0/bin/clang+0x1808e4c) #7 0x018d991d (/usr/lib/llvm-5.0/bin/clang+0x18d991d) #8 0x018d50fe clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) const (/usr/lib/llvm-5.0/bin/clang+0x18d50fe) #9 0x01767948 (/usr/lib/llvm-5.0/bin/clang+0x1767948) #10 0x0178844b clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&, bool, bool, clang::FieldDecl const*, bool, bool, bool, bool, bool, bool, clang::QualType*) const (/usr/lib/llvm-5.0/bin/clang+0x178844b) #11 0x0178a075 clang::ASTContext::getObjCEncodingForType(clang::QualType, std::string&, clang::FieldDecl const*, clang::QualType*) const (/usr/lib/llvm-5.0/bin/clang+0x178a075) #12 0x009eb86a (/usr/lib/llvm-5.0/bin/clang+0x9eb86a) #13 0x008c24ee (/usr/lib/llvm-5.0/bin/clang+0x8c24ee) #14 0x00c87423 (/usr/lib/llvm-5.0/bin/clang+0xc87423) #15 0x00c7f971 (/usr/lib/llvm-5.0/bin/clang+0xc7f971) #16 0x00dba28e clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/llvm-5.0/bin/clang+0xdba28e) #17 0x00c8557f clang::CodeGenAction::ExecuteAction() (/usr/lib/llvm-5.0/bin/clang+0xc8557f) #18 0x00b5521e clang::FrontendAction::Execute() (/usr/lib/llvm-5.0/bin/clang+0xb5521e) #19 0x00b2c5be clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/llvm-5.0/bin/clang+0xb2c5be) #20 0x00bdbd73 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/llvm-5.0/bin/clang+0xbdbd73) #21 0x007ed7c8 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/lib/llvm-5.0/bin/clang+0x7ed7c8) #22 0x007dd0ff main (/usr/lib/llvm-5.0/bin/clang+0x7dd0ff) #23 0x7f20fb56ab45 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b45) #24 0x007eb5b3 _start (/usr/lib/llvm-5.0/bin/clang+0x7eb5b3) Stack dump: 0. Program arguments: /usr/lib/llvm-5.0/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name zeroSizedIVar.m -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /root/gnustep/libobjc2/Build/Test/CMakeFiles/zeroSizedIVar_optimised.dir/zeroSizedIVar.m.gcno -D GC_DEBUG -D GNUSTEP -D NO_LEGACY -D TYPE_DEPENDENT_DISPATCH -D __OBJC_RUNTIME_INTERNAL__=1 -U NDEBUG -O3 -std=gnu99 -ferror-limit 19 -fmessage-length 142 -fblocks -fobjc-runtime=gnustep-1.7 -fobjc-dispatch-method=non-legacy -fobjc-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -x objective-c zeroSizedIVar-d413d5.m 1. /root/gnustep/libobjc2/Test/zeroSizedIVar.m:27:1: current parser token '@' 2. /root/gnustep/libobjc2/Test/zeroSizedIVar.m:25:17: LLVM IR generation of declaration 'BitfieldTest' /tmp/zeroSizedIVar-d413d5.sh: line 4: 19590 Segmentation fault "/usr/lib/llvm-5.0/bin/clang" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-emit-obj" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "zeroSizedIVar.m" "-mrelocation-model" "static" "-mthread-model" "posix" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x
[llvm-bugs] [Bug 32394] New: New ARM constant pool optimization passes wrongly aligned data to NEON load optimization
https://bugs.llvm.org/show_bug.cgi?id=32394
Bug ID: 32394
Summary: New ARM constant pool optimization passes wrongly
aligned data to NEON load optimization
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: l...@joakim.fea.st
CC: llvm-bugs@lists.llvm.org
Created attachment 18155
--> https://bugs.llvm.org/attachment.cgi?id=18155&action=edit
llvm IR, @.arrayliteral is the constant in question
This issue was discovered from running the tests for the D llvm compiler, ldc,
on Android/ARM. Several tests segfault with llvm 4.0, but not with 3.9.1,
because they pass array literals to test functions.
Disassembly shows that the new constant pool optimization places the array
constant right after the calling function, but doesn't account for the fact
that the called function may be using NEON instructions to load the array,
which could depend on 128-bit alignment.
As the array constant isn't necessarily 128-bit word aligned, the NEON load
will fail. Interestingly some tests that failed then pass at higher
optimization levels, because the array constant randomly happens to be 128-bit
word aligned, depending on the length of the optimized function before it.
If I disable the constant pool optimization with --arm-promote-constant=false,
the problem goes away: all tests pass again. I've boiled down the issue to the
following sample D code, extracted from a test:
void main() {
import core.stdc.stdio:printf;
void testIt(size_t numBits, size_t[] bitsToTest...){
printf("numBits is %d\n", numBits);
foreach(b; bitsToTest)
printf("each of bitsToTest is %d\n", b);
}
testIt(100, 0, 1, 31, 63, 85);
}
Without optimization, it runs fine, but once any optimizations are applied, it
segfaults. gdb shows that it fails at this instruction:
vld1.64 {d16-d17}, [r0 :128]!
because r0 isn't 128-bit word aligned, which is what the NEON instruction is
expecting. I've attached the IR and disassembly for the failing executable, ie
with the constant pool optimization applied. More discussion of this issue can
found on the ldc github:
https://github.com/ldc-developers/ldc/issues/2024#issuecomment-287523479
I tried reproducing this bug using clang 4.0, but for some reason it wasn't
specifying 128-bit word alignment for its NEON vld1.64 loads, so I wasn't able
to trigger it with the code I tried. I didn't spend much time with clang,
maybe it can be hit that way too.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers
http://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 32102, which changed state. Bug 32102 Summary: Apply r296134 to 4.0 release branch http://bugs.llvm.org/show_bug.cgi?id=32102 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32102] Apply r296134 to 4.0 release branch
http://bugs.llvm.org/show_bug.cgi?id=32102 Simon Dardis changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Simon Dardis --- This fix is broken. I've submitted a new version of the fix for review (D31287). I'll file against 4.0.1 if accepted. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32395] New: Merge r298551 into the 4.0 branch : [AMDGPU] Fix bug 31610
http://bugs.llvm.org/show_bug.cgi?id=32395 Bug ID: 32395 Summary: Merge r298551 into the 4.0 branch : [AMDGPU] Fix bug 31610 Product: new-bugs Version: 4.0 Hardware: All URL: https://reviews.llvm.org/rL298551 OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 32061 Is this patch OK to merge to the 4.0 branch? Referenced Bugs: http://bugs.llvm.org/show_bug.cgi?id=32061 [Bug 32061] [meta] 4.0.1 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32396] New: [LV] Miscompile caused due to incorrect index for extracting vector result
https://bugs.llvm.org/show_bug.cgi?id=32396
Bug ID: 32396
Summary: [LV] Miscompile caused due to incorrect index for
extracting vector result
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: a...@azul.com
CC: llvm-bugs@lists.llvm.org
Loop vectorizer extracts incorrect result from the vector.
Source code snippet:
int byres = 52, i=1;
for (i1 = 141; i1 < 170; i1++) {
i2 = 193;
while (--i2 > 0) {
byRes = (((i) * i));
i = i1 + i2;
}
}
printf("%d", byRes);
Here byRes should be (169 + 2) ^ 2, i.e. i2 = 2 and i1 = 169
After vectorization of inner loop, byRes becomes (169 + 1) ^ 2, i.e. i2 = 1.
In the vectorized code, I've verified that the incorrect result comes about by
extracting from the incorrect index.
vector.ph:; preds = %min.iters.checked
%broadcast.splatinsert = insertelement <16 x i32> undef, i32 %local_4_, i32 0
%broadcast.splat = shufflevector <16 x i32> %broadcast.splatinsert, <16 x
i32> undef, <16 x i32> zeroinitializer
...
br label %vector.body
vector.body:
%vec.ind = phi <16 x i32> [ , %vector.ph ], [ %vec.ind.next, %vector.body ]
%16 = add nuw nsw <16 x i32> %vec.ind, %broadcast.splat
%vec.ind.next = add <16 x i32> %vec.ind,
%18 = icmp eq i32 %index.next, 192
br i1 %18, label %middle.block, label %vector.body, !llvm.loop !0
middle.block: ; preds = %vector.body
%cmp.n = icmp eq i32 192, 192
%vector.recur.extract = extractelement <16 x i32> %16, i32 15
At index 15 from vector extract, we have i2 + i1 = 170, which is the incorrect
result to extract. The correct result is at index 14 (i2 + i1 = 171).
I'll attach the IR before vectorization and after vectorization.
Reproduce problem:
lli test.ll
29241
opt -loop-vectorize test.ll -S > test_after_vectorize.ll 2>&1
lli test_after_vectorize.ll
28900
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32184] PowerPC - llc is spewing remarks in latest build
https://bugs.llvm.org/show_bug.cgi?id=32184 Adam Nemet changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #16 from Adam Nemet --- Thanks. Good point on the status, moved it back. When Hans checks it in we can move it back to RESOLVED. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32061] [meta] 4.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=32061 Bug 32061 depends on bug 32184, which changed state. Bug 32184 Summary: PowerPC - llc is spewing remarks in latest build https://bugs.llvm.org/show_bug.cgi?id=32184 What|Removed |Added Status|RESOLVED|REOPENED 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32397] New: [X86] update_llc_test_checks.py fails on win32 triples
http://bugs.llvm.org/show_bug.cgi?id=32397 Bug ID: 32397 Summary: [X86] update_llc_test_checks.py fails on win32 triples Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com The generated assembly seems to be different enough to prevent the script working correctly -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32379] 64-bit bitfield and/or miscompiled on ARM
https://bugs.llvm.org/show_bug.cgi?id=32379 Eli Friedman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Eli Friedman --- https://reviews.llvm.org/rL298624 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31918] [AMDGPU] error in backend: Cannot select: t18: i32 = addrspacecast[2 -> 0] t24
https://bugs.llvm.org/show_bug.cgi?id=31918 Vedran Miletic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Vedran Miletic --- Fixed in r294786 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24547] Crash while parsing of invalid template specialization
http://bugs.llvm.org/show_bug.cgi?id=24547 Ismail Pazarbasi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Ismail Pazarbasi --- I've tried with 5.0 trunk, and the assertion isn't triggered. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32284] Assertion `Num < NumOperands && "Invalid child # of SDNode!"' failed with -O0 -march=skx.
https://bugs.llvm.org/show_bug.cgi?id=32284 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Nirav Dave --- Fixed in 298604. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32398] New: std::exp() produces infinite loop on Windows with -Ofast
https://bugs.llvm.org/show_bug.cgi?id=32398 Bug ID: 32398 Summary: std::exp() produces infinite loop on Windows with -Ofast Product: new-bugs Version: trunk Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: techmeol...@techmeology.co.uk CC: llvm-bugs@lists.llvm.org Created attachment 18159 --> https://bugs.llvm.org/attachment.cgi?id=18159&action=edit Demonstration of the bug When cross compiling for Windows (I haven't tested native compile on Windows), std::exp() is miscompiled as an infinite loop if -Ofast is used. exp() works correctly, and std::exp() works correctly on Linux. Clang version: 297935 (Also tried a 4.0.0 pre-release with similar results) OS: Arch Linux Steps to reproduce: see build.sh in the tarball Expected result: No infinite loop should be produced. Actual result: The produced IR has a branch to a branch to itself (i.e: an infinite loop). Contents of the tarball: build.sh Shows how I produced all the files in the out directory. exp.cpp A minimal reproducer that demonstrates the bug. out/windows_ofast/exp_expanded.cpp The preprocessed version of exp.cpp on my system for -Ofast on Windows out/windows_ofast/exp.bc The generated IR bitcode for exp.cpp The remaining files are analogous for -O3 and for native build. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32399] New: Clang fsanitize-coverage crashes on Windows
https://bugs.llvm.org/show_bug.cgi?id=32399
Bug ID: 32399
Summary: Clang fsanitize-coverage crashes on Windows
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: adam...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18160
--> https://bugs.llvm.org/attachment.cgi?id=18160&action=edit
Test data
If I compile my code on Windows with option: -fsanitize-coverage=trace-pc-guard
then I receive crash :
Assertion failed: !NodePtr->isKnownSentinel(), file
D:\src\llvm_package_298093\llvm\include\llvm/ADT/ilist_iterator.h, line 139
Source Code:
struct A{
A() {}
~A(){ delete[] d; }
void PB(const int& value) {
c *= 2;
if(c) throw 0;
d = new int[c];
}
int* d;
unsigned int c;
};
int main() {
A v;
v.PB(0);
try {
v.PB(0);
}catch (int e){}
return 0;
}
Sample program in attachment
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32400] New: Report undefined symbol errors before doing LTO
http://bugs.llvm.org/show_bug.cgi?id=32400 Bug ID: 32400 Summary: Report undefined symbol errors before doing LTO Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Currently, undefined symbols are not checked until LTO is done, so it could take a very long time to get an error message for an undefined symbol. This is not user-friendly. We should report undefined symbol errors earlier, before LTO. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32401] New: [InstCombine] failed to canonicalize bitwise logic to icmps
https://bugs.llvm.org/show_bug.cgi?id=32401
Bug ID: 32401
Summary: [InstCombine] failed to canonicalize bitwise logic to
icmps
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
In D31290 (https://reviews.llvm.org/D31290), I had a hard time getting llvm to
produce the optimal scalar code that Eli suggested.
The type is 'char' here, but that doesn't matter for the purpose of this bug.
char cmpeq_bitwise(char x0, char y0, char x1, char y1) {
return ((x0 ^ y0) | (x1 ^ y1)) == 0;
}
char cmpeq_logical(char x0, char y0, char x1, char y1) {
return ((x0 ^ y0) || (x1 ^ y1)) == 0;
}
Before we get to the codegen, we have a missing IR canonicalization of these
equivalent functions:
define i8 @cmpeq_bitwise(i8 %a, i8 %b, i8 %c, i8 %d) {
%xor1 = xor i8 %a, %b
%xor2 = xor i8 %c, %d
%or = or i8 %xor1, %xor2
%cmp = icmp eq i8 %or, 0
%z = zext i1 %cmp to i8
ret i8 %z
}
define i8 @cmpeq_logical(i8 %a, i8 %b, i8 %c, i8 %d) {
%cmp1 = icmp eq i8 %a, %b
%cmp2 = icmp eq i8 %c, %d
%and = and i1 %cmp1, %cmp2
%z = zext i1 %and to i8
ret i8 %z
}
http://rise4fun.com/Alive/C6n
We should prefer the 2nd form because it has less instructions? FWIW, x86
codegen looks better for the 1st form, so we may need to reverse the transform
in the backend.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32403] New: NewGVN will fail to fixpoint on some phis with undef
https://bugs.llvm.org/show_bug.cgi?id=32403
Bug ID: 32403
Summary: NewGVN will fail to fixpoint on some phis with undef
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: dber...@dberlin.org
CC: llvm-bugs@lists.llvm.org
Created attachment 18162
--> https://bugs.llvm.org/attachment.cgi?id=18162&action=edit
undef strikes again.ll
The attached will cause newgvn to infinite loop due to undef in a phi.
It requires a very unfortunate series of events.
We use the same check for whether we can use undef in a phi node as simplify*,
and we need to extend it, it turns out.
Here is what happens:
We have a dom tree that looks like this:
A
/ \
B C
|
..
Note that the first requirement is that B not dominate C and C not dominate B.
We also must visit C before B in RPO (note that here, either could be chosen as
the second block in RPO)
Next, in B and C there are two instructions that end up in the same congruence
class.
We visit C first, so the one in C becomes the leader.
The phi nodes eventually resolve to the instruction in B, which, if you look up
the leader, you get the one in C.
On the next iteration:
// We also special case undef, so that if we have an undef, we can't use
the
// common value unless it dominates the phi block.
if (HasUndef) {
// Only have to check for instructions
if (auto *AllSameInst = dyn_cast(AllSameValue))
if (!DT->dominates(AllSameInst, I))
return E;
The instruction in B dominates the phis, but the instruction in C does not.
So we dutily say "whoops, can't value number this phi to this value"
Which resets the resolution of the phi node cycles.
Which starts again, and gets the same result.
I believe the correct check here is in fact, "does any member of the class of
AllSameInst dominate I"
Since we only would replace it with a member that dominates that phis anyway,
this should be correct.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32404] New: Wrong vector store scheduled before vector load for overlapped array memory
https://bugs.llvm.org/show_bug.cgi?id=32404
Bug ID: 32404
Summary: Wrong vector store scheduled before vector load for
overlapped array memory
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: huih...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Created attachment 18163
--> https://bugs.llvm.org/attachment.cgi?id=18163&action=edit
test input
Consider vectorizing the loop below, give vector factor 8. Pointer a,b,c are
initialized as array of short, and array sizes are 1000.
void foo(short *a, short *b, short *c) {
...
int n = 13;
for (int i=0; i*
%vec0 = load <4 x i16>, <4 x i16>* %vector_ptr0, align 8, !alias.scope !7,
!noalias !9
%scevgep1 = getelementptr i16, i16* %b, i32 8
%vector_ptr1 = bitcast i16* %scevgep1 to <4 x i16>*
%vec1 = load <4 x i16>, <4 x i16>* %vector_ptr1, align 8, !alias.scope !13,
!noalias !14
%0 = zext <4 x i16> %vec1 to <4 x i32>
%scevgep2 = getelementptr i16, i16* %c, i32 8
%vector_ptr2 = bitcast i16* %scevgep2 to <4 x i16>*
%vec2 = load <4 x i16>, <4 x i16>* %vector_ptr2, align 8, !alias.scope !12,
!noalias !16
%1 = sext <4 x i16> %vec2 to <4 x i32>
%vec3 = add <4 x i32> %1, %0
%2 = trunc <4 x i32> %vec3 to <4 x i16>
%scevgep3 = getelementptr i16, i16* %a, i32 8
%vector_ptr3 = bitcast i16* %scevgep3 to <4 x i16>*
store <4 x i16> %2, <4 x i16>* %vector_ptr3, align 8, !alias.scope !7,
!noalias !9
%vector_ptr4 = bitcast i16* %scevgep2 to <4 x i16>*
%vec4 = load <4 x i16>, <4 x i16>* %vector_ptr4, align 8, !alias.scope !12,
!noalias !16
%3 = sext <4 x i16> %vec4 to <4 x i32>
%vec5 = mul <4 x i32> %3, %vec3
%4 = trunc <4 x i32> %vec5 to <4 x i16>
%vector_ptr5 = bitcast i16* %scevgep1 to <4 x i16>*
store <4 x i16> %4, <4 x i16>* %vector_ptr5, align 8, !alias.scope !13,
!noalias !14
%5 = sext <4 x i16> %vec0 to <4 x i32>
%vector_ptr6 = bitcast i16* %scevgep2 to <4 x i16>*
%vec6 = load <4 x i16>, <4 x i16>* %vector_ptr6, align 8, !alias.scope !12,
!noalias !16
%6 = sext <4 x i16> %vec6 to <4 x i32>
%vec7 = mul <4 x i32> %6, %5
%vec8 = add <4 x i32> %vec7, %vec5
%7 = trunc <4 x i32> %vec8 to <4 x i16>
%vector_ptr7 = bitcast i16* %scevgep3 to <4 x i16>*
store <4 x i16> %7, <4 x i16>* %vector_ptr7, align 8, !alias.scope !7,
!noalias !9
ret void
}
!7 = distinct !{!7, !8, !"polly.alias.scope.MemRef_a"}
!8 = distinct !{!8, !"polly.alias.scope.domain"}
!9 = !{!12, !13}
!12 = distinct !{!12, !8, !"polly.alias.scope.MemRef_c"}
!13 = distinct !{!13, !8, !"polly.alias.scope.MemRef_b"}
!14 = !{!12, !7}
!16 = !{!13, !7}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
