[llvm-bugs] [Bug 144981] [clang] Support layering checks for C++ modules
Issue 144981 Summary [clang] Support layering checks for C++ modules Labels clang Assignees Reporter matts1 One highly useful feature of build systems is the ability to ensure strict dependencies. For more details, see this [blog post](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html). ## What are strict deps TLDR: Strict deps enforce that code can only depend on its direct dependencies, and not transitive dependencies. Consider the following code: ``` // foo.cppm import bar; import baz; ``` ``` // bar.cppm import baz ``` ``` # BUILD cc_module( name = "foo", interface = "foo.cppm", deps = [":bar"] ) cc_module( name = "bar", interface = "bar.cppm", deps = [":baz"] ) ``` This code *should* not compile. `foo` imports `baz`, but does not declare a dependency on `baz`. However, build systems have no easy mechanism to enforce this, as they have to output compile steps along the lines of: ``` clang++ --precompile baz.cppm -o baz.pcm clang++ --precompile bar.cppm -fmodule-file=baz=baz.pcm -o bar.pcm clang++ --precompile foo.cppm -fmodule-file=baz=baz.pcm -fmodule-file=bar=bar.pcm -o foo.pcm ``` Note that we cannot simply remove the `-fmodule-file=baz=...`, otherwise we would get an error if the module `bar` ever tried to return a value of a type declared in `baz`. ## Proposal I propose that clang adds a new option `-findirect-module-file`. This has the same semantics as `-fmodule-file`, with the only difference being that if you ever attempt to import the module from the main TU, you get an error. It might also be a good idea to add `-Wstrict-module-deps` or similar, so that this option can be first applied as warnings to an existing codebase, instead of errors. This would allow the build system to generate: ``` clang++ --precompile baz.cppm -o baz.pcm clang++ --precompile bar.cppm -fmodule-file=baz=baz.pcm -o bar.pcm clang++ --precompile foo.cppm -findirect-module-file=baz=baz.pcm -fmodule-file=bar=bar.pcm -o foo.pcm ``` Thus allowing foo to fail to compile in the first place. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144964] Missed optimisation/UBSAN in chacha reference implementation
Issue
144964
Summary
Missed optimisation/UBSAN in chacha reference implementation
Labels
new issue
Assignees
Reporter
nabijaczleweli
This is a variant on ; the same problem plagues both:
```c
/*
chacha-merged.c version 20080118
D. J. Bernstein
Public domain.
*/
#include
#include
#include
#include
#include
#if !defined(BYTE_ORDER) || !defined(LITTLE_ENDIAN) || !defined(BIG_ENDIAN)
static_assert(false, "BYTE_ORDER is undefined. Perhaps, GNU extensions are not enabled");
#endif
#define IDENT16(x) ((uint16_t) (x))
#define IDENT32(x) ((uint32_t) (x))
#define IDENT64(x) ((uint64_t) (x))
#define SWAP16(x) uint16_t) (x) & 0x00ff) << 8) | \
(((uint16_t) (x) & 0xff00) >> 8))
#define SWAP32(x) uint32_t) (x) & 0x00ff) << 24) | \
(((uint32_t) (x) & 0xff00) << 8) | \
(((uint32_t) (x) & 0x00ff) >> 8) | \
(((uint32_t) (x) & 0xff00) >> 24))
#define SWAP64(x) uint64_t) (x) & 0x00ff) << 56) | \
(((uint64_t) (x) & 0xff00) << 40) | \
(((uint64_t) (x) & 0x00ff) << 24) | \
(((uint64_t) (x) & 0xff00) << 8) | \
(((uint64_t) (x) & 0x00ff) >> 8) | \
(((uint64_t) (x) & 0xff00) >> 24) | \
(((uint64_t) (x) & 0x00ff) >> 40) | \
(((uint64_t) (x) & 0xff00) >> 56))
static inline uint32_t rol32(uint32_t x, int r) {
return (x << (r & 31)) | (x >> (-r & 31));
}
#if BYTE_ORDER == LITTLE_ENDIAN
#define SWAP16LE IDENT16
#define SWAP16BE SWAP16
#define swap16le ident16
#define swap16be swap16
#define mem_inplace_swap16le mem_inplace_ident
#define mem_inplace_swap16be mem_inplace_swap16
#define memcpy_swap16le memcpy_ident16
#define memcpy_swap16be memcpy_swap16
#define SWAP32LE IDENT32
#define SWAP32BE SWAP32
#define swap32le ident32
#define swap32be swap32
#define mem_inplace_swap32le mem_inplace_ident
#define mem_inplace_swap32be mem_inplace_swap32
#define memcpy_swap32le memcpy_ident32
#define memcpy_swap32be memcpy_swap32
#define SWAP64LE IDENT64
#define SWAP64BE SWAP64
#define swap64le ident64
#define swap64be swap64
#define mem_inplace_swap64le mem_inplace_ident
#define mem_inplace_swap64be mem_inplace_swap64
#define memcpy_swap64le memcpy_ident64
#define memcpy_swap64be memcpy_swap64
#endif
#if BYTE_ORDER == BIG_ENDIAN
#define SWAP16BE IDENT16
#define SWAP16LE SWAP16
#define swap16be ident16
#define swap16le swap16
#define mem_inplace_swap16be mem_inplace_ident
#define mem_inplace_swap16le mem_inplace_swap16
#define memcpy_swap16be memcpy_ident16
#define memcpy_swap16le memcpy_swap16
#define SWAP32BE IDENT32
#define SWAP32LE SWAP32
#define swap32be ident32
#define swap32le swap32
#define mem_inplace_swap32be mem_inplace_ident
#define mem_inplace_swap32le mem_inplace_swap32
#define memcpy_swap32be memcpy_ident32
#define memcpy_swap32le memcpy_swap32
#define SWAP64BE IDENT64
#define SWAP64LE SWAP64
#define swap64be ident64
#define swap64le swap64
#define mem_inplace_swap64be mem_inplace_ident
#define mem_inplace_swap64le mem_inplace_swap64
#define memcpy_swap64be memcpy_ident64
#define memcpy_swap64le memcpy_swap64
#endif
/*
* The following macros are used to obtain exact-width results.
*/
#define U8V(v) ((uint8_t)(v) & UINT8_C(0xFF))
#define U32V(v) ((uint32_t)(v) & UINT32_C(0x))
/*
* The following macros load words from an array of bytes with
* different types of endianness, and vice versa.
*/
#define U8TO32_LITTLE(p) SWAP32LE(((uint32_t*)(p))[0])
#define U32TO8_LITTLE(p, v) (((uint32_t*)(p))[0] = SWAP32LE(v))
#define ROTATE(v,c) (rol32(v,c))
#define XOR(v,w) ((v) ^ (w))
#define PLUS(v,w) (U32V((v) + (w)))
#define PLUSONE(v) (PLUS((v),1))
#define QUARTERROUND(a,b,c,d) \
a = PLUS(a,b); d = ROTATE(XOR(d,a),16); \
c = PLUS(c,d); b = ROTATE(XOR(b,c),12); \
a = PLUS(a,b); d = ROTATE(XOR(d,a), 8); \
c = PLUS(c,d); b = ROTATE(XOR(b,c), 7);
static const char sigma[] = "expand 32-byte k";
static void chacha(unsigned rounds, const void* data, size_t length, const uint8_t* key, const uint8_t* iv, char* cipher) {
uint32_t x0, x1, x2, x3, x4, x5, x6, x7, x8, x9, x10, x11, x12, x13, x14, x15;
uint32_t j0, j1, j2, j3, j4, j5, j6, j7, j8, j9, j10, j11, j12, j13, j14, j15;
char* ctarget = 0;
char tmp[64];
int i;
if (!length) return;
j0 = U8TO32_LITTLE(sigma + 0);
j1 = U8TO32_LITTLE(sigma + 4);
j2 = U8TO32_LITTLE(sigma + 8);
j3 = U8TO32_LITTLE(sigma + 12);
j4 = U8TO32_LITTLE(key + 0);
j5 = U8TO32_LITTLE(key + 4);
j6 = U8TO32_LITTLE(key + 8);
j7 = U8TO32_LITTLE(key + 12);
j8 = U8TO32_LITTLE(key + 16);
j9 = U8TO32_LITTLE(key + 20);
j10 = U8TO32_LITTLE(key + 24);
j11 = U8TO32_LITTLE(key + 28);
j12 = 0;
j13 = 0;
j14 = U8TO32_LITTLE(iv + 0);
j15 = U8TO32_LITTLE(iv + 4);
for (;;) {
if (length < 6
[llvm-bugs] [Bug 144966] [HLSL] firstbithigh/firstbitlow raise assertions when enabled
Issue 144966 Summary [HLSL] firstbithigh/firstbitlow raise assertions when enabled Labels bug, HLSL Assignees Reporter V-FEXrt See https://github.com/llvm/offload-test-suite/pull/209 for more details Looks like something is the scalarizer is going awry causing an assertion to be raised ``` # | Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!", file E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\lib\IR\Instructions.cpp, line 757 # | PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. # | Stack dump: # | 0. Program arguments: E:\\actions-runner\\_work\\offload-test-suite\\offload-test-suite\\llvm-project\\build\\bin\\clang-dxc.exe -cc1 -triple dxilv1.5-unknown-shadermodel6.5-compute -O3 -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name source.hlsl -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -debugger-tuning=gdb -fdebug-compilation-dir=E:\\actions-runner\\_work\\offload-test-suite\\offload-test-suite\\llvm-project\\build\\tools\\OffloadTest\\test\\clang-d3d12\\Feature\\HLSLLib -fcoverage-compilation-dir=E:\\actions-runner\\_work\\offload-test-suite\\offload-test-suite\\llvm-project\\build\\tools\\OffloadTest\\test\\clang-d3d12\\Feature\\HLSLLib -resource-dir E:\\actions-runner\\_work\\offload-test-suite\\offload-test-suite\\llvm-project\\build\\lib\\clang\\21 -ferror-limit 19 -O3 -finclude-default-header -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -vectorize-loops -vectorize-slp -o C:\\WINDOWS\\SERVIC~1\\NETWOR~1\\AppData\\Local\\Temp\\lit-tmp-n1_2nql9\\source-cacd82.obj -x hlsl E:\\actions-runner\\_work\\offload-test-suite\\offload-test-suite\\llvm-project\\build\\tools\\OffloadTest\\test\\clang-d3d12\\Feature\\HLSLLib\\Output\\firstbitlow.64.test.tmp/source.hlsl # | 1. parser at end of file # | 2. Code generation # | 3. Running pass 'Function Pass Manager' on module 'E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\build\tools\OffloadTest\test\clang-d3d12\Feature\HLSLLib\Output\firstbitlow.64.test.tmp/source.hlsl'. # | 4. Running pass 'Scalarize vector operations' on function '@main' # | Exception Code: 0xC01D # | #0 0x7ff61e7831c6 HandleAbort E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\lib\Support\Windows\Signals.inc:429:0 # | #1 0x7ffb3150[198](https://github.com/llvm/offload-test-suite/actions/runs/15766564388/job/4055767?pr=209#step:10:199)9 (C:\WINDOWS\System32\ucrtbase.dll+0xc1989) # | #2 0x7ffb314e4ab1 (C:\WINDOWS\System32\ucrtbase.dll+0xa4ab1) # | #3 0x7ffb31502986 (C:\WINDOWS\System32\ucrtbase.dll+0xc2986) # | #4 0x7ffb31502b61 (C:\WINDOWS\System32\ucrtbase.dll+0xc2b61) # | #5 0x7ff61ec28947 llvm::CallInst::init(class llvm::FunctionType *, class llvm::Value *, class llvm::ArrayRef, class llvm::ArrayRef>, class llvm::Twine const &) E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\lib\IR\Instructions.cpp:755:0 # | #6 0x7ff61e47c33c llvm::CallInst::CallInst E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\include\llvm\IR\Instructions.h:1680:0 # | #7 0x7ff61e47c33c llvm::CallInst::Create(class llvm::FunctionType *, class llvm::Value *, class llvm::ArrayRef, class llvm::ArrayRef>, class llvm::Twine const &, class llvm::InsertPosition) E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\include\llvm\IR\Instructions.h:1568:0 # | #8 0x7ff61e47bdf6 llvm::IRBuilderBase::CreateCall(class llvm::FunctionType *, class llvm::Value *, class llvm::ArrayRef, class llvm::Twine const &, class llvm::MDNode *) E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\include\llvm\IR\IRBuilder.h:2507:0 # | #9 0x7ff61e71e3ce llvm::IRBuilderBase::CreateCall E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\include\llvm\IR\IRBuilder.h:2528:0 # | #10 0x7ff61e71e3ce `anonymous namespace'::ScalarizerVisitor::splitCall E:\actions-runner\_work\offload-test-suite\offload-test-suite\llvm-project\llvm\lib\Transforms\Scalar\Scalarizer.cpp:793:0 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144969] After compiling llvm project, use Clang to compile a cuda kernel which calls cutlass gemm interface, but it report a compile error
Issue 144969 Summary After compiling llvm project, use Clang to compile a cuda kernel which calls cutlass gemm interface, but it report a compile error Labels clang Assignees Reporter zhangzh33 command is: /data/llvm/build/bin/clang-19 -I/data/cutlass/include -I/usr/local/cuda-12.2/include --cuda-gpu-arch=sm_70 -O2 -std=c++17 --cuda-device-only -Xcuda-ptxas -v -o test.s test.cu compile error: clang-19: /data/llvm/clang/lib/AST/ExprClassification.cpp:72: Cl clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const: Assertion `isPRValue()' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /data/llvm/build/bin/clang-19 -cc1 -triple nvptx64-nvidia-cuda -aux-triple x86_64-unknown-linux-gnu -S -dumpdir test.ptx- -disable-free -clear-ast-before-backend -main-file-name test.cu -mrelocation-model static -mframe-pointer=all -fno-rounding-math -no-integrated-as -aux-target-cpu x86-64 -fcuda-is-device -mllvm -enable-memcpyopt-without-libcalls -fcuda-allow-variadic-functions -mlink-builtin-bitcode /usr/local/cuda-12.2/nvvm/libdevice/libdevice.10.bc -target-sdk-version=12.2 -target-cpu sm_70 -target-feature +ptx82 -debugger-tuning=gdb -fno-dwarf-directory-asm -fdebug-compilation-dir=/xp6/demo_cutlass -resource-dir /data/llvm/build/lib/clang/19 -internal-isystem /data/llvm/build/lib/clang/19/include/cuda_wrappers -include __clang_cuda_runtime_wrapper.h -I /data/cutlass/include -I /usr/local/cuda-12.2/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/x86_64-linux-gnu/c++/11 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/backward -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/x86_64-linux-gnu/c++/11 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/backward -internal-isystem /data/llvm/build/lib/clang/19/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -internal-isystem /usr/local/cuda-12.2/include -internal-isystem /data/llvm/build/lib/clang/19/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -std=c++17 -fdeprecated-macro -fno-autolink -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fcolor-diagnostics -vectorize-loops -vectorize-slp -cuid=27acb42ef6f99229 -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/test-sm_70-0e74d8.s -x cuda test.cu 1. /data/cutlass/include/cute/numeric/integral_constant.hpp:227:1 : at annotation token 2. /data/cutlass/include/cute/numeric/integral_constant.hpp:37:1: parsing namespace 'cute' #0 0x598773feab36 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /data/llvm/llvm/lib/Support/Unix/Signals.inc:723:22 #1 0x598773feaf57 PrintStackTraceSignalHandler(void*) /data/llvm/llvm/lib/Support/Unix/Signals.inc:798:1 #2 0x598773fe83a7 llvm::sys::RunSignalHandlers() /data/llvm/llvm/lib/Support/Signals.cpp:105:20 #3 0x598773fea3ce SignalHandler(int) /data/llvm/llvm/lib/Support/Unix/Signals.inc:413:1 #4 0x703d15b65520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #5 0x703d15bb99fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #6 0x703d15bb99fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10 #7 0x703d15bb99fc pthread_kill ./nptl/pthread_kill.c:89:10 #8 0x703d15b65476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #9 0x703d15b4b7f3 abort ./stdlib/abort.c:81:7 #10 0x703d15b4b71b _nl_load_domain ./intl/loadmsgcat.c:1177:9 #11 0x703d15b5ce96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #12 0x59877a36646b clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const /data/llvm/clang/lib/AST/ExprClassification.cpp:58:5 #13 0x598778aae760 clang::Expr::Classify(clang::ASTContext&) const /data/llvm/clang/include/clang/AST/Expr.h:407:3 #14 0x598779553d85 clang::Sema::DeduceAutoType(clang::TypeLoc, clang::Expr*, clang::QualType&, clang::sema::TemplateDeductionInfo&, bool, bool, clang::TemplateSpecCandidateSet*) /data/llvm/clang/lib/Sema/SemaTemplateDeduction.cpp:5280:61 #15 0x598779320431 clang::Sema::CheckTemplateAr
[llvm-bugs] [Bug 144944] [flang][OpenMP] OMP ATOMIC restriction too strong?
Issue 144944 Summary [flang][OpenMP] OMP ATOMIC restriction too strong? Labels flang Assignees Reporter eugeneepshteyn Consider the following code: ``` subroutine test(a,b,c) logical :: a,b,c !$OMP ATOMIC ! This fails: a = a .and. b .and. c ! This succeeds: a = a .and. (b .and. c) end subroutine ``` Compiling with flang: ``` $ flang -c -fopenmp atomic-err.f90 flang-21: warning: OpenMP support in flang is still experimental [-Wexperimental-option] error: Semantic errors in atomic-err.f90 ./atomic-err.f90:5:7: error: The atomic variable a cannot be a proper subexpression of an argument (here: a.and.b) in the update operation a = a .and. b .and. c ^ ./atomic-err.f90:5:7: error: The atomic variable a should appear as an argument of the top-level AND operator a = a .and. b .and. c ^ ``` It seems to be a bit arbitrary that `a = a .and. b .and. c` fails, but `a = a .and. (b .and. c)` succeeds. Perhaps it would be possible to process `a = a .and. b .and. c` as if it had parenthesis in the right places? FWIW, gfortran and ifx accept this code. Compiler version: ``` $ flang --version flang version 21.0.0git (https://github.com/llvm/llvm-project 3de01d07c33c10dfefc753c87c0a926fd512425b) Target: x86_64-unknown-linux-gnu Thread model: posix ... ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144931] [lld] Associative COMDAT symbol '.str.4' is not a key for its COMDAT
Issue 144931 Summary [lld] Associative COMDAT symbol '.str.4' is not a key for its COMDAT Labels lld Assignees Reporter thatgato Version: LD 20.1.2 Host OS: Windows 10 Flags: -O0 -fno-omit-frame-pointer -flto -fsanitize=address,undefined -g -Wall -Wextra -static **Note: Removing the -flto flag fixes the crash.** Stacktrace / Error message: https://pastebin.com/BxSLEBpW Link to my project where the crash occured: https://github.com/thatgato/SCLIReimagined/tree/llvm-bug-report I saved the state of the code onto that separate branch, hoping it would help! The code is incomplete. I suspect the crash originates from either the `Logger.cpp` or `Process.cpp` files, as commenting out `main.cpp`'s lines `29 & 30` fixes the crash. Before I added the functionality on those lines, I have never encountered this crash. *I use CLion as my IDE, so some of the CMake configuration might not be directly included in the CMakeLists.* ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144952] False positive Wreturn-type warning when a function either returns or throws
Issue
144952
Summary
False positive Wreturn-type warning when a function either returns or throws
Labels
new issue
Assignees
Reporter
TiborGY
Clang does not appear to be able to deduce that a function that always throws is effectively [[noreturn]], not even in seemingly trivial cases. Consider this:
```
void throwError(const std::string& msg){
throw std::runtime_error(msg);
}
int ensureZero(const int i){
if (i == 0) return 0;
throwError("ERROR");
}
```
Compiling with `-Wall -Wextra -O3 -std=c++2c` yields a false positive warning:
`warning: non-void function does not return a value in all control paths [-Wreturn-type]`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144884] [clang][analyzer] Crash of `unix.UnixAPIMisuseChecker` on a use of a custom-defined `getline`
Issue
144884
Summary
[clang][analyzer] Crash of `unix.UnixAPIMisuseChecker` on a use of a custom-defined `getline`
Labels
clang
Assignees
Reporter
necto
`unix.UnixAPIMisuseChecker` assumes the POSIX signature of `getline` function based on its name and tries to add an assumption about the pointer it takes. This leads to a crash if the target code uses a non-standard `getline` with different parameter types as in the following reduced example:
```C++
class AW_string {};
void getline(int *, AW_string);
void top() {
AW_string line;
int getline_file_info;
getline(&getline_file_info, line);
}
```
See the stack trace [on Compiler Explorer](https://compiler-explorer.com/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:7,positionColumn:1,positionLineNumber:1,selectionStartColumn:2,selectionStartLineNumber:7,startColumn:1,startLineNumber:1),source:'class+AW_string+%7B%7D%3B%0Avoid+getline(int+*,+AW_string)%3B%0Avoid+top()+%7B%0AAW_string+line%3B%0Aint+getline_file_info%3B%0Agetline(%26getline_file_info,+line)%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:50,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((g:!((h:compiler,i:(compiler:clang201assert,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1',verboseDemangling:'0'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'--analyze',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x86-64+clang+20.1.0+(assertions)+(Editor+%231)',t:'0')),header:(),l:'4',m:14.576635940294388,n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'x86-64+clang+20.1.0',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+clang+20.1.0+(assertions)+(Compiler+%231)',t:'0')),header:(),k:50,l:'4',m:85.4233640597056,n:'0',o:'',s:0,t:'0')),k:50,l:'3',n:'0',o:'',t:'0')),l:'2',n:'0',o:'',t:'0')),version:4):
```
'Assume' not implemented for this NonLoc
UNREACHABLE executed at /root/llvm-project/clang/lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp:68!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-20.1.0/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-14.2.0 -fcolor-diagnostics -fno-crash-diagnostics --analyze
1. parser at end of file
2. While analyzing stack:
#0 Calling top()
3. :6:5: Error evaluating statement
4. :6:5: Error evaluating statement
#0 0x03e64af8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-20.1.0/bin/clang+++0x3e64af8)
#1 0x03e627b4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-20.1.0/bin/clang+++0x3e627b4)
#2 0x03daec88 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x71efe5042520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x71efe50969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x71efe5042476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x71efe50287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x03dba5ea (/opt/compiler-explorer/clang-assertions-20.1.0/bin/clang+++0x3dba5ea)
#8 0x067c39ba clang::ento::SimpleConstraintManager::assumeAux(llvm::IntrusiveRefCntPtr, clang::ento::NonLoc, bool) (/opt/compiler-explorer/clang-assertions-20.1.0/bin/clang+++0x67c39ba)
#9 0x067c3d25 clang::ento::SimpleConstraintManager::assume(llvm::IntrusiveRefCntPtr, clang::ento::NonLoc, bool) (/opt/compiler-explorer/clang-assertions-20.1.0/bin/clang+++0x67c3d25)
#10 0x067c3f4a clang::ento::SimpleConstraintManager::assumeInternal(llvm::IntrusiveRefCntPtr, clang::ento::DefinedSVal, bool) (/opt/compiler-explorer/clang-assertions-20.1.0/bin/clang+++0x67c3f4a)
#11 0x066bac88 std::pair, llvm::IntrusiveRefCntPtr> clang::ento::ConstraintManager::assumeDualImpl, clang::ento::DefinedSVal)::'lambda'(bool)>(llvm::IntrusiveRefCntPtr&, clang::ento::ConstraintManager::assumeDual(llvm::IntrusiveRefCntPtr, clang::ento::DefinedSVal)::'lambda'(bool)&) ConstraintManager.cpp:0:0
#12 0x066baf39 clang::ento::ConstraintManager::assumeDual(llvm::IntrusiveRefCntPtr, clang::ento::DefinedSVal) (/opt/compiler-explorer/clang-assertions-20.1.0/bin/clang+++0x66baf39)
#13 0x06612550 (anonymous namespace)::UnixAPIMisu
[llvm-bugs] [Bug 144861] [X86] bcmp with zero not vectorized
Issue
144861
Summary
[X86] bcmp with zero not vectorized
Labels
backend:X86,
missed-optimization
Assignees
Reporter
nikic
A bcmp with an all zero value results in a sequence of ors, while a bcmp with all ones uses vptest.
https://llvm.godbolt.org/z/c15xY8nKv
```llvm
@zeroes = private unnamed_addr constant [64 x i8] zeroinitializer, align 1
@_ones_ = private unnamed_addr constant [64 x i8] c"\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF", align 1
declare i32 @bcmp(ptr, ptr, i64)
define zeroext i1 @test_zeroes(ptr %x) {
%bcmp = tail call i32 @bcmp(ptr %x, ptr @zeroes, i64 64)
%icmp = icmp eq i32 %bcmp, 0
ret i1 %icmp
}
define zeroext i1 @test_ones(ptr %x) {
%bcmp = tail call i32 @bcmp(ptr %x, ptr @ones, i64 64)
%icmp = icmp eq i32 %bcmp, 0
ret i1 %icmp
}
```
```
test_zeroes:# @test_zeroes
mov rax, qword ptr [rdi + 24]
mov rcx, qword ptr [rdi]
mov rdx, qword ptr [rdi + 8]
mov rsi, qword ptr [rdi + 16]
or rsi, qword ptr [rdi + 48]
or rcx, qword ptr [rdi + 32]
or rcx, rsi
or rax, qword ptr [rdi + 56]
or rdx, qword ptr [rdi + 40]
or rdx, rax
or rdx, rcx
seteal
ret
test_ones: # @test_ones
vmovdqu ymm0, ymmword ptr [rdi]
vpand ymm0, ymm0, ymmword ptr [rdi + 32]
vpcmpeqdymm1, ymm1, ymm1
vptest ymm0, ymm1
setbal
vzeroupper
ret
```
The bcmp expansions look like this (https://llvm.godbolt.org/z/Tba34zYod):
```llvm
@zeroes = private unnamed_addr constant [64 x i8] zeroinitializer, align 1
@_ones_ = private unnamed_addr constant [64 x i8] c"\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF\FF", align 1
define zeroext i1 @test_zeroes(ptr %x) {
start:
%0 = load i256, ptr %x, align 1
%1 = getelementptr i8, ptr %x, i64 32
%2 = load i256, ptr %1, align 1
%3 = or i256 %0, %2
%4 = icmp ne i256 %3, 0
%5 = zext i1 %4 to i32
%6 = icmp eq i32 %5, 0
ret i1 %6
}
define zeroext i1 @test_ones(ptr %x) {
start:
%0 = load i256, ptr %x, align 1
%1 = xor i256 %0, -1
%2 = getelementptr i8, ptr %x, i64 32
%3 = load i256, ptr %2, align 1
%4 = xor i256 %3, -1
%5 = or i256 %1, %4
%6 = icmp ne i256 %5, 0
%7 = zext i1 %6 to i32
%8 = icmp eq i32 %7, 0
ret i1 %8
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144858] [LSR][slow compilation] LSR 10000x slower for some X86-64 architectures than others
Issue 144858 Summary [LSR][slow compilation] LSR 1x slower for some X86-64 architectures than others Labels new issue Assignees Reporter jeanPerier When compiling a Fortran test with flang ([source available here](https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0108/0108_0184.f90)), it was noticed that it is more than 1000 times slower to compile when targeting most X86-64 (`icelake-serever`, or `znver2` , `znver3`, `emeraldrapids`, `skylake`), than when targeting `znver4` or `znver5`. The slow compilations are very slow (more than a 100s) and 99.9% of the time is spent in the "Loop Strength Reduction" reduction pass according to `-ftime-report`. It looks like a lot of time is spent in `CompareSCEVComplexity` under `llvm::ScalarEvolution::getAddExpr` called from `LSRInstance::GenerateReassociationsImpl`. Attached are: - [clang_repro.ll.txt](https://github.com/user-attachments/files/20815720/clang_repro.ll.txt) which contains the IR from produced by flang and one can see the compilation time difference of it with `clang -O3 -march=znver4` vs `clang -O3 -march=icelake-serever`. - [lsr_repro.ll.txt](https://github.com/user-attachments/files/20815717/lsr_repro.ll.txt) that is the IR taken from a slow compilation right before LSR. One can reproduce the slow LSR step with it with `opt -loop-reduce`. Note that `lsr_repro.ll` does not contain CPU specific attributes, so it seems the architecture does not impact LSR speed directly, but rather the IR that reaches it due to previous optimization and LSR chokes on it while it looks reasonable (a bit more than 1000 IR ops). There is likely a quadratic behavior somewhere here. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144891] [lldb] TestDetachResumes.py is flaky on Windows x86_64
Issue 144891 Summary [lldb] TestDetachResumes.py is flaky on Windows x86_64 Labels lldb, test-suite, platform:windows Assignees Reporter slydiman https://lab.llvm.org/staging/#/builders/211/builds/419 https://lab.llvm.org/staging/#/builders/211/builds/423 Around 25% of test runs fail with the assert in the last line `lldbutil.wait_for_file_on_target(self, exit_file_path)` ``` AssertionError: File C:\buildbot\as-builder-10\lldb-x86-64\build\lldb-test-build.noindex\commands\process\detach-resumes\TestDetachResumes.test_detach_resumes\exit_file_1750332982 not found even after 6 attempts. ``` Note the file `exit_file_*` is really missing after this test. This issue is easily reproducible locally running ``` C:/Python312/python.exe D:/llvm-project/lldb\test\API\dotest.py ^ -v -t ^ -u CXXFLAGS -u CFLAGS ^ --env OBJCOPY=D:/build-x64/bin/llvm-objcopy.exe ^ --env STRIP=D:/build-x64/bin/llvm-strip.exe ^ --env LLVM_LIBS_DIR=D:/build-x64/lib ^ --env LLVM_INCLUDE_DIR=D:/build-x64/include ^ --env LLVM_TOOLS_DIR=D:/build-x64/./bin ^ --env ARCHIVER=D:/build-x64/bin/llvm-ar.exe ^ --arch x86_64 ^ --build-dir D:/build-x64/lldb-test-build.noindex ^ --lldb-module-cache-dir D:/build-x64/lldb-test-build.noindex/module-cache-lldb\lldb-api ^ --clang-module-cache-dir D:/build-x64/lldb-test-build.noindex/module-cache-clang\lldb-api ^ --executable D:/build-x64/bin/lldb.exe ^ --make C:/ProgramData/chocolatey/bin/make.exe ^ --compiler D:/build-x64/bin/clang.exe ^ --dsymutil D:/build-x64/bin/dsymutil.exe ^ --llvm-tools-dir D:/build-x64/bin ^ --lldb-obj-root D:/build-x64/tools/lldb ^ --lldb-libs-dir D:/build-x64/lib ^ --cmake-build-type Release ^ D:\llvm-project\lldb\test\API\commands\process\detach-resumes -p TestDetachResumes.py ``` It seems something is really wrong with the detaching on Windows x86_64 in case of multithreading. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144856] Incorrect source range for explicit object calls when callee is pointer
Issue
144856
Summary
Incorrect source range for explicit object calls when callee is pointer
Labels
new issue
Assignees
Reporter
necto
In Clang v20.1.7, the issue range for explicit object calls has been improved for `.` calls, but not for the `->` calls. As you can observe on [Compiler Explorer](https://godbolt.org/#z:OYLghAFBqd5TKALEBjA9gEwKYFFMCWALugE4A0BIEAZgQDbYB2AhgLbYgDkAjF%2BTXRMiAZVQtGIHgBYBQogFUAztgAKAD24AGfgCsp5eiyahUAUgBMAIUtXyKxqiIEh1ZpgDC6egFc2TA3cAGQImbAA5PwAjbFIpLXIAB3QlYhcmL19/A2TU5yEQsMi2GLieBIdsJ3SRIhZSIky/AJ57bEd8plr6okKI6NiDJTqGpuzW4Z6%2B4tKpAEp7dB9SVE4uYdIfJwBqXHVE%2BgJUYgAVJAIlbbMAdhstAEFt7YA3dAJMbY4S2Igic8u9gcjqd/tsMExhpYAGzbBw0OZmADMd3uNwAIkiUWYHq93tsiNhhjwIIDDsciGcLgAqbaJIgUXb7Mkgi7Q7akbA0ciMoHkymXZ4SOZXW7Yx60%2BkAWiRuC%2BpQgCOR2wA9MrtlZsMBQtsyNsPBJ6IDSOzjMBsNsLtt6CkiAA6MVPDk0W1yn6KqwqtUASTYiVI6Ge2A%2BpFN2AdLwkLuw31ICsxnu2Pr9AaDJpMYYe6LFXAW9G4AFZ%2BAEuDpyOhuB5bLZYUsVubLIi%2BOQiNocwsANbxBJ5rjSfhsEAWKG2ngATgs5VH0gAHOUodP8zxruRi6Xy1x%2BEoQAkWyWc%2BQ4LAUBhfQxYpRqCfEme4qgjCYx%2BUBAwCaQtxAoq3yFFQvUAJ7cE2P6sKQf4APJRLoVS7k2J4cMIYFMPQAF7uQOBRD4wD6vQ9Bbrw/A4GwpqSKhhActUgZ4aW2DqFUPgEoB/ChASPalocUQhqBXg4F%2B9IEAO%2BHkIGpBRCk2BotGxGhKAe4LDQRjAEoABqBDYAA7mBiTMIxcjCGIEicE%2BgjCMoaiaKh%2BitPephVtYhgEFEW6QAs6B0ukeGSsMmBImi5jWLYFiIvwKakKQ7yEvACyVNUrgQO4YwtOQwShP0MY5CkaRCAl6V5Ok0wDGUbQdDUIyNN4zRDO00ElVMKUzIMEyldljW1UUBXzIsyyrB1PaFiuX7rts6jTlCkpQtIYLWdsY4jraWjbCShAkMaDY8HM/C7joCwQCgLDDBeEBXje4TsGsw2jeNk2mtNo6zdRS1kO8BjGaI4iSEZ8imRoX6WUV1WxfF5XjElTCYPlaWtLkmUZEDiVQ504OzBMVUxV0TWw5VxVCN0DSIw19jo1kiWTLjdXtWtzYctgT1aLmBZFgN3D3MM2wqepsRDSNY0TXe10zTwc0LfgxC6qt3JeKejArYFa0ba2cwdl2hjcH25ADhY0hzdIUKNhrPCLtIi6jvm/Woeum7bs28sHogO1oOgkvnlQh0O9eUtoNZFhaEZL6xO%2Bn6ocB/46UHoEQVBTg6XBzBEIhyFfuhmHYbhOmEcRaylmR1WUV%2BNF0QxgnMe0X7sZxf7cRnG1hQJTbCaJKgSURJiHCY1vySwilsxpWnFk2L36e9CQvV95mlvoFiGKaaC2XY7FOQqZZuUIHleT5fk2NYgXBcJYU4PPUUo50big81INg2TENJBlnSn/DeUX0jf2ozjZVE5j/1o61qWPyTr8VS1pM2oQyirWbqFNeoMzNtwTmF0eZTS9ndIWD1paNnWlbWSB5dr7WdkdKWJ0ODcHOtzK6JhtgIIFvdEWu9nryAHoZIen0VDfQsoOJ%2BR84onwxq0ZKQDH53yylwq%2BuUCgP3xtFToL9T7iJqoA7%2BYjCb/wJl/eqZQFj0mwNTTA246ZcD6quYKTMWZdw5kQy6vNSHkMFotKhVwZbi1djeWxiILBoM2m2ZWvZ%2ByDk1tcKE%2Btrizi0IiAJOstBQlNmubgFsdzW0PMge2jsKA4Ice7cxwAAD69IfBMHbM%2Begr5/ZflDihICv4w6QWglHB28FY5IRQpnbAGEsIGjwk2NOzdK5oQIORZwOdUJ51QPRNYTYi6sX4KXf8FdeLVx0nXMSjcpKtwwe3Tuqlu7aUEv3N69DdKKCYaPPQIBEST1buvWw9lHKRUXp0FeRBvKIl8jPLeZYd7hX3mw9Ix9PCCJ4XIwq/CYZv0htfe%2BvCxGHxkX/YG0jsalTxoVX%2BUi4WiNUZ1OsPV6YRIMVwGBxC0kLSyTk4U1jlpONlugramCQB7SIAdXBsR8FnS5mYqavxNhEv4EGKhT1WhbIMvEXZI8fpHI%2BQDThQKz7wpytDW%2BIKRFgoRRC2FPQpFKs/rIlRQwFHQuRQqjq6jNHaI8XoxmXBmZEFZmskxzK4HXTZdk9sxLhakrFnqFJHMGyIlcfLHRqt1Ym30WWKJ9hLZuIVuQTshtbTSACdOa4jZpDe3GoiWQPYgpYqDRuCl%2B44m5pQIQGgXJnZ8sHoK/ZJckBbispWgtNAiB/i0iAachhK00XpCwVyR8s2kErawntSha31sbc2/tbaQyds%2BRuHRJqoFcDRAQQtlr2bGlMba0h/NBaeTuWvWwto90vEuKukhwAyFaEQVu%2B5jzrB7ttHLWSCwkDYBYDgOIC9Oz5k1vmCcPAhwLlHNORE%2BYoThJ7H6kA%2BYEiBvNiGmJGC80gFrQdEtOzh7ltQvQXtE8MMDoXXWhtnBm3YbHR2pexZ%2BD9pFf2wd%2BGm3kFHeodtE7XBTuNZAyJc7cNLrUta2Bx7T3ntXg89eN6D24pZXawljrtgXrXjeu9W0H1PpfdQX1XiIMZug1uWDCmI3gc/d%2B39%2BZ/2AeAx49NUHg1hp0RYNj2L5PuOEqkVw0ggA%3D%3D), the object is included in the range for the `.` calls, but for the `->` call:
```C++
struct ExplicitThis {
void member(this ExplicitThis const& self);
};
void test1(ExplicitThis* ptr, ExplicitThis& ref, ExplicitThis val) {
ptr->member(); // Begin or CallExpr range is lost.
ref.member(); // Improved range
val.member(); // Improved range
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144857] [llvm] LLVM backend crashes when using `__builtin_ia32_prefetchi`
Issue
144857
Summary
[llvm] LLVM backend crashes when using `__builtin_ia32_prefetchi`
Labels
new issue
Assignees
Reporter
MacroModel
see: https://godbolt.org/z/aPPfjjbs3
```cpp
void x86_perfchi(void* p) noexcept
{
__builtin_ia32_prefetchi(p, 0);
}
```
```
fatal error: error in backend: Cannot select: 0x1e933290: ch = Prefetch<(load (s8) from %ir.0)> 0x1e849900, 0x1e9331b0, TargetConstant:i32<0>, TargetConstant:i32<0>, TargetConstant:i32<0>, example.cpp:3:5
0x1e9331b0: i64,ch = CopyFromReg 0x1e849900, Register:i64 %0
In function: _Z11x86_perfchiPv
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++26 -O1 -march=znver5
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module ''.
4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z11x86_perfchiPv'
#0 0x03c27a08 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3c27a08)
#1 0x03c25b4c llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3c25b4c)
#2 0x03b766b3 llvm::CrashRecoveryContext::HandleExit(int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3b766b3)
#3 0x03c1d61e llvm::sys::Process::Exit(int, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3c1d61e)
#4 0x00d9c80b LLVMErrorHandler(void*, char const*, bool) cc1_main.cpp:0:0
#5 0x03b80573 llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3b80573)
#6 0x051e9e2a llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x51e9e2a)
#7 0x051efcf9 llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x51efcf9)
#8 0x026fb3fa (anonymous namespace)::X86DAGToDAGISel::Select(llvm::SDNode*) X86ISelDAGToDAG.cpp:0:0
#9 0x051e73e4 llvm::SelectionDAGISel::DoInstructionSelection() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x51e73e4)
#10 0x051f58d2 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x51f58d2)
#11 0x051f8235 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x51f8235)
#12 0x051fa0e6 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x51fa0e6)
#13 0x051e6f71 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x51e6f71)
#14 0x0300f2d8 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#15 0x03584aa2 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3584aa2)
#16 0x03584d31 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3584d31)
#17 0x03586679 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3586679)
#18 0x03ed69d0 clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3ed69d0)
#19 0x04572f3c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4572f3c)
#20 0x061d13ec clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x61d13ec)
#21 0x04573b0d clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4573b0d)
#22 0x0488570a clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x488570a)
#23 0x0480134b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x480134b)
#24 0x0497a193 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x497a193)
#25 0x00d9e785 cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0xd9e785)
#26 0x00d9674d
[llvm-bugs] [Bug 144854] [libc++] std::abs should diagnose `unsigned char` and `unsigned short` uses
Issue 144854 Summary [libc++] std::abs should diagnose `unsigned char` and `unsigned short` uses Labels enhancement Assignees philnik777 Reporter philnik777 Clang sometimes doesn't diagnose these with our current implementation. We should be able to add `__attribute__((diagnose_if))`s to re-gain the diagnostics. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 144866] Crash in llvm::cast when using compound literal with designated initializer in macro. It has arised again in version 21 (in 20 it doesnt in 17 yes))
Issue
144866
Summary
Crash in llvm::cast when using compound literal with designated initializer in macro. It has arised again in version 21 (in 20 it doesnt in 17 yes))
Labels
new issue
Assignees
Reporter
mariete1223
It is curious because in clang 17 it fails, it seems that it was solved for versions 18-20 and reappeared in version 21(trunk).
## Assertion
```
clang: /root/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = clang::ConstantArrayType; From = const clang::ArrayType]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
```
## Stack dump
```
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -O0 -std=c2x
1. :8:14: current parser token ')'
2. :6:12: parsing function body 'main'
3. :6:12: in compound statement ('{}')
#0 0x03f6df68 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3f6df68)
#1 0x03f6bbf4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3f6bbf4)
#2 0x03eb0708 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x753cc5842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x753cc58969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x753cc5842476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x753cc58287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x753cc582871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x753cc5839e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x06c8bf6f decltype(auto) llvm::cast(clang::ArrayType const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6c8bf6f)
#10 0x06cb3abb (anonymous namespace)::InitListChecker::CheckDesignatedInitializer(clang::InitializedEntity const&, clang::InitListExpr*, clang::DesignatedInitExpr*, unsigned int, clang::QualType&, clang::DeclContext::specific_decl_iterator*, llvm::APSInt*, unsigned int&, clang::InitListExpr*, unsigned int&, bool, bool) SemaInit.cpp:0:0
#11 0x06cb1eaa (anonymous namespace)::InitListChecker::CheckArrayType(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, llvm::APSInt, bool, unsigned int&, clang::InitListExpr*, unsigned int&) SemaInit.cpp:0:0
#12 0x06caf909 (anonymous namespace)::InitListChecker::CheckListElementTypes(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, unsigned int&, clang::InitListExpr*, unsigned int&, bool) (.constprop.0) SemaInit.cpp:0:0
#13 0x06c9e95a (anonymous namespace)::InitListChecker::CheckExplicitInitList(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, clang::InitListExpr*, bool) (.constprop.0) SemaInit.cpp:0:0
#14 0x06c9f367 (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, bool, bool, llvm::SmallVectorImpl*) SemaInit.cpp:0:0
#15 0x06ca8dfb clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6ca8dfb)
#16 0x06b115a2 clang::Sema::BuildCompoundLiteralExpr(clang::SourceLocation, clang::TypeSourceInfo*, clang::SourceLocation, clang::Expr*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6b115a2)
#17 0x06b11ee8 clang::Sema::ActOnCompoundLiteral(clang::SourceLocation, clang::OpaquePtr, clang::SourceLocation, clang::Expr*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6b11ee8)
#18 0x06691ca2 clang::Parser::ParseCompoundLiteralExpression(clang::OpaquePtr, clang::SourceLocation, clang::SourceLocation) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6691ca2)
#19 0x06699e0d clang::Parser::ParseParenExpression(clang::ParenParseOption&, bool, bool, clang::OpaquePtr&, clang::SourceLocation&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6699e0d)
#20 0x0668fa6c clang::Parser::ParseCastExpression(clang::CastParseKind, bool, bool&, clang::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x668fa6c)
#21 0x06690d47 clang::Parser::ParseCastExpression(clang::CastParseKind, bool, clang::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6690d47)
#22 0x06690dd9 clang::Parser::ParseAssignmentExpression(clang::TypeCastState) (/opt/c
[llvm-bugs] [Bug 144869] SystemZ `esrl` instruction doesn't disassemble `%r0`
Issue
144869
Summary
SystemZ `esrl` instruction doesn't disassemble `%r0`
Labels
new issue
Assignees
Reporter
Rot127
The SystemZ disassembler doesn't decode `%r0` registers if they are part of an address.
```
echo "0xc6,0x00,0x00,0x00,0x00,0x05" | llvm-mc --disassemble --triple=s390x --show-encoding
.text
exrl 0, 0xa # encoding: [0xc6,0x00,A,A,A,A]
# fixup A - offset: 2, value: 12, kind: FK_390_PC32D
```
It should be `exrl %r0, 0xa`.
It does work the other way around though:
```
echo "exrl %r0, 0xa" | llvm-mc --assemble --triple=s390x --show-encoding
.text
.Ltmp0:
exrl %r0, .Ltmp0+10 # encoding: [0xc6,0x00,A,A,A,A]
# fixup A - offset: 2, value: (.Ltmp0+10)+2, kind: FK_390_PC32DBL
```
This might due to https://github.com/llvm/llvm-project/issues/44437.
Debugging shows that it happens due to these lines:
https://github.com/llvm/llvm-project/blob/1c35fe4e6b2596d153da82b23d04a3779fb12730/llvm/lib/Target/SystemZ/Disassembler/SystemZDisassembler.cpp#L87-L89
The given register table in `Regs` contains a the valid register id of `r0`, but here it ignores it.
It possibly was supposed to be?
```diff
{
assert(RegNo < Size && "Invalid register");
- if (IsAddr && RegNo == 0) {
+ if (IsAddr && Regs[RegNo] == 0) {
RegNo = SystemZ::NoRegister;
} else {
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
