www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.048 and 2.033 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
Another OSX 10.5 release :-)

Anyhow, this should work with gdb now, and has contract inheritance 
(finally).

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.048.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.033.zip

Many thanks to the numerous people who contributed to this update.
Oct 05 2009
next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Walter Bright wrote:

 Another OSX 10.5 release :-)
 
 Anyhow, this should work with gdb now, and has contract inheritance 
 (finally).
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip
 
 Many thanks to the numerous people who contributed to this update.


3301 didn't make this release. Is there outstanding problems with 
Rainer's patch? Thanks anyway.
Oct 05 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 05 Oct 2009 13:07:04 +0400, Tim Matthews <tim.matthews7 gmail.com>  
wrote:


 Walter Bright wrote:

 Another OSX 10.5 release :-)
  Anyhow, this should work with gdb now, and has contract inheritance  
 (finally).
  http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip
   http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip
  Many thanks to the numerous people who contributed to this update.


 3301 didn't make this release. Is there outstanding problems with  
 Rainer's patch? Thanks anyway.


I wonder the same. It's a blocker, and I'm forced to use DMD2.031 for that  
reason.
Oct 05 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Tim Matthews wrote:

 3301 didn't make this release. Is there outstanding problems with 
 Rainer's patch? Thanks anyway.


I just need more time to study that one.
Oct 05 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 05 Oct 2009 14:23:26 +0400, Nick Sabalausky <a a.a> wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:hac8nb$26j6$1 digitalmars.com...

 Another OSX 10.5 release :-)

 Anyhow, this should work with gdb now, and has contract inheritance
 (finally).

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip

 Many thanks to the numerous people who contributed to this update.


 "Compiler now detects some cases of illegal null dereferencing when  
 compiled
 with -O"

 A bug-detection feature that's turned on with -O? I assume that's just a
 temporary situation and is related to either it currently being detected  
 by
 the optimizer and the feature maybe being in a "trial" phase? Or maybe  
 just
 a typo? ;)


No, it's not:

void main() {
     Object o;
     o.toString();
}



(mangled name, is it done on purpose?)

Nice start, anyway, I'm looking forward to having a complete code flow  
analysis soon :)
Oct 05 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Can someone show an usage example of contract inheritance? (where inheritance
is useful).


Regarding the fixed bugs 2702 and 2469, I'm having problems still, at the
bottom y is 0:

import std.stdio: writeln;
import std.conv: to;

struct Ranged(int RANGED_MIN, int RANGED_MAX) {
    int x_ = RANGED_MIN;

    int x() { return this.x_; }
    int x(int xx) { this.x_ = xx; return xx; }
    alias x this;

    invariant() {
        //assert(this.x_ >= RANGED_MIN, "Ranged value too much small");
        assert(this.x_ < RANGED_MAX, "Ranged value too much big");
    }

    //Ranged opCast(int xx) { return Ranged(xx); }

    string toString() { return to!string(this.x_); }
}

void main() {
    typedef Ranged!(10, 20) ranged;
    ranged x;
    writeln(x);
    //ranged y = 1000; // temp.d(23): Error: cannot implicitly convert
expression (1000) of type int to ranged
    ranged y = cast(ranged)100;
    writeln(y); // 0?
}

Bye,
bearophile
Oct 05 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Another OSX 10.5 release :-)

 Anyhow, this should work with gdb now, and has contract inheritance  
 (finally).

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip

 Many thanks to the numerous people who contributed to this update.


Excellent work!  It looks like a lot of mundane bugs are getting fixed,  
which is a good sign :)

A couple questions:

1. "The result type of the typeid(type) is now the most derived TypeInfo  
class, rather than the TypeInfo base class"  Why can't this be propogated  
to D1?  I can't imagine code that depends on the return value being typed  
as TypeInfo that would not simply just work with the most derived return  
type...

