[Issue 3010] ICE(mtype.c) function pointer type deduction puts compiler in corrupt state
http://d.puremagic.com/issues/show_bug.cgi?id=3010
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Don clugd...@yahoo.com.au 2009-05-25 00:42:42 PDT ---
At last I have a patch. The root cause is that merge() never gets called on the
.next member of TypeNext.
In Type::merge(), there's a bit of code which is commented out:
if (!deco)
{
OutBuffer buf;
StringValue *sv;
//if (next)
//next = next-merge();
---
Possibly, we need a dynamic cast to reinstate it. What I've done as an
alternative is to perform the merge inside TypeNext::toDecoBuffer. Certainly,
it shouldn't be generating the type decoration for a pointer, when it hasn't
yet generated the type decoration for the type being pointed to.
I'm not sure if that's really the correct place (it might be too late), but at
least it fixes a raft of bugs. As well as both test cases for this bug and for
bug 2672 , it also fixes the very nasty ICE bug 1994.
---
PATCH 1 (a mostly unrelated cosmetic change): mtype.c, Type::toCBuffer3(),
change
case MODinvariant:
p = invariant(;
to
case MODinvariant:
p = immutable(;
-
PATCH 2: (mtype.c) in
void TypeNext::toDecoBuffer(OutBuffer *buf, int flag)
if (!next-deco) next-merge(); // add this line
next-toDecoBuffer(buf, (flag 0x100) ? 0 : mod);
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1994] Assertion failure: 't-deco' on line 597 in file 'mtype.c' - alias of function pointer type
http://d.puremagic.com/issues/show_bug.cgi?id=1994 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||patch CC||clugd...@yahoo.com.au --- Comment #11 from Don clugd...@yahoo.com.au 2009-05-25 00:53:19 PDT --- This is fixed by my patch to bug 2672. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2952] Segfault on exit when using array ops with arrays of doubles larger than 8 elements
http://d.puremagic.com/issues/show_bug.cgi?id=2952 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Version|2.029 |1.044 OS/Version|Linux |All --- Comment #1 from Don clugd...@yahoo.com.au 2009-05-25 01:25:16 PDT --- This applies also to Windows, and to D1. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2952] Segfault on exit when using array ops with arrays of doubles larger than 8 elements
http://d.puremagic.com/issues/show_bug.cgi?id=2952 --- Comment #2 from Don clugd...@yahoo.com.au 2009-05-25 03:02:40 PDT --- I have fixed this but can't post it to the runtime source since dsource is down. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 932] static foreach in second template instantiation uses wrong tupleof
http://d.puremagic.com/issues/show_bug.cgi?id=932 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||INVALID --- Comment #2 from Don clugd...@yahoo.com.au 2009-05-25 04:31:14 PDT --- This is an invalid bug. It fails because: static assert(is( typeof(a))); will always fail (a evaluates to 'int') inside a static foreach. Correct code would be: static assert(is(typeof(C.tupleof)[i] == a)); and that passes on DMD1.045 and 2.030. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3024] array slicing bypass the stack var escape check
http://d.puremagic.com/issues/show_bug.cgi?id=3024 Koroskin Denis 2kor...@gmail.com changed: What|Removed |Added CC||2kor...@gmail.com Severity|normal |enhancement --- Comment #1 from Koroskin Denis 2kor...@gmail.com 2009-05-25 06:45:13 PDT --- It is exactly the same as byte[] tmp = v[0..16]; return tmp; Compiler can't detect operations like this ATM, and is not supposed to (according to specs). Marking it as an enhancement request, I wouldn't hold my breath for this being fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3025] New: uniform(float, float) pops first, uniform(int, int) pops last
http://d.puremagic.com/issues/show_bug.cgi?id=3025
Summary: uniform(float,float) pops first, uniform(int,int) pops
last
Product: D
Version: 2.030
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: bugzi...@digitalmars.com
ReportedBy: lio+bugzi...@lunesu.com
I noticed in random.d, uniform template, that popFront is called in different
locations for integral compared to floating point types: for integral types you
.front first and .popFront afterwards, but for floating point types you start
with .popFront and then check .front.
This has a peculiar effect: for example, if you do uniform(0.0,100.0) followed
by uniform(0,100) there's a big chance that the integral part of the first
random number is equal to the second random number.
import std.stdio, std.random;
void main()
{
writeln(uniform(0.0,100.0));
writeln(uniform(0,100));
}
The location of .popFront should be standardized, either before or after any
.front.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: [Issue 2952] Segfault on exit when using array ops with arrays of doubles larger than 8 elements
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=2952 --- Comment #2 from Don clugd...@yahoo.com.au 2009-05-25 03:02:40 PDT --- I have fixed this but can't post it to the runtime source since dsource is down. In an earlier thread on one of the newsgroups, Sean expressed a preference to bugzilla based bug reports for druntime.
[Issue 339] Alias of function pointer type cannot be forward referenced
http://d.puremagic.com/issues/show_bug.cgi?id=339
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||diagnostic
CC||clugd...@yahoo.com.au
--- Comment #2 from Don clugd...@yahoo.com.au 2009-05-25 13:53:13 PDT ---
(In reply to comment #1)
Code crashes D2.
test.d
--
uint data;
void benchmark(Algorithm alg) {
alg(data);
}
alias void function(uint) Algorithm;
C: dmd test.d
Assertion failure: 't-deco' on line 1125 in file 'mtype.c'
This ICE is fixed by my patch to bug 3010.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
