On Sun, 13 Nov 2011 00:38:58 +0100, bearophile <[email protected]>
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.
