Hi,

I'm trying to build this package:

https://code.dlang.org/packages/fixed

however, the compiler error out:

ldc2-1.21.0-linux-x86_64/bin/../import/std/math.d(5783,39): Error: llroundl cannot be interpreted at compile time, because it has no available source code

Looks like it does some CTFE, but

1) I cannot find where CTFE happens in:

https://github.com/jaypha/fixed/blob/master/src/jaypha/fixed.d


2) even it does so, but why such simple function as lroundl cannot be CTFE-ed?

On Monday, 8 June 2020 at 18:08:57 UTC, mw wrote:

> 2) even it does so, but why such simple function as lroundl cannot be CTFE-ed?

Because, as the error message states, there's no source for it :) std.math calls into C math library.

On Monday, 8 June 2020 at 18:43:58 UTC, Stanislav Blinov wrote:
> On Monday, 8 June 2020 at 18:08:57 UTC, mw wrote:
>
>> 2) even it does so, but why such simple function as lroundl cannot be CTFE-ed?
>
> Because, as the error message states, there's no source for it :) std.math calls into C math library.

OK, but the compiler knows it's external C func:

  return core.stdc.math.llroundl(x);

And with a symbol-to-c-func table, it should be able to just call that C func.

This is dramatically enhance CTFE's eval ability, esp for math funcs.

On 6/8/20 2:08 PM, mw wrote:
> Hi,
> 
> I'm trying to build this package:
> 
> https://code.dlang.org/packages/fixed
> 
> however, the compiler error out:
> 
> ldc2-1.21.0-linux-x86_64/bin/../import/std/math.d(5783,39): Error: llroundl cannot be interpreted at compile time, because it has no available source code
> 
> Looks like it does some CTFE, but
> 
> 1) I cannot find where CTFE happens in:
> 
> https://github.com/jaypha/fixed/blob/master/src/jaypha/fixed.d

Are you statically initializing a Fixed type?

e.g. (in global scope):

auto myFixedVal = Fixed!2("1.5");

That constructor call is done via CTFE. The constructor calls std.math.lround. lround uses libc, which has no source available.

> 2) even it does so, but why such simple function as lroundl cannot be CTFE-ed?

The simplicity of the function has nothing to do with whether it can be CTFE. It has to do with the source code being available (as the error message indicates).

Note that the fix for the package would be to have an alternate CTFE branch, or to quit using libc.

An alternative package was created here to fix a different issue (that strings are converted to double to convert to the proper integer type), but it too will use libc when initializing a fixed point type from a double: https://github.com/m3m0ry/fixedpoint

So depending on your usage, it may solve your problem. Plus, it's actually being currently maintained, I don't think the original package is.

-Steve

On 6/8/20 2:53 PM, mw wrote:
> And with a symbol-to-c-func table, it should be able to just call that C func.

Consider that the libc available to the compiler might not be the same as the libc for the target (e.g. cross compilation).

Not just that, but this opens the compiler up to a huge hole of unpredictability and security.

-Steve

On Monday, 8 June 2020 at 19:05:45 UTC, Steven Schveighoffer wrote:
> On 6/8/20 2:53 PM, mw wrote:
>> And with a symbol-to-c-func table, it should be able to just call that C func.
>
> Consider that the libc available to the compiler might not be the same as the libc for the target (e.g. cross compilation).
>
> Not just that, but this opens the compiler up to a huge hole of unpredictability and security.

I head that.

But, can we take a pragmatic approach, not the "all-or-none" approach as I talked about in the other MI thread: (https://forum.dlang.org/post/lsnhqdoyatkzbzqbsrbb@forum.dlang.org)

We can have an approved list of C funcs that allowed to be called during CTFE? e.g. math funcs about numbers, but not network or string C funcs.

Most people define static const for some numerical values, allow C math func at CTFE may solve a large part of the problems (80-90%? just my guess).