www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Error: llroundl cannot be interpreted at compile time, because it has

reply mw <mingwu gmail.com> writes:
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?
Jun 08 2020
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
Jun 08 2020
parent reply mw <mingwu gmail.com> writes:
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.
Jun 08 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Jun 08 2020
parent mw <mingwu gmail.com> writes:
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).
Jun 08 2020
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Jun 08 2020