Bug 10215 – Regression (2.063 release): const causes wrong float calculation

Example #1: ---- import std.stdio; class Foo { public: float a = 3.14 / 2 / 0.5; const float b = 3.14 / 2 / 0.5; } void main() { float a = 3.14 / 2 / 0.5; const float b = 3.14 / 2 / 0.5; writefln("a = %f, b = %f", a, b); Foo f = new Foo(); writefln("a = %f, b = %f", f.a, f.b); } ---- Expected: a = 3.140000, b = 3.140000 a = 3.140000, b = 3.140000 I get: a = 3.140000, b = 3.140000 a = 3.140000, b = 0.000000 Example #2: ---- import std.math; import std.stdio; class Foo { public: const float airTime = 0.5; //Speed to progress the jump const float jumpSinWaveSpeed = PI_2 / airTime; float jumpSinWaveSpeed2 = PI_2 / airTime; } void main() { Foo f = new Foo(); writeln(f.jumpSinWaveSpeed); writeln(f.jumpSinWaveSpeed2); } ---- Expected: 3.14159 3.14159 I get: 6.39384e-39 3.14159

Compiler options, OS, 32/64bit, and compiler version please. I can't reproduce this locally.

No compiler options and on Linux / Windows with dmd 2.063. "Works" also on Dpaste: http://dpaste.1azy.net/e6e3bb7b and http://dpaste.1azy.net/e1975814

(In reply to comment #2) > No compiler options and on Linux / Windows with dmd 2.063. > "Works" also on Dpaste: > http://dpaste.1azy.net/e6e3bb7b > and > http://dpaste.1azy.net/e1975814 Ok I can recreate it in 2.063, but not in git-head. This seems like a pretty huge bug to have in a release version. Whatever it was it seems to be fixed now. Anyone know what happened?

Maybe we should offer a patch for this bug? It's a bit annoying. ;)

I can't seem to bisect this. Does anyone know which specific commit the 2.063 release is based on?

import std.stdio, std.math; class Foo { public: const int i = 3; auto getI(){ return i ; } int j = 3; auto getJ(){ return j;} const float x = 0.4; auto getX(){ return x; } float y = 0.4; auto getY(){ return y; } } struct Soo { const int i = 3; auto getI(){ return i ; } int j = 3; auto getJ(){ return j;} const float x = 0.4; auto getX(){ return x; } float y = 0.4; auto getY(){ return y; } } void main() { writeln("with local vars"); const float x = 3.12; const int y = 3; writeln(x , " / " , x == 3.12); writeln(y, " / ", y == 3); writeln("with classes"); Foo f = new Foo(); writeln(f.x, " ", f.getX(), " / ", f.x == f.getX() ); writeln(f.y, " ", f.getY(), " / ", f.y == f.getY() ); writeln(f.i, " ", f.getI(), " / ", f.i == f.getI() ); writeln(f.j, " ", f.getJ(), " / ", f.j == f.getJ() ); writeln("now with structs"); Soo s; writeln(s.x, " ", s.getX(), " / ", s.x == s.getX() ); writeln(s.y, " ", s.getY(), " / ", s.y == s.getY() ); writeln(s.i, " ", s.getI(), " / ", s.i == s.getI() ); writeln(s.j, " ", s.getJ(), " / ", s.j == s.getJ() ); } // outputs /** with local vars 3.12 / true 3 / true with classes 6.09598e-39 0.4 / false 0.4 0.4 / true 4350240 3 / false 3 3 / true now with structs 4.2039e-45 0.4 / false 0.4 0.4 / true 3 3 / true 3 3 / true */

it's not about calculations, it's about accessing const fields in classes and structs. it works perfectly with local variables, it works when accessing the them from within the class itself.

Does anyone knows in the meanwhile, which commit solved the problem? The workaround is to use enum but it would be nice if const would work in dmd 2.063...

(In reply to comment #8) > Does anyone knows in the meanwhile, which commit solved the problem? > The workaround is to use enum but it would be nice if const would work in dmd > 2.063... This bug reproduces just only with dmd2.063 "release". Current 2.063 branch in github http://github.com/D-Programming-Language/dmd/branches/2.063 and released zip does not contain exactly same source code. I found a difference between them, in expression.c DotVarExp::semantic. https://github.com/D-Programming-Language/dmd/blob/2.063/src/expression.c#L7501 The line "#if PULL93" and "#endif" does not exist in released src/expression.c, and the bug reproduces 2.063 branch + removing the #if and #endif lines. Therefore, I can say that the root cause was exists in the mis-operation for building and packaging release files.

(In reply to comment #9) > Therefore, I can say that the root cause was exists in the mis-operation for > building and packaging release files. I figured that might be the problem. This is another reason why we have to have an open release process, meaning we know exactly how and when a build is made.

Fixed in 2.063.2 release.