Pelles C forum
Pelles C => Bug reports => Topic started by: frankie on August 11, 2023, 01:44:45 AM
-
The following code crashes the compiler.
// If function declaration of a function using VLA's with more than 2 dimension
// is used the compiler crash.
int foo(int a, int b, short bar[a][b][100]); //Comment this to compile code
int foo(int a, int b, short bar[a][b][100])
{
return 0;
}
Commenting out the declaration of the function the compiler works.
-
Hi frankie,
Maybe there is more involved in the crash?
I dropped your example into an existing program and it compiled fine - no crash,
see screen shot.
Maybe there is a particular optimization, compile mode, setting, or the recurring Add-In complication contributing?
John Z
-
Thanks John,
indeed the bug appears only wen compiling with Debug Information full.
Could you confirm please? :)
-
Hi frankie,
Yes tested.... I tried FULL for Compile as well as Assembler. With and without some optimizations.
My 'tester' is using C11 with MS extensions BTW, also created dbg and map as well as used verbose.
I could not make it crash - there must be more to it. Possibly a corrupt Debug section in the prj file?
Maybe use the new copy feature to copy the release mode to a new debug2 mode, set debug flags in
the new debug2 mode and see if still crashes.
John Z
Update: Tried 4 dimensions also, compiled with FULL debug ok
-
Thanks John,
I still have the problem (even after reinstall), and don't see any other problem here.
The problem disappears selecting Debug information to "None" or "Line numbers only" in the compiler configuration.
The compilation fails with internal error.
I am using PellesC V.12.00.02 (Last release).
Please check the project attached.
If someone else could check would be nice thanks.
-
Well - here it is frankie, no problem using your sources and PRJ file.
See attached screen shot....sorry something going wrong on your system/installation weirdness :(
I built both debug and release....
I double checked FULL selected too.
John Z
oh DAMN I just somehow pulled version 11.00.2 I have two identical HP's I'm so sorry. I'll boot up the version 12 HP.
Mea culpa!
CONFIRMED on V12.00.2 BAD 11.00.2 GOOD
Building D:\VLADeclare\output\VlaDeclare.obj.
fatal error: Internal error: 'Access violation' at 0x00007ff716b5d69a.
*** Error code: 1 ***
Done.
Well at least that points to changes between. Sorry to muddy the waters. I didn't realize I had not upgraded both HP systems. Lesson for me....
-
CONFIRMED on V12.00.2 BAD 11.00.2 GOOD
Building D:\VLADeclare\output\VlaDeclare.obj.
fatal error: Internal error: 'Access violation' at 0x00007ff716b5d69a.
*** Error code: 1 ***
Done.
Thank you very much John for the time spent. :)
Yes All previous versions worked well with VLA and debug info. This bug is new. 8)
-
Interestingly the bug appears to be in Version 10.00.6 too.
See attached screen shot. I reinstalled version 10.00.6 to be sure this time :)
Might be helpful (was, wasn't, is) [ 10,11,12 ]
Can someone else verify?
John Z
-
v9
Building VlaDeclare.obj.
C:\code\PellesC\_Bugs\v9\VlaDeclare.c(10): fatal error: Internal error: 'Access violation' at 0x0000000140092d2f.
*** Error code: 1 ***
v10Building VlaDeclare.obj.
fatal error: Internal error: 'Access violation' at 0x000000013f81dc46.
*** Error code: 1 ***
Done.
-
Thanks Timo,
I was sure that this worked with previous versions :(
It should be a problem related to the new PellesC debug symbols.
The function declaration by itself doesn't crash the compiler if isn't followed by the function definition. Maybe the problem happen when the compiler emits the debug symbols for a translation unit that carries both the declaration and the definition.
This allows to use the declaration in an header file to be used in other units.
Timo, please can you test if removing full debug it works?
Thanks.
-
Without debug info:
v7 no error and no error with full debug info
v8 no error and no error with full debug info
v9 no error
v10 no error
PS: i collected many Pelles C versions and i use them with poide -x -xml options
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC7\bin\pocc VlaDeclare.c
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC8\bin\pocc VlaDeclare.c
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC9\bin\pocc VlaDeclare.c
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC10\bin\pocc VlaDeclare.c
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC11\bin\pocc VlaDeclare.c
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC12\bin\pocc VlaDeclare.c
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC7\bin\pocc VlaDeclare.c -Zi
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC8\bin\pocc VlaDeclare.c -Zi
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC9\bin\pocc VlaDeclare.c -Zi
VlaDeclare.c(10): fatal error: Internal error: 'Access violation' at 0x0000000140092d2f.
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC10\bin\pocc VlaDeclare.c -Zi
fatal error: Internal error: 'Access violation' at 0x000000013fbedc46.
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC11\bin\pocc VlaDeclare.c -Zi
C:\code\PellesC\_Bugs\VlaDeclare>C:\code\PellesC12\bin\pocc VlaDeclare.c -Zi
fatal error: Internal error: 'Access violation' at 0x000000013fd9d69a.
-
Thanks Timo :)
-
SO frankie was not wrong it has worked in the past, just not the recent past .... :D
Great summary TimoVJL
Seems the -xml option is a better way to handle multiple versions than what I was doing.
John Z
-
I can reproduce, and will look at it...