[Issue 3751] Optimalization error in some floating point code
http://d.puremagic.com/issues/show_bug.cgi?id=3751
--- Comment #3 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-29
04:28:20 PST ---
(In reply to comment #2)
is this maybe related to issue 3736 ?
I don't know. This is quite different issues (i'm not using structs, and i
doesn't call functions when error occure).
My bug have probably something with FPU register allocation, but this is just a
guess.
I further reduced test case, change write(%s,half) to nic(), where nic is
empty function, and write code directly in main
import std.math;
import std.stdio;
void nic() {}
void main() {
foreach (i; 1 .. 10) {
auto z = 0.1 + 0.001*i;
double left = -7.0, right = 7.0, half;
while (true) {
half = (left+right)*0.5; // or left+0.5*(right-left);
version(something) {
nic(); // adding this solves problem
}
if (left == half) {
break; // or break
}
if (half == right) {
break; // or break
}
/+
// the same effect
if ((left == half) || (half == right)) {
return half; // or break
}
+/
double fhalf = 1.0/(half*half) * (half + 0.7) - z;
if (fhalf 0.0) {
right = half;
} else if (fhalf = 0.0) {
left = half;
}
};
writefln(%g %g, z, half);
}
}
One of the dide by side diff (left -O, right -O + nic):
http://pastebin.com/f17a77299
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3751] Optimalization error in some floating point code
http://d.puremagic.com/issues/show_bug.cgi?id=3751 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #4 from Don clugd...@yahoo.com.au 2010-01-29 04:55:17 PST --- I'm not certain that there's a bug here (difficult to tell without reducing the test case further). It could be that in the optimised case you have a temporary value stored in a register, increasing the precision. It's legal for the compiler to do that. Adding a function call stops DMD from keeping the value in a register. Anyway you need to cut the test case down significantly. BTW it behaves the same way on DMD0.175, so this is definitely not a regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3751] Optimalization error in some floating point code
http://d.puremagic.com/issues/show_bug.cgi?id=3751 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #5 from Steven Schveighoffer schvei...@yahoo.com 2010-01-29 05:44:47 PST --- (In reply to comment #4) I'm not certain that there's a bug here (difficult to tell without reducing the test case further). It could be that in the optimised case you have a temporary value stored in a register, increasing the precision. It's legal for the compiler to do that. Adding a function call stops DMD from keeping the value in a register. Anyway you need to cut the test case down significantly. BTW it behaves the same way on DMD0.175, so this is definitely not a regression. I think this is exactly the problem. You are using floating point expecting that all floats are created equal. One rule about floating point is never to build an infinite loop waiting for two floats to converge using ==. You must use an epsilon if you expect any reasonable result. Your exit condition is this: if (left == half || right == half) What about trying this: if(half - left SOME_EPSILON || right - half SOME_EPSILON) where SOME_EPSILON is a very small insignificant number, like 0.01 floating point convergence is an art form, you need to understand its limitations. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3751] Optimalization error in some floating point code
http://d.puremagic.com/issues/show_bug.cgi?id=3751
--- Comment #6 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-29
05:48:52 PST ---
(In reply to comment #4)
I'm not certain that there's a bug here (difficult to tell without reducing
the
test case further). It could be that in the optimised case you have a
temporary
value stored in a register, increasing the precision. It's legal for the
compiler to do that. Adding a function call stops DMD from keeping the value
in
a register.
Anyway you need to cut the test case down significantly.
BTW it behaves the same way on DMD0.175, so this is definitely not a
regression.
Hmm, You are probably right.
Changing coditions to:
if (left = half) {
break;
}
if (half = right) {
break;
}
solves problem.
Interesingly compiling in gdc even with -O3 -finline -frelease
-funsafe-math-optimizations -frounding-math -ffast-math doesn't bring this
error.
What is also problematic is that even adding forcibly something like
cast(double) doesn't solve problem (they are noop's, becuase they are already
of correct type).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3751] Optimalization error in some floating point code
http://d.puremagic.com/issues/show_bug.cgi?id=3751 --- Comment #7 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-29 05:50:47 PST --- (In reply to comment #5) I think this is exactly the problem. You are using floating point expecting that all floats are created equal. One rule about floating point is never to build an infinite loop waiting for two floats to converge using ==. You must use an epsilon if you expect any reasonable result. I know this. Your exit condition is this: if (left == half || right == half) What about trying this: if(half - left SOME_EPSILON || right - half SOME_EPSILON) where SOME_EPSILON is a very small insignificant number, like 0.01 floating point convergence is an art form, you need to understand its limitations. Yes I know, but I was relaying of IEEE 754 semantic, in which my code should work (there will be point in execuion when left == half or right == half exactly!). I was just trying to write this routine to be slightly faster just by not using EPSILONS and substractions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3751] Optimalization error in some floating point code
http://d.puremagic.com/issues/show_bug.cgi?id=3751 --- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2010-01-29 06:06:41 PST --- (In reply to comment #7) Yes I know, but I was relaying of IEEE 754 semantic, in which my code should work (there will be point in execuion when left == half or right == half exactly!). I was just trying to write this routine to be slightly faster just by not using EPSILONS and substractions. Are you sure? I'm not really a floating point expert, so I don't know what the rules of IEEE are, but I have written floating point convergence algorithms for things like programming competitions, and I had to learn that things will get stuck if you don't use an epsilon. You can picture what's happening if you make left and right integers. What ends up happening when left - right == 1? half becomes left + .5, so it does not compare equal to left or right, but if your calculation then assigns left equal to half, the .5 is dropped and left is stuck in the same loop. I would say that this is not a bug, but again, not a floating point expert. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3752] New: File.byLine fetches lines in a confusing manner
http://d.puremagic.com/issues/show_bug.cgi?id=3752 Summary: File.byLine fetches lines in a confusing manner Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: and...@metalanguage.com --- Comment #0 from Andrei Alexandrescu and...@metalanguage.com 2010-01-29 08:25:13 PST --- Refer to the newsgroup discussion Re: Accessors, byLine, input ranges. The constructor of ByLine eagerly fetches a line (it shouldn't). The actual data transfer should ideally occur only in front(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3752] File.byLine fetches lines in a confusing manner
http://d.puremagic.com/issues/show_bug.cgi?id=3752 --- Comment #1 from Pelle M�nsson pelle.mans...@gmail.com 2010-01-29 10:59:45 PST --- Created an attachment (id=559) Rearranged using filled flag Now featuring an idle constructor. I hope I got the patch generation right. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3167] Passing result of a function call as ref argument no longer works
http://d.puremagic.com/issues/show_bug.cgi?id=3167 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #10 from Walter Bright bugzi...@digitalmars.com 2010-01-29 11:55:29 PST --- I'm going to mark this as invalid, as function return values should be rvalues, and rvalues cannot be references, even if the vagaries of the implementation make that possible. The reason is vagaries of the implementation, so it may work on one implementation but not another. Currently, whether it (used to) work or not also depended on the contents of the struct being returned. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3167] Passing result of a function call as ref argument no longer works
http://d.puremagic.com/issues/show_bug.cgi?id=3167 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #11 from Andrei Alexandrescu and...@metalanguage.com 2010-01-29 12:27:07 PST --- (In reply to comment #10) I'm going to mark this as invalid, as function return values should be rvalues, and rvalues cannot be references, even if the vagaries of the implementation make that possible. The reason is vagaries of the implementation, so it may work on one implementation but not another. Currently, whether it (used to) work or not also depended on the contents of the struct being returned. Why should we leave this to vagaries? An rvalue is not an lvalue, period. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3167] Passing result of a function call as ref argument no longer works
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Eldar Insafutdinov e.insafutdi...@gmail.com changed:
What|Removed |Added
CC||e.insafutdi...@gmail.com
--- Comment #12 from Eldar Insafutdinov e.insafutdi...@gmail.com 2010-01-29
15:00:25 PST ---
(In reply to comment #10)
I'm going to mark this as invalid, as function return values should be
rvalues,
and rvalues cannot be references, even if the vagaries of the implementation
make that possible.
The reason is vagaries of the implementation, so it may work on one
implementation but not another. Currently, whether it (used to) work or not
also depended on the contents of the struct being returned.
This test case fails for me with the latest dmd:
struct X {
}
X i() {
return X.init;
}
void foo(const ref X x) {
}
void foo() {
foo(i()); //line 12
}
This bug is not invalid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3753] New: ICE eh.c 49: Related to exception handling and alloca.
http://d.puremagic.com/issues/show_bug.cgi?id=3753 Summary: ICE eh.c 49: Related to exception handling and alloca. Product: D Version: 2.039 Platform: Other OS/Version: Linux Status: NEW Keywords: ice-on-valid-code Severity: major Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha dsim...@yahoo.com 2010-01-29 15:04:57 PST --- I can't seem to reduce this one to a small test case, but I think this comment from where the assert fires at least gives a hint that it involves some combination of exceptions and alloca: // BUG: alloca() changes the stack size, which is not reflected // in the fixed eh tables. assert(!usedalloca); Also, in the (too large to post to Bugzilla) program that this issue occurred in, removing the alloca() calls and replacing them with GC.malloc() fixed the problem. This assert is in a #if TARGET_LINUX || TARGET_OSX || TARGET_FREEBSD || TARGET_SOLARIS statement, so I guess it only happens on those OS's. The code that triggers it definitely works on Windows. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3167] Passing result of a function call as ref argument no longer works
http://d.puremagic.com/issues/show_bug.cgi?id=3167 --- Comment #13 from Walter Bright bugzi...@digitalmars.com 2010-01-29 15:50:10 PST --- It is invalid code because you are taking a reference to the return value of a function. Functions return, by definition, rvalues. You cannot take a reference to an rvalue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3751] Optimalization error in some floating point code
http://d.puremagic.com/issues/show_bug.cgi?id=3751 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #9 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-01-29 15:50:21 PST --- (In reply to comment #8) (In reply to comment #7) Yes I know, but I was relaying of IEEE 754 semantic, in which my code should work (there will be point in execuion when left == half or right == half exactly!). I was just trying to write this routine to be slightly faster just by not using EPSILONS and substractions. Are you sure? I'm not really a floating point expert, so I don't know what the rules of IEEE are, but I have written floating point convergence algorithms for things like programming competitions, and I had to learn that things will get stuck if you don't use an epsilon. You can picture what's happening if you make left and right integers. What ends up happening when left - right == 1? half becomes left + .5, so it does not compare equal to left or right, but if your calculation then assigns left equal to half, the .5 is dropped and left is stuck in the same loop. Whell it can't be that half is not equal to left, and then after assigning it is actually the same value. It is only becuase we have intermidiate half in higher precision than double precision. I'm actually using formula half = left + 0.5*(right-left); which is safer in regards of overflows, but this doesn't really metter. I would say that this is not a bug, but again, not a floating point expert. Closing it. Sorry for a problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3167] Passing result of a function call as ref argument no longer works
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #14 from Steven Schveighoffer schvei...@yahoo.com 2010-01-29
19:24:11 PST ---
(In reply to comment #13)
It is invalid code because you are taking a reference to the return value of a
function. Functions return, by definition, rvalues. You cannot take a
reference
to an rvalue.
This breaks custom types. Who are you as the compiler to assume my type is an
rvalue?
e.g.
class MyClass
{
struct myForwardRange {...}
@property myForwardRange all() {...}
}
void copy(R1, R2)(ref R1 inputrange, ref R2 outputrange)
{
...
}
void foo(MyClass mc, OutputRange r)
{
copy(mc.all, r);
}
Another case:
struct LargeStruct
{
int[100] bigarray;
void print(streamtype s) {s.print(bigarray);}
}
class X
{
LargeStruct createalargestruct() {...}
}
void foo(X x)
{
x.createalargestruct().print(stdout);
}
Also, if you can't call properties on a struct, which essentially needs a
reference to the struct, then you can't get any properties from a returned
struct.
This rule is way too limiting. at the very least, const rvalue references need
to be allowed for any reasonable value types that are not just POD to be
created.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