2. A while ago, (I can't find the post, it may have been on reddit) you  
mentioned that you were going to add property notation.  Is that still  
going to happen?  I'm really looking forward to that, and if not, is there  
a reason?

-Steve
Oct 05 2009
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 10/5/09 13:49, Steven Schveighoffer wrote:

 On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright
 <newshound1 digitalmars.com> wrote:


 Another OSX 10.5 release :-)

 Anyhow, this should work with gdb now, and has contract inheritance
 (finally).

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip

 Many thanks to the numerous people who contributed to this update.


 Excellent work! It looks like a lot of mundane bugs are getting fixed,
 which is a good sign :)

 A couple questions:

 1. "The result type of the typeid(type) is now the most derived TypeInfo
 class, rather than the TypeInfo base class" Why can't this be propogated
 to D1? I can't imagine code that depends on the return value being typed
 as TypeInfo that would not simply just work with the most derived return
 type...

 2. A while ago, (I can't find the post, it may have been on reddit) you
 mentioned that you were going to add property notation. Is that still
 going to happen? I'm really looking forward to that, and if not, is
 there a reason?


There are some traces of it in the code: 
http://www.dsource.org/projects/dmd/changeset/195 search for "property".


 -Steve
Oct 05 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 05 Oct 2009 16:55:49 +0400, Jacob Carlborg <doob me.com> wrote:


 On 10/5/09 13:49, Steven Schveighoffer wrote:

 On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright
 <newshound1 digitalmars.com> wrote:


 Another OSX 10.5 release :-)

 Anyhow, this should work with gdb now, and has contract inheritance
 (finally).

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip

 Many thanks to the numerous people who contributed to this update.


 Excellent work! It looks like a lot of mundane bugs are getting fixed,
 which is a good sign :)

 A couple questions:

 1. "The result type of the typeid(type) is now the most derived TypeInfo
 class, rather than the TypeInfo base class" Why can't this be propogated
 to D1? I can't imagine code that depends on the return value being typed
 as TypeInfo that would not simply just work with the most derived return
 type...

 2. A while ago, (I can't find the post, it may have been on reddit) you
 mentioned that you were going to add property notation. Is that still
 going to happen? I'm really looking forward to that, and if not, is
 there a reason?


 There are some traces of it in the code:  
 http://www.dsource.org/projects/dmd/changeset/195 search for "property".


 -Steve




int bar()  property
{
     return 42;
}

writeln(bar);

Yay! :)
Oct 05 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 05 Oct 2009 09:12:32 -0400, Denis Koroskin <2korden gmail.com>  
wrote:


 On Mon, 05 Oct 2009 16:55:49 +0400, Jacob Carlborg <doob me.com> wrote:


 On 10/5/09 13:49, Steven Schveighoffer wrote:

 On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright
 <newshound1 digitalmars.com> wrote:


 Another OSX 10.5 release :-)

 Anyhow, this should work with gdb now, and has contract inheritance
 (finally).

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip

 Many thanks to the numerous people who contributed to this update.


 Excellent work! It looks like a lot of mundane bugs are getting fixed,
 which is a good sign :)

 A couple questions:

 1. "The result type of the typeid(type) is now the most derived  
 TypeInfo
 class, rather than the TypeInfo base class" Why can't this be  
 propogated
 to D1? I can't imagine code that depends on the return value being  
 typed
 as TypeInfo that would not simply just work with the most derived  
 return
 type...

 2. A while ago, (I can't find the post, it may have been on reddit) you
 mentioned that you were going to add property notation. Is that still
 going to happen? I'm really looking forward to that, and if not, is
 there a reason?


 There are some traces of it in the code:  
 http://www.dsource.org/projects/dmd/changeset/195 search for "property".


 -Steve




 int bar()  property
 {
      return 42;
 }

 writeln(bar);

 Yay! :)


Cool :)

