CTFE is getting there

Martin Nowak dawg at dawgfoto.de
Sat Nov 12 16:28:54 PST 2011


On Sun, 13 Nov 2011 00:38:58 +0100, bearophile <bearophileHUGS at lycos.com>  
wrote:

> With the recent rounds of improvements to the compile-time evaluation,  
> mostly from Don, CTFE is now able to run a significant percentage of D  
> code. Some problems left:
>
>
> int foo1() {
>     enum int[] array = [1];
>     return 1;
> }
> int foo2() { // like map
>     struct Bar {
>         this(int x) {}
>     }
>     Bar(1);
>     return 2;
> }
> int foo3() { // like std.math.poly
>     version (D_InlineAsm_X86) {
>         asm {
>             nop;
>         }
>     } else {
>         // fallback code here
>     }
>     return 3;
> }
> void main() {
>     enum int f1 = foo1();
>     enum int f2 = foo2();
>     enum int f3 = foo3();
> }
>
>
>
> Another problem that I have not fully reduced yet:
> http://d.puremagic.com/issues/show_bug.cgi?id=6934
>
>
> I have recently asked regarding foo3 in D.learn. It's a bit sad case,  
> because there are some functions like std.math.poly that define usable  
> fallback code, but CTFE defines D_InlineAsm_X86 so it tries to run the  
> assembly code, and fails.
>
> Bye,
> bearophile

D_InlineAsm_X86 is just a normal version tag and does not imply asm code,  
so it has to.
IASM functions should redirect __ctfe to their non asm fallback.


More information about the Digitalmars-d mailing list