David Friedman wrote:
> Thanks for trying it out!  I guess my own code isn't 64-bit clean (gen_unix crash.)
Thanks for allowing me to try it out :)
I have no idea how that piece of code could crash, and I would rather blame it on some messup on my side instead of your code.

> The shared library error is similar to what I got when I tried to do a bootstrap build -- the C++ executables become dependent on the new libraries which are not yet installed.  Once installed, though, you can set the LD_LIBRARY_PATH environment variable.
Meh, it works like this.

> For building Phobos, I usually just change the PATH so that gdc and the same-version C and C++ compilers are the default and I don't have to do anything special for the configure script.  If you do this, remember to use the original system compiler to rebuild gdc.
I do indeed use the original system compiler which now features gdc to compile all this, and I did not attempt to do anything special. I do not think I did anything to cause the configure script to put these strange parameters, assuming that is what you are referring to.

> BTW, if you want to try out the compiler without Phobos, you can compile with -fno-exceptions and use a C-style main (i.e, extern(C) int main(int, char**) {...}).  This severely limits what you can do, but at least you can make executables.
I actually still have a semi-working phobos installation from release 1f on my system, so I can indeed play around a bit already.
But thanks for the hint, as this will probably need to non-segfaulting executables :)

Slightly updated transcript, up to the point where I am now stuck: http://ilfirin.org/gdc
Note that my previous attempt to redefine CLASSINFO_SIZE was wrong, and the current one is more or less based on coincidence as I have no clue what a monitor_t is.

-ben

Is gdb fully functional with the executable generated by GDC?

If not, what works, and what not yet?

Benjamin Herr wrote:
> David Friedman wrote:
> 
>> Thanks for trying it out!  I guess my own code isn't 64-bit clean (gen_unix crash.)
> 
> Thanks for allowing me to try it out :)
> I have no idea how that piece of code could crash, and I would rather blame it on some messup on my side instead of your code.
> 

Ah, but did I did find a bug -- used a '%d' format with a ptrdiff_t argument.

>> The shared library error is similar to what I got when I tried to do a bootstrap build -- the C++ executables become dependent on the new libraries which are not yet installed.  Once installed, though, you can set the LD_LIBRARY_PATH environment variable.
> 
> Meh, it works like this.
> 
>> For building Phobos, I usually just change the PATH so that gdc and the same-version C and C++ compilers are the default and I don't have to do anything special for the configure script.  If you do this, remember to use the original system compiler to rebuild gdc.
> 
> I do indeed use the original system compiler which now features gdc to compile all this, and I did not attempt to do anything special. I do not think I did anything to cause the configure script to put these strange parameters, assuming that is what you are referring to.
> 

Now that you mention it, I think I saw this before.  I can't remember what the cause was.

>> BTW, if you want to try out the compiler without Phobos, you can compile with -fno-exceptions and use a C-style main (i.e, extern(C) int main(int, char**) {...}).  This severely limits what you can do, but at least you can make executables.
> 
> I actually still have a semi-working phobos installation from release 1f on my system, so I can indeed play around a bit already.
> But thanks for the hint, as this will probably need to non-segfaulting executables :)
> 
> Slightly updated transcript, up to the point where I am now stuck: http://ilfirin.org/gdc
> Note that my previous attempt to redefine CLASSINFO_SIZE was wrong, and the current one is more or less based on coincidence as I have no clue what a monitor_t is.
> 
> -ben

The monitor field is a pointer to a platform-specific synchronization object.

I'll check out the updated transcript.

David

Dave schrieb:
> Frankly and on second thought, I could be wrong to suggest this, because I'm
> basing that suggestion off of tests done with an older-than-current version
> of GCC and only on a PIII to compare it with.

Not necessarily. However, all the options are alredy there, so i think it just may be up to application author to decide.

> What I've noticed in the benchmarks I've run is that -mcpu=pentium4 does
> generally make some code a decent amount faster on both P4 and
> AthlonXP/AMD64 (32 bit mode) chips, while not really effecting the results
> on the PIII class chips.

Interesting. I had considered Athlon-XP to be rather similar to P6 (Pentium 3), and Pentium 4 somewhat different, but apparently i was wrong. Perhaps some optimizations caused some kind of performance "trap" on both recent AMDs and on Pentium 4, which weren't there in prior architectures. Gotta read something on it.

> OTOH though, if you 'tune' an executable or a compiler/runtime/whatever for
> the higher-end chips, the people who use the lower-end chips scream bloody
> murder.. I kind of look at it from the other angle - I think the people who
> have invested (the money, time and effort) to upgrade shouldn't have to
> default to the lowest common denominator, so maybe those people should be
> the ones /really/ screaming bloody murder <g>

It is only tuning... the command set in use is still as for 386, yes? I think it's a pity and Pentium (but perhaps nothing above) should be mandatory.

> Anyhow, I thought maybe since D won't have all of the legacy code issues to
> deal with, it may be a good time to 'tune' GDC for the higher-end chips.

Legacy *code* issues? There is no effect on code compatibility, the only consern is a compatible hardware. I would argue that D requieres an architecture with pretty much memory anyway, and computers old enough are more or less out of question already for that reason.

-eye

some@where.com wrote:

> Is gdb fully functional with the executable generated by GDC?
> 
> If not, what works, and what not yet?
> 
> 

I would say gdb is "very much usable" ;-)  You can trace through code, inspect global and local variables, set breakpoints on specific lines, etc.

What doesn't work:

. Name mangling -- this affects global values.  Fixing this will probably require a patch to gdb.

. Inspection of local variables and arguments in nested functions -- The problems vary depending on the debugging standard used.  This might be a problem with gdb itself, however.

. Classes and structs don't have their methods defined (so they can't be called easily.)

. Local variables appear in scope before they should (actually a code gen issue).

David

Ilya Minkov wrote:

> Dave schrieb:
[snip]
> 
> It is only tuning... the command set in use is still as for 386, yes? I think it's a pity and Pentium (but perhaps nothing above) should be mandatory.
> 

Yea - it is only tuning, but nonetheless I didn't put enough thought into the original -mcpu=pentium4 suggestion. Especially given this response by the maintainer of GDC:

http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/791

>> Anyhow, I thought maybe since D won't have all of the legacy code issues to deal with, it may be a good time to 'tune' GDC for the higher-end chips.
> 
> Legacy *code* issues? There is no effect on code compatibility, the only consern is a compatible hardware. I would argue that D requieres an architecture with pretty much memory anyway, and computers old enough are more or less out of question already for that reason.
> 
> -eye

By "legacy code issues", I should have said something more along the lines of 'all that code running running on older hardware', which is what I intended.

Thanks,

- Dave