Eigen Compiler Suite

It should truncate.

Ok, I see.

I should mention that I used the x86 version of 0.0.40 and the arm64 version of 0.0.41.

Since I assumed that this again is an issue which was fixed from 0.0.40 to 0.0.41, I now updated all used ECS files of my branch to version 0.0.41.

But I still get rounded instead of truncated values (i.e. both a and b in float_convert2 and double_convert become 3)!

I already attached the source in the above comment; here also the generated cod file.

Is this possibly a machine code generator issue, or am I doing something wrong?

Are you using the legacy FPU or media-float instructions?

I'm using media-float, i.e. in compiler.cpp I set:

#elif defined AMD32BACKEND

    #include "amd64.hpp" 
    #include "amd64generator.hpp" 

    #define NAMESUFFIX "amd32" 
    static AMD64::Generator generator {diagnostics, stringPool, charset, AMD64::ProtectedMode, true, true};

didn't try yet with the legacy FPU yet; shall I try it?

It should work with the legacy FPU which is why I wasn't able to reproduce the problem. Appearently, the media-float instructions require initialisation of the rounding modes as well. The attached patch fixes this oversight for the 64-bit mode. You might have to adapt the code for your specialised 32-bit case. Thanks for reporting.

Thanks for the patch. I applied it to my version of runtime.c and repeated the test with convert.c, but the result is the same (2.7 "truncates" to 3).

Meanwhile I also tried with

AMD64::Generator generator {diagnostics, stringPool, charset, AMD64::ProtectedMode, false, true};

You might have to adapt the code for your specialised 32-bit case.

What do you mean by that? I have very little experience with i386 nor "media-float".

Replace the inline assembler for the 32-bit case with this code:

.initdata _init_fpu
    .required
    push    dword 00'0111'1111'1000'0000b
    ldmxcsr    dword [esp]
    pop    eax

That's the solution, great, thank you very much!

Please note that the generated floating-point conversion to and from unsigned integers don't behave properly in 32-bit mode.

In what respect? I didn's see an issue with unsigned ints for the positive cases in convert.c.

Unsigned integer values are basically treated as signed integers during floating-point conversions. There is no problem as long as their representations match.