yl2x is a DigitalMars-specific builtin

[ibuclaw]

Fix linker errors building with gdc, much more to come... :-)

[WalterBright]

The y2lx instruction is x86 specific, not Digital Mars specific.

[ibuclaw]

Is INLINE_YL2X set in the DMD compiler? That would be one compromise if it did.

[WalterBright]

Is INLINE_YL2X set in the DMD compiler?

No. Just provide a yl2x function in the GDC port.

[ibuclaw]

No. Just provide a yl2x function in the GDC port.

I'd rather not. There is no way to map it to any architecture (even x86) on my side.

[WalterBright]

Why wouldn't inline assembler work?

[ibuclaw]

It goes against convention - and will be a red flag for any reviewers in upstream GCC.

It's difficult enough fixing the front-end so it doesn't care about what target it is generating code for, let alone what host we will be running on.

[yebblies]

This change means that ddmd built with gdc won't be able to evaluate the yl2x intrinsics at compile time, while dmd built with gcc can? Does gcc/gdc really not provide this builtin in some way?

[yebblies]

Sorry, hit wrong button.

[ibuclaw]

Sorry, hit wrong button.

You're lucky I'll be absent next week, or you will have something to be sorry about... :-)

This change means that ddmd built with gdc won't be able to evaluate the yl2x intrinsics at compile time, while dmd built with gcc can? Does gcc/gdc really not provide this builtin in some way?

There's log2l, but it will produce wildly different results from fy2lx - that is to say, dmd's fy2lx will give incorrectly rounded results vs. log2l.

[yebblies]

You're lucky I'll be absent next week, or you will have something to be sorry about... :-)

You're not coming this year?

There's log2l, but it will produce wildly different results from fy2lx - that is to say, dmd's fy2lx will give incorrectly rounded results vs. log2l.

Hmm ok. Do we have a ctfeable implementation in core.math? If so, can we just completely remove ctfe builtin support? It seems like much too obscure a thing to have compiler code dedicated to it.

I don't want a compiler built by dmd and a compiler built by gdc to have different capabilities, I'm sure you can agree.

[ibuclaw]

Do we have a ctfeable implementation in core.math?

No.

It seems like much too obscure a thing to have compiler code dedicated to it

This is what I said in the original PR for CTFE-yl2x! You still merged it in despite my warnings.

I don't want a compiler built by dmd and a compiler built by gdc to have different capabilities

On that note, std.math.tan is a problematic function too that DMD treats like a built-in.

[yebblies]

Do we have a ctfeable implementation in core.math?

No.

Oh yeah, it doesn't need to be ctfeable. Just present. Does GDC druntime not provide this either?

This is what I said in the original PR for CTFE-yl2x! You still merged it in despite my warnings.

I didn't merge it.

On that note, std.math.tan is a problematic function too that DMD treats like a built-in.

What's so problematic about tan?

But yeah, we should probably avoid adding ctfe intrinsics that depend on the host compiler/runtime.

[ibuclaw]

What's so problematic about tan?

It's a weird half/half. DMD recognises it as a CTFE-able builtin, but runtime it uses inline assembler.

For simplicity on my part, I only implement body-less functions in std.math/core.math as intrinsics.

[ibuclaw]

And... I found a case where the implied use of yl2x broke gdc, along with every non-x86 target. dlang/phobos#3309

Sigh - We should put a stop to this by removing uses of yl2x from std.math. They might have been useful in the beginning. But not anymore.

[yebblies]

Or by implementing a portable version somewhere.

[ibuclaw]

Or by implementing a portable version somewhere.

It's caled log2, I did this 2 years ago.

dlang/phobos@bf2b2a1

[MartinNowak]

else assert(0);