[dmd-internals] compilable/interpret3.d fails on 64 bit

Don Clugston dclugston at googlemail.com
Tue May 24 02:03:57 PDT 2011


That's failing in the object file generation, so in theory CTFE should
not be relevant. Pretty much the only thing CTFE could do that would
cause this error would be to corrupt the AA literal somehow, in which
case repeating the static assert would _probably_ fail (during CTFE):
static assert(blaz()==67);
static assert(blaz()==67);
It could also be a constant-folding bug -- but in that case, I would
expect it to still fail if the static assert were removed.


On 23 May 2011 10:24, Brad Roberts <braddr at puremagic.com> wrote:
> I spent a few minutes narrowing down what's failing on all the 64 bit tests:
>
> module bug;
>
> void blah(int[char] as)
> {
>    auto k = [6: as];
>    as = k[6];
> }
> int blaz()
> {
>    int[char] q;
>    blah(q);
>    return 67;
> }
> static assert(blaz()==67);
>
> $ dmd -m64 -c bug.d
>
> #0  0x0818a0c1 in TemplateInstance::semantic (this=0x8260638, sc=0x0, fargs=0x0) at template.c:3774
> #1  0x0818a07c in TemplateInstance::semantic (this=0x8260638, sc=0x0) at template.c:3744
> #2  0x0813fcdd in TypeAArray::getImpl (this=0x8225a98) at mtype.c:4062
> #3  0x0819712d in TypeInfoAssociativeArrayDeclaration::toDt (this=0x8260200, pdt=0x8223218) at typinf.c:428
> #4  0x0819823e in TypeInfoDeclaration::toObjFile (this=0x8260200, multiobj=0) at typinf.c:750
> #5  0x081960ee in Type::getTypeInfo (this=0x8225a98, sc=0x0) at typinf.c:147
> #6  0x0819707e in TypeInfoAssociativeArrayDeclaration::toDt (this=0x8260040, pdt=0x8222cb4) at typinf.c:421
> #7  0x0819823e in TypeInfoDeclaration::toObjFile (this=0x8260040, multiobj=0) at typinf.c:750
> #8  0x081960ee in Type::getTypeInfo (this=0x825cdf0, sc=0x0) at typinf.c:147
> #9  0x080c672d in AssocArrayLiteralExp::toElem (this=0x825cd60, irs=0xffffcd84) at e2ir.c:4843
> #10 0x080bf5a1 in BinExp::toElemBin (this=0x825cea0, irs=0xffffcd84, op=54) at e2ir.c:2076
> #11 0x080c1db7 in AssignExp::toElem (this=0x825cea0, irs=0xffffcd84) at e2ir.c:2989
> #12 0x080bccb0 in Dsymbol_toElem (s=0x8225da0, irs=0xffffcd84) at e2ir.c:1170
> #13 0x080bcf87 in DeclarationExp::toElem (this=0x8225e50, irs=0xffffcd84) at e2ir.c:1234
> #14 0x080bbfe8 in Expression::toElemDtor (this=0x8225e50, irs=0xffffcd84) at e2ir.c:700
> #15 0x0816bd40 in ExpStatement::toIR (this=0x8225e38, irs=0xffffcd84) at s2ir.c:1314
> #16 0x0816bdae in CompoundStatement::toIR (this=0x8225f78, irs=0xffffcd84) at s2ir.c:1330
> #17 0x0816bdae in CompoundStatement::toIR (this=0x825cfb0, irs=0xffffcd84) at s2ir.c:1330
> #18 0x081153b4 in FuncDeclaration::toObjFile (this=0x8225b70, multiobj=0) at glue.c:928
> #19 0x08113d52 in Module::genobjfile (this=0x82254e0, multiobj=0) at glue.c:279
> #20 0x08133481 in main (argc=11, argv=0x821b500) at mars.c:1317
>
> I'll continue digging tomorrow night if Don hasn't figured it out already.  Looks like it's directly related to aa ctfe
> handling.  Somehow a TypeAArray instance is missing it's scope.  Not sure why it works on 32 bit but not 64 bit yet
> either.
>
> Later,
> Brad
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>


More information about the dmd-internals mailing list