Version 10.00 (RC1) is now available

[Pelle]

But on my system switching between 32 and 64bits the libraries path is changed in a wrong way: setting "lib\Win" for 64 bits compiles and "lib\Win64" for 32bits code. Manually fixing the libraries path in the project options->macro, compilation completes successfully.
Is it my problem or is a small IDE bug?

It's a bug (brainfart). Apparently it's not enough to have the correct statements, they need to be placed in the correct order too... 

[jullien]

jullien:
I have tried to follow "Annex K: Bounds-checking interfaces" - an optional part of the C11 and C17 standard (but possibly removed from the C2X standard). I think this proposal originally may have come from Microsoft, but Microsoft and the standard text have never been in total sync. Anyway, I rather stick to standard C (even optional parts) rather than this weeks Microsoft "standard"...

Hi I understand you point (even if breaks Windows compatible code). I've no issue to use snprintf instead as my code encapsulates all _snprintf_s calls.
I've found an issue with 32 code porting my OpenLisp Lisp compiler. I get a Fatal error somewhere. The x64 has no issue and passed all tests. I'll investage in the next few days.

[Pelle]

Hi I understand you point (even if breaks Windows compatible code). I've no issue to use snprintf instead as my code encapsulates all _snprintf_s calls.
I've found an issue with 32 code porting my OpenLisp Lisp compiler. I get a Fatal error somewhere. The x64 has no issue and passed all tests. I'll investage in the next few days.

OK. I will wait for that before doing any investigation on my own.

( This is not the year for a big gathering, but for the next few days I will do a tiny version of this anyway so...: https://sweden.se/culture-traditions/midsummer/ )

[Akko]

Great work !!  Thank you so much, Pelle !!

My own Forth compiler project compiles and runs flawless so far.  :-)

For the upcoming version 11, I will be happy to find _int128_t and __float80 too  ;o)
(only meant as cautious and respectful suggestion of course)

[TimoVJL]

I have problems with Add-Ins with this version.
For example, this code crash, if optimization is used, in line
lstrcpy(szFile+nLen, pP);

Code: [Select]

ADDINAPI void WINAPI AddInCommandEx(int idCmd, LPCVOID pcvData)
{
if (idCmd == ID_CMD)
{
HWND hwnd = AddIn_GetActiveDocument(g_hwndMain);
AddIn_ClearOutput(g_hwndMain);
if (hwnd)
{
ADDIN_DOCUMENT_INFO aidi;
int nLen;
TCHAR szFile[260], *pP;
aidi.cbSize = sizeof(ADDIN_DOCUMENT_INFO);
AddIn_GetDocumentInfo(hwnd, &aidi);
nLen = lstrlen(aidi.szFilename);
if (nLen) {
//AddIn_WriteOutput(g_hwndMain, aidi.szFilename);
pP = aidi.szFilename + nLen - 1;
while(*pP && *pP != '.') pP--; // find ext
lstrcpy(pP+1, TEXT("obj"));
while(*pP && *pP != '\\') pP--; // find name
//AddIn_WriteOutput(g_hwndMain, pP);
nLen = AddIn_GetProjectSymbol(g_hwndProj, TEXT("POC_PROJECT_OUTPUTDIR"), szFile, sizeof(szFile));
//lstrcpy(&szFile[nLen], pP);
lstrcpy(szFile+nLen, pP);
//AddIn_WriteOutput(g_hwndMain, szFile);
DumpObj(g_hwndMain, szFile);
}
}
}
}
Attached version is without optimizations.

[John Z]

Pelle,

 - Thanks very much for all of the work on RC1 of version 10.  I confirm that the _strrichr bug is fixed.
Have not yet done much other testing. 

Best Regards,
John

[Grincheux]

I have re-compiled many programs they run well. I appreciate that parts of libraries like SQLite are re-aligned.
This is the only thing new that I found. Where are the themes? Where are they hidden?
Mister Pelle you and your compiler are the best.

[John Z]

Themes are under Tools-Options-Environment

[Pelle]

Great work !!  Thank you so much, Pelle !!

Thanks!

For the upcoming version 11, I will be happy to find _int128_t and __float80 too  ;o)

I'm just curious: why do you need it?

It should be possible to use intrinsics for this, no real need for built-in support. Maybe something like the following (untested).

Code: [Select]

static inline __m128i __vectorcall add_int128(__m128i v1, __m128i v2)
{
    unsigned __int64 lo = _mm_extract_epi64(v1, 0) + _mm_extract_epi64(v2, 0);
    unsigned __int64 hi = _mm_extract_epi64(v1, 1) + _mm_extract_epi64(v2, 1) + (lo < (unsigned __int64)_mm_extract_epi64(v2, 0));
    return _mm_set_epi64x(hi, lo);
}

