Rogue version tokens when specifying -mtriple=...

[TurkeyMan]

Okay, so maybe this is a mess; I'm using a build of LDC called ldc2-1.39.0-windows-multilib, and it includes binary libs for win32 and win64 in the distribution; but I expect that all LDC builds are essentially the same and can build for any supported target given the right flags?

So, I'm doing some cross-compiling tests, trying to make sure my codegen looks okay and get my linking situation in order... using that windows compiler distribution.

What I'm seeing, is that when I specify -mtriple=arm-none-eabi for instance, version = Windows is still active, and all the Windows version blocks seem to be trying to compile.

I would like to think that supplying a triple might motivate the version macros to conform with the target I've specified?

core.stdc seems to have a lot of problems when I specify an alternative target.

[thewilsonator]

What should happen (and does so for me on run.dlang.io) is version (FreeStanding) is set.

[TurkeyMan]

Actually, my diagnistic approach is wrong... there's some weird stuff going on.
I'm finding that code like this is emitting a compile error:

pragma(mangle, muslRedirTime64Mangle!("mktime", "__mktime64"))
@system time_t  mktime(scope tm* timeptr); // @system: MT-Safe env locale

1>C:\dev\D\ldc2-1.39.0-windows-multilib\bin\..\import\core\stdc\time.d(39): error : undefined identifier `tm`

So it complains about the missing identifier tm, but then if I put static assert(false); on the line immediately before that declaration, the static assert does NOT fire off... which is how I was trying to work out which version blocks are alive or dead...

static assert(false); // SURELY THIS SHOULD EMIT AN ERROR?!
pragma(mangle, muslRedirTime64Mangle!("mktime", "__mktime64"))
@system time_t  mktime(scope tm* timeptr); // @system: MT-Safe env locale

1>C:\dev\D\ldc2-1.39.0-windows-multilib\bin\..\import\core\stdc\time.d(40): error : undefined identifier `tm`

Any insight on this? I'm not sure what tools I can use to explore the conditional compilation situation in the code if static assert doesn't work :/

[TurkeyMan]

For instance, there's code blocks like this all over the place:

version (Posix)
    public import core.sys.posix.stdc.time;
else version (Windows)
    public import core.sys.windows.stdc.time;
else
    static assert(0, "unsupported system");

Neither Posix or Windows are specified, it should emit the "unsupported system" error, but it's not doing that anywhere...

[thewilsonator]

Any insight on this? I'm not sure what tools I can use to explore the conditional compilation situation in the code if static assert doesn't work :/

First of all, can you pass -v to LDC and get a list of the predefined versions? The output should look something like:

binary    /dlang/ldc-1.38.0/bin/ldc2
version   1.38.0 (DMD v2.108.1, LLVM 18.1.5)
config    /dlang/ldc-1.38.0/etc/ldc2.conf (arm-none-unknown-eabi)
predefs   LDC all D_Version2 assert D_PreConditions D_PostConditions D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo ARM ARM_SoftFP D_HardFloat LittleEndian FreeStanding 

[kinke]

The mentioned problems are most likely caused because static asserts are evaluated way later, similar to static if happening way after version branches (all frontend territory obviously). The predefined versions should be fine.

[TurkeyMan]

static assert is evaluated way later than the validity of a function parameter list's semantic evaluation?
That doesn't make sense; static assert is used specifically to catch error conditions and inform the user about the error before that error impacts on the code that the static assert is trying to deliver an error message about...
What's the point of static assert at all if the condition that it's meant to tell you about is able to act on the code below before it tells you?

[kinke]

This isn't the place to discuss this, there are surely filed upstream issues about this, like https://issues.dlang.org/show_bug.cgi?id=16665 after a quick search.