Strange behaviour of BOOLEAN type

[vladbfg]

Hi all.
I use compiler/IDE: Lazarus 3.2 FPC 3.2.2 x86_64-win64-win32/win64

There is a strange behavoir of boolean calculation, when boolean variable is part of array/structure
Could anybody explain the results of code below:

Code: Pascal  [Select][+][-]

1. type Tstruc2 = record
2.   a: boolean;
3. end;
4.  
5. type Tstruc = record
6.   i: integer;
7.   ar: array[1..1] of Tstruc2;
8. end;
9.  
10. var
11.   mas : array[1..1] of Tstruc;
12.  
13. procedure TFMain.Button3Click(Sender: TObject);
14.   var i, j, k:integer;
15. begin
16.   k:=1;
17.   for i:=1 to 1 do
18.     for j:=1 to 1 do begin
19.       mas[i].ar[j].a :=  k=1;
20.     end;
21.    Fmain.MemoLog.Lines.Add( BoolToStr( mas[1].ar[1].a, true ) );
22. end;
23.  

Then I see "False" on the screen. Debugger shows value False too.

But when I use another var, then code works as expected

Code: Pascal  [Select][+][-]

1.      
2.     b:= k=1;
3.     mas[i].ar[j].a :=b;  
4.  

         
Then there is TRUE in the mas[1].ar[1].a

Could you tests this simple code?

[bytebites]

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3. uses sysutils;
4.  
5. type Tstruc2 = record
6.   a: boolean;
7. end;
8.  
9. type Tstruc = record
10.   i: integer;
11.   ar: array[1..1] of Tstruc2;
12. end;
13.  
14. var
15.   mas : array[1..1] of Tstruc;
16.   i, j, k:integer;
17. begin
18.   k:=1;
19.   for i:=1 to 1 do
20.     for j:=1 to 1 do begin
21.       mas[i].ar[j].a :=  k=1;
22.     end;
23.    writeln( BoolToStr( mas[1].ar[1].a, true ) );
24. end.
25.  

Output is True, Fpc version trunk.

[alpine]

I can confirm that:

Code: ASM  [Select][+][-]

1. /home/alpi/fpcupdeluxe_v2_2_0m/fpcupdeluxe/projects/project1.lpr:26  mas[i].ar[j].a :=  k=1;
2. 00000000004010C4 8B45FC                   mov eax,[rbp-$04]
3. 00000000004010C7 8B4DF8                   mov ecx,[rbp-$08]
4. 00000000004010CA 48C1E003                 shl rax,$03
5. 00000000004010CE 837DF401                 cmp dword ptr [rbp-$0C],$01
6. 00000000004010D2 488D15D7F70700           lea rdx,[rip+$0007F7D7]
7. 00000000004010D9 4801D0                   add rax,rdx
8. 00000000004010DC 0F944408FB               setz byte ptr [rcx+rax-$05]
9.  

The additional add changes the Z. FPC 3.2.2 for 64-bit target.
32-bit is OK.

[Thaddy]

Yes. And I WARNED   for that... earlier.... I hope that gets reversed. Bad idea.
The issue was mentioned before, it is the expansion that causes the trouble when using higher optimization levels. (It is fine in -O1 or -O- state)
This can easily be avoided by excuding Boolean and Bool types of being expanded.

[vladbfg]

I can confirm that:

Code: ASM  [Select][+][-]

1. /home/alpi/fpcupdeluxe_v2_2_0m/fpcupdeluxe/projects/project1.lpr:26  mas[i].ar[j].a :=  k=1;
2. 00000000004010C4 8B45FC                   mov eax,[rbp-$04]
3. 00000000004010C7 8B4DF8                   mov ecx,[rbp-$08]
4. 00000000004010CA 48C1E003                 shl rax,$03
5. 00000000004010CE 837DF401                 cmp dword ptr [rbp-$0C],$01
6. 00000000004010D2 488D15D7F70700           lea rdx,[rip+$0007F7D7]
7. 00000000004010D9 4801D0                   add rax,rdx
8. 00000000004010DC 0F944408FB               setz byte ptr [rcx+rax-$05]
9.  

The additional add changes the Z. FPC 3.2.2 for 64-bit target.
32-bit is OK.

I don't know asm, this is my debug window. Are there all ok?

[Thaddy]

No, because of the expansion being not correct.

[alpine]

I don't know asm, this is my debug window. Are there all ok?

It is not. The Z flag from the cmp instruction should be used for setz but there are 2 additional instructions: lea, add in between destroying the Z flag.
Edit: And that is with -O1

[Thaddy]

You are right. Also means my warning was right. Should be reversed. Do you report it? Or should I report it?. Better if you do it....

[rvk]

Isn't this already fixed in trunk?

Code: ASM  [Select][+][-]

1. C:\Users\Rik\AppData\Local\Temp\project1.lpr:21  mas[i].ar[j].a :=  k=1;
2. 0000000100001760 8B15BA180200             mov edx,[rip+$000218BA]
3. 0000000100001766 8B05C4180200             mov eax,[rip+$000218C4]
4. 000000010000176C 48C1E203                 shl rdx,$03
5. 0000000100001770 488D0D99180200           lea rcx,[rip+$00021899]
6. 0000000100001777 4801CA                   add rdx,rcx
7. 000000010000177A 833DBF18020001           cmp dword ptr [rip+$000218BF],$01
8. 0000000100001781 0F944402FB               setz byte ptr [rax+rdx-$05]

[Thaddy]

No, it is worse in trunk, Rik.

[alpine]

You are right. Also means my warning was right. Should be reversed. Do you report it? Or should I report it?. Better if you do it....

No, I didn't. Unfortunately I'm in a middle of something and I just can't go further right now.

Isn't this already fixed in trunk?

Quite possible, but I don't have trunk to check it. And I'm not sure what is Thaddy talking about (expansion).

[vladbfg]

If it useful here asm code when [].a : bool  (bool type, not boolean, from unit windows)
Then result is True

[alpine]

If it useful here asm code when [].a : bool  (bool type, not boolean, from unit windows)
Then result is True

Looks OK but it just shows that different types are treated differently by the compiler. Perhaps type t1=(ttFalse, ttTrue) will also work.
IMHO the trouble is the EA is calculated differently in 32/64-bit modes and in 64-bit mode the Z flag side-effect of the additional instructions wasn't taken into account.

[jamie]

(K=1)

Does that work?

[Thaddy]

Quite possible, but I don't have trunk to check it. And I'm not sure what is Thaddy talking about (expansion).

A boolean is defined as a BYTE value 0--1 in the language description. The Boolean is now expanded to register size on all platforms and all optimizations and that is wrong. There was a very recent discussion about this and why the expansion of Booleans causes problems when interfacing with other languages. Alas the "fix" in trunk causes more problems than it "fixed" and I told so...
They fixed it in the wrong way. It is fixed in a way to solve a single - rare - problem by an OP that seems to have more infuence than me and the fixer(s) would not listen.
Hence in trunk the behavior of Booleans has changed.... to the worse...
In that case I demonstrated the different behavior with and without optimizations.

This is related, btw.
Depending on optimization settings, the result of boolean operations indeed differs, also in 3.2.x.

The change in trunk, though, breaks existing code even more.