static inline __m128i __vectorcall mul_int128(__m128i v1, __m128i v2)
{
    __int64 hi, lo = __mul128(_mm_extract_epi64(v1, 0), _mm_extract_epi64(v2, 0), &hi);
    hi += (_mm_extract_epi64(v1, 1) * _mm_extract_epi64(v2, 0)) +
          (_mm_extract_epi64(v1, 0) * _mm_extract_epi64(v2, 1));
    return _mm_set_epi64x(hi, lo);
}

// and so on...


[Akko]

For the upcoming version 11, I will be happy to find _int128_t and __float80 too  ;o)

I'm just curious: why do you need it?

x86-64 CPUs support 80-bit extended precision floating-point numbers on the chip.
A number of C compilers make them availabe to users as long doubles.
They are very helpful to keep error accumulation in repeated calculations (eg simulation)
below the normal double format __float64 threshold.
Since __float80's have a 64-bit mantissa, conversion between 64-bit integers and long doubles
is lossless.

gcc supports _in128_t types, MSVC also has a _umul128, et cetera
Double quad integers are are needed in cryptography for instance.
They are also useful for extremely fast comparison of short strings (symbols).

[Pelle]

x86-64 CPUs support 80-bit extended precision floating-point numbers on the chip.
A number of C compilers make them availabe to users as long doubles.
They are very helpful to keep error accumulation in repeated calculations (eg simulation)
below the normal double format __float64 threshold.
Since __float80's have a 64-bit mantissa, conversion between 64-bit integers and long doubles
is lossless.

The only way to handle 80-bit floats in hardware is through X87, which is mostly a thing of the past. The modern way is to use SIMD, possibly doing several calculations in parallel, but then you are limited to single or double precision floats (32 or 64 bits).

gcc supports _in128_t types, MSVC also has a _umul128, et cetera
Double quad integers are are needed in cryptography for instance.
They are also useful for extremely fast comparison of short strings (symbols).

There is almost no hardware support for 128-bit integers (AND, OR, XOR, and not much else). No ADD, SUB, MUL, DIV etc. The way it's done today is by splitting up the calculation in 64-bit parts. I have already shown how to do this (using __mul128() which is effectively the same thing as __umul128(): 64x64=>128).

I see no reason to add 128-bit integers until there is proper hardware support for it.

[Marco]

Hello,

First of all, a big thank you for a such a great compiler, Pelle. I can just imagine the hard work behind this project.

Well, I compiled some my projects with this new version, but I receive the following error:

error #2168: Operands of '=' have incompatible types 'void *' and 'void'.

Here is the code that give the error (it's just an example to reproduce the error):

Code: [Select]

WCHAR buffer[32];
lstrcpyW(buffer, L"test");
WCHAR buff [ lstrlenW(buffer) +1 ];        // <-- error

If I change the above code by using a variable, it's compiled with no error:

Code: [Select]

WCHAR buffer[32];
lstrcpyW(buffer, L"test");
int n = lstrlenW(buffer) +1;
WCHAR buff [ n ];        // <-- no error

Is there an "easy" way to fix it? I have something like more than 200 lines similar to the above first code.

Thank you.

[Pelle]

Well, I compiled some my projects with this new version, but I receive the following error:
error #2168: Operands of '=' have incompatible types 'void *' and 'void'.

You have manged to find a set of operations that trigger a compiler bug, a bug that sailed through ~2500 compiler tests, so I guess "congratulations"... (and I now have ~2500 + 1 tests) 

Is there an "easy" way to fix it? I have something like more than 200 lines similar to the above first code.

Yes. Sit back, relax, and wait for RC2...

[Marco]

You have manged to find a set of operations that trigger a compiler bug, a bug that sailed through ~2500 compiler tests, so I guess "congratulations"... (and I now have ~2500 + 1 tests) 

Oh well, "beta tester" is my second name Joking aside, thank you very much for your reply. I'll wait for RC2.

[MrBcx]

Well, I compiled some my projects with this new version, but I receive the following error:
error #2168: Operands of '=' have incompatible types 'void *' and 'void'.

You have manged to find a set of operations that trigger a compiler bug, a bug that sailed through ~2500 compiler tests, so I guess "congratulations"... (and I now have ~2500 + 1 tests) 

Is there an "easy" way to fix it? I have something like more than 200 lines similar to the above first code.

Yes. Sit back, relax, and wait for RC2...

Thanks for the chuckle ...

I love a good sense of humor!