Unfortunately, this still compiles :(

int bar()
{
    return 42;
}

writeln("%d", bar);

And this too:

int bar()  property
{
   return 42;
}

writeln("%d", bar());

So it appears that  property is a noop for now, but is valid syntax.

Also interesting from this revelation is that attributes are coming :D

int bar()  blah
{
   return 42;
}


testme.d(8): valid attribute identifiers are property, not blah

-Steve
Oct 05 2009
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 10/5/09 15:46, Steven Schveighoffer wrote:

 On Mon, 05 Oct 2009 09:12:32 -0400, Denis Koroskin <2korden gmail.com>
 wrote:


 On Mon, 05 Oct 2009 16:55:49 +0400, Jacob Carlborg <doob me.com> wrote:


 On 10/5/09 13:49, Steven Schveighoffer wrote:

 On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright
 <newshound1 digitalmars.com> wrote:


 Another OSX 10.5 release :-)

 Anyhow, this should work with gdb now, and has contract inheritance
 (finally).

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip

 Many thanks to the numerous people who contributed to this update.


 Excellent work! It looks like a lot of mundane bugs are getting fixed,
 which is a good sign :)

 A couple questions:

 1. "The result type of the typeid(type) is now the most derived
 TypeInfo
 class, rather than the TypeInfo base class" Why can't this be
 propogated
 to D1? I can't imagine code that depends on the return value being
 typed
 as TypeInfo that would not simply just work with the most derived
 return
 type...

 2. A while ago, (I can't find the post, it may have been on reddit) you
 mentioned that you were going to add property notation. Is that still
 going to happen? I'm really looking forward to that, and if not, is
 there a reason?


 There are some traces of it in the code:
 http://www.dsource.org/projects/dmd/changeset/195 search for "property".


 -Steve




 int bar()  property
 {
 return 42;
 }

 writeln(bar);

 Yay! :)


 Cool :)

 Unfortunately, this still compiles :(

 int bar()
 {
 return 42;
 }

 writeln("%d", bar);

 And this too:

 int bar()  property
 {
 return 42;
 }

 writeln("%d", bar());

 So it appears that  property is a noop for now, but is valid syntax.

 Also interesting from this revelation is that attributes are coming :D


I just hope that they also will be user defined.


 int bar()  blah
 {
 return 42;
 }


 testme.d(8): valid attribute identifiers are property, not blah

 -Steve
Oct 05 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Jacob Carlborg, el  5 de octubre a las 16:08 me escribiste:

2. A while ago, (I can't find the post, it may have been on reddit) you
mentioned that you were going to add property notation. Is that still
going to happen? I'm really looking forward to that, and if not, is
there a reason?


There are some traces of it in the code:
http://www.dsource.org/projects/dmd/changeset/195 search for "property".


-Steve




int bar()  property
{
return 42;
}

writeln(bar);

Yay! :)


Cool :)

Unfortunately, this still compiles :(

int bar()
{
return 42;
}

writeln("%d", bar);

And this too:

int bar()  property
{
return 42;
}

writeln("%d", bar());

So it appears that  property is a noop for now, but is valid syntax.

Also interesting from this revelation is that attributes are coming :D


 
 I just hope that they also will be user defined.


Ok, this is getting interesting... 8-)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Dentro de 30 años Argentina va a ser un gran supermercado con 15
changuitos, porque esa va a ser la cantidad de gente que va a poder
comprar algo.
	-- Sidharta Wiki
Oct 05 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 Also interesting from this revelation is that attributes are coming :D


Despite all, it seems sometimes Walter listens :-)

Maybe this syntax will be allowed (attribute before instead of after function
name):
 property int bar() {...

Bye,
bearophile
Oct 05 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
bearophile wrote:

 Steven Schveighoffer:

 Also interesting from this revelation is that attributes are coming :D


 
 Despite all, it seems sometimes Walter listens :-)


Wow, indeed he does. :-D
Oct 05 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:

 Yay! :)


