[Issue 23868] New: Compiler-generated opAssign has very high stack frame usage
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Sat Apr 29 20:48:35 UTC 2023
https://issues.dlang.org/show_bug.cgi?id=23868
Issue ID: 23868
Summary: Compiler-generated opAssign has very high stack frame
usage
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nobody at puremagic.com
Reporter: johanengelen at weka.io
Testcase:
```
struct S {
int[100] arr;
~this() {}
}
S s;
```
This gives AST (https://d.godbolt.org/z/KKzYnPjah):
```
{
int[100] arr;
~this()
{
}
alias __xdtor = ~this()
{
}
;
ref @system S opAssign(S p) return
{
(S __swap2 = void;) , __swap2 = this , (this = p , __swap2.~this());
return this;
}
}
```
The local `__swap2` variable in the compiler-generated opAssign() results in
very high stack frame usage for large structs.
I believe this implemention of opAssign would solve the problem, as I am 99%
sure that the semantic difference (dtor call before the assignment) is allowed
by the spec:
```
ref @system S opAssign(S p) return
{
this.S.~this();
this = p;
return this;
}
```
Workaround is to disable the generation of opAssign: `@disable ref typeof(this)
opAssign(typeof(this) p);`.
--
More information about the Digitalmars-d-bugs
mailing list