View Issue Details

IDProjectCategoryView StatusLast Update
0038973FPCCompilerpublic2021-06-13 18:56
ReporterPierre Muller Assigned To 
Status newResolutionopen 
OSAt least MacOS and Linux 
Product Version3.2.2 
Summary0038973: Optimizer leads to wrong short boolean code generation
Description  Reported by Tobias Giesen on fpc-pascal mailinglist, 2021/05/30

it seems that the newest 32-bit FPC sometimes creates complete Boolean Evaluation
rather than partial, which causes my application to crash. My context is like this:

type BOOL=LongBool;

function DoSomething(const Cancel:PBOOL=nil);
   if Assigned(Cancel) and Cancel^ then

This crashes because Cancel and Cancel^ are always evaluated, even if Cancel is nil.

It works fine in 64-bit.

Is this a known problem?


I modified this to a simple test, which shows that x86_64 3.2.2 release compiler
also generates wrong code for this simple source!
Steps To Reproducemuller@gcc10:~/pas/check$ fpc -gl -O2 test-complete-boolean.pp -al
Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Note: Switching assembler to default source writing assembler
Target OS: Linux for x86-64
Compiling test-complete-boolean.pp
Assembling program
Linking test-complete-boolean
26 lines compiled, 0.2 sec
1 note(s) issued
muller@gcc10:~/pas/check$ ./test-complete-boolean
First try
2nd try
Runtime error 216 at $00000000004001E2
   $00000000004001E2 DOSOMETHING, line 8 of test-complete-boolean.pp
Additional Informationmuller@gcc10:~/pas/check$ cat test-complete-boolean.pp
{$mode objfpc}

type BOOL=LongBool;

procedure DoSomething(const Cancel:PBOOL=nil);
  if Assigned(Cancel) and Cancel^ then
  writeln('Cancel is false');

    b : BOOL;
    pb : PBOOL;
   Writeln('First try');
   Writeln('2nd try');
   Writeln('3rd try');
TagsNo tags attached.
Fixed in Revision
Attached Files


Serge Anvarov

2021-06-08 10:46

reporter   ~0131198

Confirm on Windows (fpc 3.2.0).
Both x32 and x64 give an error, but only at the 2nd level of optimization. At the 1st, 3rd, and 4th level of optimization, everything is fine

J. Gareth Moreton

2021-06-08 16:19

developer   ~0131202

What happens if you specify -OoNOPEEPHOLE? I just want to clarify if it's something I did or not.

Pierre Muller

2021-06-08 16:26

developer   ~0131203

It seems that using -O2 with trunk x86_64 compiler does not trigger this error,
but I don't know if there is a combination of options that might still also
trigger the bug.

  I do get the bug simply with -O2 option
for 3.2.0 and 3.2.2 x86_64 release compiler on linux OS.

Serge Anvarov

2021-06-09 16:33

reporter   ~0131215

Sorry, on Windows I made a mistake on the optimization levels. Error at all, above the first level. I used {$OPTIMIZATION LEVEL3} and LEVEL4, but it looks like the compiler only understands LEVEL2, though in the documentation it seems that it can do both 3 and 4.
-OoNOPEEPHOLE doesn't help.
FPC 3.2.0, error on x64 too:
d:\this>.....\lazarus64\fpc\3.2.0\bin\x86_64-win64\fpc.exe -O2 project1.lpr
Free Pascal Compiler version 3.2.0 [2021/02/21] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling project1.lpr
Linking project1.exe
27 lines compiled, 0.1 sec, 32544 bytes code, 1524 bytes data

First try
2nd try
Runtime error 216 at $00000001000015A7


2021-06-09 18:19

reporter   ~0131216

Last edited: 2021-06-10 05:35

View 4 revisions

if this happens only with integral bool (ByteBool, WordBool, LongBool), then the issue is known: 0035272
and this would work: if Assigned(Cancel) and boolean(Cancel^) then ...

The AND-example in 0035272 is not the same, but the common issue is that boolean expressions with integral bools can fail,
and the issue resolution is the same: prior convert to simple booleans.

J. Gareth Moreton

2021-06-09 22:03

developer   ~0131223

If it still occurs with -OoNOPEEPHOLE, then that indicates the bug is not in the peephole optimizer, so that helps narrow it down a bit. Does it occur on any other platforms or is it specific fo x86 platforms? It's starting to sound like a node generation issue.


2021-06-13 18:56

reporter   ~0131292

I can confirm the crash on 32-bit Linux for armhf with fpc 3.2.0.
When compiled with fpc 3.0.4, the program runs correct.

Issue History

Date Modified Username Field Change
2021-06-07 21:57 Pierre Muller New Issue
2021-06-08 02:13 J. Gareth Moreton Priority normal => high
2021-06-08 02:13 J. Gareth Moreton Severity minor => major
2021-06-08 02:13 J. Gareth Moreton FPCTarget => -
2021-06-08 10:46 Serge Anvarov Note Added: 0131198
2021-06-08 16:19 J. Gareth Moreton Note Added: 0131202
2021-06-08 16:26 Pierre Muller Note Added: 0131203
2021-06-09 16:33 Serge Anvarov Note Added: 0131215
2021-06-09 18:19 nanobit Note Added: 0131216
2021-06-09 18:35 nanobit Note Edited: 0131216 View Revisions
2021-06-09 22:03 J. Gareth Moreton Note Added: 0131223
2021-06-10 03:30 nanobit Note Edited: 0131216 View Revisions
2021-06-10 05:35 nanobit Note Edited: 0131216 View Revisions
2021-06-13 18:56 Bernd Note Added: 0131292