www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - when is a GDC/D2/Phobos bug a GDC bug?

reply Graham Fawcett <fawcett uwindsor.ca> writes:
Hi folks,

I've played with the new GDC version today. Overall it seems solid, but
I've encountered some issues that are probably Phobos-related. Since
this is my first 64-bit D compiler, I wonder whether some parts of
Phobos might not yet be 64-bit ready.

Example 1:

// test_regex.d
import std.regex;

void main() {
  auto r = regex("aeiou");
}

$ gdmd test_regex.d
/opt/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.5/../../../../
include/d2/4.4.5/std/regex.d:442:
Error: cannot implicitly convert expression (len2) of type immutable
(ulong) to uint


Example 2:

// test_iota.d
import std.range;

void main() {
  auto r = iota(0, 10);
}

$ gdmd test_iota.d
/opt/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.5/../../../../
include/d2/4.4.5/std/range.d:3728:
Error: cannot implicitly convert expression (cast(ulong)this.current +
cast(ulong)this.step * n) of type ulong to int

Do you think I should post these to the digitalmars bug tracker, or the
GDC bug tracker? Or should I just let the Phobos team work out the 
64 bits issues generally, and then try again?

Best,
Graham
Nov 23 2010
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Graham Fawcett schrieb:
 Do you think I should post these to the digitalmars bug tracker, or the
 GDC bug tracker? 
Probably both and link each other, so if one team fixes it first the other one knows about it and can copy the fix.
 Or should I just let the Phobos team work out the 
 64 bits issues generally, and then try again?
Probably depends on how fast you want it fixed. (Probably it'd be fastest to create a patch yourself if you want it to be fixed fast)
 
 Best,
 Graham
 
Cheers, - Daniel
Nov 23 2010
parent Daniel Gibson <metalcaedes gmail.com> writes:
Daniel Gibson schrieb:
 Graham Fawcett schrieb:
 Do you think I should post these to the digitalmars bug tracker, or the
 GDC bug tracker? 
Probably both and link each other, so if one team fixes it first the other one knows about it and can copy the fix.
 Or should I just let the Phobos team work out the 64 bits issues 
 generally, and then try again?
Probably depends on how fast you want it fixed. (Probably it'd be fastest to create a patch yourself if you want it to be fixed fast)
 Best,
 Graham
Cheers, - Daniel
Maybe it's already fixed in phobos trunk, see http://www.dsource.org/projects/phobos/changeset/2151#file4
Nov 23 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Graham Fawcett:

 I've played with the new GDC version today. Overall it seems solid, but
 I've encountered some issues that are probably Phobos-related. Since
 this is my first 64-bit D compiler, I wonder whether some parts of
 Phobos might not yet be 64-bit ready.
Is it possible to improve the D language so there are less problems in converting code written on 32 bit to 64 bit (or the other way around)? There are many possible ideas. Bye, bearophile
Nov 23 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
bearophile schrieb:
 Graham Fawcett:
 
 I've played with the new GDC version today. Overall it seems solid, but
 I've encountered some issues that are probably Phobos-related. Since
 this is my first 64-bit D compiler, I wonder whether some parts of
 Phobos might not yet be 64-bit ready.
Is it possible to improve the D language so there are less problems in converting code written on 32 bit to 64 bit (or the other way around)? There are many possible ideas.
Not necessary (at least for these problems), people just have to use size_t instead of (u)int for indexes and such more consequently ;)
 Bye,
 bearophile
Cheers, - Daniel
Nov 23 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Daniel Gibson:

 Not necessary (at least for these problems), people just have to use size_t 
 instead of (u)int for indexes and such more consequently ;)
Elsewhere I have suggested to turn uint and size_t into two different types (like with a typedef): http://d.puremagic.com/issues/show_bug.cgi?id=5063 But Walter has answered me:
 Code that compiles on 32 bits but fails to compile on 64 bits with an
 appropriate message is not much of a problem. Making size_t its own type rather
 than an alias brings along a whole host of other problems.
 
 Besides, it is perfectly legitimate to use an int to index an array on 64 bits.
So a simple type system solution is not enough. I don't know what better solutions there are. Bye, bearophile
Nov 23 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Daniel Gibson wrote:
 Not necessary (at least for these problems), people just have to use 
 size_t instead of (u)int for indexes and such more consequently ;)
Or use D's type inference abilities and not worry about it.
Nov 23 2010
parent Daniel Gibson <metalcaedes gmail.com> writes:
Walter Bright schrieb:
 Daniel Gibson wrote:
 Not necessary (at least for these problems), people just have to use 
 size_t instead of (u)int for indexes and such more consequently ;)