It's only half-implemented. Don't use it yet :-(
Oct 05 2009
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Denis Koroskin wrote:
<snip>

 int bar()  property
 {
     return 42;
 }


What is   going to be used for generally?  (What is the essential 
difference between an attribute that's an  word and one that's a simple 
keyword before or after the type?)

Stewart.
Oct 05 2009
parent reply Kagamin <spam here.lot> writes:
Stewart Gordon Wrote:


 What is   going to be used for generally?  (What is the essential 
 difference between an attribute that's an  word and one that's a simple 
 keyword before or after the type?)


Annotations can be user-defined and can contain data.
Oct 06 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Kagamin wrote:

 Stewart Gordon Wrote:
 

 What is   going to be used for generally?  (What is the essential 
 difference between an attribute that's an  word and one that's a simple 
 keyword before or after the type?)


 
 Annotations can be user-defined and can contain data.


But  property clearly cannot be user-defined, unless it's merely a new 
kind of documentation comment with no meaning as far as the language is 
concerned.  So what is its status as an annotation being used for here?

Stewart.
Oct 10 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:

 1. "The result type of the typeid(type) is now the most derived TypeInfo 
 class, rather than the TypeInfo base class"  Why can't this be 
 propogated to D1?  I can't imagine code that depends on the return value 
 being typed as TypeInfo that would not simply just work with the most 
 derived return type...


Changing the spec constantly for D1 makes it not stable.


 2. A while ago, (I can't find the post, it may have been on reddit) you 
 mentioned that you were going to add property notation.  Is that still 
 going to happen?  I'm really looking forward to that, and if not, is 
 there a reason?


It's high on the list, it's just that there were some important 
improvements that I felt should be released now rather than holding them 
back.
Oct 05 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:hac8nb$26j6$1 digitalmars.com...

 Another OSX 10.5 release :-)

 Anyhow, this should work with gdb now, and has contract inheritance
 (finally).

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip

 Many thanks to the numerous people who contributed to this update.


 
 "Compiler now detects some cases of illegal null dereferencing when
 compiled with -O"
 
 A bug-detection feature that's turned on with -O? I assume that's just a
 temporary situation and is related to either it currently being detected
 by the optimizer and the feature maybe being in a "trial" phase? Or maybe
 just a typo? ;)


Somewhere in the huge thread(s) on the topic Walter mentioned the optimizer 
does (some of) the required flow analysis, so presumably it needs to run in 
order for this to work.
Oct 05 2009
prev sibling next sibling parent reply #ponce <aliloko gmail.com> writes:
 
 Somewhere in the huge thread(s) on the topic Walter mentioned the optimizer 
 does (some of) the required flow analysis, so presumably it needs to run in 
 order for this to work.


I think it's disabled in debug mode to keep the compilation time low. 
I guess it's more expensive CPU-wise than escape analysis which is done in both
modes.
So it seems the right thing to do for me.
Oct 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
#ponce wrote:

 I think it's disabled in debug mode to keep the compilation time low. 


That, and the optimizer tends to scramble the relationship between 
source and assembler, making source debugging next to impossible.


 I guess it's more expensive CPU-wise than escape analysis which is done in
both modes.
 So it seems the right thing to do for me.
Oct 05 2009
parent reply BCS <none anon.com> writes:
Hello Walter,


 #ponce wrote:
 

 I think it's disabled in debug mode to keep the compilation time low.
 


 That, and the optimizer tends to scramble the relationship between
 source and assembler, making source debugging next to impossible.
 


How hard would it be to have the code generate run on the unoptimized code 
and then do the optimizer backed test and only if no bugs jump out, move 
the results into the object file?
Oct 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 Hello Walter,
 

 #ponce wrote:


 I think it's disabled in debug mode to keep the compilation time low.


 That, and the optimizer tends to scramble the relationship between
 source and assembler, making source debugging next to impossible.


 
 How hard would it be to have the code generate run on the unoptimized 
 code and then do the optimizer backed test and only if no bugs jump out, 
 move the results into the object file?
 


It seems even easier to just compile with -0.
Oct 05 2009
parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:hadst9$581$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hadqcs$30n8$2 digitalmars.com...

 BCS wrote:

 Hello Walter,


 #ponce wrote:


 I think it's disabled in debug mode to keep the compilation time low.


 That, and the optimizer tends to scramble the relationship between
 source and assembler, making source debugging next to impossible.


 How hard would it be to have the code generate run on the unoptimized 
 code and then do the optimizer backed test and only if no bugs jump out, 
 move the results into the object file?


 It seems even easier to just compile with -0.


 It isn't. *Very* typical workflow:


 [stuff]

 None of those are particularly good options, and I don't see any other 
 possibilities.


 
 ...Plus it's just plain unintuitive.


