View Issue Details

IDProjectCategoryView StatusLast Update
0035708FPCCompilerpublic2019-06-12 21:03
ReporterYukiAssigned ToJ. Gareth Moreton 
Status resolvedResolutionno change required 
Platformx64OSWindowsOS Version10 (1903)
Product Version3.0.4Product Build 
Target VersionFixed in Version 
Summary0035708: Compilers ignore an IF in assembly generation
DescriptionCompilers ignore an IF in assembly generation in a specific case, but considers the IF if any other code added inside it (but yet generate a broken logic).
Steps To ReproduceA function like this:

procedure MWindow.ProcessEvents();
    while (SDL_PollEvent(event) = 1) do
        if (event^.type_ = SDL_QUITEV) then;
            running := False;
Turn into (see, no cmp for the IF whatsoever)

mahouwindow.pas:44 begin
0000000100011860 55 push %rbp
0000000100011861 4889e5 mov %rsp,%rbp
0000000100011864 488d6424d0 lea -0x30(%rsp),%rsp
0000000100011869 48894df8 mov %rcx,-0x8(%rbp)
mahouwindow.pas:45 while (SDL_PollEvent(event) = 1) do
000000010001186D eb17 jmp 0x100011886 <PROCESSEVENTS+38>
000000010001186F 90 nop
mahouwindow.pas:47 if (event^.type_ = SDL_QUITEV) then;
0000000100011870 488b45f8 mov -0x8(%rbp),%rax
0000000100011874 488b4020813800010000 mov 0x20(%rax),%rax
mahouwindow.pas:49 running := False;
000000010001187E 488b45f8 mov -0x8(%rbp),%rax
0000000100011882 c6402800 movb $0x0,0x28(%rax)
mahouwindow.pas:45 while (SDL_PollEvent(event) = 1) do
0000000100011886 488b45f8 mov -0x8(%rbp),%rax
000000010001188A 488b4820 mov 0x20(%rax),%rcx
000000010001188E e82dfdfeff callq 0x1000015c0 <__$dll$sdl2$SDL_PollEvent>
0000000100011893 83f801 cmp $0x1,%eax
0000000100011896 74d8 je 0x100011870 <PROCESSEVENTS+16>
mahouwindow.pas:52 end;
0000000100011898 90 nop
0000000100011899 488d6500 lea 0x0(%rbp),%rsp
000000010001189D 5d pop %rbp
000000010001189E c300 retq

But if you add a simple Writeln (or any other code together inside it)

procedure MWindow.ProcessEvents();
    while (SDL_PollEvent(event) = 1) do
        if (event^.type_ = SDL_QUITEV) then;
            running := False;

It goes "normally", there's a cmpl, but the logic is broken since it enters the if after a few executions.

mahouwindow.pas:44 begin
0000000100011890 55 push %rbp
0000000100011891 4889e5 mov %rsp,%rbp
0000000100011894 488d6424d0 lea -0x30(%rsp),%rsp
0000000100011899 48895df0 mov %rbx,-0x10(%rbp)
000000010001189D 48894df8 mov %rcx,-0x8(%rbp)
mahouwindow.pas:45 while (SDL_PollEvent(event) = 1) do
00000001000118A1 eb49 jmp 0x1000118ec <PROCESSEVENTS+92>
00000001000118A3 66666690 data32 data32 xchg %ax,%ax
00000001000118A7 90 nop
mahouwindow.pas:47 if (event^.type_ = SDL_QUITEV) then;
00000001000118A8 488b45f8 mov -0x8(%rbp),%rax
00000001000118AC 488b4020 mov 0x20(%rax),%rax
00000001000118B0 813800010000 cmpl $0x100,(%rax)
mahouwindow.pas:49 Writeln('yes');
00000001000118B6 e8d5b6ffff callq 0x10000cf90 <fpc_get_output>
00000001000118BB 4889c3 mov %rax,%rbx
00000001000118BE 4c8d05bb9d0100 lea 0x19dbb(%rip),%r8 # 0x10002b680 <_$MAHOUWINDOW$_Ld1>
00000001000118C5 4889da mov %rbx,%rdx
00000001000118C8 b900000000 mov $0x0,%ecx
00000001000118CD e8feb8ffff callq 0x10000d1d0 <fpc_write_text_shortstr>
00000001000118D2 e8397bffff callq 0x100009410 <fpc_iocheck>
00000001000118D7 4889d9 mov %rbx,%rcx
00000001000118DA e831b8ffff callq 0x10000d110 <fpc_writeln_end>
00000001000118DF e82c7bffff callq 0x100009410 <fpc_iocheck>
mahouwindow.pas:50 running := False;
00000001000118E4 488b45f8 mov -0x8(%rbp),%rax
00000001000118E8 c6402800 movb $0x0,0x28(%rax)
mahouwindow.pas:45 while (SDL_PollEvent(event) = 1) do
00000001000118EC 488b45f8 mov -0x8(%rbp),%rax
00000001000118F0 488b4820 mov 0x20(%rax),%rcx
00000001000118F4 e8c7fcfeff callq 0x1000015c0 <__$dll$sdl2$SDL_PollEvent>
00000001000118F9 83f801 cmp $0x1,%eax
00000001000118FC 74aa je 0x1000118a8 <PROCESSEVENTS+24>
mahouwindow.pas:53 end;
00000001000118FE 488b5df0 mov -0x10(%rbp),%rbx
0000000100011902 488d6500 lea 0x0(%rbp),%rsp
0000000100011906 5d pop %rbp
0000000100011907 c30000000000000000 retq
TagsNo tags attached.
Fixed in Revision
Attached Files



