digitalmars.D.learn - Unexplainable behaviour with direct struct assignment.
- HuskyNator (35/35) May 18 2022 I came across strange, seemingly non-deterministic, behaviour
- H. S. Teoh (14/43) May 18 2022 [...]
- Dennis (6/12) May 18 2022 Which compiler and flags are you using? For me it just prints 50,
- HuskyNator (7/20) May 18 2022 I've been using `DMD 2.098.0` using a default DUB (1.27.0) init
- HuskyNator (3/7) May 18 2022 I don't know if this matters either, but I'm using windows 10 (64
- Tejas (2/9) May 18 2022 Does this happen with LDC as well?
- HuskyNator (3/4) May 19 2022 I tried it using `LDC 1.29.0` and it prints correctly under both
- bauss (6/13) May 18 2022 Can confirm this is the case for me too on Windows 10.
- frame (8/12) May 19 2022 I'm still on 2098.1, Windows 10 and get this at 64bit only
I came across strange, seemingly non-deterministic, behaviour today. I simplified it the best I could below. I entice you to run the following piece of code. ```d module app; import std.stdio; struct A { float[1] vec; this(float[1] n) { this.vec = n; } } void main(string[] args) { A c = A([50.0f]); writeln(c.vec[0]); A b = A([50.0f]); writeln(b.vec[0]); c = A([50.0f]); writeln(c.vec[0]); } ``` This will print: ``` 0 50 nan ``` My findings: - The first initializer will always contain 0 - Initialization to another variable will yield the expected 50 - Reinitialization will always yield null Am I missing something? Is this a bug? I have no idea what is wrong. Thanks for you help, - HN
May 18 2022
On Wed, May 18, 2022 at 08:05:05PM +0000, HuskyNator via Digitalmars-d-learn wrote: [...]```d module app; import std.stdio; struct A { float[1] vec; this(float[1] n) { this.vec = n; } } void main(string[] args) { A c = A([50.0f]); writeln(c.vec[0]); A b = A([50.0f]); writeln(b.vec[0]); c = A([50.0f]); writeln(c.vec[0]); } ``` This will print: ``` 0 50 nan ```[...] Can't replicate this problem. On my local machine (Linux/64), I get the output: ```` 50 50 50 ```` What's the exact compile command you're using? T -- To err is human; to forgive is not our policy. -- Samuel Adler
May 18 2022
On Wednesday, 18 May 2022 at 20:05:05 UTC, HuskyNator wrote:This will print: ``` 0 50 nan ```Which compiler and flags are you using? For me it just prints 50, you might be stumbling on some (old) bugs in the DMD backend with floating point registers. Examples of such bugs are: https://issues.dlang.org/show_bug.cgi?id=18573 https://issues.dlang.org/show_bug.cgi?id=22163
May 18 2022
On Wednesday, 18 May 2022 at 20:16:51 UTC, Dennis wrote:On Wednesday, 18 May 2022 at 20:05:05 UTC, HuskyNator wrote:I've been using `DMD 2.098.0` using a default DUB (1.27.0) init project (I'm not quite sure what the compile flags are). After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get this behavior. Only when I use `dub run --b=debug` however (default for me). `dub run --b=release` does return what one would expect.This will print: ``` 0 50 nan ```Which compiler and flags are you using? For me it just prints 50, you might be stumbling on some (old) bugs in the DMD backend with floating point registers. Examples of such bugs are: https://issues.dlang.org/show_bug.cgi?id=18573 https://issues.dlang.org/show_bug.cgi?id=22163
May 18 2022
On Wednesday, 18 May 2022 at 21:49:14 UTC, HuskyNator wrote:After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get this behavior. Only when I use `dub run --b=debug` however (default for me). `dub run --b=release` does return what one would expect.I don't know if this matters either, but I'm using windows 10 (64 bits).
May 18 2022
On Wednesday, 18 May 2022 at 21:52:18 UTC, HuskyNator wrote:On Wednesday, 18 May 2022 at 21:49:14 UTC, HuskyNator wrote:Does this happen with LDC as well?After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get this behavior. Only when I use `dub run --b=debug` however (default for me). `dub run --b=release` does return what one would expect.I don't know if this matters either, but I'm using windows 10 (64 bits).
May 18 2022
On Thursday, 19 May 2022 at 04:33:01 UTC, Tejas wrote:Does this happen with LDC as well?I tried it using `LDC 1.29.0` and it prints correctly under both `--b=release` and `--b=debug` builds.
May 19 2022
On Wednesday, 18 May 2022 at 21:52:18 UTC, HuskyNator wrote:On Wednesday, 18 May 2022 at 21:49:14 UTC, HuskyNator wrote:Can confirm this is the case for me too on Windows 10. Release prints 50 3 times, debug prints 0, 50, nan. This is with DMD, I currently don't have LDC or GDC installed on this machine. So it looks like a Windows bug, critical at that.After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get this behavior. Only when I use `dub run --b=debug` however (default for me). `dub run --b=release` does return what one would expect.I don't know if this matters either, but I'm using windows 10 (64 bits).
May 18 2022
On Wednesday, 18 May 2022 at 21:49:14 UTC, HuskyNator wrote:After updating to `DMD 2.100.0` & `DUB 1.29.0`, I still get this behavior. Only when I use `dub run --b=debug` however (default for me). `dub run --b=release` does return what one would expect.I'm still on 2098.1, Windows 10 and get this at 64bit only ``` 9.18366e-40 50 nan ``` but no matter if debug build or not.
May 19 2022