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