KennyTM~ wrote:
> (It seems the message is lost. Let me try again.)
>
> On Apr 29, 11 15:10, Jens Mueller wrote:
> > KennyTM~ wrote:
> [snip]
> >
> > I think the compiler performs that floating point division at compile
> > time. I should look at the assembly. So the floating point exception
> > h
(It seems the message is lost. Let me try again.)
On Apr 29, 11 15:10, Jens Mueller wrote:
> KennyTM~ wrote:
[snip]
>
> I think the compiler performs that floating point division at compile
> time. I should look at the assembly. So the floating point exception
> happens at that point. Shouldn't t
KennyTM~ wrote:
> On Apr 29, 11 14:27, Walter Bright wrote:
> >That's because the a/=1.0L; is a dead assignment and is removed by the
> >optimizer.
>
> I'd say it's a wrong-code bug.
>
> -
> import std.math, std.stdio;
> void main() {
> auto a = 1.0, b = 0
On Apr 29, 11 14:27, Walter Bright wrote:
That's because the a/=1.0L; is a dead assignment and is removed by the
optimizer.
I'd say it's a wrong-code bug.
-
import std.math, std.stdio;
void main() {
auto a = 1.0, b = 0.0;
writeln(a);
writeln(i
On 4/28/2011 3:02 PM, Jens Mueller wrote:
Hi,
checking whether a floating point exception occurred is good coding
practice for me.
I discovered a strange behavior using dmd.
divByZero.d:
import std.math;
unittest {
auto a = 1.0L;
assert(!ieeeFlags.divByZero);
a /= 0.0L;
asse
Hi,
checking whether a floating point exception occurred is good coding
practice for me.
I discovered a strange behavior using dmd.
divByZero.d:
import std.math;
unittest {
auto a = 1.0L;
assert(!ieeeFlags.divByZero);
a /= 0.0L;
assert(ieeeFlags.divByZero);
}
$ rdmd --main -unitt
