[Issue 4389] ICE(constfold.c, expression.c), or wrong code: string~=dchar in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4389
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|CTFE: Appending dchar to|ICE(constfold.c,
|empty string creates|expression.c), or wrong
|invalid string. |code: string~=dchar in CTFE
--- Comment #1 from Don clugd...@yahoo.com.au 2010-11-23 00:56:25 PST ---
Actually constant folding of string ~= dchar is ALWAYS wrong, even if the
string is non-empty. All these tests fail. It can also cause an
ICE(constfold.c) if you attempt a further concatenation, or ICE(expression.c)
if it is mixed in (bug 3490).
It happens because string ~= dchar is treated specially in the backend, but not
in constfold.c.
-
int bug4389()
{
string s;
dchar c = '\u2348';
s ~= c;
assert(s.length==3);
dchar d = 'D';
s ~= d;
assert(s.length==4);
s = ;
s ~= c;
assert(s.length==3);
s ~= d;
assert(s.length==4);
string z;
wchar w = '\u0300';
z ~= w;
assert(z.length==2);
z = ;
z ~= w;
assert(z.length==2);
return 1;
}
static assert(bug4389());
// ICE(constfold.c)
int ice4389()
{
string s;
dchar c = '\u2348';
s ~= c;
s = s ~ xxx;
return 1;
}
static assert(ice4389());
// ICE(expression.c)
string ice4390()
{
string s;
dchar c = '`';
s ~= c;
s ~= c;
return s;
}
static assert(mixin(ice4390()) == ``);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5260] New: std.math.feqrel() returns negative number
http://d.puremagic.com/issues/show_bug.cgi?id=5260 Summary: std.math.feqrel() returns negative number Product: D Version: D1 D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bugzi...@kyllingen.net --- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-11-23 03:41:42 PST --- This prints -688: writeln(feqrel(0.0, double.min_normal/100)); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3175] rejects templated ref return function
http://d.puremagic.com/issues/show_bug.cgi?id=3175 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #6 from Don clugd...@yahoo.com.au 2010-11-23 05:15:10 PST --- (In reply to comment #5) (In reply to comment #4) Applied the patch http://www.dsource.org/projects/dmd/changeset/695 but the bug remains. Are you saying the bug remains since the reproducing code in comment #0 doesn't compile? It's because the type of [1,2,3] has changed to dynamic int[]. Replacing 'auto' to 'int[3]' would make it compile. Indeed it does work in DMD2.050. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4389] ICE(constfold.c, expression.c), or wrong code: string~=dchar in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4389 --- Comment #3 from Don clugd...@yahoo.com.au 2010-11-23 12:33:23 PST --- Created an attachment (id=827) Patch against D2 svn 767 Although the patch is relatively long, it is very mundane. The patch adds these functions to utf.c (they are copied from druntime). These convert single chars from UTF32 to UTF8 or UTF16. void utf_encodeChar(unsigned char *s, dchar_t c); void utf_encodeWchar(unsigned short *s, dchar_t c); int utf_codeLengthChar(dchar_t c); int utf_codeLengthWchar(dchar_t c); Two other wrapper functions provide the interface that is actually used: int utf_codeLength(int sz, dchar_t c); void utf_encode(int sz, void *s, dchar_t c); Then, these functions are used in Cat() in constfold.c Instead of assuming a len of 1, it uses utf_codeLength; and instead of a memcpy, it uses utf_encode. The cases which are patched in Cat() are: TOKnull ~ dchar, dchar ~ TOKnull, TOKstring ~ dchar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4900] compiler still slow due to a single function
http://d.puremagic.com/issues/show_bug.cgi?id=4900 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2010-11-23 12:57:31 PST --- Yes, the linked list should be replaced with a hashtable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5262] New: divide by 0 in std.datetime's Ticks.toMicroseconds()
http://d.puremagic.com/issues/show_bug.cgi?id=5262
Summary: divide by 0 in std.datetime's Ticks.toMicroseconds()
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bra...@puremagic.com
--- Comment #0 from Brad Roberts bra...@puremagic.com 2010-11-23 16:08:41 PST
---
fedora 12 (ami-0d638d64 running on an ec2 t1.micro in case it matters), running
the phobos unit tests I'm getting a fp exception. This is a 64 bit box, 32 bit
build of dmd, druntime, and phobos.
Inside the static ctor for struct Ticks, it's hitting the true code path of the
static if and false path of if clock_getres():
ticksPerSec = 1000_000_000 / ts.tv_nsec;
ts.tv_nsec=999848 which results in ticksPerSec=1000.
Later, when this code runs:
const
T toMicroseconds(T)() if (isIntegral!T T.sizeof = 4)
{
return value/(ticksPerSec/1000/1000);
}
ticksPerSec/1000/1000 -- 0
called from here:
285 unittest
286 {
287 auto t = Ticks.fromMicroseconds(100);
288 assert(t.usec == 100); // --- here
On the auto-testers, running ubuntu, it takes the false path of that static if
and just directly assigns ticksPerSec to 1M which survives the /1000/1000 as 1.
The full stack:
(gdb) bt
#0 0x0808490c in __ULDIV__ ()
#1 0x0807a952 in std.datetime.Ticks.toMicroseconds!(long).toMicroseconds
(this=0xd35c) at std/datetime.d:248
#2 0x0807a31c in std.datetime.Ticks.__unittest6 () at std/datetime.d:284
#3 0x0807bba0 in _D3std8datetime9__modtestFZv ()
#4 0x08080d5c in
_D4core7runtime18runModuleUnitTestsUZb16__foreachbody168MFKPS6object10ModuleInfoZi
()
#5 0x0807dcd2 in _D6object10ModuleInfo7opApplyFMDFKPS6object10ModuleInfoZiZi
()
#6 0x08080c77 in runModuleUnitTests ()
#7 0x0807e448 in _D2rt6dmain24mainUiPPaZi6runAllMFZv ()
#8 0x0807e370 in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#9 0x0807e316 in main ()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5262] divide by 0 in std.datetime's Ticks.toMicroseconds()
http://d.puremagic.com/issues/show_bug.cgi?id=5262
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-23 20:10:42
PST ---
I'm pretty certain that the fix is to change toMicroseconds to
T toMicroseconds(T)() if (isIntegral!T T.sizeof = 4)
{
enum unitsPerSec = 1_000_000;
if(ticksPerSec = unitsPerSec)
return value / (ticksPerSec / unitsPerSec);
else
return value * (unitsPerSec / ticksPerSec);
}
All of the toX() functions should be like this with differing unitsPerSec.
However, microseconds is probably the only one where it's actually an issue.
I did a templated version in my datetime code which is essentially the function
above, adjusted to take multiple units into account. Once my datetime code has
been put into Phobos, replacing the current std.datetime, this bug should be
fixed. But the above version of toMicroseconds should fix the problem for now.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5263] New: rationalize differences between phobos and druntime intrinsic.d
http://d.puremagic.com/issues/show_bug.cgi?id=5263 Summary: rationalize differences between phobos and druntime intrinsic.d Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Keywords: patch Severity: normal Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts bra...@puremagic.com 2010-11-23 22:06:38 PST --- Created an attachment (id=828) diff to druntime's copy of intrinsic.d The two copies of intrinsic.d and .di have drifted. This rationalizes them as well as switching from uint* to size_t* for future 64 bit compatibility. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5263] rationalize differences between phobos and druntime intrinsic.d
http://d.puremagic.com/issues/show_bug.cgi?id=5263 --- Comment #1 from Brad Roberts bra...@puremagic.com 2010-11-23 22:07:33 PST --- Created an attachment (id=829) the phobos half of the rationalization The phobos half of the rationalization -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5264] New: x86_64 changes for druntime 2
http://d.puremagic.com/issues/show_bug.cgi?id=5264 Summary: x86_64 changes for druntime 2 Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts bra...@puremagic.com 2010-11-23 22:17:28 PST --- Created an attachment (id=830) most of the changes to get druntime 2 to build with dmd -m64 I spent a couple hours today working on getting druntime 2 to build with the x86_64 dmd compiler. It's not 100% so far, but almost there. What's broken: 1) lifetime.d has 4 va_arg calls commented out. The compiler croaks with: src/core/stdc/stdarg.d(229): Error: static assert not a valid argument type for va_arg src/rt/lifetime.d(814):instantiated from here: va_arg!(ulong) 2) lifetime.d _d_arrayappendcT needs to be altered to work with varargs properly. The 64 bit support is fragile/hacky/whatever and I haven't pieced together how this code evolved between d1 and d2's runtimes. 3) lifetime.d _d_arrayshrinkfit() crashes the backend of the compiler: function _d_arrayshrinkfit cod2.c:1769: assert(stackpush == stackpushsave) // 0xfffc == 0 Normally I'd create 3 bugs since there's 3 different issues, but I don't think that'd be useful here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5264] x86_64 changes for druntime 2
http://d.puremagic.com/issues/show_bug.cgi?id=5264
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|s...@invisibleduck.org |bra...@puremagic.com
--- Comment #1 from Brad Roberts bra...@puremagic.com 2010-11-23 23:15:13 PST
---
Ok, for #2, I think the right answer is to change _d_arrayappendcT to this:
extern (C) void[] _d_arrayappendcT(TypeInfo ti, Array *x, ...)
{
version(X86)
{
byte *argp = cast(byte*)(ti + 2);
return _d_arrayappendT(ti, x, argp[0..1]);
}
else version(X86_64)
{
va_list ap;
va_start(ap, __va_argsave);
byte[] argp;
va_arg(ap, ti.next, argp);
return _d_arrayappendT(ti, x, argp);
}
else
static assert(false, unknown version);
}
Builds at least, but can't test it yet.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