It's pretty standard, though. For example, there are some bugs which 
Visual C++ detects only when the optimiser is on. From memory, they are 
all flow-related. The MS docs recommend compiling a release build 
occasionally to catch them.
Oct 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 It's pretty standard, though. For example, there are some bugs which 
 Visual C++ detects only when the optimiser is on. From memory, they are 
 all flow-related. The MS docs recommend compiling a release build 
 occasionally to catch them.



The flow analysis could be run on every compile by default, but it would 
make for pretty slow turnaround.
Oct 06 2009
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:


 Don wrote:

 It's pretty standard, though. For example, there are some bugs which
 Visual C++ detects only when the optimiser is on. From memory, they are
 all flow-related. The MS docs recommend compiling a release build
 occasionally to catch them.


 
 
 The flow analysis could be run on every compile by default, but it would
 make for pretty slow turnaround.


Is it possible / reasonably to run flow analysis but still have a build that 
can be properly debugged? If yes, wouldn't it be nice to have it as a 
separate compiler option? Some people with build slaves, fast cpu's or 
smallish projects won't care that much for the performance.
Oct 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Lutger wrote:

 Walter Bright wrote:
 

 Don wrote:

 It's pretty standard, though. For example, there are some bugs which
 Visual C++ detects only when the optimiser is on. From memory, they are
 all flow-related. The MS docs recommend compiling a release build
 occasionally to catch them.


 The flow analysis could be run on every compile by default, but it would
 make for pretty slow turnaround.


 
 Is it possible / reasonably to run flow analysis but still have a build that 
 can be properly debugged? If yes, wouldn't it be nice to have it as a 
 separate compiler option? Some people with build slaves, fast cpu's or 
 smallish projects won't care that much for the performance. 


Just compile with:
	-debug -O
Oct 06 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Lutger wrote:

 Walter Bright wrote:


 Don wrote:

 It's pretty standard, though. For example, there are some bugs which
 Visual C++ detects only when the optimiser is on. From memory, they ar=








e

 all flow-related. The MS docs recommend compiling a release build
 occasionally to catch them.


 The flow analysis could be run on every compile by default, but it woul=






d

 make for pretty slow turnaround.


 Is it possible / reasonably to run flow analysis but still have a build
 that can be properly debugged? If yes, wouldn't it be nice to have it as=




 a

 separate compiler option? Some people with build slaves, fast cpu's or
 smallish projects won't care that much for the performance.


 Just compile with:
 =A0 =A0 =A0 =A0-debug -O


You don't seem to be grasping the issue here. It's not using -O with
-debug that's the problem, it's using it with -g. You can't reasonably
expect someone to put an optimized executable through a debugger.
Oct 06 2009
parent reply grauzone <none example.net> writes:
Jarrett Billingsley wrote:

 On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Lutger wrote:

 Walter Bright wrote:


 Don wrote:

 It's pretty standard, though. For example, there are some bugs which
 Visual C++ detects only when the optimiser is on. From memory, they are
 all flow-related. The MS docs recommend compiling a release build
 occasionally to catch them.


 The flow analysis could be run on every compile by default, but it would
 make for pretty slow turnaround.


 Is it possible / reasonably to run flow analysis but still have a build
 that can be properly debugged? If yes, wouldn't it be nice to have it as a
 separate compiler option? Some people with build slaves, fast cpu's or
 smallish projects won't care that much for the performance.


 Just compile with:
        -debug -O


 
 You don't seem to be grasping the issue here. It's not using -O with
 -debug that's the problem, it's using it with -g. You can't reasonably
 expect someone to put an optimized executable through a debugger.


