At Dconf Manu asked to use pow expressions at CTFE.
Luckily he can.
powExpressions work at ctfe.

On 09.05.2016 11:24, Stefan Koch wrote:
> At Dconf Manu asked to use pow expressions at CTFE.
> Luckily he can.
> powExpressions work at ctfe.

enum x=2.4^^4.5;

DMD master:

./../../phobos/std/math.d(4857): Error: cannot convert &real to ushort* at compile time
./../../phobos/std/math.d(6113):        called from here: isNaN(y)
./../../phobos/std/math.d(6303):        called from here: impl(cast(real)x, cast(real)y)
ctfepow.d(1):        called from here: pow(2.4, 4.5)

On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote:
> On 09.05.2016 11:24, Stefan Koch wrote:
>> At Dconf Manu asked to use pow expressions at CTFE.
>> Luckily he can.
>> powExpressions work at ctfe.
>
> enum x=2.4^^4.5;
>
> DMD master:
>
> ./../../phobos/std/math.d(4857): Error: cannot convert &real to ushort* at compile time
> ./../../phobos/std/math.d(6113):        called from here: isNaN(y)
> ./../../phobos/std/math.d(6303):        called from here: impl(cast(real)x, cast(real)y)
> ctfepow.d(1):        called from here: pow(2.4, 4.5)

I see.
I did not test a floating point value at the left-hand site.
working on a fix.

On Monday, 9 May 2016 at 12:33:33 UTC, Stefan Koch wrote:
> On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote:
>> On 09.05.2016 11:24, Stefan Koch wrote:
>>> At Dconf Manu asked to use pow expressions at CTFE.
>>> Luckily he can.
>>> powExpressions work at ctfe.
>>
>> enum x=2.4^^4.5;
>>
>> DMD master:
>>
>> ./../../phobos/std/math.d(4857): Error: cannot convert &real to ushort* at compile time
>> ./../../phobos/std/math.d(6113):        called from here: isNaN(y)
>> ./../../phobos/std/math.d(6303):        called from here: impl(cast(real)x, cast(real)y)
>> ctfepow.d(1):        called from here: pow(2.4, 4.5)
>
> I see.
> I did not test a floating point value at the left-hand site.
> working on a fix.

okay the workaround would be just to avoid pointer casts.
And use bitwise operations to convert the values.
Another option is not to jit std.math routines at ctfe.

I would prefer the second option, any opinions ?

On Monday, 9 May 2016 at 12:49:16 UTC, Stefan Koch wrote:
> On Monday, 9 May 2016 at 12:33:33 UTC, Stefan Koch wrote:
>> On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote:
>>> [...]
>>
>> I see.
>> I did not test a floating point value at the left-hand site.
>> working on a fix.
>
> okay the workaround would be just to avoid pointer casts.
> And use bitwise operations to convert the values.
> Another option is not to jit std.math routines at ctfe.
>
> I would prefer the second option, any opinions ?

Yet another option is using soft-float for ctfe, that would also prevent issues with cross-compiled binarys that have ctfe in them.

On Monday, May 09, 2016 13:02:50 Stefan Koch via Digitalmars-d wrote:
> that would also
> prevent issues with cross-compiled binarys that have ctfe in them.

That's going to be pretty critical in the long run, especially now that the compiler frontend is in D.

- Jonathan M Davis

On 9 May 2016 at 23:02, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 9 May 2016 at 12:49:16 UTC, Stefan Koch wrote:
>>
>> On Monday, 9 May 2016 at 12:33:33 UTC, Stefan Koch wrote:
>>>
>>> On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote:
>>>>
>>>> [...]
>>>
>>>
>>> I see.
>>> I did not test a floating point value at the left-hand site.
>>> working on a fix.
>>
>>
>> okay the workaround would be just to avoid pointer casts.
>> And use bitwise operations to convert the values.
>> Another option is not to jit std.math routines at ctfe.
>>
>> I would prefer the second option, any opinions ?
>
>
> Yet another option is using soft-float for ctfe, that would also prevent issues with cross-compiled binarys that have ctfe in them.

This is almost certainly the correct solution... at least a soft-float implementation of pow, since it's an operator ;)