[llvm-bugs] [Bug 80806] [clang++] warning: stack frame size (11850326592728) exceeds limit (4294967295) in 'main'
Issue
80806
Summary
[clang++] warning: stack frame size (11850326592728) exceeds limit (4294967295) in 'main'
Labels
clang
Assignees
Reporter
stsp
Compiling this code with clang++-16 and 17:
```
#include
#include
#include
template
struct offset_of {
constexpr operator size_t() const {
return (std::uintptr_t)&(static_cast(nullptr)->*M);
}
};
template
struct B {
char aa[10];
static const int off = offset_of();
};
struct A {
char a;
char _mark[0];
B b;
};
int main()
{
A a;
std::cout << "size " << sizeof(A) << " off " << a.b.off << std::endl;
return 0;
}
```
gives this:
```
warning: stack frame size (11812651990584) exceeds limit (4294967295) in 'main' [-Wframe-larger-than]
23 | int main()
| ^
1 warning generated.
```
That looks wrong, and gcc-g++ doesn't say
anything of that kind when compiling this.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80807] flang/lib/Semantics/data-to-inits.cpp:523:Suspicious condition
Issue
80807
Summary
flang/lib/Semantics/data-to-inits.cpp:523:Suspicious condition
Labels
flang
Assignees
Reporter
dcb314
Static analyser cppcheck says:
flang/lib/Semantics/data-to-inits.cpp:523:13: warning: Suspicious condition. The result of find() is an iterator, but it is not properly checked. [stlIfFind]
Source code is
if (std::find_if(
directs.begin(), directs.end(), [](const Symbol &component) {
return !IsAllocatable(component) &&
HasDeclarationInitializer(component);
})) {
Checking for != 0 looks wrong because != last should be IMHO tested for.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80808] Backport fix for compiler-rt build on mingw
Issue 80808 Summary Backport fix for compiler-rt build on mingw Labels new issue Assignees Reporter nikic /cherry-pick dd22140e21f2ef51cf031354966a3d41c191c6e7 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80831] TLS with large code model on x86_64-apple-darwin asserts
Issue
80831
Summary
TLS with large code model on x86_64-apple-darwin asserts
Labels
backend:X86,
llvm:crash
Assignees
Reporter
nikic
```llvm
target triple = "x86_64-apple-macosx10.12.0"
@g = external thread_local global i8
define ptr @test() {
ret ptr @g
}
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"Code Model", i32 4}
```
Results in:
```
llc: /home/npopov/repos/llvm-project/llvm/lib/Target/X86/X86ISelLowering.cpp:35071: MachineBasicBlock *llvm::X86TargetLowering::EmitLoweredTLSCall(MachineInstr &, MachineBasicBlock *) const: Assertion `MI.getOperand(3).isGlobal() && "This should be a global"' failed.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80836] Floating point exception with loop-vectorize
Issue
80836
Summary
Floating point exception with loop-vectorize
Labels
new issue
Assignees
Reporter
TatyanaDoubts
Run opt with -passes=loop-vectorize
https://godbolt.org/z/s3PWY3vhE
Test.ll
```
; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define ptr addrspace(1) @wombat(i64 %arg, ptr addrspace(1) %arg1) gc "statepoint-example" {
bb:
br label %bb2
bb2: ; preds = %bb4, %bb
br label %bb3
bb3: ; preds = %bb3, %bb2
%phi = phi i64 [ 0, %bb2 ], [ %add, %bb3 ]
%add = add i64 %phi, 1
%load = load i8, ptr addrspace(1) %arg1, align 1
%shl = shl i64 0, 0
store i16 0, ptr addrspace(1) null, align 2
%icmp = icmp ult i64 %phi, %arg
br i1 %icmp, label %bb3, label %bb4
bb4: ; preds = %bb3
br i1 false, label %bb5, label %bb2, !prof !0
bb5: ; preds = %bb4
ret ptr addrspace(1) null
}
!0 = !{!"branch_weights", i32 1, i32 -1}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80843] Please backport 62c352e13c14 to release/18.x
Issue 80843 Summary Please backport 62c352e13c14 to release/18.x Labels new issue Assignees Reporter zahiraam In https://github.com/llvm/llvm-project/pull/76873 a warning was added when the macros INFINITY and NAN are used in binary expressions. But that generated some redundant warnings. https://github.com/llvm/llvm-project/pull/80290 fixes that. /cherry-pick https://github.com/llvm/llvm-project/commit/62c352e13c145b5606ace88ecbe9164ff011b5cf ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80844] Backport 3d186a7 to release/18.x
Issue 80844 Summary Backport 3d186a7 to release/18.x Labels new issue Assignees Reporter sdesmalen-arm I'd like to request #80681 to be backported to the release/18.x branch. /cherry-pick 3d186a77cf1aa979014a6443cb423a633c167d9f ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80850] Create readability-math-missing-parentheses check
Issue
80850
Summary
Create readability-math-missing-parentheses check
Labels
clang-tidy,
check-request
Assignees
Reporter
PiotrZSL
I'm adding this here so, i woudn't forget.
Create check that detect missing () around mathematical expressions when operators of different priority are used.
```
int main()
{
return 2 + 2 * 2;
}
```
Should be:
```
int main()
{
return 2 + (2 * 2);
}
```
Similar thing for other math operators.
Main purpose is to explicitly show evaluation order.
Consider adding option to skip constructions that properly handled from left to right like: `2 * 2 + 2`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80852] Create readability-logic-missing-parentheses check
Issue 80852 Summary Create readability-logic-missing-parentheses check Labels clang-tidy, check-request Assignees Reporter PiotrZSL I'm adding this here so, i wouldn't forget. Create check that detect missing () around logical expressions when operators of different priority are used. ``` x && y || z; ``` Should be: ``` (x && y) || z; ``` Main purpose is to explicitly show evaluation order. Add option to ignore short expressions, as this will be way useful when many operators are used in single `if` or where expressions are long, like some function calls. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80853] Create performance-avoid-reserve-in-loop
Issue
80853
Summary
Create performance-avoid-reserve-in-loop
Labels
clang-tidy,
check-request
Assignees
Reporter
PiotrZSL
I'm adding this here so, i wouldn't forget.
Background: https://www.dominikgrabiec.com/c++/2023/10/31/cpp_antipattern_using_reserve_in_loop.html)/c++/2023/10/31/cpp_antipattern_using_reserve_in_loop.html
```
Container container;
for (const auto& entry : entries)
{
container.reserve(container.size() + entry.ItemCount());
entry.AppendItems(container);
}
```
Check should detect calls to reserve in loop on object that is outside of the loop.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80854] Create bugprone-string-view-data-usage check
Issue
80854
Summary
Create bugprone-string-view-data-usage check
Labels
clang-tidy,
check-request
Assignees
Reporter
PiotrZSL
I'm adding this here so, i wouldn't forget.
I run into this issue personally.
Background:
```
void something(std::string s);
int main()
{
std::string_view sv("something");
sv = sv.substr(0, 5);
something(sv.data());
}
```
Because constructor in std::string that take std::string_view is implicit, this forces developer to be more ... productive.
Problem is that in such case .data() may not be null terminated or may not point to proper string.
Enforce:
Find all calls to std::string_view::data, that are passed to method/function, where other parameter isnt an std::string_view::length/size.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80858] Create bugprone-accuracy-lost-in-floating-point-calculation check
Issue
80858
Summary
Create bugprone-accuracy-lost-in-floating-point-calculation check
Labels
clang-tidy,
check-request
Assignees
Reporter
PiotrZSL
I'm adding this here so, i wouldn't forget.
```
int test(int a)
{
return int((double)a * 0.01); // could be done as a/100;
}
```
Example not the best but, idea is to find all expressions (sometimes multiline) where input is an integer and output is an integer, but calculation is done on floating-point. Sometimes by changing order of operation entire calculation could be done fully on integers.
Check could have also other names.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80859] Create performance-proxy-object-copy check
Issue
80859
Summary
Create performance-proxy-object-copy check
Labels
clang-tidy,
check-request
Assignees
Reporter
PiotrZSL
I'm adding this here so, i wouldn't forget.
Example:
```
struct A
{
const std::string& getS() { return s; }
std::string s;
};
struct AProxy
{
AProxy(A& a) : a(a) {}
std::string getS() { return s.getS(); }
A& a;
};
```
Should detect copies of nontrivial heavy objects returned from a call as const reference, but returned as value.
This can be common mistake when writing proxies, and then changing only 1 interface instead of two.
This can be expected behaviour when writing proxies that add something (like mutex locks), in such case behavior can be expected, so best would be to detect only functions that have only returnStmt.
Check name is up to negotation.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80862] [Clang-Tidy] Create readability-unambiguous-optional-assigment check
Issue
80862
Summary
[Clang-Tidy] Create readability-unambiguous-optional-assigment check
Labels
clang-tidy,
check-request
Assignees
Reporter
PiotrZSL
I'm adding this here so, i wouldn't forget. Check name to negotiation.
```
std::optional opt;
...
opt = {};
opt = std::optional();
```
Problem with above, is that it's not so straightforward. I run into issue when developer initialized optional with `= std::optional<...>()` and were thinking that optional is actually set.
In std::optional we got very nice methods called `reset` and `emplace`. I would argue that they should be used instead of above examples. Even `std::nullopt` is better.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80868] tools/llvm-readtapi/stubify-simple.test fails when it is disallowed to write into the input directory
Issue 80868 Summary tools/llvm-readtapi/stubify-simple.test fails when it is disallowed to write into the input directory Labels llvm-tools Assignees cyndyishida Reporter ilya-biryukov We have noticed our tests don't pass with https://github.com/llvm/llvm-project/commit/7189219ec9fc768f159917052b4b5998d077c39f internally. We have a stricter setup in which we don't allow to write into arbitrary files during test execution. It turns out that `stubify-simple.test` actually writes into `.tbd` file during its execution and gets "permission denied" error in our setup. This happens because if uses a path of the `InterfaceFile` to figure out the output path and it can be empty in some cases. In particular, if I `assert(!IF->getPath().empty())` to [this line](https://github.com/llvm/llvm-project/blob/7189219ec9fc768f159917052b4b5998d077c39f/llvm/tools/llvm-readtapi/llvm-readtapi.cpp#L204), the test fails upstream as well. @cyndyishida could you please take a look? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80869] ICE in clang::Sema::DefineImplicitMoveConstructor
Issue
80869
Summary
ICE in clang::Sema::DefineImplicitMoveConstructor
Labels
clang
Assignees
Reporter
mpolacek
From https://gcc.gnu.org/PR94231:
```c++
struct F {F(F&&)=delete;};
template
struct M {
F f;
M();
M(const M&);
M(M&&);
};
template
M::M(M&&)=default;
M<> f() {
M<> m;
return m;
}
```
results in
```
xclang++: /home/mpolacek/src/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:15860: void clang::Sema::DefineImplicitMoveConstructor(clang::SourceLocation, clang::CXXConstructorDecl*): Assertion `(MoveConstructor->isDefaulted() && MoveConstructor->isMoveConstructor() && !MoveConstructor->doesThisDeclarationHaveABody() && !MoveConstructor->isDeleted()) && "DefineImplicitMoveConstructor - call it for implicit move ctor"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: xclang++ -c 94231.C
1. parser at end of file
2. 94231.C:12:9: instantiating function definition 'M<>::M'
#0 0x047aa4a5 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/mpolacek/src/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22
#1 0x047aa595 PrintStackTraceSignalHandler(void*) /home/mpolacek/src/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
#2 0x047a8072 llvm::sys::RunSignalHandlers() /home/mpolacek/src/llvm-project/llvm/lib/Support/Signals.cpp:105:20
#3 0x047a9d98 llvm::sys::CleanupOnSignal(unsigned long) /home/mpolacek/src/llvm-project/llvm/lib/Support/Unix/Signals.inc:367:31
#4 0x046df006 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) /home/mpolacek/src/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:73:5
#5 0x046df495 CrashRecoverySignalHandler(int) /home/mpolacek/src/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:391:1
#6 0x7fa723f7b9a0 __restore_rt (/lib64/libc.so.6+0x3e9a0)
#7 0x7fa723fcd834 __pthread_kill_implementation /usr/src/debug/glibc-2.38-16.fc39.x86_64/nptl/pthread_kill.c:44:76
#8 0x7fa723f7b8ee gsignal /usr/src/debug/glibc-2.38-16.fc39.x86_64/signal/../sysdeps/posix/raise.c:27:6
#9 0x7fa723f638ff abort /usr/src/debug/glibc-2.38-16.fc39.x86_64/stdlib/abort.c:81:7
#10 0x7fa723f6381b _nl_load_domain.cold /usr/src/debug/glibc-2.38-16.fc39.x86_64/intl/loadmsgcat.c:1177:9
#11 0x7fa723f73c57 (/lib64/libc.so.6+0x36c57)
#12 0x088d14e0 clang::Sema::DefineImplicitMoveConstructor(clang::SourceLocation, clang::CXXConstructorDecl*) /home/mpolacek/src/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:15865:36
#13 0x088abbb8 DefineDefaultedFunction(clang::Sema&, clang::FunctionDecl*, clang::SourceLocation) /home/mpolacek/src/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:6847:5
#14 0x088db9fe clang::Sema::SetDeclDefaulted(clang::Decl*, clang::SourceLocation) /home/mpolacek/src/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:18292:30
#15 0x095128b8 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) /home/mpolacek/src/llvm-project/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:5142:21
#16 0x0951717c clang::Sema::PerformPendingInstantiations(bool) /home/mpolacek/src/llvm-project/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:6451:32
#17 0x084ea329 clang::Sema::ActOnEndOfTranslationUnitFragment(clang::Sema::TUFragmentKind) /home/mpolacek/src/llvm-project/clang/lib/Sema/Sema.cpp:1089:3
#18 0x084ea6cd clang::Sema::ActOnEndOfTranslationUnit() /home/mpolacek/src/llvm-project/clang/lib/Sema/Sema.cpp:1130:9
#19 0x0834e260 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) /home/mpolacek/src/llvm-project/clang/lib/Parse/Parser.cpp:729:12
#20 0x083495e2 clang::ParseAST(clang::Sema&, bool, bool) /home/mpolacek/src/llvm-project/clang/lib/Parse/ParseAST.cpp:163:37
#21 0x05734fb2 clang::ASTFrontendAction::ExecuteAction() /home/mpolacek/src/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1183:11
#22 0x05464475 clang::CodeGenAction::ExecuteAction() /home/mpolacek/src/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:1154:5
#23 0x05734903 clang::FrontendAction::Execute() /home/mpolacek/src/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1073:38
#24 0x0565d300 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /home/mpolacek/src/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1057:42
#25 0x058cc12a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /home/mpolacek/src/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:272:38
#26 0x00dabccc cc1_main(llvm::ArrayRef, char const*, void*) /home/mpolac
[llvm-bugs] [Bug 80877] Merge 6b2fd7aed66d592738f26c76caa8fff95e168598 into 18.x
Issue 80877 Summary Merge 6b2fd7aed66d592738f26c76caa8fff95e168598 into 18.x Labels Assignees Reporter brad0 [MIPS] Use generic isBlockOnlyReachableByFallthrough (#80799) FastISel may create a redundant BGTZ terminal which fallthroughes. ``` BGTZ %2:gpr32, %bb.1, implicit-def $at bb.1.bb1: ; predecessors: %bb.0 ``` The `!I->isBarrier()` check in MipsAsmPrinter::isBlockOnlyReachableByFallthrough will incorrectly not print a label, leading to a `Undefined temporary symbol ` error when we try assembling the output assembly file. See the updated `Fast-ISel/pr40325.ll` and https://github.com/rust-lang/rust/issues/108835 In addition, the `SwitchInst` condition is too conservative and prints many unneeded labels (see the updated tests). Just use the generic isBlockOnlyReachableByFallthrough, updated by commit 1995b9fead62f2f6c0ad217bd00ce3184f741fdb for SPARC, which also handles MIPS. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80880] Constant reusing fails to understand when bits are irrelevant
Issue
80880
Summary
Constant reusing fails to understand when bits are irrelevant
Labels
new issue
Assignees
Reporter
Validark
In my code, I had a snippet like this:
```zig
export fn foo(x: u64) u64 {
return ((x ^ 0x) * 0x) << 4;
}
```
Unfortunately, this gets optimized to the equivalent of this:
```zig
export fn foo(x: u64) u64 {
return (x ^ 0x0111) * 0x1110;
}
```
```asm
foo:
movabs rcx, 76861433640456465
movabs rax, 1229782938247303440
xor rcx, rdi
imulrax, rcx
ret
```
Rather than:
```zig
export fn bar(x: u64) u64 {
return (x ^ 0x) * 0x1110;
}
```
```asm
bar:
movabs rcx, 1229782938247303440
lea rax, [rcx + 1]
xor rax, rdi
imulrax, rcx
ret
```
It would be nice if the constant reusing feature recognized that I don't actually need `0x0111`, but `0xZ111`, where `Z` is any bitstring. That means that even if I had written `(x ^ 0xF111) * 0x1110;`, the same optimization could be applied.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80884] [flang] Segfault in lowering ConvertExpr
Issue 80884 Summary [flang] Segfault in lowering ConvertExpr Labels flang Assignees Reporter bcornille When building one of the [GenASiS Basic](https://github.com/GenASiS/GenASiS_Basics) codes I encountered a segfault in flang. Best guess is this is related polymorphic types and extended types. ``` ... #3 0x7ff2b3525a24 fir::FirOpBuilder::getRefType(mlir::Type) (/share/contrib-modules/Core/amd-trunk-dev/2024-02-06_18.0-0/bin/../lib/../lib/libFIRBuilder.so.19git+0x6aa24) #4 0x7ff2b9a5d954 (anonymous namespace)::ScalarExprLowering::genComponent(Fortran::evaluate::Component const&) ConvertExpr.cpp:0:0 #5 0x7ff2b9a5dabe (anonymous namespace)::ScalarExprLowering::gen(Fortran::evaluate::Component const&) ConvertExpr.cpp:0:0 #6 0x7ff2b9a5db4c (anonymous namespace)::ScalarExprLowering::genval(Fortran::evaluate::Component const&) ConvertExpr.cpp:0:0 #7 0x7ff2b9a5dbfc std::__detail::__variant::__gen_vtable_impl... ... flang-new version 19.0.0git (https://github.com/ROCm/llvm-project 58ac649a15feb2a8bbaf07c0c1d30054b0bb6af3) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /share/contrib-modules/Core/amd-trunk-dev/2024-02-06_18.0-0/bin Configuration file: /share/contrib-modules/Core/amd-trunk-dev/2024-02-06_18.0-0/bin/flang.cfg flang-new: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: flang-new: note: diagnostic msg: /tmp/StructuredGridImage_Form-2b7399 flang-new: note: diagnostic msg: /tmp/StructuredGridImage_Form-2b7399.sh ``` I have attached the preprocessed source, full error message, and module files that may be needed to reproduce the compiler error. [StructuredGridImage_Form.zip](https://github.com/llvm/llvm-project/files/14184239/StructuredGridImage_Form.zip) [StructuredGridImage_Form-modules.zip](https://github.com/llvm/llvm-project/files/14184355/StructuredGridImage_Form-modules.zip) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80887] Backport a7bc9cb to release/18.xI
Issue 80887 Summary Backport a7bc9cb to release/18.xI Labels clang:frontend Assignees Reporter shafik I would like to request https://github.com/llvm/llvm-project/issues/80435 be backported to the release/18.x branch. /cherry-pick a7bc9cb ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80895] [libc++] Use stable names for chrono synopsis
Issue 80895 Summary [libc++] Use stable names for chrono synopsis Labels libc++ Assignees mordante Reporter ldionne From https://github.com/llvm/llvm-project/pull/74928#discussion_r1477294895 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80896] PowerPC DAGISel selects lwsync on unsupported targets.
Issue 80896 Summary PowerPC DAGISel selects lwsync on unsupported targets. Labels new issue Assignees Reporter winocm ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80897] Vendor group links broken in developer policy doc
Issue 80897 Summary Vendor group links broken in developer policy doc Labels new issue Assignees Reporter danakj https://llvm.org/docs/DeveloperPolicy.html contains two links, which are 404: * [Clang vendors](https://reviews.llvm.org/project/members/113/) * [libc++ vendors](https://reviews.llvm.org/project/members/109/) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80898] [Python] Access init values when parsing C++ header with clanglib
Issue
80898
Summary
[Python] Access init values when parsing C++ header with clanglib
Labels
new issue
Assignees
Reporter
sebaleme
Hi,
I am using the python bindings from libclang in order to parse a C++ header file and generate a json file. The idea is to get a dictionary with the values defined in the header. Until now, I was not able to get the init values defined in the header:
```
namespace Parameters
{
struct test
{
unsigned long value3{UL};
double floating_val{1.987};
};
/// @brief sequence counter incremented for each output message
unsigned long counter{UL};
/// @brief sequence counter incremented for each output message
bool is_true{false};
/// @brief sequence counter incremented for each output message
float floating_val{1.852F};
test test_instance{};
} // namespace Parameters
```
I am using the following python code to parse the header:
```
def walk(node, origin_dict, current_dict):
parent = False
var_name = ""
if node.kind == cl.CursorKind.VAR_DECL:
var_name = str(node.type.spelling) + "_" + str(node.spelling)
current_dict[var_name] = node.xdata
if node.kind == cl.CursorKind.FIELD_DECL:
var_name = str(node.type.spelling) + "_" + str(node.spelling)
current_dict[var_name] = node.xdata
if node.kind == cl.CursorKind.STRUCT_DECL:
var_name = "struct_" + str(node.spelling)
current_dict[var_name] = {}
parent = True
if node.kind == cl.CursorKind.NAMESPACE:
var_name = "namespace_" + str(node.spelling)
current_dict[var_name] = {}
parent = True
for subnode in node.get_children():
if parent:
walk(subnode, origin_dict, current_dict[var_name])
else:
walk(subnode, origin_dict, current_dict)
def main():
file_dict = {}
index = cl.Index.create()
tu = index.parse(
filepath,
args=[
"/usr/include/",
"/usr/include/c++/9/",
"/usr/include/x86_64-linux-gnu/",
],
)
print("Translation unit:", tu.spelling)
walk(tu.cursor, file_dict, file_dict)
with open(OUTPUT_PATH + jsonfile_name, "w", encoding="utf-8") as outputfile:
json.dump(file_dict, outputfile, indent=4)
```
However, `node.xdata` is wrong, and I always get 0.
```
{
"namespace_Parameters": {
"struct_test": {
"unsigned long_value3": 0,
"double_floating_val": 0
},
"unsigned long_counter": 0,
"bool_is_true": 0,
"float_floating_val": 0,
"test_test_instance": 0
}
}
```
I don t know which python interface could give me the data from the AST. Because when I generate it with clang++, I do have the information:
```
|-VarDecl 0x55f769af3520 col:15 counter 'unsigned long' listinit
| |-InitListExpr 0x55f769af3600 'unsigned long'
| | `-IntegerLiteral 0x55f769af3588 'unsigned long'
| `-FullComment 0x55f769af3de0
| |-ParagraphComment 0x55f769af3d30
| | `-TextComment 0x55f769af3d00 Text=" "
| `-BlockCommandComment 0x55f769af3d50 Name="brief"
| `-ParagraphComment 0x55f769af3db0
| `-TextComment 0x55f769af3d80 Text=" sequence counter incremented for each output message"
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80901] [libc++] Clean up `-stdlib=apple-libc++` Lit features in the test suite with short-hands
Issue
80901
Summary
[libc++] Clean up `-stdlib=apple-libc++` Lit features in the test suite with short-hands
Labels
libc++
Assignees
ldionne
Reporter
ldionne
There's a bunch of Apple back-deployment that we can simplify using short-hands. Also some can be removed entirely:
```
diff --git a/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/generic_category.pass.cpp b/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/generic_category.pass.cpp
index 068202c6e415..5c43b5507c2d 100644
--- a/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/generic_category.pass.cpp
+++ b/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/generic_category.pass.cpp
@@ -6,8 +6,6 @@
//
//===--===//
-// XFAIL: stdlib=apple-libc++ && target={{.+}}-apple-macosx10.{{9|10|11|12}}
-
//
// class error_category
diff --git a/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/system_category.pass.cpp b/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/system_category.pass.cpp
index 42fdd1cb3b91..70282e724765 100644
--- a/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/system_category.pass.cpp
+++ b/libcxx/test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/system_category.pass.cpp
@@ -12,8 +12,6 @@
// const error_category& system_category();
-// XFAIL: stdlib=apple-libc++ && target={{.+}}-apple-macosx10.{{9|10|11|12}}
-
#include
#include
#include
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80909] Fatal error: error in backend: Cannot select: 0x6008887851f0: i64 = bitcast Constant:i8<97>
Issue 80909 Summary Fatal error: error in backend: Cannot select: 0x6008887851f0: i64 = bitcast Constant:i8<97> Labels new issue Assignees Reporter elsid Compiler output: ``` fatal error: error in backend: Cannot select: 0x6008887851f0: i64 = bitcast Constant:i8<97> 0x600887b2f890: i8 = Constant<97> In function: _ZN3VFS4Path12_GLOBAL__N_136gtest_suite_NormalizedOperatorsTest_13supportsEqualINS0_14NormalizedViewEE8TestBodyEv 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: /usr/bin/clang++ -march=native -Wall -Wextra -Wundef -Wextra-semi -Wno-unused-parameter -pedantic -Wno-long-long -Wnon-virtual-dtor -Wunused -Wno-potentially-evaluated-_expression_ -Og -std=c++20 -DBOOST_NO_CXX11_SCOPED_ENUMS=ON -DBT_USE_DOUBLE_PRECISION -DMYGUI_DONT_REPLACE_NULLPTR -DOPENMW_DATA_DIR=u8\"/home/elsid/dev/openmw/build/clang/fast/apps/openmw_test_suite/data\" -DOPENMW_PROJECT_SOURCE_DIR=u8\"/home/elsid/dev/openmw\" -D__STDC_CONSTANT_MACROS -I/home/elsid/dev/openmw/extern/Base64/. -I/home/elsid/dev/openmw/extern/smhasher/. -isystem /home/elsid/dev/icu/build/clang/release/install/include -isystem /home/elsid/dev/openmw/extern/sol_config -isystem /home/elsid/dev/openmw/extern/sol3 -isystem /home/elsid/dev/LuaJIT/build/clang/release/install/include/luajit-2.1 -isystem /home/elsid/dev/bullet3/build/clang/release/install/include/bullet -isystem /usr/include/AL -isystem /home/elsid/dev/mygui/build/clang/release/install/include/MYGUI -isystem /home/elsid/dev/boost/build/clang/release/boost_1_83_0/install/include -isystem /home/elsid/dev/openmw/. -isystem /home/elsid/dev/OpenSceneGraph/build/clang/release/install/include -isystem /home/elsid/dev/googletest/build/clang/release/install/include -isystem /usr/include/SDL2 -isystem /home/elsid/dev/recastnavigation/build/clang/release/install/include/recastnavigation -isystem /home/elsid/dev/yaml-cpp/build/clang/release/install/include -stdlib=libc++ -DNDEBUG -c -MD -MT apps/openmw_test_suite/CMakeFiles/openmw_test_suite.dir/vfs/testpathutil.cpp.o -MF CMakeFiles/openmw_test_suite.dir/vfs/testpathutil.cpp.o.d -fcolor-diagnostics -o CMakeFiles/openmw_test_suite.dir/vfs/testpathutil.cpp.o /home/elsid/dev/openmw/apps/openmw_test_suite/vfs/testpathutil.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/home/elsid/dev/openmw/apps/openmw_test_suite/vfs/testpathutil.cpp'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_ZN3VFS4Path12_GLOBAL__N_136gtest_suite_NormalizedOperatorsTest_13supportsEqualINS0_14NormalizedViewEE8TestBodyEv' #0 0x7ef94bc1f503 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/libLLVM-16.so+0xe1f503) #1 0x7ef94bc1c7bf llvm::sys::RunSignalHandlers() (/usr/lib/libLLVM-16.so+0xe1c7bf) #2 0x7ef94bb08d9a llvm::CrashRecoveryContext::HandleExit(int) (/usr/lib/libLLVM-16.so+0xd08d9a) #3 0x7ef94bc158d4 llvm::sys::Process::Exit(int, bool) (/usr/lib/libLLVM-16.so+0xe158d4) #4 0x6008867ac463 (/usr/bin/clang+++0xf463) #5 0x7ef94bb1f002 llvm::report_fatal_error(llvm::Twine const&, bool) (/usr/lib/libLLVM-16.so+0xd1f002) #6 0x7ef94c6fad4a llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/usr/lib/libLLVM-16.so+0x18fad4a) #7 0x7ef94c6fd7ba llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/usr/lib/libLLVM-16.so+0x18fd7ba) #8 0x7ef94f7885f8 (/usr/lib/libLLVM-16.so+0x49885f8) #9 0x7ef94c6f7f5c llvm::SelectionDAGISel::DoInstructionSelection() (/usr/lib/libLLVM-16.so+0x18f7f5c) #10 0x7ef94c70268c llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/lib/libLLVM-16.so+0x190268c) #11 0x7ef94c70592d llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/lib/libLLVM-16.so+0x190592d) #12 0x7ef94c7079b6 (/usr/lib/libLLVM-16.so+0x19079b6) #13 0x7ef94f78efb7 (/usr/lib/libLLVM-16.so+0x498efb7) #14 0x7ef94c0ea945 (/usr/lib/libLLVM-16.so+0x12ea945) #15 0x7ef94bdab989 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/libLLVM-16.so+0xfab989) #16 0x7ef94bdabd34 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/libLLVM-16.so+0xfabd34) #17 0x7ef94bdac6ac llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/libLLVM-16.so+0xfac6ac) #18 0x7ef9548f3fb3 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr>) (/usr/lib/libclang-cpp.so.16+0x16f3fb3) #19 0x7ef954c19229 (/usr/lib/libclang-cpp.so.16+0x1a19229) #20 0x7ef
[llvm-bugs] [Bug 80910] RISCV64 vector miscompile at -O2
Issue
80910
Summary
RISCV64 vector miscompile at -O2
Labels
new issue
Assignees
Reporter
patrick-rivos
Testcase:
```c
int printf(const char *, ...);
int b, e, z, v, h;
short i, j;
int *k = &b;
static int l;
static int *n = &l;
static int o;
static int r() {
long x = 0;
signed char y = 0;
short w = 0;
*k = 1;
h = 0;
n;
while (h < 2) {
e = i = 0;
while (i < 3) {
j = o << l;
w = b * 3;
e ^= j >= 0;
long q = e;
x = w & -q ?: w;
y = x;
z |= y;
while (o < 2)
o += 1;
i += 1;
}
h++;
}
return z;
}
int main() {
v = r();
printf("%d\n", v);
}
```
Commands:
```bash
> /scratch/tc-testing/llvm-feb-5/build/bin/clang -O2 -march=rv64gcv red.c -o user-config.out -Wno-unused-value
> QEMU_CPU=rv64,Zve32f=true,Zve64f=true /scratch/tc-testing/llvm-feb-5/build/bin/qemu-riscv64 user-config.out
0
> /scratch/tc-testing/llvm-feb-5/build/bin/clang -O1 -march=rv64gcv red.c -o user-config.out -Wno-unused-value
> QEMU_CPU=rv64,Zve32f=true,Zve64f=true /scratch/tc-testing/llvm-feb-5/build/bin/qemu-riscv64 user-config.out
3
```
.c, .bc, .asm:
[c-bc-asm.zip](https://github.com/llvm/llvm-project/files/14186745/c-bc-asm.zip)
`--opt-bisect-limit` points to `InstCombinePass`
Discovered/tested using a7bc9cb6ffa91ff0ebabc45c0c7263c7c2c3a4de (not bisected)
Found using fuzzer.
#80792 also fails with `-march=rv64gcv -O2` so these might be related?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80925] [-Wunsafe-buffer-usage] Extra size arg in fixit for std::span initialization with constant size array
Issue
80925
Summary
[-Wunsafe-buffer-usage] Extra size arg in fixit for std::span initialization with constant size array
Labels
new issue
Assignees
jkorous-apple
Reporter
jkorous-apple
Currently the fixit that transforms a local pointer initialized with constant size array uses 2-parameter std::span constructor to which it passes the array and it's size.
https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/warn-unsafe-buffer-usage-fixits-local-var-span.cpp#L52
```
void local_variable_qualifiers_specifiers() {
int a[10];
...
// CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:3-[[@LINE-1]]:18}:"std::span p"
// CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:19-[[@LINE-2]]:19}:"{"
// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:20}:", 10}"
```
Idiomatic fixit should not repeat the size and instead rely on single parameter std::span constructor that take const size array.
No. 4 here: https://en.cppreference.com/w/cpp/container/span/span
Example:
```
void foo() {
int foo[5];
std::span sp = foo;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80929] [C] error: unexpected token in argument list (target datalayout)
Issue
80929
Summary
[C] error: unexpected token in argument list (target datalayout)
Labels
new issue
Assignees
Reporter
alejandro-colomar
When trying to compile with Clang some library that I'm writing, I get this error:
```
$ make .tmp/a2i/a2i.c.o CC=clang --debug=print
CC (cpp) .tmp/a2i/a2i.c.i
clang -I./include -I.tmp -O3 -std=gnu11 -flto -Wall -Wextra -Wstrict-prototypes -Wdeclaration-after-statement -Wno-attributes -Wno-nullability-completeness -Wno-unknown-attributes -Wno-unknown-pragmas -Wno-unused-command-line-argument -E -o .tmp/a2i/a2i.c.i .tmp/a2i/a2i.c
CC .tmp/a2i/a2i.c.s
clang -I./include -I.tmp -O3 -std=gnu11 -flto -Wall -Wextra -Wstrict-prototypes -Wdeclaration-after-statement -Wno-attributes -Wno-nullability-completeness -Wno-unknown-attributes -Wno-unknown-pragmas -Wno-unused-command-line-argument -S -o .tmp/a2i/a2i.c.s .tmp/a2i/a2i.c
CC (as) .tmp/a2i/a2i.c.o
clang -I./include -I.tmp -O3 -std=gnu11 -flto -Wall -Wextra -Wstrict-prototypes -Wdeclaration-after-statement -Wno-attributes -Wno-nullability-completeness -Wno-unknown-attributes -Wno-unknown-pragmas -Wno-unused-command-line-argument -c -o .tmp/a2i/a2i.c.o .tmp/a2i/a2i.c.s
.tmp/a2i/a2i.c.s:1:14: error: missing _expression_
; ModuleID = '.tmp/a2i/a2i.c'
^
.tmp/a2i/a2i.c.s:3:19: error: unexpected token in argument list
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
^
.tmp/a2i/a2i.c.s:4:15: error: unexpected token in argument list
target triple = "x86_64-pc-linux-gnu"
^
.tmp/a2i/a2i.c.s:6:17: error: unexpected token in argument list
; Function Attrs: inlinehint nounwind uwtable
^
.tmp/a2i/a2i.c.s:7:18: error: unexpected token in argument list
define dso_local i32 @a2shh(ptr noalias nocapture noundef writeonly %0, ptr noundef %1, ptr noalias noundef %2, i32 noundef %3, i8 noundef signext %4, i8 noundef signext %5) local_unnamed_addr #0 {
^
```
Is it maybe due to some CFLAGS? I wouldn't suspect of the code, but can share it if you want to see it.
Cc: @thesamesam
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80935] [llvm-cov][nit] inconsistent variable name of type `MCDCView`
Issue 80935 Summary [llvm-cov][nit] inconsistent variable name of type `MCDCView` Labels new issue Assignees Reporter whentojump https://github.com/llvm/llvm-project/blob/424b9cf41abf376cc7a34640f5f451c91714f77b/llvm/tools/llvm-cov/SourceCoverageViewText.h#L80 https://github.com/llvm/llvm-project/blob/424b9cf41abf376cc7a34640f5f451c91714f77b/llvm/tools/llvm-cov/SourceCoverageView.h#L257 https://github.com/llvm/llvm-project/blob/424b9cf41abf376cc7a34640f5f451c91714f77b/llvm/tools/llvm-cov/SourceCoverageViewHTML.cpp#L980 https://github.com/llvm/llvm-project/blob/424b9cf41abf376cc7a34640f5f451c91714f77b/llvm/tools/llvm-cov/SourceCoverageViewHTML.h#L94 https://github.com/llvm/llvm-project/blob/424b9cf41abf376cc7a34640f5f451c91714f77b/llvm/tools/llvm-cov/SourceCoverageViewText.cpp#L340 https://github.com/llvm/llvm-project/blob/424b9cf41abf376cc7a34640f5f451c91714f77b/llvm/tools/llvm-cov/SourceCoverageView.cpp#L221-L222 https://github.com/llvm/llvm-project/blob/424b9cf41abf376cc7a34640f5f451c91714f77b/llvm/tools/llvm-cov/SourceCoverageView.cpp#L290-L292 Currently we have `BRV` (looking like a `BranchView`), `MRV`, `*MSV`. It would be nice if we can stick to one. @evodius96 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80944] [lldb] Unittests fail to compile on Windows using MSVC 2019
Issue 80944 Summary [lldb] Unittests fail to compile on Windows using MSVC 2019 Labels lldb Assignees Reporter CarlosAlbertoEnciso Compiling the LLDB unittests on Windows using MSVC 2019, fails with the following error: ``` -- Build started: Project: UtilityTests, Configuration: Release x64 -- ConstStringTest.cpp llvm-project\lldb\unittests\Utility\ConstStringTest.cpp(150,3): error C2440: '': cannot convert from 'lldb_private::ConstString' to 'llvm::StringRef' llvm-project\lldb\unittests\Utility\ConstStringTest.cpp(150,3): message : No constructor could take the source type, or constructor overload resolution was ambiguous llvm-project\lldb\unittests\Utility\ConstStringTest.cpp(150,3): error C2660: 'testing::internal::EqHelper::Compare': function does not take 3 arguments llvm-project\third-party\unittest\googletest\include\gtest/gtest.h(1407,26): message : see declaration of 'testing::internal::EqHelper::Compare' llvm-project\lldb\unittests\Utility\ConstStringTest.cpp(150,3): error C2737: 'gtest_ar': const object must be initialized Done building project "UtilityTests.vcxproj" -- FAILED. ``` Compiling using ninja is fine. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 22028 in oss-fuzz: llvm:clang-format-fuzzer: Out-of-memory in clang-format-fuzzer
Updates: Status: WontFix Comment #2 on issue 22028 by ClusterFuzz-External: llvm:clang-format-fuzzer: Out-of-memory in clang-format-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22028#c2 ClusterFuzz testcase 5757152051855360 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80949] [clang][C++20][Modules] Duplicated static local vars when function is exported from module interface unit
Issue
80949
Summary
[clang][C++20][Modules] Duplicated static local vars when function is exported from module interface unit
Labels
clang
Assignees
Reporter
Lancern
Given the following set of translation units:
```cpp
export module a;
export int __attribute__((always_inline)) foo() {
static int x;
return ++x;
}
```
```cpp
import a;
int test1() { return foo(); }
```
```cpp
import a;
int test2() { return foo(); }
```
```cpp
#include
int test1();
int test2();
int main() {
std::cout << test1();
std::cout << test2();
}
```
The program outputs `11` instead of the expected result `12`. Function `test1` and function `test2` access distinct `static int x` objects which are mistakenly inlined into their bodies.
Up to clang 17.0.1, this behavior can happen even if `foo` is not marked with `always_inline` (with optimizations enabled). Seems like this problem is partially fixed by PR #71031 , but the PR misses `always_inline` functions.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