As I understand, -0 just enables flow analysis (which is slow and thus 
shouldn't be run normally), not full optimization.
Oct 06 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 07 Oct 2009 00:54:22 +0400, grauzone <none example.net> wrote:


 Jarrett Billingsley wrote:

 On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Lutger wrote:

 Walter Bright wrote:


 Don wrote:

 It's pretty standard, though. For example, there are some bugs which
 Visual C++ detects only when the optimiser is on. From memory, they  
 are
 all flow-related. The MS docs recommend compiling a release build
 occasionally to catch them.


 The flow analysis could be run on every compile by default, but it  
 would
 make for pretty slow turnaround.


 Is it possible / reasonably to run flow analysis but still have a  
 build
 that can be properly debugged? If yes, wouldn't it be nice to have it  
 as a
 separate compiler option? Some people with build slaves, fast cpu's or
 smallish projects won't care that much for the performance.


 Just compile with:
        -debug -O


  You don't seem to be grasping the issue here. It's not using -O with
 -debug that's the problem, it's using it with -g. You can't reasonably
 expect someone to put an optimized executable through a debugger.


 As I understand, -0 just enables flow analysis (which is slow and thus  
 shouldn't be run normally), not full optimization.


No, -O means "optimize". It's just much easier to check code flow when an  
executable is optimized, that's it.
Oct 06 2009
parent grauzone <none example.net> writes:
Denis Koroskin wrote:

 On Wed, 07 Oct 2009 00:54:22 +0400, grauzone <none example.net> wrote:
 

 Jarrett Billingsley wrote:

 On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Lutger wrote:

 Walter Bright wrote:


 Don wrote:

 It's pretty standard, though. For example, there are some bugs which
 Visual C++ detects only when the optimiser is on. From memory, 
 they are
 all flow-related. The MS docs recommend compiling a release build
 occasionally to catch them.


 The flow analysis could be run on every compile by default, but it 
 would
 make for pretty slow turnaround.


 Is it possible / reasonably to run flow analysis but still have a 
 build
 that can be properly debugged? If yes, wouldn't it be nice to have 
 it as a
 separate compiler option? Some people with build slaves, fast cpu's or
 smallish projects won't care that much for the performance.


 Just compile with:
        -debug -O


  You don't seem to be grasping the issue here. It's not using -O with
 -debug that's the problem, it's using it with -g. You can't reasonably
 expect someone to put an optimized executable through a debugger.


 As I understand, -0 just enables flow analysis (which is slow and thus 
 shouldn't be run normally), not full optimization.


 
 No, -O means "optimize". It's just much easier to check code flow when 
 an executable is optimized, that's it.


And I thought it was a zero... never mind, then.
Oct 06 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 The flow analysis could be run on every compile by default, but it would 
 make for pretty slow turnaround.


On GCC if you want a safer compilation you add things like -Wall -Wextra, etc.

In D the default is better to be safe (just like you add -release to remove
some safeties), so with flow analysis activated. If someone needs a faster but
less safe compilation, then such person may add a flag to disable flow
analysis, like -noflow.

Bye,
bearophile
Oct 06 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 "Compiler now detects some cases of illegal null dereferencing when compiled 
 with -O"
 
 A bug-detection feature that's turned on with -O? I assume that's just a 
 temporary situation and is related to either it currently being detected by 
 the optimizer and the feature maybe being in a "trial" phase? Or maybe just 
 a typo? ;) 


No, it's deliberate. Turns out, in order for it to work reliably and not 
give false positives, it needs the full attention of the optimizer. 
Otherwise, you get false positives like:

   int* p = null;
   ...
   if (p)
      *p = 7;
Oct 05 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 I see, but is that just a temporary situation? I'm fine with it for now, but 
 optimizers are known for conflicting with debugging, so in the long run I'd 
 hate to have to split my debug builds into separate "maximum static 
 analysis" vs "debuggable" builds (I already had been forced to split my 
 debug builds into separate "debug with warnings" and "debug without 
 warnings" builds, which was a real pain in the ass until I started hacking 
 in that "optionally treat warnings as warnings" patch...but I've had to 
 temporarily abandon use of even that since I'm working on a 
 multi-build-version tool, used by some projects I've released, and none of 
 those should have to be reliant on a feature that only exists in a custom 
 build of DMD).


Just build your releases with -O.
Oct 05 2009
prev sibling next sibling parent reply "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Mon, 05 Oct 2009 10:54:22 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:


 gdb stack trace should work now


Could someone please elaborate on this a bit (what exactly was changed),  
or at least point to the respective SVN revision or something?

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com
Oct 05 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Vladimir Panteleev wrote:

 On Mon, 05 Oct 2009 10:54:22 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 

 gdb stack trace should work now


 
 Could someone please elaborate on this a bit (what exactly was changed), 
 or at least point to the respective SVN revision or something?
 


All the changes are in dwarf.c.
Oct 05 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Which gdb should this release work with?

I seem to have misplaced my patched gdb.  The standard gdb 6.8 can show 
backtraces but can't list code, even if the code is linked in libraries from 
C++.

Walter Bright wrote:


 Another OSX 10.5 release :-)
 
 Anyhow, this should work with gdb now, and has contract inheritance
 (finally).
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.048.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.033.zip
 
 Many thanks to the numerous people who contributed to this update.
