Pelles C forum

Pelles C => Bug reports => Topic started by: ander_cc on April 14, 2026, 03:38:30 PM

Title: Maybe a optimization bug.
Post by: ander_cc on April 14, 2026, 03:38:30 PM
Today, I showed a sample code about while statement to my students. But got a error result. :-[
I think it might be a bug related to optimization. Because when I close optimization, I can get the right value.

Pelles C v14, Windows 11 pro Chinese (Samplify) 25H2
1.png
Title: Re: Maybe a optimization bug.
Post by: John Z on April 14, 2026, 04:43:36 PM
Hi ander_cc,

A good lesson there similar to a lawyers credo "In Court don't ask a question if you don't already know the answer"  the corollary to teaching, esp programing, is "In classroom don't use an example you haven't tested"  :)  (half kidding you, no offense meant)

But seriously yes there have been, and are issues, with using the optimizations and extensive testing is always needed for these.  I have many programs using optimizations successfully.

Perhaps Pelle can find the cause of this short program, meanwhile

Your program can use optimizations by using this 'fix':

volatile int i=1;

which, as I understand it inhibits the optimizer from making assumptions about i.

John Z

As an aside I would recommend not using any optimizations for teaching.  Optimizing should be performed by the students learning programing.

Cheers,
Title: Re: Maybe a optimization bug.
Post by: Vortex on April 14, 2026, 06:06:04 PM
Compiling the code with the maximize speed option :

#include <stdio.h>

int main(void)
{
    int i=1, sum=0;
    while (i<=100)
    {
        //printf("i=%d\n",i);
        sum=sum+i;
        i++;
    }
    printf("i=%d\n",i);
    printf("sum=%d\n",sum);
    return 0;
}

Disassembling the object module :

_text  SEGMENT PARA 'CODE'                            ; section number 1

main    PROC
        sub    rsp, 40                                ; 0000 _ 48: 83. EC, 28
        lea    rcx, [@152]                            ; 0004 _ 48: 8D. 0D, 00000000(rel)
        call    printf                                  ; 000B _ E8, 00000000(rel)
        lea    rcx, [@154]                            ; 0010 _ 48: 8D. 0D, 00000000(rel)
        mov    edx, 5050                              ; 0017 _ BA, 000013BA
        call    printf                                  ; 001C _ E8, 00000000(rel)
        xor    eax, eax                                ; 0021 _ 31. C0
        add    rsp, 40                                ; 0023 _ 48: 83. C4, 28
        ret                                            ; 0027 _ C3
main    ENDP

_text  ENDS

.xdata  SEGMENT ALIGN(8) 'CONST'                        ; section number 3

..?xdatasym1 label byte
        db 01H, 04H, 01H, 00H, 04H, 42H, 00H, 00H      ; 0000 _ .....B..

.xdata  ENDS

.rdata  SEGMENT PARA 'CONST'                            ; section number 4

@154    label byte
        db 73H, 75H, 6DH, 3DH, 25H, 64H, 0AH, 00H      ; 0000 _ sum=%d..

@152    label byte
        db 69H, 3DH, 25H, 64H, 0AH, 00H                ; 0008 _ i=%d..

.rdata  ENDS

The first printf call should take a second parameter, edx pointint the value of i. Since this statement is missing, printf will print the random value stored by the register edx.
Title: Re: Maybe a optimization bug.
Post by: TimoVJL on April 14, 2026, 07:41:26 PM
For small tests quick look with podump.exe

Disasm obj Add-In (https://forum.pellesc.de/index.php?msg=26516)
Title: Re: Maybe a optimization bug.
Post by: Vortex on April 14, 2026, 08:37:49 PM
Hi Timo,

Here is the output of Podump :

\PellesC\bin\podump.exe /DISASM output\sum.obj
sub               rsp,28
lea               rcx,[@152]
call              printf
lea               rcx,[@154]
mov               edx,13BA
call              printf
xor               eax,eax
add               rsp,28
ret