[llvm-bugs] [Bug 123700] Should operands in ternary operator be allowed to have explicit copy constructor?
Issue
123700
Summary
Should operands in ternary operator be allowed to have explicit copy constructor?
Labels
new issue
Assignees
Reporter
Rush10233
I've got a very confusing output with the following test:
```c++
struct QString
{
QString()=default;
explicit QString( const QString & );
};
QString def(){
return QString{};
};
void foo( bool b, QString s )
{
auto res = b ? def() : s;
}
```
It turns out that GCC accepts this with `-std=c++17` or above; EDG and ICC always accept, and clang and MSVC always reject even with `-std=c++17` or above: https://godbolt.org/z/zhza8Krfa
The diagnostic of clang and MSVC points out that if `s` is taken, the conversion from `s` to `res` will implicitly use the copy ctor of `QString`, which is not allowed:
```c++
:13:29: error: no matching constructor for initialization of 'QString'
13 | auto res = b ? def() : s;
| ^
:4:14: note: explicit constructor is not a candidate
4 | explicit QString( const QString & );
| ^
:3:5: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
3 | QString()=default;
| ^
1 error generated.
```
Although the diagnostic sounds reasonable here, I still wonder if the standard has been made some changes since C++17 according to the behavior of GCC.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123681] clang frontend command failed with exit code 139
Issue 123681 Summary clang frontend command failed with exit code 139 Labels clang Assignees Reporter bb33bb 01-Version clang version 18.0.0 02- when compiling lineagOS the error shows like the following ``` #46 0x7cf26fed3e08 (/usr/lib/libc.so.6+0x25e08) #47 0x7cf26fed3ecc __libc_start_main (/usr/lib/libc.so.6+0x25ecc) #48 0x561e5d09e2a9 (prebuilts/clang/host/linux-x86/clang-r510928/bin/clang++.real+0x669e2a9) clang++: error: clang frontend command failed with exit code 139 (use -v to see invocation) Android (11368308, +pgo, +bolt, +lto, +mlgo, based on r510928) clang version 18.0.0 (https://android.googlesource.com/toolchain/llvm-project 477610d4d0d98 8e69dbc3fae4fe86bff3f07f2b5) Target: aarch64-unknown-linux-android31 Thread model: posix InstalledDir: prebuilts/clang/host/linux-x86/clang-r510928/bin clang++: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++: note: diagnostic msg: /mnt/4t/android/LineageOS/lineageOS21/out/soong/.temp/jni_env_ext-af4f0d.cpp clang++: note: diagnostic msg: /mnt/4t/android/LineageOS/lineageOS21/out/soong/.temp/jni_env_ext-af4f0d.sh clang++: note: diagnostic msg: 12:53:27 Got signal: interrupt 12:53:27 ninja failed with: exit status 130 There was 1 action that completed after the action that failed. See verbose.log.gz for its output. ``` 03-previous issue https://github.com/llvm/llvm-project/issues/62518 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123689] rtsan/rtsan_interceptors_posix.cpp?l=930:18: error: conflicting types for 'recvmmsg'
Issue 123689 Summary rtsan/rtsan_interceptors_posix.cpp?l=930:18: error: conflicting types for 'recvmmsg' Labels Assignees Reporter appujee Top of the trunk failed with compiler error: ``` FAILED: compiler-rt/lib/rtsan/CMakeFiles/RTRtsan.x86_64.dir/rtsan_interceptors_posix.cpp.o /tmpfs/src/git/out/stage1/./bin/clang++ --target=x86_64-unknown-linux-gnu --sysroot=/tmpfs/src/git/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.17-4.8/sysroot -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/tmpfs/src/git/out/llvm-project/compiler-rt/lib/rtsan/.. -ffile-prefix-map=/tmpfs/src/git/= -B/tmpfs/src/git/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.17-4.8/x86_64-linux/bin -D_LIBCPP_AVAILABILITY_HAS_NO_VERBOSE_ABORT=1 -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -O3 -DNDEBUG -fPIC -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -stdlib=libc++ -DSANITIZER_COMMON_NO_REDEFINE_BUILTINS -fno-rtti -std=c++17 -MD -MT compiler-rt/lib/rtsan/CMakeFiles/RTRtsan.x86_64.dir/rtsan_interceptors_posix.cpp.o -MF compiler-rt/lib/rtsan/CMakeFiles/RTRtsan.x86_64.dir/rtsan_interceptors_posix.cpp.o.d -o compiler-rt/lib/rtsan/CMakeFiles/RTRtsan.x86_64.dir/rtsan_interceptors_posix.cpp.o -c /tmpfs/src/git/out/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp /[tmpfs/src/git/out/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp:930](https://cs.corp.google.com/piper///depot/google3/tmpfs/src/git/out/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp?l=930):18: error: conflicting types for 'recvmmsg' 930 | INTERCEPTOR(int, recvmmsg, int socket, struct mmsghdr *message, | ^ /[tmpfs/src/git/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.17-4.8/sysroot/usr/include/x86_64-linux-gnu/sys/socket.h:211](https://cs.corp.google.com/piper///depot/google3/tmpfs/src/git/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.17-4.8/sysroot/usr/include/x86_64-linux-gnu/sys/socket.h?l=211):12: note: previous declaration is here 211 | extern int recvmmsg (int __fd, struct mmsghdr *__vmessages, |^ 1 error generated. ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123591] Clang frontend command failed with exit code 139
Issue
123591
Summary
Clang frontend command failed with exit code 139
Labels
clang
Assignees
Reporter
dvora124-wq
Hi,
I've been experimenting with ways to model an AST in modern C++. During one of these experiments, my compiler crashed on me. Per request of the compiler itself, I've attached the output and the associated culprit files below.
The issue seems to arise from a leftover `template ` declaration:
```
template // <<< right here, sorry!
using AstNode = std::variant;
```
I accidentally left it in place when I was restructuring the program. Once I remove the declaration, the program still doesn't compile (that's correct), but the compiler doesn't crash anymore.
---
[main-8471ef.tar.gz](https://github.com/user-attachments/files/18476429/main-8471ef.tar.gz)
```
Stack dump:
0. Program arguments: clang++ -std=c++20 -Wall -Wextra -Wconversion -Wpedantic -funsigned-char -fsanitize=address,undefined -fno-omit-frame-pointer -g3 -glldb -O0 -c -o target/main.o src/main.cc
1. src/main.cc:69:112: current parser token ';'
2. src/main.cc:68:1: parsing function body 'main'
3. src/main.cc:68:1: in compound statement ('{}')
#0 0x7fd90b8b0a8a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xeb0a8a)
#1 0x7fd90b8ae634 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xeae634)
#2 0x7fd90b7f44f4 (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xdf44f4)
#3 0x7fd90a449da0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fda0)
#4 0x7fd913a850e4 clang::TemplateArgument::isPackExpansion() const (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x12850e4)
#5 0x7fd914631acb clang::Sema::getFullyPackExpandedSize(clang::TemplateArgument) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1e31acb)
#6 0x7fd9145bf020 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1dbf020)
#7 0x7fd9145c8bcb (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1dc8bcb)
#8 0x7fd91459a425 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1d9a425)
#9 0x7fd9145d2ab0 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1dd2ab0)
#10 0x7fd9145d9867 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1dd9867)
#11 0x7fd9145d6d6d (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1dd6d6d)
#12 0x7fd91459348b (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1d9348b)
#13 0x7fd91459a3a7 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1d9a3a7)
#14 0x7fd91459a232 clang::Sema::SubstTemplateArgument(clang::TemplateArgumentLoc const&, clang::MultiLevelTemplateArgumentList const&, clang::TemplateArgumentLoc&, clang::SourceLocation, clang::DeclarationName const&) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1d9a232)
#15 0x7fd91445daab (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1c5daab)
#16 0x7fd91445d57e clang::Sema::SubstDefaultTemplateArgumentIfAvailable(clang::TemplateDecl*, clang::SourceLocation, clang::SourceLocation, clang::Decl*, llvm::ArrayRef, llvm::ArrayRef, bool&) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1c5d57e)
#17 0x7fd9144e3c61 clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*, bool, llvm::function_ref) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1ce3c61)
#18 0x7fd91454001b (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1d4001b)
#19 0x7fd913d93671 clang::Sema::runWithSufficientStackSpace(clang::SourceLocation, llvm::function_ref) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1593671)
#20 0x7fd9144e5c1b clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool, bool, clang::QualType, clang::Expr::Classification, llvm::function_ref)>) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1ce5c1b)
#21 0x7fd9143cb434 clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::OverloadCandidateSet&, bool, bool, bool, clang::CallExpr::ADLCallKind, clang::OverloadCandidateParamOrder, bool) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1bcb434)
#22 0x7fd9142a0847 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1aa0847)
#23 0x7fd914293c39 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1a93c39)
#24 0x7fd9142930d9 clang::Sema::DeduceTemplateSpecializationFromInitializer(clang::TypeSourceInfo*, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1a930d9)
#2
[llvm-bugs] [Bug 123605] Add missing F32->I64 vec_signede, F32->I64 vec_signedo, F32->U64 vec_unsignede, and F32->U64 vec_unsignedo to altivec.h header
Issue 123605 Summary Add missing F32->I64 vec_signede, F32->I64 vec_signedo, F32->U64 vec_unsignede, and F32->U64 vec_unsignedo to altivec.h header Labels new issue Assignees Reporter johnplatts GCC 15 has removed the __builtin_vsx_xvcvspsxds builtin and replaced the __builtin_vsx_xvcvspsxds builtin with F32->I64 vec_signede/vec_signedo intrinsics. GCC 15 has also removed the __builtin_vsx_xvcvspuxds builtin and replaced the __builtin_vsx_xvcvspuxds builtin with F32->U64 vec_unsignede/vec_unsignedo intrinsics. Clang already has the F64->I32 vec_signede/vec_signedo and F64->U32 vec_unsignede/vec_unsignedo intrinsics, but not the F32->I64 vec_signede/vec_signedo or the F32->U64 vec_unsignede/vec_unsignedo intrinsics. The following functions need to be added to clang/lib/Headers/altivec.h: - ```vector signed long long vec_signede(vector float a)```: equivalent to __builtin_vsx_xvcvspsxds on big-endian VSX and equivalent to `__builtin_vsx_xvcvspsxds(vec_sld(a, a, 4))` on little-endian VSX - ```vector signed long long vec_signedo(vector float a)```: equivalent to __builtin_vsx_xvcvspsxds on little-endian VSX and equivalent to `__builtin_vsx_xvcvspsxds(vec_sld(a, a, 4))` on big-endian VSX - ```vector unsigned long long vec_unsignede(vector float a)```: equivalent to __builtin_vsx_xvcvspuxds on big-endian VSX and equivalent to `__builtin_vsx_xvcvspuxds(vec_sld(a, a, 4))` on little-endian VSX - ```vector unsigned long long vec_unsignedo(vector float a)```: equivalent to __builtin_vsx_xvcvspuxds on little-endian VSX and equivalent to `__builtin_vsx_xvcvspuxds(vec_sld(a, a, 4))` on big-endian VSX ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123579] macOS prebuilt binaries cannot use prebuilt `libc++.1.dylib`
Issue 123579 Summary macOS prebuilt binaries cannot use prebuilt `libc++.1.dylib` Labels libc++ Assignees Reporter WittonBell macOS prebuilt binaries cannot use prebuilt `libc++.1.dylib`. use `otool -L ./clang` to see the report: ``` ./clang: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.157.0) ``` it need depend `@rpath/libc++.1.dylib`. the other prebuilt binaries, such as `dylib`, `executable file`, etc has a same issue. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123586] Request Commit Access For gbNagyM
Issue 123586 Summary Request Commit Access For gbNagyM Labels infra:commit-access-request Assignees Reporter gbMattN ### Why Are you requesting commit access ? I have been working on compiler-rt, especially the new Type Sanitizer for a few months now. I have several merged and several in-progress pull requests, and I'm hoping to do some more! Currently I have to @ users if I want to ask them for review, and I have to ask other users to merge my approved pull requests for me, which isn't ideal!😅 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123582] Doxygen grouping commands not visible in AST
Issue
123582
Summary
Doxygen grouping commands not visible in AST
Labels
new issue
Assignees
Reporter
tcottin
[Doxygen grouping](https://www.doxygen.nl/manual/grouping.html) seems not to be available in the AST.
Taking one of the examples from the Doxygen grouping docs:
```c
/**
* \defgroup IntVariables Global integer variables
* @{
*/
/** an integer variable */
extern int IntegerVariable;
/**@}*/
```
Dump AST:
```bash
> clang.exe -Xclang -ast-dump -fsyntax-only test.c
TranslationUnitDecl 0x2428362dd28 <>
|-TypedefDecl 0x2428362e558 <> implicit __int128_t '__int128'
| `-BuiltinType 0x2428362e2f0 '__int128'
|-TypedefDecl 0x2428362e5c8 <> implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x2428362e310 'unsigned __int128'
|-TypedefDecl 0x2428362e8d0 <> implicit __NSConstantString 'struct __NSConstantString_tag'
| `-RecordType 0x2428362e6a0 'struct __NSConstantString_tag'
| `-Record 0x2428362e620 '__NSConstantString_tag'
|-TypedefDecl 0x2428362e978 <> implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x2428362e930 'char *'
| `-BuiltinType 0x2428362ddd0 'char'
|-TypedefDecl 0x2428362e9e8 <> implicit __builtin_va_list 'char *'
| `-PointerType 0x2428362e930 'char *'
| `-BuiltinType 0x2428362ddd0 'char'
`-VarDecl 0x2428362eab8 \test.c:7:1, col:12> col:12 IntegerVariable 'int' extern
`-FullComment 0x2428362ec40
`-ParagraphComment 0x2428362ec10
`-TextComment 0x2428362ebe0 Text=" an integer variable "
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123569] Remove PointerType::get/getUnqual with element type argument
Issue 123569 Summary Remove PointerType::get/getUnqual with element type argument Labels new issue Assignees Reporter nikic These two methods should be removed now that the opaque pointers migration is complete: https://github.com/llvm/llvm-project/blob/6f0a627dd3c21209ea45f355ecedd15d739418a1/llvm/include/llvm/IR/DerivedTypes.h#L677-L679 https://github.com/llvm/llvm-project/blob/6f0a627dd3c21209ea45f355ecedd15d739418a1/llvm/include/llvm/IR/DerivedTypes.h#L684-L688 Steps: * [ ] Remove all the callers, by switching to the methods accepting LLVMContext (or other more appropriate helpers) instead. * [ ] Deprecate the methods. * [ ] Remove the methods. cc @JOE1994 as you handled the migration away from Type::getPointerTo(). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123565] [ARM] Why mlong-calls codegen is not position independent?
Issue
123565
Summary
[ARM] Why mlong-calls codegen is not position independent?
Labels
question,
backend:ARM
Assignees
Reporter
hstk30-hw
https://godbolt.org/z/eeEzd3Gre
```
const char * remote_n1 (void);
const char * call_remote_n1 (void) { return remote_n1 () + 1; }
```
with command : `-O1 -fPIC -mlong-calls` will generate `R_ARM_ABS32` relocation type for `remote_n1` ,
this lead to link error when create shared object :
```
relocation R_ARM_ABS32 cannot be used against symbol 'remote_n1'; recompile with -fPIC
```
Source code do the assert check in DEBUG edition, but not warning in RELEASE edition
https://github.com/llvm/llvm-project/blob/6972788bf3d330b7a6136e2ddd840782882b8dd0/llvm/lib/Target/ARM/ARMISelLowering.cpp#L2823-L2828
Besides, GCC work fine.
Have SPEC about this rule?
rel MR: https://github.com/llvm/llvm-project/commit/32bb362655c14d75124bb4d38c176145105c68c8
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123567] Rare ld.lld failures
Issue
123567
Summary
Rare ld.lld failures
Labels
lld:ELF
Assignees
Reporter
chestnykh
In a few runs ld.lld fails with SIGBUS with the following bt in coredump:
```
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:345
() 0x55836ad02906 in void lld::elf::InputSection::writeTo >(unsigned char*) ()
() 0x55836ad26bcd in std::_Function_handler >(unsigned char*, llvm::parallel::TaskGroup&)::{lambda()#3}>::_M_invoke(std::_Any_data const&) ()
() 0x7f14a5934ca4 in std::_Function_handler, bool)::{lambda()#1}>::_M_invoke(std::_Any_data const&) ()
so 0x7f14a5934ac9 in std::thread::_State_impl > >::_M_run() ()
.6 0x7f14a5015b2f in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
86 0x7f14aa417fa3 in start_thread (arg=) at pthread_create.c:486
95 0x7f14a4cf406f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
Unfortunately i don't have reproducers :(
@MaskRay any ideas?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123637] Bad error trace for issue with unique_ptr
Issue
123637
Summary
Bad error trace for issue with unique_ptr
Labels
new issue
Assignees
Reporter
JVApen
The following is reduced from a build with clang-cl and the MS stl implementation:
#include
#include
#include
template
struct ms_default_delete { // default deleter for unique_ptr
constexpr ms_default_delete() noexcept = default;
template , int> = 0>
ms_default_delete(const ms_default_delete<_Ty2>&) noexcept {}
void operator()(_Ty* _Ptr) const noexcept /* strengthened */ { // delete a pointer
static_assert(0 < sizeof(_Ty), "can't delete an incomplete type");
delete _Ptr;
}
};
struct FWD;
struct S
{
~S() = default;
std::vector>> member;
};
int main(int, char**){
S s;
}
https://compiler-explorer.com/z/6K8ebK3E1
This gives the error:
:13:27: error: invalid application of 'sizeof' to an incomplete type 'FWD'
13 | static_assert(0 < sizeof(_Ty), "can't delete an incomplete type");
| ^~~
/opt/compiler-explorer/clang-trunk-20250120/bin/../include/c++/v1/__memory/unique_ptr.h:300:7: note: in instantiation of member function 'ms_default_delete::operator()' requested here
300 | __deleter_(__tmp);
| ^
/opt/compiler-explorer/clang-trunk-20250120/bin/../include/c++/v1/__memory/unique_ptr.h:269:71: note: in instantiation of member function 'std::unique_ptr>::reset' requested here
269 | _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
| ^
/opt/compiler-explorer/clang-trunk-20250120/bin/../include/c++/v1/__memory/construct_at.h:66:11: note: in instantiation of member function 'std::unique_ptr>::~unique_ptr' requested here
66 | __loc->~_Tp();
| ^
:17:8: note: forward declaration of 'FWD'
17 | struct FWD;
|^
1 error generated.
In this trace, this mentions the location of the `static_assert`, it mentions the location of the forward declare.
Though what is missing in this trace is the location that started the initialization. (The inline destructor of struct `S`)
This last is especially useful if you have the output of multiple compilations together without explicit mention of the file that was compiled.
(Like a multi-process build via CMake, a CI system that runs clang-tidy on multiple files and puts all results together ...)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123649] Poor performance for Romberg's method
Issue
123649
Summary
Poor performance for Romberg's method
Labels
new issue
Assignees
Reporter
thesamesam
This is a companion bug of a GCC bug I've just filed (https://gcc.gnu.org/PR118570).
This was reported on IRC by `trn` who observed that with GCC, this testcase completes much quicker at -O2 than at -O3. For Clang, it always has the bad-case performance that we currently see with GCC -O3.
```c
#include
#include
#define MAX_STEPS 10
#define I_OP sin
static double
romberg(a, b, acc)
double a;
double b;
double acc;
{
long i, j, k, ep;
double R1[MAX_STEPS], R2[MAX_STEPS];
double *Rp = &R1[0], *Rc = &R2[0];
double h = b - a;
double c, n_k;
double *rt;
Rp[0] = (I_OP(a) + I_OP(b)) * h * 0.5;
for (i = 1; i < MAX_STEPS; ++i) {
h = h / 2.0;
c = 0;
ep = 1 << (i - 1);
for (j = 1; j <= ep; ++j)
c = c + I_OP(a + (2 * j - 1) * h);
Rc[0] = h * c + 0.5 * Rp[0];
for (j = 1; j <= i; ++j) {
n_k = 1;
for (k = 0; k < j; ++k)
n_k *= 4;
Rc[j] = (n_k * Rc[j - 1] - Rp[j - 1]) / (n_k - 1);
}
if (i > 1 && fabs(Rp[i - 1] - Rc[i]) < acc)
return Rc[i];
rt = Rp;
Rp = Rc;
Rc = rt;
}
return Rp[MAX_STEPS - 1];
}
int
main()
{
double a = 0.0;
double b = 3.14159265358979323846264338327950288419716939937510;
double c = 2.71828182845904523536028747135266249775724709369995;
double acc = 1e-6;
long l;
double x = 0.001;
for (l = 0; l <= 250; l++)
x = x + romberg(a, b, acc) * romberg(a, c, acc);
printf("%.15lf\n", x);
return 0;
}
```
```
$ clang -O2 rom3.c -o rom3 -lm && time ./rom3
rom3.c:33:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C23 [-Wdeprecated-non-prototype]
33 | romberg(a, b, acc)
| ^
1 warning generated.
9558673.398323269560933
real0m2.550s
user0m2.508s
sys 0m0.014s
$ clang -O3 rom3.c -o rom3 -lm && time ./rom3
rom3.c:33:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C23 [-Wdeprecated-non-prototype]
33 | romberg(a, b, acc)
| ^
1 warning generated.
9558673.398323269560933
real0m2.499s
user0m2.461s
sys 0m0.015s
$ gcc -O2 rom3.c -o rom3 -lm && time ./rom3
rom3.c: In function ‘romberg’:
rom3.c:33:1: warning: old-style function definition [-Wold-style-definition]
33 | romberg(a, b, acc)
| ^~~
9558673.398323269560933
real0m0.018s
user0m0.003s
sys 0m0.014s
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123650] [flang] preprocessor issue
Issue 123650 Summary [flang] preprocessor issue Labels flang Assignees Reporter shivaramaarao for the following program preprocessor output is incorrect program main INTEGER::n !$ ndi integer ! $ndi n=0 END PROGRAM $flang -E -fopenmp t.f90 program main INTEGER::n ndi integer END PROGRAM The issue is in line number 3 when !$ is the prefix . This line should have been considered as comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123659] [clang] Clang crashes when an objective C exception is attempted to be caught when `-fwasm-exceptions` is enabled on a wasm{32, 64} target
Issue
123659
Summary
[clang] Clang crashes when an objective C exception is attempted to be caught when `-fwasm-exceptions` is enabled on a wasm{32,64} target
Labels
clang
Assignees
Reporter
Frityet
[Crash info](https://gist.github.com/Frityet/83fa2c7eee836515f871d59c594e9479)
Reproducer:
```objc
extern void f();
int main()
{
@try {
f();
} @catch(id) {
}
}
```
Command:
```
# Crash reproducer for Homebrew clang version 19.1.6
# Driver args: "t.m" "-target" "wasm32-unknown-none" "-fwasm-exceptions"
# Original command: "/usr/local/Cellar/llvm/19.1.6/bin/clang-19" "-cc1" "-triple" "wasm32-unknown-none" "-emit-obj" "-dumpdir" "a-" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "t.m" "-mrelocation-model" "static" "-mframe-pointer=none" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-target-feature" "+exception-handling" "-mllvm" "-wasm-enable-eh" "-target-feature" "+multivalue" "-target-feature" "+reference-types" "-target-cpu" "generic" "-fvisibility=hidden" "-debugger-tuning=gdb" "-fdebug-compilation-dir=/Users/frityet/Documents/scratch" "-target-linker-version" "1022.1" "-fcoverage-compilation-dir=/Users/frityet/Documents/scratch" "-resource-dir" "/usr/local/Cellar/llvm/19.1.6/lib/clang/19" "-internal-isystem" "/usr/local/Cellar/llvm/19.1.6/lib/clang/19/include" "-internal-isystem" "/include" "-ferror-limit" "19" "-fgnuc-version=4.2.1" "-fskip-odr-check-in-gmf" "-fobjc-runtime=gnustep" "-fobjc-encode-cxx-class-template-spec" "-fobjc-exceptions" "-fexceptions" "-exception-model=wasm" "-fcolor-diagnostics" "-o" "/var/folders/ps/cqv_3ytx5nn59k5q3k17th50gn/T/t-e67633.o" "-x" "objective-c" "t.m"
"/usr/local/Cellar/llvm/19.1.6/bin/clang-19" "-cc1" "-triple" "wasm32-unknown-none" "-emit-obj" "-dumpdir" "a-" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "t.m" "-mrelocation-model" "static" "-mframe-pointer=none" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-target-feature" "+exception-handling" "-mllvm" "-wasm-enable-eh" "-target-feature" "+multivalue" "-target-feature" "+reference-types" "-target-cpu" "generic" "-fvisibility=hidden" "-debugger-tuning=gdb" "-fdebug-compilation-dir=/Users/frityet/Documents/scratch" "-target-linker-version" "1022.1" "-fcoverage-compilation-dir=/Users/frityet/Documents/scratch" "-ferror-limit" "19" "-fgnuc-version=4.2.1" "-fskip-odr-check-in-gmf" "-fobjc-runtime=gnustep" "-fobjc-encode-cxx-class-template-spec" "-fobjc-exceptions" "-fexceptions" "-exception-model=wasm" "-fcolor-diagnostics" "-x" "objective-c" "t-3e83b8.m"
```
Cannot be reproduced on godbolt due to the fact that godbolt objective C does not allow for clang to be selected as the compiler for some reason?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123639] SLP Vectorizer miscompilation
Issue
123639
Summary
SLP Vectorizer miscompilation
Labels
miscompilation,
llvm:SLPVectorizer
Assignees
Reporter
aleks-tmb
During our local testing, we identified a miscompilation where the SLP Vectorizer appears to be the cause. Here is the reproducer we managed to prepare:
https://godbolt.org/z/9nePcq7Go
The issue can be demonstrated using the `lli` tool. Unfortunately, I cannot use alive2 due to unknown libcall errors, such as @llvm.vector.insert.v32i32.v16i32 not being recognized by alive2
```
$ bin/opt -passes=slp-vectorizer -mattr=+avx2 src.ll -S > tgt.ll
$ bin/lli src.ll
Result: -256
$ bin/lli tgt.ll
Result: -272
```
The pseudocode represented by the IR is
```
t = 0
for (i = 0; i < 16; i++) {
s -= (t + i)
t = i
}
```
```
s -= (1 + 0) + (2 + 1) + (3 + 2) + (4 + 3) + ... + (14 + 15) + (15 + 16)
s = -256
```
This indicates that the SLP Vectorizer pass produces incorrect IR.
The issue became reproducible after patch `[SLP] Match poison as instruction with the same opcode` made by @alexey-bataev
https://github.com/llvm/llvm-project/commit/b8703369daf06196ff914c0376c27adde3cf
I'll provide more details on how the patch affects the issue as soon as I receive them.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123646] [clang-tidy] readability-named-parameter shouldn't comment out parameter names in function declaration
Issue 123646 Summary [clang-tidy] readability-named-parameter shouldn't comment out parameter names in function declaration Labels enhancement, clang-tidy Assignees Reporter LegalizeAdulthood Suppose you have the following declaration: ``` static void transform(DblCoords *); ``` when readability-named-parameter is run, the code becomes: ``` static void transform(DblCoords * /*point*/); ``` Since this is a declaration, not a definition, the parameter name should not be commented out. To reproduce: 1. `git clone https://github.com/LegalizeAdulthood/iterated-dynamics.git` 2. `git checkout 784b6062108a0d56d2e84313e975a5b04981d62f` 3. Configure with cmake, e.g. `cmake --preset default` 4. Run readability-named-parameter on `loadfile.cpp`, line 175 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123668] [Flang][PPC] frontend `-funroll-loops` does not affect unroll on PPC target
Issue 123668 Summary [Flang][PPC] frontend `-funroll-loops` does not affect unroll on PPC target Labels flang Assignees Reporter mustartt 2 test cases that are currently failing on `ppc64-flang-aix` and `ppc64le-flang-rhel-clang` ``` FAIL: Flang::unroll-loops.fir FAIL: Flang::unroll-loops.f90 ``` ``` TEST 'Flang :: Integration/unroll-loops.f90' FAILED Exit Code: 1 Command Output (stderr): -- RUN: at line 1: /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/build/bin/flang -fc1 -emit-llvm -O1 -funroll-loops -mllvm -force-vector-width=2 -o- /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/llvm-project/flang/test/Integration/unroll-loops.f90 | /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/build/bin/FileCheck /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/llvm-project/flang/test/Integration/unroll-loops.f90 --check-prefixes=CHECK,UNROLL + /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/build/bin/FileCheck /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/llvm-project/flang/test/Integration/unroll-loops.f90 --check-prefixes=CHECK,UNROLL + /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/build/bin/flang -fc1 -emit-llvm -O1 -funroll-loops -mllvm -force-vector-width=2 -o- /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/llvm-project/flang/test/Integration/unroll-loops.f90 /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/llvm-project/flang/test/Integration/unroll-loops.f90:22:17: error: UNROLL-NEXT: is not on the line after the previous match ! UNROLL-NEXT: %[[GEP0:.*]] = getelementptr i64, ptr %[[ARG0]], i64 %[[IND]] ^ :21:2: note: 'next' match was here %1 = getelementptr i64, ptr %0, i64 %index ^ :14:51: note: previous match ended here %step.add = add <2 x i64> %vec.ind, splat (i64 2) ^ :15:1: note: non-matching line after previous match is here %step.add.2 = add <2 x i64> %vec.ind, splat (i64 4) ^ Input file: Check file: /home/buildbots/llvm-external-buildbots/workers/ppc64le-flang-rhel-test/ppc64le-flang-rhel-clang-build/llvm-project/flang/test/Integration/unroll-loops.f90 -dump-input=help explains the following input dump. Input was: << . . . 16: %step.add.3 = add <2 x i64> %vec.ind, splat (i64 6) 17: %step.add.4 = add <2 x i64> %vec.ind, splat (i64 8) 18: %step.add.5 = add <2 x i64> %vec.ind, splat (i64 10) 19: %step.add.6 = add <2 x i64> %vec.ind, splat (i64 12) 20: %step.add.7 = add <2 x i64> %vec.ind, splat (i64 14) 21: %1 = getelementptr i64, ptr %0, i64 %index next:22 !~ error: match on wrong line 22: %2 = getelementptr i8, ptr %1, i64 16 23: %3 = getelementptr i8, ptr %1, i64 32 24: %4 = getelementptr i8, ptr %1, i64 48 25: %5 = getelementptr i8, ptr %1, i64 64 26: %6 = getelementptr i8, ptr %1, i64 80 . . . >> -- ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123665] JIT can't overwrite a weak function content for re-execution
Issue
123665
Summary
JIT can't overwrite a weak function content for re-execution
Labels
new issue
Assignees
Reporter
wesuRage
I'm making a JIT REPL, where I made a while loop for each iteration of the REPL. Before the loop starts up, it initializes the LLVM and the LLJIT:
```cpp
llvm::InitializeNativeTarget();
llvm::InitializeNativeTargetAsmPrinter();
llvm::InitializeNativeTargetAsmParser();
auto JIT = llvm::orc::LLJITBuilder().create();
if (!JIT) {
llvm::errs() << "Error initializing LLJIT: " << llvm::toString(JIT.takeError()) << "\n";
return 1;
}
llvm::LLVMContext TheContext;
```
Now, inside the loop, for each iteration I've made a redefinition of the Module and the Builder, so every time I press enter, it starts from scratch.
```cpp
auto TheModule = std::make_unique("GalaxyJIT", TheContext);
llvm::IRBuilder Builder(TheContext);
```
But I kept track of declaration of functions and variables, variables attributions and extern functions, so it can be reloaded in the code generation of my language.
After this, I create an `entry.main` function which is a weak function, where all the code is stored:
```cpp
llvm::FunctionType *mainFuncType = llvm::FunctionType::get(Builder.getVoidTy(), false);
llvm::Function *mainFunc = llvm::Function::Create(mainFuncType, llvm::GlobalValue::WeakODRLinkage, "entry.main", *TheModule);
llvm::BasicBlock *entryBlock = llvm::BasicBlock::Create(TheContext, "entry", mainFunc);
Builder.SetInsertPoint(entryBlock);
generate_ir(ast, TheContext, *TheModule, Builder);
Builder.CreateRetVoid();
```
And after all of this I add the module to the JIT:
```cpp
if (auto Err = (*JIT)->addIRModule(llvm::orc::ThreadSafeModule(std::move(TheModule), std::make_unique( {
llvm::errs() << "Error adding the IR module to JIT: " << llvm::toString(std::move(Err)) << "\n";
free_ast_node(ast);
freeTokens(tokens, count);
return 1;
}
auto Func = (*JIT)->lookup("entry.main");
if (!Func) {
llvm::errs() << "Error: entry.main not found.\n";
free_ast_node(ast);
freeTokens(tokens, count);
continue;
}
```
So that's the design of my REPL. But the problem is: from my understanding of reading the docs, only weak functions can be redefined. And I emmited the LLVM of each iteration, confirming that it happens. But even when the function is overwritten, the JIT engine cant see the new function with the new IR inside. It only works on the first iteration. But the weirdest thing is that on the emmited LLVM everything seems to be fine, since all the IR is indeed generated, but not executed. It seems like the JIT engine only "remembers" the first function's state. How can I solve it?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123669] CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
Issue
123669
Summary
CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
Labels
new issue
Assignees
Reporter
guimvmatos
I'm trying to install LLVM in docker as described [here](https://llvm.org/docs/Docker.html). But after the first command, I get the error below. How can I resolve this?
The command:
```
./llvm/utils/docker/build_docker_image.sh \
--source debian10 \
--docker-repository clang-debian10 --docker-tag "staging" \
-p clang -i install-clang -i install-clang-resource-headers \
-- \
-DCMAKE_BUILD_TYPE=Release
```
The output:
```
> [builder 9/9] RUN /tmp/scripts/build_install_llvm.sh --to /tmp/clang-install -i install-clang -i install-clang-resource-headers -- -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang:
0.394 /tmp/clang-build/build /
0.394 Running build
0.591 CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
0.591 CMake 3.20.0 or higher is required. You are running version 3.13.4
0.591
0.591
0.592 -- Configuring incomplete, errors occurred!
--
Dockerfile:41
39 | # Run the build. Results of the build will be available at /tmp/clang-install/.
40 | ARG buildscript_args
41 | >>> RUN /tmp/scripts/build_install_llvm.sh --to /tmp/clang-install ${buildscript_args}
42 |
43 |
ERROR: failed to solve: process "/bin/sh -c /tmp/scripts/build_install_llvm.sh --to /tmp/clang-install ${buildscript_args}" did not complete successfully: exit code: 1
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123630] [mlir] Improve code re-use in VectorEmulateNarrowType.cpp
Issue 123630 Summary [mlir] Improve code re-use in VectorEmulateNarrowType.cpp Labels Assignees Reporter banach-space Hi folks! Having reviewed a few recent PRs for [VectorEmulateNarrowType.cpp](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp), e.g.: * https://github.com/llvm/llvm-project/pull/115922, or * #121298, I believe it’s time to improve code reusability and unify naming conventions in the file. At ~1.7k lines, it's becoming increasingly difficult to review patches. ### Proposal 1 To begin with, I would like for us to start re-using the logic from [alignedConversionPrecondition](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L1084-L1109). This hook effectively checks **two conditions**: 1. [Per-element alignment](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L1096) (e.g. `i2` and `i8` are aligned, `i3` and `i8` are not aligned). 2. Could the input/source _vector of sub-byte scalar types_ (e.g. `vector<2xi4>`) fit within the target mulit-byte container type (e.g. `i8` or `i32`), this is checked [here](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L1103). Similar checks are repeated throughout the code, e.g. * **Cond 1:** [check 1](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L320), [check 2](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L391), [check 3](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L499) ... . * **Cond 2:** [check 1](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L340), [check 2](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L398), [check 3](https://github.com/llvm/llvm-project/blob/3b001db4f9668cfa29572e5f1911ec7cef8b0ac2/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L535), ... . In order to enable re-use, it would help to do some minor variable renaming first. Otherwise, it's quite hard to see that basically identical quantity is computed/defined multiple times throughout the code. Rather than implementing this in one big patch, I have split it into 4 independent changes: * https://github.com/llvm/llvm-project/pull/123526 * https://github.com/llvm/llvm-project/pull/123527 * https://github.com/llvm/llvm-project/pull/123528 * https://github.com/llvm/llvm-project/pull/123529 These are basically stacked PRs. I've made sure to link the relevant commit (1 per PR) in the summary, so that it's easy for you to find it. ### Proposal 2 We should clarify the meaning of "source" and "destination" types. Currently, the usage is ambiguous. For example, for this `arith.extsi` Op, ```mlir %0 = arith.extsi %arg0 : vector<8xi2> to vector<8xi32> ``` `vector<8xi2>` and `vector<8xi32>` are the "source" and "destination" types, respectively (i.e. that's the interpretation we tend to use). However, patterns like `RewriteAlignedSubByteIntExt` introduce `vector.bitcast` Ops like this: ```mlir %bitcast = vector.bitcast %arg0 : vector<8xi2> to vector<2xi8> ``` I've noticed that we tend to consider both: * `vector<2xi8>`(the result of `vector.bitcast`), and `vector<8xi32>` (the output of `arith.extsi`) as the destination type. That should be clarified. I suggest two steps: * Avoid "destination" and "source" when referring to the "emulation" logic. Reserve that for the original Op (e.g. `arith.extsi` above). Better still, use the naming from Op definitions (for [arith.extsi](https://mlir.llvm.org/docs/Dialects/ArithOps/#arithextsi-arithextsiop) that would mean `in` and `out` for "source" and "destination"). * For the "emulation" logic, use "emulated type" and "container name" for the original type (to be emulated, e.g. `i2`) and the target type that's used for emulation (e.g. `i8`). WDYT? ### Proposal 3 Document the updated naming in the file. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123631] [AMDGPU][GISel] BFI generated instead of a smaller load
Issue
123631
Summary
[AMDGPU][GISel] BFI generated instead of a smaller load
Labels
backend:AMDGPU,
llvm:globalisel
Assignees
Reporter
qcolombet
When using GISel I end up with `bfi` instructions where SDISel uses simpler sequence of instructions.
I've attached a small reproducer and a slightly bigger one because I don't know if the fix will be exactly the same for both cases since the smallest reproducer has all relevant instructions in the same basic block whereas the bigger one does not.
In both cases, the problem stems from the fact that SDISel is able to simplify `extract_subvector (load <8 x half> %addr), high_4_half` into `load <4 x half> %add + 8`, whereas GISel lowers this sequence all the way to ISel without any simplification.
This combine may be worth putting in the generic combiner helper.
# To Reproduce #
Download the attached reproducer or copy/paste the IR at the end.
[repro.ll.txt](https://github.com/user-attachments/files/18479391/repro.ll.txt)
And run:
```bash
llc -O3 -march=amdgcn -mcpu=gfx942 -mtriple amdgcn-amd-hmcsa -global-isel=<0|1> repro.ll -o -
```
# Result #
GISel produces `bfi` instructions whereas SDISel doesn't. (Showing the result only for the smallest reproducer.)
With GISel:
```asm
s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
ds_read2_b64 v[2:5], v0 offset1:1
s_mov_b32 s0, 0x
s_waitcnt lgkmcnt(0)
v_bfi_b32 v2, s0, v4, v4 <--- these
v_bfi_b32 v3, s0, v5, v5 <--- these
ds_write_b64 v1, v[2:3]
s_waitcnt lgkmcnt(0)
s_setpc_b64 s[30:31]
```
With SDISel:
```asm
s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
ds_read2_b64 v[2:5], v0 offset1:1
s_waitcnt lgkmcnt(0)
ds_write_b64 v1, v[4:5]
s_waitcnt lgkmcnt(0)
s_setpc_b64 s[30:31]
```
# Note #
Small reproducer:
```llvm
define void @bla(ptr addrspace(3) %in, ptr addrspace(3) %out) {
%val = load <8 x half>, ptr addrspace(3) %in, align 8
%res = shufflevector <8 x half> %val, <8 x half> poison, <4 x i32>
store <4 x half> %res, ptr addrspace(3) %out, align 8
ret void
}
```
Bigger reproducer (automatically reduced):
```llvm
define amdgpu_kernel void @foo() {
bb:
%i395.pre = load <8 x half>, ptr addrspace(3) null, align 8
br label %bb374
bb374: ; preds = %bb374, %bb
%i375 = phi [1 x [2 x [1 x [4 x [1 x <4 x float>] [ zeroinitializer, %bb ], [ %i845, %bb374 ]
%i377 = phi <1 x float> [ zeroinitializer, %bb ], [ %i509, %bb374 ]
%i414 = shufflevector <8 x half> %i395.pre, <8 x half> zeroinitializer, <4 x i32>
%i415 = tail call <16 x float> @llvm.amdgcn.mfma.f32.32x32x8f16(<4 x half> %i414, <4 x half> zeroinitializer, <16 x float> zeroinitializer, i32 0, i32 0, i32 0)
%i446 = shufflevector <16 x float> %i415, <16 x float> zeroinitializer, <1 x i32>
%i509 = fmul <1 x float> %i446, %i377
%i511 = extractelement <1 x float> %i377, i64 0
%i665 = insertelement <4 x float> zeroinitializer, float %i511, i64 0
%i670 = extractvalue [1 x [2 x [1 x [4 x [1 x <4 x float>] %i375, 0, 1, 0, 0, 0
%i796 = shufflevector <4 x float> %i670, <4 x float> zeroinitializer, <8 x i32>
%i844 = insertvalue [1 x [4 x [1 x <4 x float>]]] zeroinitializer, <4 x float> %i665, 0, 3, 0
%i845 = insertvalue [1 x [2 x [1 x [4 x [1 x <4 x float>] zeroinitializer, [1 x [4 x [1 x <4 x float>]]] %i844, 0, 1
br label %bb374
}
; Function Attrs: convergent nocallback nofree nosync nounwind willreturn memory(none)
declare <16 x float> @llvm.amdgcn.mfma.f32.32x32x8f16(<4 x half>, <4 x half>, <16 x float>, i32 immarg, i32 immarg, i32 immarg) #0
attributes #0 = { convergent nocallback nofree nosync nounwind willreturn memory(none) }
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123573] [clang-format] Qualifiers are not sorted properly when `[[maybe_unused]]` or `[[nodiscard]]` attributes are used
Issue
123573
Summary
[clang-format] Qualifiers are not sorted properly when `[[maybe_unused]]` or `[[nodiscard]]` attributes are used
Labels
clang-format
Assignees
Reporter
lluisalemanypuig
I'm using clang-format 19
```
$ clang-format-19 --version
Ubuntu clang-format version 19.1.7 (++20250114103320+cd708029e0b2-1~exp1~20250114103432.75)
```
to format my C++ code. I specified the order of qualifiers in the following manner in my `.clang-format` file:
```
Language: Cpp
QualifierAlignment: Custom
QualifierOrder: [static, constexpr, inline, const, friend, type]
```
and it works well for functions and variable declarations when there are no attributes at the front:
```cpp
// the [[nodiscard]] attribute prevents clang-format from
// ordering the qualifiers 'constexpr' and 'static' properly.
[[nodiscard]] inline constexpr static int function_with_nodiscard() noexcept {
return 1;
}
// the attributes are ordered according to the specified order in the
// .clang-format file
static constexpr inline int function_without_nodiscard() noexcept { return 1; }
int main() {
// the [[maybe_unused]] attribute prevents clang-format from
// ordering the qualifiers 'constexpr' and 'static' properly.
[[maybe_unused]] constexpr static int A = 1234;
// the attributes are ordered according to the specified order in the
// .clang-format file
static constexpr int B = 1234;
}
```
I expected all the qualifiers to be ordered according to the predefined order in the file, so that they are ordered like this:
```cpp
[[nodiscard]] static constexpr inline int function_with_nodiscard() noexcept {
return 1;
}
static constexpr inline int function_without_nodiscard() noexcept { return 1; }
int main() {
[[maybe_unused]] static constexpr int A = 1234;
static constexpr int B = 1234;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
