Walter Bright:
is not done because of roundoff error. Also,
0 * x = 0
is also not done because it is not a correct replacement if x is a NaN.
I have done a little experiment, compiling this D1 code with LDC:
import tango.stdc.stdio: printf;
void main(char[][] args) {
double x =
Walter Bright wrote:
Don wrote:
bearophile wrote:
kai:
Any ideas? Am I somehow not hitting a vital compiler optimization?
DMD compiler doesn't perform many optimizations, especially on
floating point computations.
More precisely:
In terms of optimizations performed, DMD isn't too far
On Fri, 14 May 2010 12:40:52 -0400, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
In C/C++, the default value for doubles is 0.
I think in C and C++ the default value for doubles is uninitialized
(that is anything).
You are probably right. All I did to figure this
On Sat, 15 May 2010 16:15:23 -0400, strtr st...@spam.com wrote:
Should I report these bugs?
(and how should I call this first one?)
module main;
//const S S1 = S(); // uncomment this to compile
struct S
{
float value;
static S opCall()
{
S s;
return s;
}
const S S2 = S();
Hello Don,
The most glaring limitation of the FP optimiser is that it seems to
never keep values in the FP stack. So that it will often do:
FSTP x
FLD x
instead of FST x
Fixing this would probably give a speedup of ~20% on almost all FP
code, and would unlock the path to further optimisation.
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Sat, 15 May 2010 16:15:23 -0400, strtr st...@spam.com wrote:
Should I report these bugs?
(and how should I call this first one?)
module main;
//const S S1 = S(); // uncomment this to compile
struct S
{
On Mon, 17 May 2010 10:28:47 -0400, strtr st...@spam.com wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Sat, 15 May 2010 16:15:23 -0400, strtr st...@spam.com wrote:
Should I report these bugs?
(and how should I call this first one?)
module main;
//const
Steven Schveighoffer:
Unlike some languages, D1 const does not imply static. Which means you
are trying to define an S as containing an S, which would then contain
another S and so on.
It seems the const implies static, in structs... I don't know if this is by
design, or it's a compiler
Hi, Dan used the following method for his vector class:
void opOpAssign (string op:+=)(ref Vector3 other) {...}
Why the ref? As I understand it, objects of class vector
would already be passed as references.
Larry
On Mon, 17 May 2010 16:38:49 -0400, Larry Luther larry.lut...@dolby.com
wrote:
Hi, Dan used the following method for his vector class:
void opOpAssign (string op:+=)(ref Vector3 other) {...}
Why the ref? As I understand it, objects of class vector
would already be passed as references.
Steven Schveighoffer:
No, I was simply wrong :) I think it's by design. Which means the
original bug report is valid.
The original bug report is valid, but I don't understand that code still. Is
the const implying a static only in some situations?
Why is this OK for the compiler:
struct
Walter Bright:
In my view, such switches are bad news, because:
The Intel compiler, Microsoft compiler, GCC and LLVM have a similar switch
(fp:fast in the Microsoft compiler, -ffast-math on GCC, etc). So you might send
your list of comments to the devs of each of those four compilers.
I have
div0 d...@users.sourceforge.net wrote in message
news:hshfe9$o0...@digitalmars.com...
Strange what OPTLINK is doing; normally it crashes at the drop of a hat,
so it seems unreasonable that it processes the .obj a bit then
(un)successfully exits. Maybe the .obj is corrupt in some way that
13 matches
Mail list logo