Or use D's type inference abilities and not worry about it.
http://www.dsource.org/projects/phobos/changeset/2151#file4 suggest that auto isn't always possible or doesn't always help :-)
Nov 23 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Graham Fawcett (fawcett uwindsor.ca)'s article
 Hi folks,
 I've played with the new GDC version today. Overall it seems solid, but
 I've encountered some issues that are probably Phobos-related. Since
 this is my first 64-bit D compiler, I wonder whether some parts of
 Phobos might not yet be 64-bit ready.
FWIW, SVN Phobos passes 64-bit semantic analysis even with unittests instantitating templates on DMD. DMD is mostly 64-bit capable, but a lot of nitty-gritty issues remain before it can be used for anything more than semantic analysis. Phobos 2.050 hadn't been fully fixed for 64 support. Iaian has apparently been patching it to get it to compile, but a more thorough job was done on the main SVN trunk recently.
Nov 23 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article
 == Quote from Graham Fawcett (fawcett uwindsor.ca)'s article
 Hi folks,
 I've played with the new GDC version today. Overall it seems solid, but
 I've encountered some issues that are probably Phobos-related. Since
 this is my first 64-bit D compiler, I wonder whether some parts of
 Phobos might not yet be 64-bit ready.
FWIW, SVN Phobos passes 64-bit semantic analysis even with unittests instantitating templates on DMD. DMD is mostly 64-bit capable, but a lot of nitty-gritty issues remain before it can be used for anything more than semantic analysis. Phobos 2.050 hadn't been fully fixed for 64 support. Iaian has apparently been patching it to get it to compile, but a more thorough job was done on the main SVN trunk recently.
The only 64bit-related changes I've made are quite slim now. Though yes I've only been doing "enough" to get it compiling. Around the 2.040 merge, I made the decision to drop the entire library that was currently maintained in the GDC2 tree in favour of just using the upstream version - with minimal GDC-specific changes added, of course (frequent hefty changes in Phobos2 and headaches from merges that were more complicated than they needed to be brought this about). In a way, now I have less on my plate to worry about. And it leaves most of the work to the job of the Phobos Devs to get on with what they do best. --- src/phobos/crc32.d 2010-11-19 22:39:03.387906002 +0000 +++ d/phobos2/crc32.d 2010-11-20 13:06:33.711039410 +0000 -73,7 +73,7 uint strcrc32(char[] s) { uint crc = init_crc32(); - for (int i = 0; i < s.length; i++) + for (size_t i = 0; i < s.length; i++) crc = update_crc32(s[i], crc); return crc; } --- src/phobos/std/algorithm.d 2010-11-19 22:39:03.059906002 +0000 +++ d/phobos2/std/algorithm.d 2010-11-22 13:33:42.718249002 +0000 -2682,7 +2682,7 haystack.popFront), $(D haystack.startsWith!pred(needle)). If no such number could be found, return $(D -1). */ -int indexOf(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle) +sizediff_t indexOf(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle) if (is(typeof(startsWith!pred(haystack, needle)))) { static if (isNarrowString!R1) --- src/phobos/std/format.d 2010-11-19 22:39:02.715906002 +0000 +++ d/phobos2/std/format.d 2010-11-23 00:19:07.651608384 +0000 -949,12 +962,12 // write left pad; write sign; write 0x or 0X; write digits; // write right pad // Writing left pad - int spacesToPrint = + sizediff_t spacesToPrint = f.width // start with the minimum width - digits.length // take away digits to print - (forcedPrefix != 0) // take away the sign if any - (base == 16 && f.flHash && arg ? 2 : 0); // 0x or 0X - const int delta = f.precision - digits.length; + const sizediff_t delta = f.precision - digits.length; if (delta > 0) spacesToPrint -= delta; //writeln(spacesToPrint); if (spacesToPrint > 0) // need to do some padding -980,7 +993,7 // write the digits if (arg || f.precision) { - int zerosToPrint = f.precision - digits.length; + sizediff_t zerosToPrint = f.precision - digits.length; foreach (i ; 0 .. zerosToPrint) put(w, '0'); put(w, digits); }
Nov 23 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Graham Fawcett wrote:
 Do you think I should post these to the digitalmars bug tracker, or the
 GDC bug tracker? Or should I just let the Phobos team work out the 
 64 bits issues generally, and then try again?
Post the bug as a Phobos bug, because it occurs when compiling Phobos. Let the Phobos team reclassify it if they determine if it is a compiler problem.
Nov 23 2010
prev sibling parent Trass3r <un known.com> writes:
 I've played with the new GDC version today. Overall it seems solid, but
 I've encountered some issues that are probably Phobos-related. Since
 this is my first 64-bit D compiler, I wonder whether some parts of
 Phobos might not yet be 64-bit ready.
I'm pretty sure there are certain corner cases. This is a tiny one: http://d.puremagic.com/issues/show_bug.cgi?id=4310
Nov 23 2010