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

[Brad Roberts]

It started failing as soon as the new test was merged, so it's not really a regression, just looks like one.  The test
case can be further reduced to just:

module bug;

void blah(int[char] as)
{
    auto k = [6: as];
}

More tonight..

On 5/24/2011 2:03 AM, Don Clugston wrote:
> 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
>>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals