[llvm-bugs] [Bug 46741] New: Facing problem in compilatoin of C++ code (having dlib and opencv) to WASM
https://bugs.llvm.org/show_bug.cgi?id=46741 Bug ID: 46741 Summary: Facing problem in compilatoin of C++ code (having dlib and opencv) to WASM Product: clang Version: unspecified Hardware: PC OS: other Status: NEW Severity: enhancement Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: mayanktiwarigg...@gmail.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk I am trying to compile the C++ code to WASM but facing problems in it. My C++ code included dlib and OpenCV libraries. I have successfully compiled OpenCV and dlib for C++ environment. Also, I have installed emscripten in my system. While I am executing the following command emcc -msse3 -msimd128 -std=c++11 -O3 -I ../dlib -I ../opencv/build/include main.cpp -lstdc++ -lpthread -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=4 -s TOTAL_MEMORY=1024MB -s "EXTRA_EXPORTED_RUNTIME_METHODS=['ccall', 'cwrap']" -s WASM=1 -o main.js I am getting the following error. Assertion failed: Legal->getLAI()->getSymbolicStrides().empty() && "Specializing for stride == 1 under -Os/-Oz", file C:\b\s\w\ir\cache\builder\emscripten-releases\llvm-project\llvm\lib\Transforms\Vectorize\LoopVectorize.cpp, line 4941 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: C:/emsdk/upstream/bin\clang++.exe -target wasm32-unknown-emscripten -D__EMSCRIPTEN_major__=1 -D__EMSCRIPTEN_minor__=39 -D__EMSCRIPTEN_tiny__=19 -D_LIBCPP_ABI_VERSION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -nostdsysteminc -D__SSE__=1 -D__SSE2__=1 -D__SSE3__=1 -Xclang -isystemC:\emsdk\upstream\emscripten\system\include\libcxx -Xclang -isystemC:\emsdk\upstream\emscripten\system\lib\libcxxabi\include -Xclang -isystemC:\emsdk\upstream\emscripten\system\lib\libunwind\include -Xclang -isystemC:\emsdk\upstream\emscripten\system\include\compat -Xclang -isystemC:\emsdk\upstream\emscripten\system\include -Xclang -isystemC:\emsdk\upstream\emscripten\system\include\libc -Xclang -isystemC:\emsdk\upstream\emscripten\system\lib\libc\musl\arch\emscripten -Xclang -isystemC:\emsdk\upstream\emscripten\system\local\include -Xclang -isystemC:\emsdk\upstream\emscripten\system\include\SSE -Xclang -isystemC:\emsdk\upstream\emscripten\cache\wasm\include -DEMSCRIPTEN -fignore-exceptions -msimd128 -std=c++11 -O3 -I../dlib -I../opencv/build/include main.cpp -Xclang -isystemC:\emsdk\upstream\emscripten\system\include\SDL -c -o C:\Users\Nitin\AppData\Local\Temp\emscripten_temp_43tvpnaz\main_0.o -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Function Pass Manager' on module 'main.cpp'. 4. Running pass 'Loop Vectorization' on function '@_ZN4dlib4svd4INS_9matrix_opINS_8op_transINS_6matrixIdLl3ELl0ENS_33memory_manager_stateless_kernel_1IcEENS_16row_major_layoutEEELl0ELl1ELl0ELl0ELl3ELl0ES5_S5_S5_S6_EElNS_10svd_u_modeEbRKNS_10matrix_expIT_EERNS3_INSC_4typeEXT2_EXT3_ET6_T9_EERNS3_ISG_XT0_EXT1_ET7_SI_EERNS3_ISG_XT4_EXT5_ET8_SI_EE' #0 0x7ff770728146 (C:\emsdk\upstream\bin\clang++.exe+0x10a8146) #1 0x7ffa5a82cb7d (C:\Windows\System32\ucrtbase.dll+0x6cb7d) #2 0x7ffa5a82db81 (C:\Windows\System32\ucrtbase.dll+0x6db81) #3 0x7ffa5a82f5be (C:\Windows\System32\ucrtbase.dll+0x6f5be) #4 0x7ffa5a82f4b5 (C:\Windows\System32\ucrtbase.dll+0x6f4b5) #5 0x7ffa5a82f841 (C:\Windows\System32\ucrtbase.dll+0x6f841) #6 0x7ff7708d516e (C:\emsdk\upstream\bin\clang++.exe+0x125516e) #7 0x7ff7708d5665 (C:\emsdk\upstream\bin\clang++.exe+0x1255665) #8 0x7ff7708e139a (C:\emsdk\upstream\bin\clang++.exe+0x126139a) #9 0x7ff7708ec040 (C:\emsdk\upstream\bin\clang++.exe+0x126c040) #10 0x7ff7708ef4da (C:\emsdk\upstream\bin\clang++.exe+0x126f4da) #11 0x7ff7708f1e8f (C:\emsdk\upstream\bin\clang++.exe+0x1271e8f) #12 0x7ff77008f8b4 (C:\emsdk\upstream\bin\clang++.exe+0xa0f8b4) #13 0x7ff77008fc03 (C:\emsdk\upstream\bin\clang++.exe+0xa0fc03) #14 0x7ff7700902ed (C:\emsdk\upstream\bin\clang++.exe+0xa102ed) #15 0x7ff770a0585f (C:\emsdk\upstream\bin\clang++.exe+0x138585f) #16 0x7ff7731713bf (C:\emsdk\upstream\bin\clang++.exe+0x3af13bf) #17 0x7ff771e7a4e3 (C:\emsdk\upstream\bin\clang++.exe+0x27fa4e3) #18 0x7ff770fdd215 (C:\emsdk\upstream\bin\clang++.exe+0x195d215) #19 0x7ff770f99f2c (C:\emsdk\upstream\bin\clang++.exe+0x1919f2c) #20 0x7ff771051c0d (C:\emsdk\upstream\bin\clang++.exe+0x19d1c0d) #21 0x7ff76f6875fa (C:\emsdk\upstream\bin\clang++.exe+0x75fa) #22 0x7ff76f684914 (C:\emsdk\upstream\bin\clan
[llvm-bugs] [Bug 46652] opt -loop-vectorize fails with llvm::LoopVectorizationCostModel::runtimeChecksRequired(): Assertion `Legal->getLAI()->getSymbolicStrides().empty() && "Specializing for stride =
https://bugs.llvm.org/show_bug.cgi?id=46652 Heejin Ahn changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||82a5157ff1650e3366f7a9c6192 ||69766ad1d5e93 CC||ahee...@gmail.com Resolution|--- |FIXED --- Comment #1 from Heejin Ahn --- Looks like it has been fixed by https://github.com/llvm/llvm-project/commit/82a5157ff1650e3366f7a9c619269766ad1d5e93. -- 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 46741] Facing problem in compilatoin of C++ code (having dlib and opencv) to WASM
https://bugs.llvm.org/show_bug.cgi?id=46741 Heejin Ahn changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||ahee...@gmail.com --- Comment #1 from Heejin Ahn --- It looks like a duplicate of https://bugs.llvm.org/show_bug.cgi?id=46652, which was fixed a few days ago by https://github.com/llvm/llvm-project/commit/82a5157ff1650e3366f7a9c619269766ad1d5e93. *** This bug has been marked as a duplicate of bug 46652 *** -- 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 46396] WebAssembly exception handling catchpads cannot be addressed sometimes
https://bugs.llvm.org/show_bug.cgi?id=46396 Sascha Braun changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #3 from Sascha Braun --- For me, yes. Sorry for not coming back earlier. Thank You. -- 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 46743] New: libunwind's FrameHeaderCache looks broken on Android 10 and earlier
https://bugs.llvm.org/show_bug.cgi?id=46743 Bug ID: 46743 Summary: libunwind's FrameHeaderCache looks broken on Android 10 and earlier Product: Runtime Libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: libunwind Assignee: unassignedb...@nondot.org Reporter: rprich...@google.com CC: llvm-bugs@lists.llvm.org libunwind now uses the dlpi_adds and dlpi_subs fields in dl_phdr_info (the callback struct for dl_iterate_phdr) to detect an unloaded module and invalidate its cache: https://reviews.llvm.org/D75954 While these fields were common in glibc/BSD/etc for many years, they're still very new in Android. (They're not in Android 10, but will be in the next version.) https://android-review.googlesource.com/c/platform/bionic/+/1104597/ libunwind isn't checking the callback size parameter, so AFAICT, on current versions of Android, it will read bogus stack memory. If a module is unloaded (dlclose), then libunwind might fail to invalidate a cache entry. This issue won't affect ARM32 (because it uses dl_unwind_find_exidx), which is the only target that Android proper (the platform and NDK) officially use libunwind for. Android plans to switch to libunwind for the other architectures, though, and someone in the larger Android community might be using libunwind on other architectures. libgcc also uses these fields, but it verifies that `size` is large enough before assuming the extended dl_phdr_info fields exists. Maybe libunwind could use a check like: (size >= offsetof(dl_phdr_info, dlpi_subs) + sizeof(...->dlpi_subs)) Aside: IIUC, on a cache miss, we're still scanning each entry of the frame cache, for each module passed to the callback. That seems slow? I would think we would want to check the cache on only the first callback invocation, and we'd want to check the cache even when this condition holds: pinfo->dlpi_phnum == 0 || cbdata->targetAddr < pinfo->dlpi_addr Also: A frame cache is still possible (and probably very helpful) on versions of Android before R, but it requires special logic. On a cache hit, it's necessary to scan the modules to verify the hit. This scan can be very quick compared to the current behavior. I'd like to prototype this, but as it's only useful for Android, I'm not sure how interested upstream would be. -- 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 46744] New: Incorrect generation of HTML reports
https://bugs.llvm.org/show_bug.cgi?id=46744 Bug ID: 46744 Summary: Incorrect generation of HTML reports Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: pritam01gha...@gmail.com CC: dcough...@apple.com, llvm-bugs@lists.llvm.org Created attachment 23727 --> https://bugs.llvm.org/attachment.cgi?id=23727&action=edit HTML file generated by scan-build (version 10.0.0) The HTML file generated by the Clang Static Analyser (version 10.0.0) has an issue with the nesting of closing tags. I have attached one such HTML file. In this file, at line 2314, the placement of closing of outermost tr and td tags is incorrect. As a result, HTML parsers like jsoup and pup fail to read the HTML file past the line number 2314. HTML validator reports issues with all the line numbers beginning from 2315 until the end of HTML file. I manually fixed the issue and then the parsers were able to parse the entire HTML file. -- 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 22260 in oss-fuzz: llvm: Coverage build failure
Comment #8 on issue 22260 by ClusterFuzz-External: llvm: Coverage build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22260#c8 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-e13c3d83-2000-4ae3-9ddd-12eca93cbb99.txt -- 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 46745] New: Assertion `(LocalChanged || (RefHash == StructuralHash(F))) && "Pass modifies its input and doesn't report it."' for -loop-idiom pass
https://bugs.llvm.org/show_bug.cgi?id=46745
Bug ID: 46745
Summary: Assertion `(LocalChanged || (RefHash ==
StructuralHash(F))) && "Pass modifies its input and
doesn't report it."' for -loop-idiom pass
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
sguel...@redhat.com
Created attachment 23728
--> https://bugs.llvm.org/attachment.cgi?id=23728&action=edit
IR reproducer.
LLVM commit: 274332282cb4ce167de8e73fb9c59d2eecd67c25
Requires an expensive checks build to reproduce.
$ opt -loop-idiom -disable-basic-aa -S loop-idiom.ll
opt: ../lib/IR/LegacyPassManager.cpp:1591: bool
llvm::FPPassManager::runOnFunction(llvm::Function &): Assertion `(LocalChanged
|| (RefHash == StructuralHash(F))) && "Pass modifies its input and doesn't
report it."' failed.
After some very shallow troubleshooting, the issue seems to be that we return
false in this case:
if (mayLoopAccessLocation(BasePtr, ModRefInfo::ModRef, CurLoop, BECount,
StoreSize, *AA, Stores)) {
Expander.clear();
// If we generated new code for the base pointer, clean up.
RecursivelyDeleteTriviallyDeadInstructions(BasePtr, TLI);
return false;
}
--
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 46746] New: Clang can't compile libstdc++ ranges
https://bugs.llvm.org/show_bug.cgi?id=46746
Bug ID: 46746
Summary: Clang can't compile libstdc++ ranges
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: boris.stale...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Created attachment 23729
--> https://bugs.llvm.org/attachment.cgi?id=23729&action=edit
Preprocessed example that reproduces the error.
GCC 10.1.0 came with libstdc++ that has `` implemented. Also clang 10
supports concepts. I wanted to use clang to compile a simple snippet that
relies on ranges, but clang encountered some errors that just don't happen with
gcc.
```
#include
int main(void)
{
char c[3] = {'a', 'b', 'v'};
std::ranges::subrange sub(c);
}
```
The preprocessed file can be found here: https://godbolt.org/z/7hfbq5
I've also made an attachment with the same preprocessed file compressed.
--
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 46747] New: Lower limit of availability attribute isn't enforced
https://bugs.llvm.org/show_bug.cgi?id=46747
Bug ID: 46747
Summary: Lower limit of availability attribute isn't enforced
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: malcolm_fergu...@yahoo.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The following does not produce an error. I expect it should:
$ cat << EOF | ./clang -x c - -mmacosx-version-min=10.9
__attribute__((availability(macosx,introduced=10.10,deprecated=10.11,obsoleted=10.12)))
int fn(void) { return 1; }
int main() { return fn(); }
EOF
If I set -mmacosx-version-min=10.11, clang issues a warning. If I set it to
10.12, clang issues an error. It handles the upper limit of the availibity
attribute, but not the lower limit.
This was a problem for us compiling Python3 to run on macOS 10.9 using a modern
version of Xcode. The fdopendir() function was added to dirent.h in
MacOSX10.10.sdk and is available on systems running macOS 10.10 or later. The
autoconf script for Python detects that fdopendir is available and uses this
instead of opendir(), but it wouldn't do this if clang issued an error. This
led to runtime fails on the min. supported system. We build all of our
products this way, which means we run the risk of accidentally using functions
that aren't available.
Apple's dirent.h declares:
__OSX_AVAILABLE_STARTING(__MAC_10_10, __IPHONE_8_0)
DIR *fdopendir(int) __DARWIN_ALIAS_I(fdopendir);
Which preprocesses to:
# 128
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/dirent.h"
3 4
__attribute__((availability(macosx,introduced=10.10)))
DIR *fdopendir(int) __asm("_" "fdopendir" "$INODE64" );
--
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 46748] New: Unexpected signed integer or fixed point type: UNREACHABLE executed at ASTContext.cpp:9789!
https://bugs.llvm.org/show_bug.cgi?id=46748
Bug ID: 46748
Summary: Unexpected signed integer or fixed point type:
UNREACHABLE executed at ASTContext.cpp:9789!
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: t.pries...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 23730
--> https://bugs.llvm.org/attachment.cgi?id=23730&action=edit
Preprocessed source file
Compiling the following (reduced) file with clang 11.0 (compiled from trunk)
causes clang to crash with the following message:
$ cat bug.cpp
void a() {
wchar_t *b;
b = (char*)v
}
Error (full error output attached):
Unexpected signed integer or fixed point type
UNREACHABLE executed at
/home/user/llvm-project/clang/lib/AST/ASTContext.cpp:9789!
Note: Clang version 10.0.0 just reports a compile error and doesn't crash.
Additional Information:
$ clang++ --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
e73d0b5719966ddbeff7a3da70a3cb782c3733ed)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/user/llvm-project/build/bin
$ cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20200710"
--
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 46749] New: Assertion `(LocalChanged || (RefHash == StructuralHash(F))) && "Pass modifies its input and doesn't report it."' for -globalopt pass
https://bugs.llvm.org/show_bug.cgi?id=46749 Bug ID: 46749 Summary: Assertion `(LocalChanged || (RefHash == StructuralHash(F))) && "Pass modifies its input and doesn't report it."' for -globalopt pass Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: david.stenb...@ericsson.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, sguel...@redhat.com Created attachment 23733 --> https://bugs.llvm.org/attachment.cgi?id=23733&action=edit IR reproducer. Requires an expensive checks build to reproduce. $ opt -globalopt -S globalopt.ll opt: ../lib/IR/LegacyPassManager.cpp:1702: bool (anonymous namespace)::MPPassManager::runOnModule(llvm::Module &): Assertion `(LocalChanged || (RefHash == StructuralHash(M))) && "Pass modifies its input and doesn't report it."' failed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46750] New: Crash in BitcodeReader.cpp under LTO
https://bugs.llvm.org/show_bug.cgi?id=46750 Bug ID: 46750 Summary: Crash in BitcodeReader.cpp under LTO Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llc Assignee: unassignedb...@nondot.org Reporter: chenmindong...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 23736 --> https://bugs.llvm.org/attachment.cgi?id=23736&action=edit reduced c code $ clang -O2 -flto=full test.c -o test.o Or $ llvm-dis test.o llvm/lib/IR/Value.cpp:404: void llvm::Value::doRAUW(llvm::Value*, llvm::Value::ReplaceMetadataUses): Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed. After some trouble shooting, I think the root is it's when parseConstants() in BitcodeReader reads in a CST_CODE_CE_SELECT record, e.g. select , , If “ty” here is a vector type and “cond” is a forward reference, LLVM uses i1 as the placeholder type of “cond” if it cannot find “cond” in ValueList, as the code follows: Type *SelectorTy = Type::getInt1Ty(Context); // The selector might be an i1 or an // Get the type from the ValueList before getting a forward ref. if (VectorType *VTy = dyn_cast(CurTy)) if (Value *V = ValueList[Record[0]]) if (SelectorTy != V->getType()) SelectorTy = VectorType::get(SelectorTy, VTy->getNumElements()); However, the program aborts in RAUW() if we find “selty” is a vector type later, because LLVM are trying to replace an i1 placeholder with an value. -- 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 46740] Merge 00f3579aea6e3d4a4b7464c3db47294f71cef9e4 to 11.0
https://bugs.llvm.org/show_bug.cgi?id=46740 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Pushed in 529f2e03592c072bb0f768db5b5e3731cccbebf3. 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] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46740, which changed state. Bug 46740 Summary: Merge 00f3579aea6e3d4a4b7464c3db47294f71cef9e4 to 11.0 https://bugs.llvm.org/show_bug.cgi?id=46740 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 46751] New: flang changes on LLVM Phabricator that should cause build failures not flagged as such
https://bugs.llvm.org/show_bug.cgi?id=46751 Bug ID: 46751 Summary: flang changes on LLVM Phabricator that should cause build failures not flagged as such Product: Phabricator Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: jura...@google.com CC: llvm-bugs@lists.llvm.org A change that I had posted for review (https://reviews.llvm.org/D83522) had a compile error, but LLVM's Phabricator build declared that build passed. Flang seems to be building in the builds, but the build was never flagged as failing. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46593, which changed state. Bug 46593 Summary: OpenMP: Reduction initializer missing construnctor call. Test segfaults failed at runtime. https://bugs.llvm.org/show_bug.cgi?id=46593 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 46593] OpenMP: Reduction initializer missing construnctor call. Test segfaults failed at runtime.
https://bugs.llvm.org/show_bug.cgi?id=46593 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Pushed to 11.x as 3388ca490dc61365a6607b3217bfe446de3eabe4 -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46688, which changed state. Bug 46688 Summary: omp_pteam_mem_alloc memory "Invalid constantexpr cast" https://bugs.llvm.org/show_bug.cgi?id=46688 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 46688] omp_pteam_mem_alloc memory "Invalid constantexpr cast"
https://bugs.llvm.org/show_bug.cgi?id=46688 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- (In reply to Alexey Bataev from comment #1) > Fixed in 9dc327d1b74637dac6dc432fb66f88711af16a55 Pushed to 11.x in 73e8ca7bbad561170a874de6246863a0b9fc24f9 -- 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46712, which changed state. Bug 46712 Summary: Instcombine infinite combine loop - conflicting transforms https://bugs.llvm.org/show_bug.cgi?id=46712 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 46712] Instcombine infinite combine loop - conflicting transforms
https://bugs.llvm.org/show_bug.cgi?id=46712 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #5 from Hans Wennborg --- Thanks! Pushed to 11.x as 59521a06026e3912319db118340d48430838db09 and 12aa43e621ff3b60b515eaf33bb25ba439094140 -- 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 42876] bool != less efficient than bool ==
https://bugs.llvm.org/show_bug.cgi?id=42876 Roger Ferrer Ibanez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Roger Ferrer Ibanez --- Fixed in 14bc5e149d11 -- 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 46753] New: AssumeBundles bad interaction with SROA
https://bugs.llvm.org/show_bug.cgi?id=46753 Bug ID: 46753 Summary: AssumeBundles bad interaction with SROA Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: x...@google.com CC: llvm-bugs@lists.llvm.org Created attachment 23737 --> https://bugs.llvm.org/attachment.cgi?id=23737&action=edit test case The recently change on alignment assumption generated very inefficient codes -- it seems SROA cannot handle the patten in the new implementation and fail to do the cleanup. Some of our internal tests suffer 10x slow down. The attached program shows the problem. Without the patch, we have 6 instructions. With the patch, we have ~100 instructions, most of them are redundant. -- 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 46744] Incorrect generation of HTML reports
https://bugs.llvm.org/show_bug.cgi?id=46744 Artem Dergachev changed: What|Removed |Added Resolution|--- |DUPLICATE CC||noqnoq...@gmail.com Status|NEW |RESOLVED --- Comment #1 from Artem Dergachev --- I believe i fixed this recently in 482e236e569e / https://bugs.llvm.org/show_bug.cgi?id=44782 / https://reviews.llvm.org/D73993. If this is still an issue in clang-11, could you point me to some specific source code to reproduce the problem? (that's GNU coreutils, right?) *** This bug has been marked as a duplicate of bug 44782 *** -- 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 46744] Incorrect generation of HTML reports
https://bugs.llvm.org/show_bug.cgi?id=46744 Artem Dergachev changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #3 from Artem Dergachev --- Wait, no, there weren't any 10.x minor releases yet. The patch should have been in 10.0.0. I'll try to reproduce with coreutils then (but specific details are still welcome). -- 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 46754] New: [11.x branch] clangd writes index to random directories
https://bugs.llvm.org/show_bug.cgi?id=46754 Bug ID: 46754 Summary: [11.x branch] clangd writes index to random directories Product: clang-tools-extra Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: clangd Assignee: h...@chromium.org Reporter: sammcc...@google.com CC: kadircetinkaya.06...@gmail.com, llvm-bugs@lists.llvm.org We're accidentally writing index files to `.cache/clangd/index/` relative to the working directory, instead of relative to the project. (This appears to be an old latent bug that was recently exposed) The fix is simple and has been committed on master, but should be cherrypicked to 11.x https://github.com/llvm/llvm-project/commit/46c921003c2ce5f1cdc4de9ef613eb001980780c -- 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 46755] New: Windows bots require Cmake update
https://bugs.llvm.org/show_bug.cgi?id=46755 Bug ID: 46755 Summary: Windows bots require Cmake update Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: amcca...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk The following bots need to be updated to CMake 3.13.4 or newer in order to build LLVM: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc http://lab.llvm.org:8011/builders/sanitizer-windows The primary for these bots (@rnk) is on leave. We're trying to figure whether anyone else has access to do this in the mean time. Thanks to @ldionne for bringing this to our attention. -- 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 46756] New: Is it intended behaviour for LLVM to emit `vpbroadcastd` for a constant on every iteration.
https://bugs.llvm.org/show_bug.cgi?id=46756 Bug ID: 46756 Summary: Is it intended behaviour for LLVM to emit `vpbroadcastd` for a constant on every iteration. Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: denis.yaroshevs...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk This is the main loop: ``` .LBB0_8:# Parent Loop BB0_6 Depth=1 # => This Inner Loop Header: Depth=2 vmovdqa ymm7, ymmword ptr [rdi] vpcmpgtdymm8, ymm2, ymm7 vpminsd ymm2, ymm2, ymm7 vpblendvb ymm1, ymm1, ymm6, ymm8 vpbroadcastdymm7, dword ptr [rip + .LCPI0_2] # ymm7 = [8,8,8,8,8,8,8,8] vpaddd ymm6, ymm6, ymm7 add rdi, 32 cmp rcx, rdi jne .LBB0_8 ``` This `vpbroadcastd` that just assigns 8 on every step seems like a bug. In a similar situation llvm keeps it in the register, see https://gcc.godbolt.org/z/94M91c for both unrolled and not unrolled cases. Profiling is inconclusive in terms of if this `broadcast` is a problem: 0.11 │ data16 data16 data16 data16 nop WORD PTR cs:[rax+rax*1+0x0] 0.88 │ vmovdqa ymm8,YMMWORD PTR [rdi] 0.27 │ vpcmpgtd ymm9,ymm5,ymm8 27.13 │ vpminsd ymm5,ymm5,ymm8 30.93 │ vpblendvbymm4,ymm4,ymm7,ymm9 │ vpbroadcastd ymm8,DWORD PTR [rip+0x9974b] My code you won't be able to compile, but here is a complete disassembly: https://github.com/DenisYaroshevskiy/unsq_eve/blob/8dc8e992d9ced36c0a37b8ea6a6ae3eb6e97d6e2/disassemble/disassemble.s#L118 Is this expected? If it's not - can you recommend a workaround? -- 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 42643] OpenMP target regions cause CUBLAS_STATUS_INTERNAL_ERROR in libcublas
https://bugs.llvm.org/show_bug.cgi?id=42643 Ye Luo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||c5348aecd7723e7aa7b18406d0c ||97724c0659f34 -- 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 46757] New: loop-reduce introduce invnalid ptrtoint/inttoptr
https://bugs.llvm.org/show_bug.cgi?id=46757
Bug ID: 46757
Summary: loop-reduce introduce invnalid ptrtoint/inttoptr
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org
Optimizing the code below with `opt -loop-reduce` causes incorrect `inttoptr`
to be emitted for the non-integral pointer.
```
target datalayout =
"e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64-ni:10:11:12:13"
target triple = "armv7l-unknown-linux-gnueabihf"
define dso_local void @julia_roundup_19730() {
top:
br label %L37
L37: ; preds = %L49, %top
%value_phi7 = phi i32 [ %3, %L49 ], [ 0, %top ]
br i1 undef, label %L49, label %L47
L47: ; preds = %L37
unreachable
L49: ; preds = %L37
%0 = add i32 %value_phi7, -2
%1 = getelementptr inbounds i8, i8 addrspace(13)* null, i32 %0
%2 = load i8, i8 addrspace(13)* %1, align 1
%3 = add i32 %value_phi7, -1
br label %L37
}
```
The transformation done is,
```
*** IR Dump Before Loop Strength Reduction ***
; Preheader:
top:
br label %L37
; Loop:
L37: ; preds = %L49, %top
%value_phi7 = phi i32 [ %3, %L49 ], [ 0, %top ]
br i1 false, label %L49, label %L47
L49: ; preds = %L37
%0 = add i32 %value_phi7, -2
%1 = getelementptr inbounds i8, i8 addrspace(13)* null, i32 %0
%2 = load i8, i8 addrspace(13)* %1, align 1
%3 = add i32 %value_phi7, -1
br label %L37
; Exit blocks
L47: ; preds = %L37
unreachable
*** IR Dump After Loop Strength Reduction ***
; Preheader:
top:
br label %L37
; Loop:
L37: ; preds = %L49, %top
%lsr.iv = phi i32 [ %lsr.iv.next, %L49 ], [ -2, %top ]
%lsr.iv1 = inttoptr i32 %lsr.iv to i8 addrspace(13)*
br i1 false, label %L49, label %L47
L49: ; preds = %L37
%0 = load i8, i8 addrspace(13)* %lsr.iv1, align 1
%lsr.iv.next = add nsw i32 %lsr.iv, -1
br label %L37
; Exit blocks
L47: ; preds = %L37
unreachable
```
Reproducible as of a week ago on master.
--
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 46758] New: StackColoring mutate IR and generate invalid IR
https://bugs.llvm.org/show_bug.cgi?id=46758
Bug ID: 46758
Summary: StackColoring mutate IR and generate invalid IR
Product: libraries
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org
I have not been able to reproduce this in a standalone way yet.
Here's the IR for the function.
```
define internal void @julia_now_16891([1 x [1 x [1 x i64]]]* noalias nocapture
sret %0) !dbg !137639 {
top:
%1 = alloca {} addrspace(10)*, i32 3
%gcframe = alloca {} addrspace(10)*, i32 3, align 16
%2 = bitcast {} addrspace(10)** %gcframe to i8*
call void @llvm.memset.p0i8.i32(i8* align 16 %2, i8 0, i32 12, i1 false),
!tbaa !8249
%3 = alloca i128, align 16
%4 = bitcast i128* %6 to i8*
%5 = alloca i448, align 16
%6 = bitcast i448* %5 to i128*
%7 = alloca i32, align 8
%8 = alloca i64, align 8
%thread_ptr = call i8* asm "mrc p15, 0, $0, c13, c0, 3", "=r"()
%ptls_i8 = getelementptr i8, i8* %thread_ptr, i32 8
%ptls = bitcast i8* %ptls_i8 to {}***
%9 = bitcast {} addrspace(10)** %gcframe to {} addrspace(10)**
%10 = bitcast {} addrspace(10)** %9 to i32*
store i32 4, i32* %10, align 4, !tbaa !8249
%11 = bitcast {}*** %ptls to {}***
%12 = load {}**, {}*** %11, align 4
%13 = getelementptr {} addrspace(10)*, {} addrspace(10)** %gcframe, i32 1
%14 = bitcast {} addrspace(10)** %13 to {}***
store {}** %12, {}*** %14, align 4, !tbaa !8249
%15 = bitcast {}*** %11 to {} addrspace(10)***
store {} addrspace(10)** %gcframe, {} addrspace(10)*** %15, align 4
call void @llvm.lifetime.start.p0i8(i64 16, i8* nonnull %4)
%16 = bitcast i128* %6 to i8*, !dbg !137640
%17 = load atomic i32 (i8*)*, i32 (i8*)** bitcast (void ()**
@jlplt_jl_gettimeofday_16894_got to i32 (i8*)**) unordered, align 4, !dbg
!137640
%18 = call i32 %17(i8* nonnull %16), !dbg !137640
%19 = icmp eq i32 %18, 0, !dbg !137643
br i1 %19, label %L10, label %L8, !dbg !137647
L8: ; preds = %top
%20 = bitcast i128* %6 to i8*
%21 = load {}*, {}** @jl_globalYY.1777, align 4, !dbg !137647, !tbaa !8259,
!nonnull !4
%22 = addrspacecast {}* %21 to {} addrspace(10)*, !dbg !137647
%23 = load {}*, {}** @jl_globalYY.5951, align 4, !dbg !137647, !tbaa !8259,
!nonnull !4
%24 = addrspacecast {}* %23 to {} addrspace(10)*, !dbg !137647
call void @llvm.lifetime.end.p0i8(i64 16, i8* nonnull %20)
%25 = call {} addrspace(10)* @jl_box_int32(i32 signext %18), !dbg !137647
%26 = getelementptr {} addrspace(10)*, {} addrspace(10)** %gcframe, i32 2
store {} addrspace(10)* %25, {} addrspace(10)** %26
%27 = bitcast {} addrspace(10)** %1 to {} addrspace(10)**, !dbg !137647
store {} addrspace(10)* %24, {} addrspace(10)** %27, align 4, !dbg !137647
%28 = getelementptr {} addrspace(10)*, {} addrspace(10)** %1, i32 1, !dbg
!137647
store {} addrspace(10)* %25, {} addrspace(10)** %28, align 4, !dbg !137647
%29 = call nonnull {} addrspace(10)* @jl_apply_generic({} addrspace(10)* %22,
{} addrspace(10)** %1, i32 2), !dbg !137647
call void @llvm.trap(), !dbg !137647
unreachable, !dbg !137647
L10: ; preds = %top
%30 = bitcast i448* %5 to i8*
%31 = bitcast i128* %6 to i8*
%32 = bitcast i128* %6 to [2 x i64]*, !dbg !137648
%.elt = bitcast i128* %6 to i64*, !dbg !137648
%.unpack = load i64, i64* %.elt, align 16, !dbg !137648, !tbaa !8286
%.elt10 = getelementptr inbounds [2 x i64], [2 x i64]* %32, i32 0, i32 1,
!dbg !137648
%.unpack11 = load i64, i64* %.elt10, align 8, !dbg !137648, !tbaa !8286
call void @llvm.lifetime.end.p0i8(i64 16, i8* nonnull %31)
call void @llvm.lifetime.start.p0i8(i64 56, i8* nonnull %30)
%33 = bitcast i448* %5 to i32*, !dbg !137653
store i32 0, i32* %33, align 16, !dbg !137653, !tbaa !8286
%34 = bitcast i448* %5 to i8*, !dbg !137653
%35 = getelementptr inbounds i8, i8* %34, i32 4, !dbg !137653
%36 = bitcast i8* %35 to i32*, !dbg !137653
store i32 0, i32* %36, align 4, !dbg !137653, !tbaa !8286
%37 = bitcast i448* %5 to i8*, !dbg !137653
%38 = getelementptr inbounds i8, i8* %37, i32 8, !dbg !137653
%39 = bitcast i8* %38 to i32*, !dbg !137653
store i32 0, i32* %39, align 8, !dbg !137653, !tbaa !8286
%40 = bitcast i448* %5 to i8*, !dbg !137653
%41 = getelementptr inbounds i8, i8* %40, i32 12, !dbg !137653
%42 = bitcast i8* %41 to i32*, !dbg !137653
store i32 0, i32* %42, align 4, !dbg !137653, !tbaa !8286
%43 = bitcast i448* %5 to i8*, !dbg !137653
%44 = getelementptr inbounds i8, i8* %43, i32 16, !dbg !137653
%45 = bitcast i8* %44 to i32*, !dbg !137653
store i32 0, i32* %45, align 16, !dbg !137653, !tbaa !8286
%46 = bitcast i448* %5 to i8*, !dbg !137653
%47 = getele
