[llvm-bugs] [Bug 146805] [clang-tidy] Check request: performance-incorrect-move-with-smart-pointer-cast
Issue 146805 Summary [clang-tidy] Check request: performance-incorrect-move-with-smart-pointer-cast Labels clang-tidy Assignees Reporter denzor200 Need a check that will find incorrect usage of `std::move` with smart pointer casts (e.g., `std::static_pointer_cast`, `std::dynamic_pointer_cast`, their `boost` analogues, etc). BEFORE: ``` std::shared_ptr b = std::move(std::dynamic_pointer_cast(a)); ``` AFTER: ``` std::shared_ptr b = std::dynamic_pointer_cast(std::move(a)); ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146818] Assertion `isLValue()` failed in `Cl clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const`
Issue
146818
Summary
Assertion `isLValue()` failed in `Cl clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const`
Labels
clang
Assignees
Reporter
Rush10233
Probably goes back to clang-3.1: https://godbolt.org/z/4qTWPhrWr
Generated by fuzzer.
Simplified test:
```c++
template class complex;
template<> class complex
{
public:
complex(double =0.0, double =0.0);
private:
typedef _ComplexT;
_ComplexT _M_value;
};
inline
complex::complex(double __r, double __i)
{
__imag__ _M_value = __i;
}
```
Stack Dump:
```
:9:9: error: a type specifier is required for all declarations
9 | typedef _ComplexT;
| ~~~ ^
clang++: /root/llvm-project/llvm/tools/clang/lib/AST/ExprClassification.cpp:57: Cl clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const: Assertion `isLValue()' 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: /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
1. :16:24: current parser token ';'
2. :15:1: parsing function body 'complex::complex'
3. :15:1: in compound statement ('{}')
#0 0x03f78848 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f78848)
#1 0x03f764d4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f764d4)
#2 0x03ebb048 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7398b3242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7398b32969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7398b3242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7398b32287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7398b322871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7398b3239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x0781a886 clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x781a886)
#10 0x0781aa5d clang::Expr::isModifiableLvalue(clang::ASTContext&, clang::SourceLocation*) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x781aa5d)
#11 0x06b4481c CheckForModifiableLvalue(clang::Expr*, clang::SourceLocation, clang::Sema&) SemaExpr.cpp:0:0
#12 0x06b79dd7 clang::Sema::CheckAssignmentOperands(clang::Expr*, clang::ActionResult&, clang::SourceLocation, clang::QualType, clang::BinaryOperatorKind) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6b79dd7)
#13 0x06b7b38b clang::Sema::CreateBuiltinBinOp(clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6b7b38b)
#14 0x06b7ca91 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6b7ca91)
#15 0x06b7d016 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6b7d016)
#16 0x066a31f0 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66a31f0)
#17 0x066a6699 clang::Parser::ParseExpression(clang::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66a6699)
#18 0x0673a479 clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x673a479)
#19 0x06731e28 clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::ParsedAttributes&, clang::ParsedAttributes&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6731e28)
#20 0x06732c4d clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6732c4d)
#21 0x0673ab73 clang::Parser::ParseCompoundStatementBody(bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x673ab73)
#22 0x0673b33a clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6
[llvm-bugs] [Bug 146817] [clang] Assertion `Constructor->getInheritedConstructor() && !Constructor->doesThisDeclarationHaveABody() && !Constructor->isDeleted()` failed
Issue
146817
Summary
[clang] Assertion `Constructor->getInheritedConstructor() && !Constructor->doesThisDeclarationHaveABody() && !Constructor->isDeleted()` failed
Labels
clang
Assignees
Reporter
Rush10233
Start from clang-17: https://godbolt.org/z/s6czh6bsv
Generated by fuzzer.
Simplified test:
```c++
struct base {
base (int, int) {}
};
template
struct derived : base {
union MyUnion {
struct NonTrivial {
NonTrivial() {}
} member;
} u;
using base::base;
};
int
main ()
{
base (13, 42);
derived (13, 42);
}
```
Stack dump:
```
clang++: /root/llvm-project/llvm/tools/clang/lib/Sema/SemaDeclCXX.cpp:14331: void clang::Sema::DefineInheritingConstructor(clang::SourceLocation, clang::CXXConstructorDecl*): Assertion `Constructor->getInheritedConstructor() && !Constructor->doesThisDeclarationHaveABody() && !Constructor->isDeleted()' 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: /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
1. :19:24: current parser token ';'
2. :17:1: parsing function body 'main'
3. :17:1: in compound statement ('{}')
#0 0x03f78848 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f78848)
#1 0x03f764d4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f764d4)
#2 0x03ebb048 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x715cf7242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x715cf72969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x715cf7242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x715cf72287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x715cf722871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x715cf7239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x06ac3857 clang::Sema::DefineInheritingConstructor(clang::SourceLocation, clang::CXXConstructorDecl*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6ac3857)
#10 0x06b60103 void llvm::function_ref::callback_fn(long) SemaExpr.cpp:0:0
#11 0x07eadef1 clang::StackExhaustionHandler::runWithSufficientStackSpace(clang::SourceLocation, llvm::function_ref) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7eadef1)
#12 0x06b5e65f clang::Sema::MarkFunctionReferenced(clang::SourceLocation, clang::FunctionDecl*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6b5e65f)
#13 0x06cab0df PerformConstructorInitialization(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::InitializationSequence::Step const&, bool&, bool, bool, clang::SourceLocation, clang::SourceLocation) SemaInit.cpp:0:0
#14 0x06cba882 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6cba882)
#15 0x06c28dd7 clang::Sema::BuildCXXTypeConstructExpr(clang::TypeSourceInfo*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6c28dd7)
#16 0x06c29609 clang::Sema::ActOnCXXTypeConstructExpr(clang::OpaquePtr, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6c29609)
#17 0x066bd0e5 clang::Parser::ParseCXXTypeConstructExpression(clang::DeclSpec const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66bd0e5)
#18 0x066a1400 clang::Parser::ParseCastExpression(clang::CastParseKind, bool, bool&, clang::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66a1400)
#19 0x066a1f47 clang::Parser::ParseCastExpression(clang::CastParseKind, bool, clang::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66a1f47)
#20 0x066a1fd9 clang::Parser::ParseAssignmentExpression(clang::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66a1fd9)
#21 0x066a6699 clang::Parser::ParseExpression(clang::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66a6699)
#22 0x0673a479 clang::Parser::ParseExprStatement(clang::Parser:
[llvm-bugs] [Bug 146802] [flang] flang doesn't correctly handle `-mframe-pointer=reserved`
Issue 146802 Summary [flang] flang doesn't correctly handle `-mframe-pointer=reserved` Labels flang:driver Assignees Reporter dpaoliello Clang recently started using `FramePointerKind::Reserved` for Arm64 Windows: #146582 Flang translates this to `-mframe-pointer=reserved`: https://github.com/llvm/llvm-project/blob/925588cd001a91d592b99e6e7c6bee9514f5a26e/clang/lib/Driver/ToolChains/Flang.cpp#L944-L946 However, Flang's command line parser doesn't handle `-mframe-pointer=reserved` (from ): ``` FAILED: include/flang/__fortran_builtins.mod C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/include/flang/__fortran_builtins.mod C:\WINDOWS\system32\cmd.exe /C "cd /D C:\Users\tcwg\llvm-worker\flang-arm64-windows-msvc\build\tools\flang\tools\f18 && C:\Users\tcwg\scoop\apps\cmake\3.29.2\bin\cmake.exe -E make_directory C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/include/flang && C:\Users\tcwg\llvm-worker\flang-arm64-windows-msvc\build\bin\flang.exe -cpp -fsyntax-only -module-dir C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/build/include/flang C:/Users/tcwg/llvm-worker/flang-arm64-windows-msvc/llvm-project/flang/module/__fortran_builtins.f90" error: invalid value 'reserved' in '-mframe-pointer=reserved' ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146804] clang cannot process intertwined assembly sections
Issue 146804 Summary clang cannot process intertwined assembly sections Labels clang Assignees Reporter amsen20 assembly sections are allowed to be nested and intertwined if their associated sections are, for example, the following code: ```asm .section A .cfi_startproc .cfi_def_cfa_offset 1 .section B .cfi_startproc .cfi_def_cfa_offset 2 .section A .cfi_def_cfa_offset 3 .cfi_endproc .section B .cfi_def_cfa_offset 4 .cfi_endproc ``` Is equivalent to: ```asm .section A .cfi_startproc .cfi_def_cfa_offset 1 .cfi_def_cfa_offset 3 .cfi_endproc .section B .cfi_startproc .cfi_def_cfa_offset 2 .cfi_def_cfa_offset 4 .cfi_endproc ``` GNU assembler can process this code as intended: ``` $ as -g a.s -o a.o && objdump --dwarf=frames a.o a.o: file format elf64-x86-64 Contents of the .eh_frame section: 0018 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_def_cfa_offset: 1 DW_CFA_def_cfa_offset: 3 DW_CFA_nop DW_CFA_nop 001c 0010 0020 FDE cie= pc=.. DW_CFA_nop DW_CFA_nop DW_CFA_nop 0030 0018 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_def_cfa_offset: 2 DW_CFA_def_cfa_offset: 4 DW_CFA_nop DW_CFA_nop 004c 0010 0020 FDE cie=0030 pc=.. DW_CFA_nop DW_CFA_nop DW_CFA_nop ``` But LLVM just emits an error for it: ``` $ clang -c -g a.s -o a.o :0: error: invalid CFI advance_loc _expression_ :0: error: invalid CFI advance_loc _expression_ :0: error: Cannot represent a difference across sections :0: error: Cannot represent a difference across sections ``` This problem does not happen when the sections are intertwined like a stack, for example both of the following codes: ``` .section A .cfi_startproc .cfi_def_cfa_offset 1 .section B .cfi_startproc .cfi_def_cfa_offset 2 .cfi_def_cfa_offset 3 .cfi_endproc .section A .cfi_def_cfa_offset 4 .cfi_endproc ``` and ``` .pushsection A .cfi_startproc .cfi_def_cfa_offset 1 .pushsection B .cfi_startproc .cfi_def_cfa_offset 2 .cfi_def_cfa_offset 3 .cfi_endproc .popsection .cfi_def_cfa_offset 4 .cfi_endproc .popsection ``` Are equal in the eye of `clang`, and the debug info in sections is correctly processed: ``` a.o:file format elf64-x86-64 .debug_frame contents: .eh_frame contents: 0014 CIE Format:DWARF32 Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1B DW_CFA_def_cfa: reg7 +8 DW_CFA_offset: reg16 -8 DW_CFA_nop: DW_CFA_nop: CFA=reg7+8: reg16=[CFA-8] 0018 0014 001c FDE cie= pc=... Format: DWARF32 DW_CFA_def_cfa_offset: +1 DW_CFA_def_cfa_offset: +4 DW_CFA_nop: DW_CFA_nop: DW_CFA_nop: 0x0: CFA=reg7+4: reg16=[CFA-8] 0030 0014 0034 FDE cie= pc=... Format: DWARF32 DW_CFA_def_cfa_offset: +2 DW_CFA_def_cfa_offset: +3 DW_CFA_nop: DW_CFA_nop: DW_CFA_nop: 0x0: CFA=reg7+3: reg16=[CFA-8] ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146683] [tsan] CHECK failed in thread sanitizer on ThreadCreate after finished thread was joined using pthread_clockjoin_np
Issue 146683 Summary [tsan] CHECK failed in thread sanitizer on ThreadCreate after finished thread was joined using pthread_clockjoin_np Labels new issue Assignees Reporter doschropa In an application that uses a large number of threads, I can frequently reproduce a CHECK failed in Thread Sanitizer. ```bash ThreadSanitizer: CHECK failed: sanitizer_thread_registry.cpp:186 "((live_.try_emplace(user_id, tid).second)) != (0)" (0x0, 0x0) (tid=50579) #0 __tsan::CheckUnwind() ../../../../libsanitizer/tsan/tsan_rtl.cpp:676 (libtsan.so.2+0x6a63a) (BuildId: 51a623d990ea8c1d192774bb95a1b723606c1288) #1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (libtsan.so.2+0xa504f) (BuildId: 51a623d990ea8c1d192774bb95a1b723606c1288) #2 __sanitizer::ThreadRegistry::CreateThread(unsigned long, bool, unsigned int, unsigned int, void*) (libtsan.so.2+0xa9cad) (BuildId: 51a623d990ea8c1d192774bb95a1b723606c1288) #3 __tsan::ThreadCreate(__tsan::ThreadState*, unsigned long, unsigned long, bool) ../../../../libsanitizer/sanitizer_common/sanitizer_thread_registry.h:113 (libtsan.so.2+0x82136) (BuildId: 51a623d990ea8c1d192774bb95a1b723606c1288) #4 pthread_create (libtsan.so.2+0x1f4ed) (BuildId: 51a623d990ea8c1d192774bb95a1b723606c1288) #5 g_system_thread_new ../glib/gthread-posix.c:762 (libglib-2.0.so.0+0x76a30) (BuildId: 2acd4dfbc176f0dd02c08005d3214bc81469bc57) #6 g_thread_new_internal ../glib/gthread.c:997 (libglib-2.0.so.0+0x76a30) #7 g_thread_new (libglib-2.0.so.0+0x76c2d) (BuildId: 2acd4dfbc176f0dd02c08005d3214bc81469bc57) #8 (libgstrtpmanager.so+0x137bb) (BuildId: e88f813782372b3b152ccf0a96c690f09b3e652b) #9 gst_element_change_state (libgstreamer-1.0.so.0+0x473b3) (BuildId: 8c4e928d60fdc40f3b85e0049c507f274fa8fb7a) #10 gst_element_set_state_func.lto_priv.0 (libgstreamer-1.0.so.0+0x4796b) (BuildId: 8c4e928d60fdc40f3b85e0049c507f274fa8fb7a) #11 gst_bin_change_state_func (libgstreamer-1.0.so.0+0x1c077) (BuildId: 8c4e928d60fdc40f3b85e0049c507f274fa8fb7a) #12 gst_pipeline_change_state (libgstreamer-1.0.so.0+0x7981e) (BuildId: 8c4e928d60fdc40f3b85e0049c507f274fa8fb7a) #13 gst_element_change_state (libgstreamer-1.0.so.0+0x473b3) (BuildId: 8c4e928d60fdc40f3b85e0049c507f274fa8fb7a) #14 gst_element_change_state (libgstreamer-1.0.so.0+0x473fa) (BuildId: 8c4e928d60fdc40f3b85e0049c507f274fa8fb7a) #15 gst_element_set_state_func.lto_priv.0 (libgstreamer-1.0.so.0+0x4796b) (BuildId: 8c4e928d60fdc40f3b85e0049c507f274fa8fb7a) ``` If I understood correctly, the `user_id` that is inserted into `live_` in [sanitizer_thread_registry.cpp](https://github.com/llvm/llvm-project/blob/1b7cbe1f871ebe572e383a2531257b88168eea1b/compiler-rt/lib/sanitizer_common/sanitizer_thread_registry.cpp#L186) is supposed to be the value of pthread_t that is passed by pointer to `pthread_create`. The failing check reveals that a `pthread_t` is already present in the map, as if the system may be attempting to assign the same `pthread_t` to multiple concurrently running threads. I can imagine that `live_` is not cleaned up when a thread finishes using `pthread_clockjoin_np`, which has been used by Qt's QThread since version 6.9, as there does not appear to be an interceptor set in [tsan_interceptors_posix.cpp](https://github.com/llvm/llvm-project/blob/c0e9084b1ce1a93fd8c2a650e48b3e11d831b649/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp) for `pthread_clockjoin_np`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146712] [flang] Assertion failed: detail::isPresent(Val) && "dyn_cast on a non-existent value"
Issue 146712 Summary [flang] Assertion failed: detail::isPresent(Val) && "dyn_cast on a non-existent value" Labels flang Assignees Reporter augusew1 I have run into the assertion in the title while compiling an incredibly large fortran project. I am using a custom build LLVM 20.1.7 toolchain on Windows compiled by `clang-cl.exe` 19.1.5 with the following options: ``` cmake ` -G "Ninja" ` -Wno-dev ` -Wno-deprecated ` -DCMAKE_C_COMPILER="clang-cl.exe" ` -DCMAKE_CXX_COMPILER="clang-cl.exe" ` -DCMAKE_C_LINK_EXECUTABLE="lld-link.exe" ` -DCMAKE_CXX_LINK_EXECUTABLE="lld-link.exe" ` -DCMAKE_BUILD_TYPE=Release ` -DCMAKE_INSTALL_PREFIX:PATH="$($InstallDir)" ` -DLLVM_ENABLE_ASSERTIONS=ON ` -DLLVM_TARGETS_TO_BUILD=host ` -DLLVM_ENABLE_PROJECTS="clang;mlir;lld;lldb;openmp;flang" ` -DLLVM_ENABLE_RUNTIMES="compiler-rt" ` -B "$($BuildDir)" ` -DLLVM_LIT_ARGS=-svj4 ` -S ".\llvm-src\llvm" ``` The full error is below Error Log ``` Assertion failed: detail::isPresent(Val) && "dyn_cast on a non-existent value", file C:\Users\augusew1\Documents\git\llvm\llvm-project-llvmorg-20.1.7\llvm\include\llvm/Support/Casting.h, line 662 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: C:\\Users\\augusew1\\Documents\\git\\llvm\\llvm-install\\bin\\flang -fc1 -triple x86_64-pc-windows-msvc19.44.35209 -emit-obj -I otis4src\\libs/bcslib\\libbcslib.a.p -I otis4src\\libs/blas\\libblas.a.p -I otis4src\\libs/cdheat\\libcdheat.a.p -I otis4src\\libs/gram07\\libgram.a.p -I otis4src\\libs/jhuapl/borders\\libjhuapl_borders.a.p -I otis4src\\libs/jhuapl/massprops\\libjhuapl_massprops.a.p -I otis4src\\libs/jpl\\libjpl.a.p -I otis4src\\libs/linpack\\liblinpack.a.p -I otis4src\\libs/miniver\\libminiver.a.p -I otis4src\\libs/novas\\libnovas.a.p -I otis4src\\libs/slsqp\\libslsqp.a.p -I otis4src\\libs/smath\\libsmath.a.p -I otis4src\\spice/toolkit/src/spicelib\\libspicelib.a.p -I otis4src\\libs/snopt7\\libsnopt.a.p -I otis4src\\src\\otis4.exe.p -I otis4src\\src -I ..\\otis4src\\src -D NDEBUG -D _FILE_OFFSET_BITS=64 -ffixed-line-length=132 -mrelocation-model pic -pic-level 2 -target-cpu x86-64 --dependent-lib=clang_rt.builtins-x86_64.lib -D_MT --dependent-lib=libcmt --dependent-lib=FortranRuntime.static.lib --dependent-lib=FortranDecimal.static.lib -D_MSC_VER=1944 -D_MSC_FULL_VER=194435209 -D_WIN32 -D_M_X64=100 -fversion-loops-for-stride -module-dir otis4src\\src\\otis4.exe.p -resource-dir C:\\Users\\augusew1\\Documents\\git\\llvm\\llvm-install\\lib\\clang\\20 -mframe-pointer=none -O3 -o otis4src/src/otis4.exe.p/phmap.f.obj -x f95-cpp-input ../otis4src/src/phmap.f Exception Code: 0xC01D #0 0x7ff61cc569a6 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x5469a6) #1 0x7ff9a6cae6d5 (C:\WINDOWS\System32\ucrtbase.dll+0x7e6d5) #2 0x7ff9a6caf6e1 (C:\WINDOWS\System32\ucrtbase.dll+0x7f6e1) #3 0x7ff9a6cb108e (C:\WINDOWS\System32\ucrtbase.dll+0x8108e) #4 0x7ff9a6cb12d1 (C:\WINDOWS\System32\ucrtbase.dll+0x812d1) #5 0x7ff620d404bf (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x46304bf) #6 0x7ff61fdf6ccb (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x36e6ccb) #7 0x7ff61fdf6325 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x36e6325) #8 0x7ff61fdf5fdb (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x36e5fdb) #9 0x7ff620d16a74 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x4606a74) #10 0x7ff6212c0364 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x4bb0364) #11 0x7ff6212bd289 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x4bad289) #12 0x7ff620d17b7b (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x4607b7b) #13 0x7ff620d16ba1 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x4606ba1) #14 0x7ff620d18172 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x4608172) #15 0x7ff620d1cdde (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x460cdde) #16 0x7ff61fdf221b (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x36e221b) #17 0x7ff61e293933 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x1b83933) #18 0x7ff61e293f3b (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x1b83f3b) #19 0x7ff61e2966f5 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x1b866f5) #20 0x7ff61cd8339a (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x67339a) #21 0x7ff61cd87554 (C:\Users\augusew1\Documents\git\llvm\llvm-install\bin\flang.exe+0x677554) #22 0x7ff61ccee12d
[llvm-bugs] [Bug 146713] [wasm-ld] using `--import-memory` cancels out `--page-size=N` options without telling user.
Issue 146713 Summary [wasm-ld] using `--import-memory` cancels out `--page-size=N` options without telling user. Labels new issue Assignees Reporter anlavandier The current version of the Webassembly linker `wasm-ld` allows the argument `--page-size=N` with N being either `1` or `65536` since the merging of #128942. For some reason, when also passing the `--import-memory` flag, the `page-size` is completely disregarded without telling the caller. This results in `.wasm` files that try to import a memory with the default page-size even if `--page-size=1` was given. # How to reproduce I don't know anything about linkers and discovered that while compiling rust code to wasm bytecode so it's what I'll describe. Setup : ```bash rustc -Vv rustc 1.88.0 (6b00bc388 2025-06-23) binary: rustc commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc commit-date: 2025-06-23 host: x86_64-unknown-linux-gnu release: 1.88.0 LLVM version: 20.1.5 wasm-ld --version LLD 21.0.0 (https://github.com/llvm/llvm-project.git 1b7cbe1f871ebe572e383a2531257b88168eea1b) # Compiled from source on 2.07.25 ``` ``` cargo new --lib wasm-ld-bug-test cd wasm-ld-bug-test ``` add ```toml [lib] crate-type=["cdylib", "rlib] ``` to the `Cargo.toml` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146679] [asan][win] The memory used for PoisonShadow should be created
Issue
146679
Summary
[asan][win] The memory used for PoisonShadow should be created
Labels
new issue
Assignees
Reporter
GkvJwa
Here is a [issue](https://github.com/llvm/llvm-project/issues/144355) on Win
Because the memory is not created when running to ```FastPoisonShadow->memset```, an access violation will be triggered under the debugger
As mentioned in the issue, msvc's asan does not have this problem, So I analyzed the asan version of msvc, there is indeed a big difference
The memory for ```PoisonShadow``` will be created
```
void __fastcall __asan::AsanMapUnmapCallback::OnMap(
__asan::AsanMapUnmapCallback *this,
unsigned __int64 p,
unsigned __int64 size)
{
__asan::AsanStats *CurrentThreadStats; // rax
_sanitizer_virtual_alloc(
(char *)_asan_shadow_memory_dynamic_address + (p >> 3),
(unsigned __int64)_asan_shadow_memory_dynamic_address
+ ((size + p - 8) >> 3)
- ((_QWORD)_asan_shadow_memory_dynamic_address
+ (p >> 3))
+ 1,
0x1000u,
4u);
__asan::PoisonShadow(p, size, 0xFAu);
CurrentThreadStats = __asan::GetCurrentThreadStats();
++CurrentThreadStats->mmaps;
CurrentThreadStats->mmaped += size;
}
-->
void AsanMapUnmapCallback::OnMap(uptr p, uptr size) const {
uptr shadow_beg = MEM_TO_SHADOW(p);
uptr shadow_end = MEM_TO_SHADOW(p + size - ASAN_SHADOW_GRANULARITY) + 1;
VirtualAlloc((LPVOID)shadow_beg, shadow_end - shadow_beg, MEM_COMMIT,
PAGE_READWRITE);
PoisonShadow(p, size, kAsanHeapLeftRedzoneMagic);
// Statistics.
AsanStats &thread_stats = GetCurrentThreadStats();
thread_stats.mmaps++;
thread_stats.mmaped += size;
}
```
To avoid exceptions in debugger
Of course, MSVC's ASAN also has many other logics
like
When calling PoisonShadow, _sanitizer_virtual_alloc is basically executed first
```
void __fastcall __asan::AsanThread::ClearShadowForThreadStackAndTLS(__asan::AsanThread *this)
{
unsigned __int64 stack_bottom; // rax
unsigned __int64 stack_top; // r8
unsigned __int64 tls_end; // rax
unsigned __int64 tls_begin; // rdi
unsigned __int64 v6; // rdi
unsigned __int64 v7; // rbx
stack_bottom = this->stack_bottom_;
stack_top = this->stack_top_;
if ( stack_top != stack_bottom )
{
_sanitizer_virtual_alloc(
(char *)_asan_shadow_memory_dynamic_address + (stack_bottom >> 3),
(unsigned __int64)_asan_shadow_memory_dynamic_address
+ ((stack_top - 8) >> 3)
- ((_QWORD)_asan_shadow_memory_dynamic_address
+ (stack_bottom >> 3))
+ 1,
0x1000u,
4u);
__asan::PoisonShadow(this->stack_bottom_, this->stack_top_ - this->stack_bottom_, 0);
}
tls_end = this->tls_end_;
```
rewritten VirtualAlloc
```
void *__fastcall _sanitizer_virtual_alloc(
void *lpAddress,
unsigned __int64 dwSize,
unsigned int flAllocationType,
unsigned int flProtect)
{
void *v5; // [rsp+40h] [rbp+8h] BYREF
unsigned __int64 v6; // [rsp+48h] [rbp+10h] BYREF
unsigned int v7; // [rsp+50h] [rbp+18h] BYREF
unsigned int v8; // [rsp+58h] [rbp+20h] BYREF
v8 = flProtect;
v7 = flAllocationType;
v6 = dwSize;
v5 = lpAddress;
return __sanitizer::IATOverwriteGuard(
"VirtualAlloc IAT entry overwritten.",
(void *(__fastcall *)(void *, unsigned __int64, unsigned int, unsigned int))VirtualAlloc,
&v5,
&v6,
&v7,
&v8);
}
```
Therefore, it may be better for asan to create the memory for PoisonShadow in advance on the windows, like MSVC does.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146735] [DirectX] Incorrect format metadata when using `Buffer` or `Buffer`
Issue 146735 Summary [DirectX] Incorrect format metadata when using `Buffer` or `Buffer` Labels backend:DirectX Assignees Reporter bogner HLSL allows `Buffer` and `RWBuffer` of `double`, `int64`, or 2-element vectors of the same, but when lowering these to DXIL they use 32-bit accesses to the buffer itself and convert the value as needed. However, we emit the format metadata for a buffer based on what's stored there, not how we use it, so for `Buffer In` we currently see from clang: ``` ; Name Type Format Dim ID HLSL Bind Count ; -- -- --- --- --- -- - ; Intexture f64 buf T0 t0 1 ``` This does not match dxc, which gives: ``` ; Name Type Format Dim ID HLSL Bind Count ; -- -- --- --- --- -- -- ; Intexture u32 buf T0 t0 1 ``` Note the `u32` format here. We need to make sure that `dxil::ResourceTypeInfo::getTyped()` has the correct `ElementTy` in these cases. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146743] llvm/Support/Error.h ODR design violation issue around error identity
Issue
146743
Summary
llvm/Support/Error.h ODR design violation issue around error identity
Labels
new issue
Assignees
Reporter
zbowling
Error.h and the base Error classes within have a long-standing fundamental design issue that results in a constant stream of ODR issues linking llvm in different ways that often blow in subtle runtime bugs. Some of these are also caught in ASAN builds of LLVM.
There is a 10-year-old smelly design pattern used across much of Error.h for comparing the memory address of a `static char ID` as a system of unique identity for error types.
Here is the current API design:
```
class LLVM_ABI ErrorInfoBase {
public:
...
// Returns the class ID for this type.
static const void *classID() { return &ID; }
...
// Check whether this instance is a subclass of the class identified by
// ClassID.
virtual bool isA(const void *const ClassID) const {
return ClassID == classID();
}
// Check whether this instance is a subclass of ErrorInfoT.
template bool isA() const {
return isA(ErrorInfoT::classID());
}
private:
...
static char ID;
```
The problem here is depending on how you compile, link, and use LLVM in various configurations, using static data members in a header, especially for address-based identity, often fails. The compiler is allowed to inline this static member into every implementation it compiles. It's why C++17 added static inline for this case but here that would be the opposite of what we want. While this pattern is fast and probably fine if you are fully statically compiling (in most cases) against LLVM, it is pretty brittle in certain static linking setups and very broken in most dynamic link setups against llvm.
In our use cases in modular, this breaks with how we statically link llvm/Support across multiple dylibs and use them together resulting in runtime ODR bugs comparing Error types, but it's also broken by how lldb builds upstream with how liblldb.so/dylib (which links llvm/Support) and how frontend tools (like lldb and lldb-dap) and lldb plugins all link the liblldb dso and also link llvm/Support directly themselves (statically or dynamically).
As LLVM becomes more friendly with dynamic linking, these Error classes should probably be redesigned around how they handle unique identity comparisons.
I can't think of a simple fix because whatever unique identity is used, it has to be safe across different linking setups and there are many and downstream users are doing unique things as well (like us) so it shouldn't prescribe a specific setup required with how it's linked to be able to function properly. If you want to use a memory comparison, any dynamic or static linker has to always have visibility across different linker setups and has to be able to de-dup. It might make sense to move a string comparison, maybe containing a GUID or some namespace-qualified string for global uniqueness of error subclasses?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146742] Missed optimization of strdup to malloc + memcpy if argument is known at compile time
Issue
146742
Summary
Missed optimization of strdup to malloc + memcpy if argument is known at compile time
Labels
new issue
Assignees
Reporter
BreadTom
[Clang godbolt](https://godbolt.org/z/5GM85jT3G)
[GCC godbolt](https://godbolt.org/z/afqarMj9n)
Clang 20.1 and GCC 15.1 missed optimizing strdup("Hello") to malloc then memcpy "Hello" like f0_fast().
Maybe useful if the string came from -D:
```
#define HELLO_WORLD "Hello world"
char *f0_slow (void)
{
return __builtin_strdup (HELLO_WORLD);
}
```
C source code
```
char *f0_fast (void)
{
char *ret_val = __builtin_malloc (strlen ("Hello") + 1);
if (ret_val)
__builtin_memcpy (ret_val, "Hello", strlen ("Hello") + 1);
return ret_val;
}
char *f0_slow (void)
{
return __builtin_strdup ("Hello");
}
```
LLVM IR
```
@.str = private unnamed_addr constant [6 x i8] c"Hello\00", align 1
define dso_local noalias noundef ptr @f0_fast() local_unnamed_addr {
entry:
%call = tail call dereferenceable_or_null(6) ptr @malloc(i64 noundef 6) #5
%tobool.not = icmp eq ptr %call, null
br i1 %tobool.not, label %if.end, label %if.then
if.then:
tail call void @llvm.memcpy.p0.p0.i64(ptr noundef nonnull align 1 dereferenceable(6) %call, ptr noundef nonnull align 1 dereferenceable(6) @.str, i64 6, i1 false)
br label %if.end
if.end:
ret ptr %call
}
declare noalias noundef ptr @malloc(i64 noundef) local_unnamed_addr #1
declare void @llvm.memcpy.p0.p0.i64(ptr noalias nocapture writeonly, ptr noalias nocapture readonly, i64, i1 immarg) #2
define dso_local noalias noundef ptr @f0_slow() local_unnamed_addr {
entry:
%call = tail call dereferenceable_or_null(6) ptr @strdup(ptr noundef nonnull @.str) #5
ret ptr %call
}
declare noalias ptr @strdup(ptr nocapture noundef readonly) local_unnamed_addr #4
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146693] [clang-tidy] suppress dump of disabled checks options when running `--dump-config`
Issue 146693 Summary [clang-tidy] suppress dump of disabled checks options when running `--dump-config` Labels enhancement, clang-tidy Assignees Reporter vbvictor When running `clang-tidy --dump-config`, the output includes `CheckOptions` for checks that are currently disabled in the `Checks` configuration. This creates unnecessary noise and can be confusing for users trying to understand their active configuration. Need to filter out disabled check options: Only show `CheckOptions` for checks that are actually enabled in the current `Checks` configuration Here is an example when running on LLVM codebase: `clang-tidy -p build --dump-config clang-tools-extra/clang-tidy/ClangTidy.cpp` ``` --- Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-const-correctness,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-misc-no-recursion,-misc-use-anonymous-namespace,readability-identifier-naming,-misc-include-cleaner' WarningsAsErrors: '' HeaderFileExtensions: - '' - h - hh - hpp - hxx ImplementationFileExtensions: - c - cc - cpp - cxx HeaderFilterRegex: '' ExcludeHeaderFilterRegex: '' FormatStyle: none User:victor CheckOptions: cert-arr39-c.WarnOnSizeOfCompareToConstant: 'false' cert-arr39-c.WarnOnSizeOfConstant: 'false' cert-arr39-c.WarnOnSizeOfIntegerExpression: 'false' cert-arr39-c.WarnOnSizeOfPointer: 'false' cert-arr39-c.WarnOnSizeOfPointerToAggregate: 'false' cert-arr39-c.WarnOnSizeOfThis: 'false' cert-dcl16-c.NewSuffixes: 'L;LL;LU;LLU' cert-err33-c.AllowCastToVoid: 'true' cert-err33-c.CheckedFunctions: '^::aligned_alloc;^::asctime_s;^::at_quick_exit;^::atexit;^::bsearch;^::bsearch_s;^::btowc;^::c16rtomb;^::c32rtomb;^::calloc;^::clock;^::cnd_broadcast;^::cnd_init;^::cnd_signal;^::cnd_timedwait;^::cnd_wait;^::ctime_s;^::fclose;^::fflush;^::fgetc;^::fgetpos;^::fgets;^::fgetwc;^::fopen;^::fopen_s;^::fprintf;^::fprintf_s;^::fputc;^::fputs;^::fputwc;^::fputws;^::fread;^::freopen;^::freopen_s;^::fscanf;^::fscanf_s;^::fseek;^::fsetpos;^::ftell;^::fwprintf;^::fwprintf_s;^::fwrite;^::fwscanf;^::fwscanf_s;^::getc;^::getchar;^::getenv;^::getenv_s;^::gets_s;^::getwc;^::getwchar;^::gmtime;^::gmtime_s;^::localtime;^::localtime_s;^::malloc;^::mbrtoc16;^::mbrtoc32;^::mbsrtowcs;^::mbsrtowcs_s;^::mbstowcs;^::mbstowcs_s;^::memchr;^::mktime;^::mtx_init;^::mtx_lock;^::mtx_timedlock;^::mtx_trylock;^::mtx_unlock;^::printf_s;^::putc;^::putwc;^::raise;^::realloc;^::remove;^::rename;^::scanf;^::scanf_s;^::setlocale;^::setvbuf;^::signal;^::snprintf;^::snprintf_s;^::sprintf;^::sprintf_s;^::sscanf;^::sscanf_s;^::strchr;^::strerror_s;^::strftime;^::strpbrk;^::strrchr;^::strstr;^::strtod;^::strtof;^::strtoimax;^::strtok;^::strtok_s;^::strtol;^::strtold;^::strtoll;^::strtoul;^::strtoull;^::strtoumax;^::strxfrm;^::swprintf;^::swprintf_s;^::swscanf;^::swscanf_s;^::thrd_create;^::thrd_detach;^::thrd_join;^::thrd_sleep;^::time;^::timespec_get;^::tmpfile;^::tmpfile_s;^::tmpnam;^::tmpnam_s;^::tss_create;^::tss_get;^::tss_set;^::ungetc;^::ungetwc;^::vfprintf;^::vfprintf_s;^::vfscanf;^::vfscanf_s;^::vfwprintf;^::vfwprintf_s;^::vfwscanf;^::vfwscanf_s;^::vprintf_s;^::vscanf;^::vscanf_s;^::vsnprintf;^::vsnprintf_s;^::vsprintf;^::vsprintf_s;^::vsscanf;^::vsscanf_s;^::vswprintf;^::vswprintf_s;^::vswscanf;^::vswscanf_s;^::vwprintf_s;^::vwscanf;^::vwscanf_s;^::wcrtomb;^::wcschr;^::wcsftime;^::wcspbrk;^::wcsrchr;^::wcsrtombs;^::wcsrtombs_s;^::wcsstr;^::wcstod;^::wcstof;^::wcstoimax;^::wcstok;^::wcstok_s;^::wcstol;^::wcstold;^::wcstoll;^::wcstombs;^::wcstombs_s;^::wcstoul;^::wcstoull;^::wcstoumax;^::wcsxfrm;^::wctob;^::wctrans;^::wctype;^::wmemchr;^::wprintf_s;^::wscanf;^::wscanf_s;' cert-oop54-cpp.WarnOnlyIfThisHasSuspiciousField: 'false' cert-str34-c.DiagnoseSignedUnsignedCharComparisons: 'false' cppcoreguidelines-non-private-member-variables-in-classes.IgnoreClassesWithAllMemberVariablesBeingPublic: 'true' google-readability-braces-around-statements.ShortStatementLines: '1' google-readability-function-size.StatementThreshold: '800' google-readability-namespace-comments.ShortNamespaceLines: '10' google-readability-namespace-comments.SpacesBeforeComments: '2' llvm-else-after-return.WarnOnConditionVariables: 'false' llvm-else-after-return.WarnOnUnfixable: 'false' llvm-namespace-comment.ShortNamespaceLines: '1' llvm-namespace-comment.SpacesBeforeComments: '1' llvm-qualified-auto.AddConstToQualified: 'false' misc-coroutine-hostile-raii.RAIITypesList: 'std::lock_guard;std::scoped_lock' misc-coroutine-hostile-raii.SafeAwaitableList: '' misc-header-include-cycle.IgnoredFilesList: '' misc-throw-by-value-catch-by-reference.CheckThrowTemporaries: 'true' misc-throw-by-value-catch-by-reference.MaxSize: '18446744073709551615'
[llvm-bugs] [Bug 146722] [LLD] Linker crashes when trying to parse ':ALIGN'
Issue
146722
Summary
[LLD] Linker crashes when trying to parse ':ALIGN'
Labels
lld
Assignees
Reporter
parth-07
If there is no space between ":" and ALIGN, linker will misparse the following script:
```bash
SECTIONS
{
S :ALIGN(4096) {}
}
```
Moreover, when recovering from this error, it will enter infinite recursion and overflow the stack.
Thank you @quic-akaryaki for finding this issue.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146652] [Clang][TBAA] Clang's TBAA is too conservative than GCC when long type cast?
Issue
146652
Summary
[Clang][TBAA] Clang's TBAA is too conservative than GCC when long type cast?
Labels
llvm:optimizations,
missed-optimization,
TBAA
Assignees
Reporter
hstk30-hw
https://godbolt.org/z/cnjvbzj9a
```typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef signed short int16_t;
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
typedef long int intptr_t;
typedef struct MBuf {
void *buf_addr;
union {
void *userdata;
uint64_t udata64;
};
} __attribute__((__aligned__(64))) MBuf_t;
typedef struct MBuf MBuf;
typedef union {
struct {
uint32_t srcIp;
uint32_t dstIp;
uint16_t srcPort;
uint16_t dstPort;
uint16_t vrfIndex;
uint8_t protocol;
} detail;
} FlowKey;
typedef struct {
union {
uint8_t u6_ucaddr[16];
uint16_t u6_usaddr[8];
uint32_t u6_uladdr[4];
uint64_t u6_ulladdr[2];
} u6_addr;
} In6Addr;
typedef struct {
uint16_t vsys_index;
FlowKey packet_key;
uint16_t dst_nat_port;
uint32_t dst_nat_ip;
struct {
In6Addr src_ip;
In6Addr dst_ip;
} ipv6_pkt_info;
} __attribute__((__aligned__(64))) MbufContext;
typedef struct {
_Bool is_ipv6;
union {
uint32_t v4;
In6Addr v6;
} addr;
} ip_addr_t;
typedef struct fc_fwd_flow_info_s {
ip_addr_t src_ip;
ip_addr_t src_natip;
ip_addr_t dst_ip;
ip_addr_t dst_natip;
uint16_t vsys_id;
uint16_t vrf_index;
uint16_t src_port;
uint16_t dst_port;
uint16_t dst_natport;
uint8_t proto;
uint8_t nat_type;
} flow_info_t;
enum PORT_TYPE {
TYPE_ONE,
TYPE_TWO,
TYPE_THREE,
TYPE_FOUR,
TYPE_FIVE,
TYPE_MAX
};
void foo(MBuf *mbuf, flow_info_t *info)
{
info->vsys_id = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->vsys_index);
info->vrf_index = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.vrfIndex);
info->proto = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.protocol);
info->src_port = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.srcPort);
info->dst_port = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.dstPort);
info->dst_natport = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->dst_nat_port);
info->dst_natip.addr.v4 = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->dst_nat_ip);
switch (info->nat_type) {
case TYPE_ONE: {
info->src_ip.addr.v6 = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->ipv6_pkt_info.src_ip);
info->dst_ip.addr.v6 = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->ipv6_pkt_info.dst_ip);
break;
}
case TYPE_TWO:
info->src_ip.addr.v4 = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.srcIp);
info->dst_ip.addr.v4 = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.dstIp);
break;
case TYPE_THREE:
case TYPE_FOUR:
default: {
info->src_ip.addr.v4 = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.srcIp);
info->dst_ip.addr.v4 = (((MbufContext *)((uint8_t *)((MBuf*)(intptr_t)(mbuf))->userdata))->packet_key.detail.dstIp);
break;
}
}
}
```
the TBAA matedata is `omnipotent char` cause the cast path have `uint8_t *`,
I'm not familiar with GCC's TBAA, but I think there are potential for performance improvement.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146648] IR after optimization increases of code instructions
Issue 146648 Summary IR after optimization increases of code instructions Labels new issue Assignees Reporter r00t0s The code before optimization is more shorter than after optimization, when I use -O1 code looks correct, but when I use -O2 -O3 looks so bad, for example GCC don't have this problem Example: -O1 https://godbolt.org/z/9nq3hd8ve After use -O2 or -O3 https://godbolt.org/z/xYeKzveze ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146646] [HIP] User provided deduction guides are considered as __host__ functions
Issue
146646
Summary
[HIP] User provided deduction guides are considered as __host__ functions
Labels
new issue
Assignees
Reporter
MiroPalmu
With clang 20.1.6 following fails to compile ( `clang++ -c -x hip foo.cpp`):
```cpp
#include
template
struct Foo {
template
constexpr Foo(U...) {}
};
template
Foo(U...) -> Foo;
__global__ void f() {
Foo(1, 2, 3);
}
```
with error message:
```
foo.cpp:11:5: error: no viable constructor or deduction guide for deduction of template arguments of 'Foo'
11 | Foo(1, 2, 3);
| ^
foo.cpp:8:1: note: candidate function not viable: call to __host__ function from __global__ function
8 | Foo(U...) -> Foo;
| ^
foo.cpp:4:15: note: candidate template ignored: couldn't infer template argument ''
4 | constexpr Foo(U...) {}
| ^
foo.cpp:4:15: note: implicit deduction guide declared as 'template Foo(U ...) -> Foo'
foo.cpp:2:8: note: candidate function template not viable: requires 1 argument, but 3 were provided
2 | struct Foo {
|^~~
foo.cpp:2:8: note: implicit deduction guide declared as 'template Foo(Foo) -> Foo'
1 error generated when compiling for gfx906.
```
However if the deduction guide is removed, then it compiles:
```cpp
#include
template
struct Foo {
template
constexpr Foo(U...) {}
};
__global__ void f() {
Foo<3>(1, 2, 3);
}
```
Potentially relevant issue: #69366
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146658] [lld] crash linking OSS https://github.com/Ranchero-Software/NetNewsWire
Issue
146658
Summary
[lld] crash linking OSS https://github.com/Ranchero-Software/NetNewsWire
Labels
lld
Assignees
Reporter
johnno1962
Hi,
I'm seeing a crash linking this Open Source project https://github.com/Ranchero-Software/NetNewsWire during linking. The crash occurs here in `lld/MachO/SyntheticSections.cpp` building of main. `*reloc` is returned nil inside the loop. I'm working with the source at the moment, if you have any suggestions I could try or information I can gather let me know as I'd like to see if I can fix this.
```
void ObjCMethListSection::setUp() {
for (const ConcatInputSection *isec : inputs) {
uint32_t structSizeAndFlags = 0, structCount = 0;
readMethodListHeader(isec->data.data(), structSizeAndFlags, structCount);
uint32_t originalStructSize = structSizeAndFlags & structSizeMask;
// Method name is immediately after header
uint32_t methodNameOff = methodListHeaderSize;
// Loop through all methods, and ensure a selref for each of them exists.
while (methodNameOff < isec->data.size()) {
const Reloc *reloc = isec->getRelocAt(methodNameOff);
assert(reloc && "Relocation expected at method list name slot");
StringRef methname = reloc->getReferentString();
if (!ObjCSelRefsHelper::getSelRef(methname))
ObjCSelRefsHelper::makeSelRef(methname);
// Jump to method name offset in next struct
methodNameOff += originalStructSize;
}
}
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146760] [mlir][amdgpu][docs] Add op examples to dialect docs
Issue 146760 Summary [mlir][amdgpu][docs] Add op examples to dialect docs Labels mlir Assignees Reporter kuhar The amdgpu dialect docs contain op description and auto-generated syntax but not actual examples. We should improve dialect documentation by adding an example(s) for each op. Other dialects like [arith](https://mlir.llvm.org/docs/Dialects/ArithOps/) or [SPIR-V](https://mlir.llvm.org/docs/Dialects/SPIR-V/) can be referenced for inspiration on how to provide examples, e.g.: > Example: > ```mlir > // Scalar addition. > %a = arith.addi %b, %c : i64 > > // Scalar addition with overflow flags. > %a = arith.addi %b, %c overflow : i64 > > // SIMD vector element-wise addition. > %f = arith.addi %g, %h : vector<4xi32> > > // Tensor element-wise addition. > %x = arith.addi %y, %z : tensor<4x?xi8> > ``` We should be able to extract examples by looking at op tests in https://github.com/llvm/llvm-project/blob/main/mlir/test/Dialect/AMDGPU/ops.mlir ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146798] [clangd] Crashing when running on Mac and Windows paths are found in compile_commands.json, and vice versa
Issue
146798
Summary
[clangd] Crashing when running on Mac and Windows paths are found in compile_commands.json, and vice versa
Labels
new issue
Assignees
Reporter
Iritscen
Due to an unusual attempt on my part to make the same compile_commands.json file work in both macOS and Windows, I added the same set of source files to the JSON file twice, with the paths to the files on my Mac and on my Windows PC. This was allowed when I was using Apple clangd 17.0.0 as my language server, but it crashes in clangd 19.1.4 on Windows and a self-built clangd 21.0.0git on macOS. Obviously it would be preferable to get an error message saying that a Windows path is not allowed on Mac and a Mac path not allowed in Windows, if it's the case that clangd is not supposed to support this sort of cross-platform kludge in compile_commands.json.
The minimal repro case for this issue is to make a compile_commands.json file in your source directory and place a single listing in it for a file, using some arbitrary path starting with "C:/" if on Mac, or starting with "/" if on Windows, and then run clangd on a source file in that directory (e.g. `clangd --check=source/main.cpp`). When clangd finds the JSON file it will blow up. Example file for causing the crash on a Mac:
```
[
{
"directory": "C:/my/path/to/source",
"command": "clang++ -std=c++20 -c -o VSCode/build/main.o ./source/main.cpp",
"file": "main.cpp"
}
]
```
Error message:
`Assertion failed: (llvm::sys::path::is_absolute(Path)), function absoluteParent, file Path.cpp, line 23.`
Stack trace:
```
#0 0x00010474b938 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x1004f7938)
#1 0x00010474bf30 PrintStackTraceSignalHandler(void*) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x1004f7f30)
#2 0x000104749bb4 llvm::sys::RunSignalHandlers() (/my/path/to/llvm-project/build/Debug/bin/clangd+0x1004f5bb4)
#3 0x00010474d494 SignalHandler(int, __siginfo*, void*) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x1004f9494)
#4 0x000190b68624 (/usr/lib/system/libsystem_platform.dylib+0x1804ac624)
#5 0x000190b2e88c (/usr/lib/system/libsystem_pthread.dylib+0x18047288c)
#6 0x000190a37c60 (/usr/lib/system/libsystem_c.dylib+0x18037bc60)
#7 0x000190a36eec (/usr/lib/system/libsystem_c.dylib+0x18037aeec)
#8 0x0001075313b0 clang::clangd::absoluteParent(llvm::StringRef) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x1032dd3b0)
#9 0x000106fec18c clang::clangd::(anonymous namespace)::actOnAllParentDirectories(llvm::StringRef, llvm::function_ref) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102d9818c)
#10 0x000106ff0188 clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::Filter::addParents(llvm::StringRef) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102d9c188)
#11 0x000106fecae8 clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::Filter::filter(std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>>, std::__1::atomic&) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102d98ae8)
#12 0x000106fec804 clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::process(clang::clangd::DirectoryBasedGlobalCompilationDatabase::CDBLookupResult const&) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102d98804)
#13 0x000106ffcc70 clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::run() (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102da8c70)
#14 0x000106ffcb54 clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::BroadcastThread(clang::clangd::DirectoryBasedGlobalCompilationDatabase&)::'lambda'()::operator()() const (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102da8b54)
#15 0x000106ffcb04 decltype(std::declval()()) std::__1::__invoke[abi:dn190102](clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::BroadcastThread(clang::clangd::DirectoryBasedGlobalCompilationDatabase&)::'lambda'()&&) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102da8b04)
#16 0x000106ffcae0 void std::__1::__thread_execute[abi:dn190102]>, clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::BroadcastThread(clang::clangd::DirectoryBasedGlobalCompilationDatabase&)::'lambda'()>(std::__1::tuple>, clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThread::BroadcastThread(clang::clangd::DirectoryBasedGlobalCompilationDatabase&)::'lambda'()>&, std::__1::__tuple_indices<>) (/my/path/to/llvm-project/build/Debug/bin/clangd+0x102da8ae0)
#17 0x000106ffc81c void* std::__1::__thread_proxy[abi:dn190102]>, clang::clangd::DirectoryBasedGlobalCompilationDatabase::BroadcastThr
[llvm-bugs] [Bug 146642] [InstCombine] Missed optimization for icmp of select with constants and invertible binop
Issue
146642
Summary
[InstCombine] Missed optimization for icmp of select with constants and invertible binop
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
nikic
We currently fail to fold variations of this pattern:
https://alive2.llvm.org/ce/z/tT3yNU
```llvm
define i1 @src(i64 %a, i1 %c) {
%idx = shl nsw i64 %a, 3
%sel = select i1 %c, i64 8, i64 0
%cmp = icmp eq i64 %idx, %sel
ret i1 %cmp
}
define i1 @tgt(i64 %a, i1 %c) {
%sel = select i1 %c, i64 1, i64 0
%cmp = icmp eq i64 %a, %sel
ret i1 %cmp
}
```
The underlying pattern here is something like `f(x) == y` converted to `x == f^-1(y)` where f invertible and `f^-1(y)` folds because the shift arms are constant.
>From https://github.com/dtcxzyw/llvm-opt-benchmark/pull/2524/files/9ca17b717ceea34b52263bf8b20cf12ad02cd4fd#r2179220735.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146665] Request Commit Access For cowardsa
Issue 146665 Summary Request Commit Access For cowardsa Labels infra:commit-access-request Assignees Reporter cowardsa ### Why Are you requesting commit access ? A research fellow at University College London, contributing to the CIRCT project, specifically extending synthesis capabilities in collaboration with SiFive and Grosser Lab (University of Cambridge). Have merged the following PRs into CIRCT: - https://github.com/llvm/circt/pull/8497 - https://github.com/llvm/circt/pull/8457 - https://github.com/llvm/circt/pull/8425 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146668] [AVR] cannot find -lgcc when using Arduino avr-ld version
Issue 146668 Summary [AVR] cannot find -lgcc when using Arduino avr-ld version Labels new issue Assignees Reporter tomtor ``` tom@swan-ubu20:~/src/rust/arduino-hal-test/bug$ which avr-ld /home/tom/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-ld tom@swan-ubu20:~/src/rust/arduino-hal-test/bug$ clang -v -target avr-none -mmcu=attiny84 bad_copy_data.c clang version 21.0.0git (g...@github.com:tomtor/llvm-project.git ee414e35047c588daba1ee62e8291ea171700f43) Target: avr-none Thread model: posix InstalledDir: /media/scratch/rust/llvm-project/build/bin Build config: +unoptimized, +assertions "/media/scratch/rust/llvm-project/build/bin/clang-21" -cc1 -triple avr-none -emit-obj -dumpdir a- -disable-f ree -clear-ast-before-backend -main-file-name bad_copy_data.c -mrelocation-model static -mframe-pointer=all - fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -fno-use-init-array -fno-use-cxa-atexit -target-cpu attiny84 -debugger-tuning=gdb -fdebug-compilation-dir=/home/tom/src/rust/arduino-hal-test/bug -v -fcoverage-compilation-dir=/home/tom/src/rust/arduino-hal-test/bug -resource-dir /media/scratch/rust/llvm-pr oject/build/lib/clang/21 -internal-isystem /usr/lib/avr/include -ferror-limit 19 -fmessage-length=109 -fgnuc- version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -faddrsig -o /tmp/bad_copy_data-274bb1.o -x c bad_c opy_data.c clang -cc1 version 21.0.0git based upon LLVM 21.0.0git default target x86_64-unknown-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/lib/avr/include /usr/local/include /media/scratch/rust/llvm-project/build/lib/clang/21/include /usr/include End of search list. "/home/tom/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-ld" -o a.out --gc-sec tions -L/usr/lib/avr/lib/avr25 -L/avr25 --defsym=__DATA_REGION_ORIGIN__=0x800060 --start-group -l:crtattiny84 .o -lgcc -lm -lc -lattiny84 /tmp/bad_copy_data-274bb1.o --end-group --relax -mavr25 /home/tom/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-ld: cannot find -lgcc clang: error: avr-ld command failed with exit code 1 (use -v to see invocation) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146769] [ConstantFolding][Intrinsics] Missed folding of poison in a few trivially vectorizable intrinsics
Issue 146769 Summary [ConstantFolding][Intrinsics] Missed folding of poison in a few trivially vectorizable intrinsics Labels new issue Assignees Reporter badumbatish Per https://godbolt.org/z/68dTozY9r, we're not folding a few intrinsics that's trivially vectorizable. Below's a list of folded and non-folded intrinsics (from godbolt) ``` ; Intrinsic::abs: CORRECT // Begin integer bit-manipulation. ; Intrinsic::bswap: CORRECT ; Intrinsic::bitreverse: CORRECT ; Intrinsic::ctpop: CORRECT ; Intrinsic::ctlz: CORRECT ; Intrinsic::cttz: CORRECT ; Intrinsic::fshl: CORRECT ; Intrinsic::fshr: CORRECT ; Intrinsic::smax: CORRECT ; Intrinsic::smin: CORRECT ; Intrinsic::umax: CORRECT ; Intrinsic::umin: CORRECT ; Intrinsic::sadd_sat: CORRECT ; Intrinsic::ssub_sat: CORRRECY ; Intrinsic::uadd_sat: CORRECT ; Intrinsic::usub_sat: CORRECT ; Intrinsic::smul_fix: CORRECT ; Intrinsic::smul_fix_sat: CORRECT ; Intrinsic::umul_fix: MISS ; Intrinsic::umul_fix_sat: MISS ; Intrinsic::sqrt: CORRECT // Begin floating-point. ; Intrinsic::asin: MISS ; Intrinsic::acos: MISS ; Intrinsic::atan: MISS ; Intrinsic::atan2: MISS ; Intrinsic::sin: MISS ; Intrinsic::cos: MISS ; Intrinsic::sincos: MISS ; Intrinsic::sincospi: MISS ; Intrinsic::tan: MISS ; Intrinsic::sinh: MISS ; Intrinsic::cosh: MISS ; Intrinsic::tanh: MISS ; Intrinsic::exp: MISS ; Intrinsic::exp10: MISS ; Intrinsic::exp2: MISS ; Intrinsic::log: MISS ; Intrinsic::log10: MISS ; Intrinsic::log2: MISS ; Intrinsic::fabs: CORRECT ; Intrinsic::minnum: CORRECT ; Intrinsic::maxnum: CORRECT ; Intrinsic::minimum: CORRECT ; Intrinsic::maximum: CORRECT ; Intrinsic::minimumnum: CORRECT ; Intrinsic::maximumnum: CORRECT ; Intrinsic::modf: MISS ; Intrinsic::copysign: CORRECT ; Intrinsic::floor: MISS ; Intrinsic::ceil: MISS ; Intrinsic::trunc: MISS ; Intrinsic::rint: MISS ; Intrinsic::nearbyint: MISS ; Intrinsic::round: MISS ; Intrinsic::roundeven: MISS ; Intrinsic::pow: MISS ; Intrinsic::fma: CORRECT ; Intrinsic::fmuladd: CORRECT ; Intrinsic::is_fpclass: CORRECT ; Intrinsic::powi: MISS ; Intrinsic::canonicalize: CORRECT ; Intrinsic::fptosi_sat: CORRECT ; Intrinsic::fptoui_sat: CORRECT ; Intrinsic::lrint: MISS ; Intrinsic::llrint: MISS ; Intrinsic::ucmp: CORRECT ; Intrinsic::scmp: CORRECT ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146770] clang-repl Typing an error in a formula may be followed by an unresolved while linking error
Issue
146770
Summary
clang-repl Typing an error in a formula may be followed by an unresolved while linking error
Labels
new issue
Assignees
Reporter
guitargeek
In some cases, `clang-repl` doesn't recover correctly from input errors, resulting in a state where unexpected linker errors can happen in correct statements given afterwards.
It seems that this kind of error occurs only with "pow".
@vgvassilev @Vipul-Cariappa
Reproducer (I ran it with the LLVM 20 packages in NixOS):
```txt
LLVM (http://llvm.org/):
LLVM version 20.1.6
Optimized build.
```
```txt
clang-repl> #include
clang-repl> #include
clang-repl> (10-)*std::pow(2,2);
In file included from <<< inputs >>>:1:
input_line_3:1:5: error: expected _expression_
1 | (10-)*std::pow(2,2);
| ^
error: Parsing failed.
clang-repl> std::cout << ((10-1)*std::pow(2,2)) << std::endl;
JIT session error: Symbols not found: [ _ZSt3powIiiEN9__gnu_cxx9__promoteIDTplcvNS1_IT_Xsr3std12__is_integerIS2_EE7__valueEE6__typeELi0EcvNS1_IT0_Xsr3std12__is_integerIS5_EE7__valueEE6__typeELi0EEXsr3std12__is_integerIS8_EE7__valueEE6__typeES2_S5_ ]
error: Failed to materialize symbols: { (main, { $.incr_module_3.__inits.0, __orc_init_func.incr_module_3 }) }
clang-repl>
```
What is expected:
```txt
clang-repl> #include
clang-repl> #include
clang-repl> (10-)*std::pow(2,2);
In file included from <<< inputs >>>:1:
input_line_3:1:5: error: expected _expression_
1 | (10-)*std::pow(2,2);
| ^
error: Parsing failed.
clang-repl> std::cout << ((10-1)*std::pow(2,2)) << std::endl;
36
clang-repl>
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146771] [C++20][Modules][ABI] Silent bad codegen in module with TU-local exposure
Issue
146771
Summary
[C++20][Modules][ABI] Silent bad codegen in module with TU-local exposure
Labels
new issue
Assignees
Reporter
barcharcraz
consider:
mod1.cppm
```c++
export module mod1;
static int func1_internal() { return 4;}
export inline int func2_external() { return func1_internal(); }
```
main.cpp
```c++
import mod1;
static int func1_internal() {
return 5;
}
int main() {
return func2_external() + func1_internal();
}
```
this program returns "8" when compiled with clang.
This code is ill-formed, because `func2_external()` exposes the TU-local `func1_internal()`, but clang doesn't diagnose it.
Instead of diagnosing clang instead generates bad code, emitting code for the definition of func1_internal inside mod1.cppm when compiling the main.cpp TU and emitting no code for "func1_internal()" inside main.
Sidenote: right now it seems like just adding inline is enough to cause func2_external() to be emitted as a weak symbol in importing TUs, which isn't really ideal, it could just as well still be a strong extern symbol emitted inside mod1's associated object file.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146765] [clang-tidy] add new option `--(dump/create)-default-config`
Issue 146765 Summary [clang-tidy] add new option `--(dump/create)-default-config` Labels enhancement, clang-tidy Assignees Reporter vbvictor After completion of https://github.com/llvm/llvm-project/issues/146482, there would be no default checks enable, which can potentially confuse users. We should provide an easy way to start using clang-tidy for new users. I propose a new option `--dump-default-config` or `--create-default-config`. This option will create a `.clang-tidy` config with some checks enabled by default. The default config will be a good start for users to "just run analysis" and later explore more checks. The list of default checks is largely debatable, possible a mixture of `bugprone`, `modernize`, `misc` and `performace` that has a low number of false positives. Alternative solution suggested by @nicovank: If no checks are enabled, the default config should just be used directly. Maybe adding warnings saying 1. the default config/checks will be used and 2. use `--dump-default-config` to get started with a custom configuration file in that directory. It's better user experience to just run with the default config immediately rather than add one setup step. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146781] [Infrastructure] flang/test/Semantics/windows.f90 failing with "RUN: at line 1 has no command after substitutions"
Issue 146781 Summary [Infrastructure] flang/test/Semantics/windows.f90 failing with "RUN: at line 1 has no command after substitutions" Labels infrastructure, flang Assignees Reporter dpaoliello See build: Test is failing for Linux only: ``` 2025-07-02T18:03:40.9385241Z FAIL: Flang :: Semantics/windows.f90 (3463 of 3566) 2025-07-02T18:03:40.9385789Z TEST 'Flang :: Semantics/windows.f90' FAILED 2025-07-02T18:03:40.9386277Z Exit Code: 1 2025-07-02T18:03:40.9386441Z 2025-07-02T18:03:40.9386576Z Command Output (stdout): 2025-07-02T18:03:40.9386889Z -- 2025-07-02T18:03:40.9387125Z --- 2025-07-02T18:03:40.9387366Z +++ 2025-07-02T18:03:40.9387633Z @@ -0,0 +1,2 @@ 2025-07-02T18:03:40.9387801Z 2025-07-02T18:03:40.9388091Z expect at 6: User IDs do not exist on Windows. This function will always return 1 2025-07-02T18:03:40.9388756Z expect at 11: Group IDs do not exist on Windows. This function will always return 1 2025-07-02T18:03:40.9389166Z 2025-07-02T18:03:40.9389319Z FAIL 2025-07-02T18:03:40.9389459Z 2025-07-02T18:03:40.9389549Z -- 2025-07-02T18:03:40.9389783Z Command Output (stderr): 2025-07-02T18:03:40.9390099Z -- 2025-07-02T18:03:40.9390396Z RUN: at line 1 has no command after substitutions 2025-07-02T18:03:40.9392544Z "/usr/bin/python3" /home/gha/actions-runner/_work/llvm-project/llvm-project/flang/test/Semantics/test_errors.py /home/gha/actions-runner/_work/llvm-project/llvm-project/flang/test/Semantics/windows.f90 /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/flang --target=aarch64-pc-windows-msvc -Werror # RUN: at line 2 2025-07-02T18:03:40.9396750Z + /usr/bin/python3 /home/gha/actions-runner/_work/llvm-project/llvm-project/flang/test/Semantics/test_errors.py /home/gha/actions-runner/_work/llvm-project/llvm-project/flang/test/Semantics/windows.f90 /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/flang --target=aarch64-pc-windows-msvc -Werror 2025-07-02T18:03:40.9398458Z 2025-07-02T18:03:40.9398563Z -- 2025-07-02T18:03:40.9398690Z 2025-07-02T18:03:40.9398786Z ``` The RUN command is contained in an `%if` block, so if there is no x86_64 or aarch64 registered targets, then it will result in an empty command: https://github.com/llvm/llvm-project/blob/551d6ddaa3810749ecae33f65759870b78b9a86a/flang/test/Semantics/windows.f90#L1-L2 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