2019-06-12 12:38

reporter   ~0116686

It enters the if after a few executions >>
Even the logic proposition inside it being (512 = 256)


2019-06-12 12:56

reporter   ~0116688

Last edited: 2019-06-12 12:57

View 2 revisions

Project sample (Win x64)

Mahou.7z (473,189 bytes)


2019-06-12 13:47

reporter   ~0116689

Code generation works differently, but it's broken on X86 too.


2019-06-12 13:48

reporter   ~0116690

"then;" - what for semicolon is here? If it's what you actually mean, then "running := False;" is out of if statement. Generated code looks good to me, even if there is no CMP instruction in first example.


2019-06-12 13:51

reporter   ~0116691

Switching the if to case

case event^.type_ of
              running := False;
Generates good code and works normally!

J. Gareth Moreton

2019-06-12 13:55

developer   ~0116692

Yeah, you've got a coding error. Remove the semicolon after "then" and give it another try. With the semicolon after "then", the "if" statement effectively becomes pointless code and the optimiser tries to remove it.

Marco van de Voort

2019-06-12 15:00

manager   ~0116693

However, is the compiler allowed to eliminate the SDL call? (I btw can't reproduce that with trunk or 32-bit 3.0.4 (don't have 64-bit release here))

J. Gareth Moreton

2019-06-12 19:27

developer   ~0116698

As far as I know, no function call is being eliminated; SDL_QUITEV is a constant.

J. Gareth Moreton

2019-06-12 21:03

developer   ~0116699

Marked as "resolved -> no change required" because this is due to a typographical error in the sample code, not a compiler bug. If such a bug does exist in some form, please open a new issue with a valid code sample.

Issue History

Date Modified Username Field Change
2019-06-12 12:37 Yuki New Issue
2019-06-12 12:38 Yuki Note Added: 0116686
2019-06-12 12:56 Yuki File Added: Mahou.7z
2019-06-12 12:56 Yuki Note Added: 0116688
2019-06-12 12:57 Yuki Note Edited: 0116688 View Revisions
2019-06-12 13:47 Yuki Note Added: 0116689
2019-06-12 13:48 Marģers Note Added: 0116690
2019-06-12 13:51 Yuki Note Added: 0116691
2019-06-12 13:55 J. Gareth Moreton Note Added: 0116692
2019-06-12 15:00 Marco van de Voort Note Added: 0116693
2019-06-12 19:27 J. Gareth Moreton Note Added: 0116698
2019-06-12 21:03 J. Gareth Moreton Assigned To => J. Gareth Moreton
2019-06-12 21:03 J. Gareth Moreton Status new => resolved
2019-06-12 21:03 J. Gareth Moreton Resolution open => no change required
2019-06-12 21:03 J. Gareth Moreton FPCTarget => -
2019-06-12 21:03 J. Gareth Moreton Note Added: 0116699