[Issue 3264] -O causes wrong "used before set" error when using enum.

2009-08-26 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3264


Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com




--- Comment #1 from Walter Bright   2009-08-26 
16:25:35 PDT ---
This bug does affect D1, but in different ways.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 1625] CTFE: cannot evaluate function when return type includes a union

2009-08-26 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1625


Don  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au
Summary|cannot evaluate function|CTFE: cannot evaluate
   |@compile-time when return   |function when return type
   |type includes a union   |includes a union




--- Comment #3 from Don   2009-08-26 09:45:28 PDT ---
Actually it cannot evaluate any function which involves reading the value of a
union. (It can WRITE to a union, though!)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 2665] ICE(cod4.c) on certain const struct function return types

2009-08-26 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2665





--- Comment #4 from Don   2009-08-26 00:56:09 PDT ---
(In reply to comment #3)
> "const(struct)" is the common component for the issues related to ICE(cod4.c)
> 35#.
> Here is a list of problematic code:
> In the function "cdeq" which generates code for an assignment
> 
>  sz = tysize[tyml];
>  assert((int)sz > 0); <- failed this assertion.
> 
> where tyml is a type of lvalue, sz represents # of bytes to transfer.
> 
> This issue is apparently due to bypass of type-size{tysize} registration for
> const(struct), besides registration for struct itself is done.

A variation of that test case is interesting:
struct A {}
struct B {
const A a;
}

void f() {
//A a;//  if you uncomment this, it doesn't ICE!
B b = B(A());
}
Comparing the intermediate code using elem_print(e); shows that there's a
difference between the two cases by the start of codelem().
 But there's no difference in the code generated by DeclarationExp::toElem() in
e2ir.c. Somewhere between the two, an optimisation/rewriting step is performed
in the correct case, but not in the ICE case. I haven't yet worked out where it
happens.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---