Pelles C forum
Pelles C => Announcements => Topic started by: Pelle on June 16, 2020, 07:23:02 PM
-
Pelles C version 10.00 (Release Candidate #1) is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm
Major changes:
http://www.smorgasbordet.com/pellesc/changes_900_1000.htm
/Pelle
-
This is very good news. Thank you Pelle!
Will be use it.
-
I don't know if I am missing something but the download link posted just takes me to the older 9.0 downloads.
-
I don't know if I am missing something but the download link posted just takes me to the older 9.0 downloads.
http://www.smorgasbordet.com/pellesc/1000/setup.exe
-
Thank You Mr Pelle.
That's a good news.
I installed the new version, I don't see any change except the dialog boxes for the project options.
They were better in version 9.0.
I hoped that the new version would bring other things. I am disapointed.
Thanks for all you do for giving us the best compiler in the Windows World.
-
Thank you Pelle !
Your compiler has long been my favorite -- fast compiles, competitive performance, and thoughtful improvements.
I spent time today testing and everything is looking great.
Your tools provide Winapi developers with a sane, comfortable, and reliable alternative to Visual Studio.
-
Thanks Pelle.
-
Many thanks for working to a new version.
The RC1 dropped Windows _snprintf_ and _TRUNCATE support. I now get for example:
stacks.c(118): warning #2018: Undeclared function '_snprintf_s' (did you mean: snprintf?); assuming 'extern' returning 'int'.
stacks.c(118): error #2048: Undeclared identifier '_TRUNCATE' (did you mean: ?).
See: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-s-snprintf-s-l-snwprintf-s-snwprintf-s-l?view=vs-2019
-
:) Great Pelle!
But where can I now select to get a 32 bit or a 64 bit target?
-
Although I'm still trying to learn C I have downloaded and installed V10 Candidate #1 to help kick the tires ;D
Thanks for keeping Pelles C alive
-
:) Thanks
I have same question as Alex: where can we select 32/64bits? :)
-
bitcoin, MrBcx, TimoVJL, briman:
Thank you!
AlexN, frankie:
Thank you! I moved 32/64-bit selection to Project "Properties" (right-click a project node f.e.): easier for me to do all the changes in one place (old code was an afterthought, and not a very good one).
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"...
-
AlexN, frankie:
Thank you! I moved 32/64-bit selection to Project "Properties" (right-click a project node f.e.): easier for me to do all the changes in one place (old code was an afterthought, and not a very good one).
Thank you! I found it, but I don't expect it there.
-
AlexN, frankie:
Thank you! I moved 32/64-bit selection to Project "Properties" (right-click a project node f.e.): easier for me to do all the changes in one place (old code was an afterthought, and not a very good one).
Got it thanks.
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?
-
Thank you! I found it, but I don't expect it there.
Good... and, I guess, ... SURPRISE! :)
-
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:
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.
-
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/ (https://sweden.se/culture-traditions/midsummer/) )
-
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)
-
I have problems with Add-Ins with this version.
For example, this code crash, if optimization is used, in line
lstrcpy(szFile+nLen, pP);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.
-
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
-
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. ;D ;D ;D ;D ;D ;D
-
Themes are under Tools-Options-Environment
-
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).
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...
-
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).
-
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.
-
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):
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:
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.
-
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...
-
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 :D Joking aside, thank you very much for your reply. I'll wait for RC2.
-
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!
-
Pelle, what you think about adding:
- ASLR support ( in compiler options in IDE, such as https://forum.pellesc.de/index.php?topic=5185.msg19922#msg19922 )
- retry instruction (in LCC: Provokes a jump to the start of the try/except block );
Or this is bad ideas?
-
I just found out that a program of mine crashes when compiled with PellesC v10. This does not happen when I compile it with Pellesc v6.50. To be more precise, the program is executed correctly, but it crashes when it tries to show a Save dialog box (it uses the IFileOpenDialog COM interface). This Save dialog box checks the selected file name before closing the window (it uses the IFileDialogEvents:OnFileOk method). I used the same code used in the FileDlgs.zip file, located in the source code section of the Web site. So, I compiled that demo file, and it also crashes when the executable tries to show the Save dialog box (it shows the Open dialog box with no problems instead). It seems that the crash occurs when the program executes the instruction "hr = IFileSaveDialog_Advise(pfsd, pfde, &dwCookie);" (line 234 of the "main.c" file). I'm not a COM expert, so I don't know if it's a compiler problem or a code problem. I thought it was worth reporting it.
-
Pelle, what you think about adding:
- ASLR support ( in compiler options in IDE, such as https://forum.pellesc.de/index.php?topic=5185.msg19922#msg19922 )
It's enabled automatically by the linker when the major subsystem version is >= 6 (Windows Vista+). The default subsystem version depends on the selected subsystem type, but for "Console" and "Windows" it's 6.0 (so enabled by default). Adding an option for "/DYNAMICBASE" will likely add more confusion than help, I suspect...
- retry instruction (in LCC: Provokes a jump to the start of the try/except block );
I'm not familiar with "retry", but it sounds like a normal C statement (like goto) should work. Or am I missing something?
-
I just found out that a program of mine crashes when compiled with PellesC v10. This does not happen when I compile it with Pellesc v6.50. To be more precise, the program is executed correctly, but it crashes when it tries to show a Save dialog box (it uses the IFileOpenDialog COM interface). This Save dialog box checks the selected file name before closing the window (it uses the IFileDialogEvents:OnFileOk method). I used the same code used in the FileDlgs.zip file, located in the source code section of the Web site. So, I compiled that demo file, and it also crashes when the executable tries to show the Save dialog box (it shows the Open dialog box with no problems instead). It seems that the crash occurs when the program executes the instruction "hr = IFileSaveDialog_Advise(pfsd, pfde, &dwCookie);" (line 234 of the "main.c" file). I'm not a COM expert, so I don't know if it's a compiler problem or a code problem. I thought it was worth reporting it.
Thanks for reporting this! It looks like a problem with the code. I will upload a new version when I have fixed it (could take a few days).
-
I will upload a new version when I have fixed it (could take a few days).
Yes I will, and now it's fixed and uploaded... (that wasn't so hard, was it? "A few days"... bah!)
-
Thank you very much. Pelle! I applied the fix also in my program and (of course) it does work flawlessly.
-
Hi,
This error is similar to one reported by Marco. Under version 9 there is no issue but under version 10
RC1 the following statement always fails, even when it should resolve as TRUE
if ((_stristr(p_LineIn, "JPEG") != NULL) || (_stristr(p_LineIn, "JPG") != NULL))
unless the left side(s) is/are resolved before executing the if, so changing into
char *po1 = _stristr(p_LineIn, "JPEG") ;
char *po2 = _stristr(p_LineIn, "JPG");
if (po1 != NULL) || (po2 != NULL))
and then it works perfectly.
John
-
Hi,
The new UI for Project Options:
On the Linker "Library and objects files:" edit box it needs to be able to auto wrap, horizontal scroll bar, or at least allow the cursor to scroll the text. Half of the library entries can't be seen or accessed. Attached screen shot.
This may be an issue across the new UI in several screens, for example Define Symbols
Regards,
John
-
Today I compiled another of my programs and the compiler gave me the following error:
fatal error: Internal error: 'Access violation' at 0x00007ffd3f842503
I spent some time in order to understand what was wrong with code and I found out that the problem was related to an #include preprocessor directive. It seems that the compiler does not "like" the #include preprocessor directive if it does include a relative path similar to "..\..\header.h". So, for example:
#include "..\header.h" // <-- ok
#include "..\..\header.h" // <-- fatal error
-
The new UI for Project Options:
On the Linker "Library and objects files:" edit box it needs to be able to auto wrap, horizontal scroll bar, or at least allow the cursor to scroll the text. Half of the library entries can't be seen or accessed. Attached screen shot.
Thanks. Found it myself a few days ago.
-
This error is similar to one reported by Marco. Under version 9 there is no issue but under version 10
RC1 the following statement always fails, even when it should resolve as TRUE
...
I can't reproduce this. Please provide a complete, compilable, example demonstrating the problem.
-
Today I compiled another of my programs and the compiler gave me the following error:
fatal error: Internal error: 'Access violation' at 0x00007ffd3f842503
I spent some time in order to understand what was wrong with code and I found out that the problem was related to an #include preprocessor directive. It seems that the compiler does not "like" the #include preprocessor directive if it does include a relative path similar to "..\..\header.h". So, for example:
#include "..\header.h" // <-- ok
#include "..\..\header.h" // <-- fatal error
I must be missing something, similar cases works fine here. Can you provide a more complete example?
-
This error is similar to one reported by Marco. Under version 9 there is no issue but under version 10
RC1 the following statement always fails, even when it should resolve as TRUE
...
I can't reproduce this. Please provide a complete, compilable, example demonstrating the problem.
MY error a preceding buffer had an overflow by a few bytes that somehow was innocuous when V9 compiles and reorganizing the code in V10 just further obscured the real issue - Sorry :-[
Update 6/25
Well it is not that simple either. Still trying to pinpoint and replicate in a smaller code piece. It only happens with optimize for speed selected in V10 but does not happen in V9 with the same optimization selected. Basically a wchar_t pointer ends up pointing at a location within a declared char pointer space even though the wchar_t pointer is never touched after the declaration and assignment to its own space. It 'seems' that I can prevent this by moving a memset for the wchar_t pointer space earlier in the code. Strange indeed. But until I can replicate I'm not faulting the optimizer, most likely I've done something weird.
-
I can't reproduce this. Please provide a complete, compilable, example demonstrating the problem.
After reading what you wrote, I investigated the issue further. I use a very simple batch file to compile my programs, and I found out that the problem was related to the declaration of the INCLUDE environment variable. The INCLUDE variable was set as following:
set INCLUDE=\include;%PellesCDir%\Include;%PellesCDir%\Include\Win;%INCLUDE%
The very first "\include" path does not exists, and it "crashes" the compiler. After removing that path, the compiler did work as expected. Of course, that path was erroneously entered (my mistake) and the old compiler (v6.50) never worried about it.
-
After reading what you wrote, I investigated the issue further. I use a very simple batch file to compile my programs, and I found out that the problem was related to the declaration of the INCLUDE environment variable. The INCLUDE variable was set as following:
set INCLUDE=\include;%PellesCDir%\Include;%PellesCDir%\Include\Win;%INCLUDE%
The very first "\include" path does not exists, and it "crashes" the compiler. After removing that path, the compiler did work as expected. Of course, that path was erroneously entered (my mistake) and the old compiler (v6.50) never worried about it.
Hmm. The compiler should never crash, but I still have trouble reproducing this (and the code in v10 is ~98% different from v6.50, so no point in comparing them). I will test some more, but if you have any additional info it would be helpful...
-
Here how to reproduce the issue. Please, create the following 3 files into the BIN folder of PellesC:
comp.bat
@ECHO OFF
CALL povars64.bat
set INCLUDE=\Include;%INCLUDE%
pocc -W1 -Gd -Go -Ze -Zx -MT -Tamd64-coff -D_WIN32_WINNT=0x0600 %1.c
polink -subsystem:windows -machine:x64 %1.obj %1.res
test1.c
#include "..\header.h"
test2.c
#include "..\..\header.h"
Start a CMD shell, go to the above BIN folder and then execute:
comp test1.c
Output:
Setting 64-bit environment for Pelles C...
test1.c(3): fatal error #1035: Can't find include file "..\header.h".
POLINK: fatal error: File not found: 'test1.obj'.
comp test2.c
Output:
Setting 64-bit environment for Pelles C...
fatal error: Internal error: 'Access violation' at 0x0000000077581d1e.
POLINK: fatal error: File not found: 'test2.obj'.
I hope this helps.
-
Here how to reproduce the issue. Please, create the following 3 files into the BIN folder of PellesC:
...
I hope this helps.
Sure did. Now I can reproduce this. Will have a look...