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

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
>

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