http://bugzilla.gdcproject.org/show_bug.cgi?id=178

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #1 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
it is reproducible on my GNU/Linux x86 box. moreover, it's reproducible with DMD, so it's a general frontend bug. mind filling an issue in DMD bugzilla?

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #2 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
ah, i looked closer at your sample and found that it's an expected behavior. ;-)

what going on here is CTFE. as `ResetHandler` never exits, CTFE interpreter never exits too. it's possible to write a simple enless loop detector in interpreter, but it's impossible to detect all kind of endless loops.

so i don't know how to solve this: setting some arbitrary limit on loop iteration will simply hide the problem, but won't solve it.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #3 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
p.s. but for this particular case CTFE can fail early, as `Reset_Handler` is `void`, so there is no sense to interpret it.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #4 from Jens Bauer <jens-bugzilla@gpio.dk> ---
Being new to D is probably why this confuses me.

Eg.. I am expecting the compiler to generate code, not execute it.

The GDC I've build is a cross-compiler, thus it generates code for a different
architecture than my host architecture.
Would GDC really 'run' my code ?

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #5 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
see the part about CTFE here: http://dlang.org/function.html#interpretation

one of the features of D is that it can run code in *compile* *time* (hence the "CTFE" term — it's "Compile Time Function Evaluation"). compiler can run D code while compiling your source and use the result to initialise variables.

in your case compiler tries to evaluate `Reset_Handler()` and use it's return value to init array element. it's a very powerful feature, as you can calculate various tables without resorting to external "generators". i, for example, using that to generate parity flag table in my Z80 emulator:

auto genParityTable () {
  ubyte[256] t;
  foreach (immutable f; 0..256) {
    int n, p;
    for (n = f, p = 0; n != 0; n >>= 1) p ^= n&0x01;
    t[f] = (p ? 0 : 1);
  }
  return t;
}
private immutable ubyte[256] tblParity = genParityTable();

here compiler executes `genParityTable()` when it compiling my code and using it's result to init `tblParity`.

it's vital to understand that `tblParity` is initialized in COMPILE time, there is no runtime function calls.

the power of D, yeah.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #6 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
i.e. D compiler can interpret D code in compile time, it has full-featured D interpreter built in. ;-)

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #7 from Jens Bauer <jens-bugzilla@gpio.dk> ---
(In reply to Ketmar Dark from comment #5)
> private immutable ubyte[256] tblParity = genParityTable();
> 
> it's vital to understand that `tblParity` is initialized in COMPILE time, there is no runtime function calls.

I agree; CTFE is a good feature, indeed.
Does this happen only for immutable assignments ?
If so, then the problem is not so big, but it still is nasty, when the compiler
locks up.

Detection could probably be tricky. I would expect that even if checking the
condition given to while() could fail, so that when there's in fact no lock-up,
it would happen as well.
And a naive 32-bit loop-counter would probably not do well either.

Recognizing a while(constant){ ... } would of course help.
I think that it all boils down to if there's a branch-back without any kind of
conditional exit instruction in the generated code, it would work quite well
(but would probably not be completely foolproof).

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #8 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to Jens Bauer from comment #7)
> I agree; CTFE is a good feature, indeed.
> Does this happen only for immutable assignments ?

and for array initialization. you'd better read some D book to get it right, as i really bad at explanations. ;-) i "feel" it, but can't "word" it.


> I think that it all boils down to if there's a branch-back without any kind of conditional exit instruction in the generated code, it would work quite well (but would probably not be completely foolproof).

this will require deeper code analysis in frontend. it's doable, but i don't know if someone will take that task.

in your case, however, CTFE engine should abort before even trying to evaluate anything, as `void` is not a value suitable for array element. this check is easier, and it worth filling a bug in DMD bugzilla.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #9 from Jens Bauer <jens-bugzilla@gpio.dk> ---
(In reply to Ketmar Dark from comment #8)
> in your case, however, CTFE engine should abort before even trying to evaluate anything, as `void` is not a value suitable for array element. this check is easier, and it worth filling a bug in DMD bugzilla.

Yes, I agree. Evaluating the function is also redundant, as void is specified to return 0.

If I had made it return an int, the case would be different.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=178

--- Comment #10 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I raised this upstream.

https://issues.dlang.org/show_bug.cgi?id=14419

-- 
You are receiving this mail because:
You are watching all bug changes.