Oct 05 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:

 Which gdb should this release work with?
 
 I seem to have misplaced my patched gdb.  The standard gdb 6.8 can show 
 backtraces but can't list code, even if the code is linked in libraries from 
 C++.


If you're using the standard gdb, try compiling with -gc. I'm using 
whatever gdb came with Ubuntu.
Oct 05 2009
parent Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:


 Jason House wrote:

 Which gdb should this release work with?
 
 I seem to have misplaced my patched gdb.  The standard gdb 6.8 can show 
 backtraces but can't list code, even if the code is linked in libraries from 
 C++.


 
 If you're using the standard gdb, try compiling with -gc. I'm using 
 whatever gdb came with Ubuntu.


My mini dmd test omitted that... Oops

It turns out the issue with my larger project was that g++ -g -O3 generates
really, really bad debug info. So bad that it's practically unusable. Removing
-O3 did wonders...
Oct 06 2009
prev sibling parent reply MIURA Masahiro <echochamber gmail.com> writes:
Jason House wrote:

 The standard gdb 6.8 can show 
 backtraces but can't list code, even if the code is linked in libraries from 
 C++.


Can gdb *always* list code for you?
For me, it sometimes does, sometimes doesn't.

---- cut here ----
% cat -n foo.d
     1  import std.stdio;
     2
     3  void main()
     4  {
     5      *(cast(ubyte*)0) = 0;       // intentional SEGV
     6      // writefln("hello");
     7  }
% dmd -gc foo.d; /usr/bin/gdb --quiet ./foo
(gdb) run
Starting program: /home/miura/work/foo
[Thread debugging using libthread_db enabled]
[New Thread 0xb7dde6f0 (LWP 12300)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7dde6f0 (LWP 12300)]
0x08049239 in _Dmain () at foo.d:5
5           *(cast(ubyte*)0) = 0;       // intentional SEGV
(gdb) list
1       import std.stdio;
2
3       void main()
4       {
5           *(cast(ubyte*)0) = 0;       // intentional SEGV
6           // writefln("hello");
7       }
(gdb) backtrace






(gdb)
---- cut here ----

Uncomment the line 6, and gdb is now unable to list code:

---- cut here ----
% dmd -gc foo.d; /usr/bin/gdb --quiet ./foo
(gdb) run
Starting program: /home/miura/work/foo
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d696f0 (LWP 12311)]
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
(gdb) list
1       // Written in the D programming language.
2
3       /**
4       Standard I/O functions that extend $(B std.c.stdio).  $(B std.c.stdio)
5       is $(D_PARAM public)ally imported when importing $(B std.stdio).
6
7       Macros:
8       WIKI=Phobos/StdStdio
9
10      Copyright: Copyright Digital Mars 2007 - 2009.
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
(gdb) backtrace
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
(gdb)
---- cut here ----

That's Kubuntu 32bit 9.04, gdb 6.8, and DMD 2.033.
Oct 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
MIURA Masahiro wrote:

 Uncomment the line 6, and gdb is now unable to list code:


Please post to bugzilla.
Oct 05 2009
parent MIURA Masahiro <echochamber gmail.com> writes:
Walter Bright wrote:

 Please post to bugzilla.


Done!
http://d.puremagic.com/issues/show_bug.cgi?id=3368
Oct 05 2009