[Issue 3553] ICE when a function argument defaults to __LINE__
http://d.puremagic.com/issues/show_bug.cgi?id=3553
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Don clugd...@yahoo.com.au 2009-11-26 23:55:23 PST ---
There are two issues. One is that this use of __LINE__ is a very special case.
The code in Parser::parseDefaultInitExp() in parse.c is unlikely to be correct
-- it only treats a default of __LINE__ specially; __LINE__+0 does NOT become a
LineInitExp.
But, without changing that, the immediate problem is in expression.c,
functionParameters(), around line 670.
The lineInitExp only gets resolved if it's unaltered. But, it might
have been implicitly cast. This patch fixes that.
A more complete fix would change parse.c to allow arbitrary use of __LINE__,
and to resolve recursively in expression.c looking for LineInitExp's. But
that's a pretty obscure feature; this patch is enough to fix the ICE.
Index: expression.c
===
--- expression.c(revision 267)
+++ expression.c(working copy)
@@ -667,7 +667,13 @@
}
arg = p-defaultArg;
#if DMDV2
-if (arg-op == TOKdefault)
+if (arg-op == TOKcast ((CastExp*)arg)-e1-op == TOKdefault)
+{ // The default value may have been implicitly cast
+arg = arg-copy();
+CastExp * def = (CastExp*)arg;
+def-e1 = ((DefaultInitExp *)(def-e1))-resolve(loc, sc);
+}
+else if (arg-op == TOKdefault)
{ DefaultInitExp *de = (DefaultInitExp *)arg;
arg = de-resolve(loc, sc);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3521] Optimized code access popped register
http://d.puremagic.com/issues/show_bug.cgi?id=3521
--- Comment #2 from Don clugd...@yahoo.com.au 2009-11-27 00:15:10 PST ---
I investigated this a bit, so far without success. I'm writing notes here for
when I come back to it.
It's something to do with the register allocation. The compiler is somehow
forgetting that it already assigned a register for c when doing the assignment.
I removed the assert to make disassembly even easier: this hits a breakpoint
only when compiled with -O. It only happens if c is zero. You can change the !=
into any kind of comparison, and the c=200 into c+=200, without affecting the
bug. However, changing it into ((c = 200)!=*a) avoids the bug.
void crash(int x)
{
if (x==200) return;
asm { int 3; }
}
void bug3521(int *a){
int c = 0;
*a = 0;
if ( *a || (*a != (c = 200)) )
crash(c);
}
void main (){
int x;
bug3521(x);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3553] ICE when a function argument defaults to __LINE__
http://d.puremagic.com/issues/show_bug.cgi?id=3553 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #3 from Brad Roberts bra...@puremagic.com 2009-11-27 00:22:00 PST --- Hrm.. what's that entire block of code in the 'if' doing? TOKfile and TOKline are handled down through the layers of expression parsing (primarily in parsePrimaryExp) just fine, from a quick study of the code. I haven't tried just killing that block to see what happens. Might it be better to change the two parts of parsePrimaryExp to create FileInitExp and LineInitExp's rather than StringExp and IntegerExp's respectively? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] New: Ddoc generats invalid output for documentation comments with non paired paranthasis
http://d.puremagic.com/issues/show_bug.cgi?id=3554
Summary: Ddoc generats invalid output for documentation
comments with non paired paranthasis
Product: D
Version: 2.032
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bary...@smp.if.uj.edu.pl
--- Comment #0 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-27
08:07:12 PST ---
Both this code:
/** Produces something in (a;b] */
float f(float a, float b) { return (a+b)/2.0; }
produces:
=
brbr
$(DDOC_MODULE_MEMBERS
dtbigfloat uf/u(float ia/i, float ib/i);
/big/dt
ddProduces something in (ia/i;ib/i]
)
brbr
/dd
=
and this:
/** Produces something in [a;b) */
float f(float a, float b) { return (a+b)/2.0; }
produces
=
brbr
dldtbigfloat uf/u(float ia/i, float ib/i);
/big/dt
ddProduces something in [ia/i;ib/ibrbr
/dd
/dl
)
=
Produces very broken HTML files.
It should be somthing like:
==
brbr
dldtbigfloat uf/u(float ia/i, float ib/i);
/big/dt
ddProduces something in [ia/i;ib/i)
brbr
/dd
/dl
==
Of course i can use HTML entities, or other tricks, but this breaks assumption
that ddoc comments should be both readble in code and in HTML.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
