Recent

Author Topic: Strange behaviour of BOOLEAN type  (Read 4652 times)

vladbfg

  • Newbie
  • Posts: 4
Strange behaviour of BOOLEAN type
« on: May 30, 2024, 08:17:55 am »
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

  • Hero Member
  • *****
  • Posts: 647
Re: Strange behaviour of BOOLEAN type
« Reply #1 on: May 30, 2024, 08:46:41 am »
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

  • Hero Member
  • *****
  • Posts: 1139
Re: Strange behaviour of BOOLEAN type
« Reply #2 on: May 30, 2024, 08:51:05 am »
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'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

Thaddy

  • Hero Member
  • *****
  • Posts: 14825
  • Censorship about opinions does not belong here.
Re: Strange behaviour of BOOLEAN type
« Reply #3 on: May 30, 2024, 08:54:07 am »
Yes. And I WARNED   >:D 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.
« Last Edit: May 30, 2024, 09:01:38 am by Thaddy »
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

vladbfg

  • Newbie
  • Posts: 4
Re: Strange behaviour of BOOLEAN type
« Reply #4 on: May 30, 2024, 09:02:14 am »
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

  • Hero Member
  • *****
  • Posts: 14825
  • Censorship about opinions does not belong here.
Re: Strange behaviour of BOOLEAN type
« Reply #5 on: May 30, 2024, 09:04:01 am »
No, because of the expansion being not correct.
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

alpine

  • Hero Member
  • *****
  • Posts: 1139
Re: Strange behaviour of BOOLEAN type
« Reply #6 on: May 30, 2024, 09:13:19 am »
Quote
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

« Last Edit: May 30, 2024, 09:15:06 am by alpine »
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

Thaddy

  • Hero Member
  • *****
  • Posts: 14825
  • Censorship about opinions does not belong here.
Re: Strange behaviour of BOOLEAN type
« Reply #7 on: May 30, 2024, 09:17:53 am »
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....
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

rvk

  • Hero Member
  • *****
  • Posts: 6268
Re: Strange behaviour of BOOLEAN type
« Reply #8 on: May 30, 2024, 09:18:56 am »
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

  • Hero Member
  • *****
  • Posts: 14825
  • Censorship about opinions does not belong here.
Re: Strange behaviour of BOOLEAN type
« Reply #9 on: May 30, 2024, 09:55:38 am »
No, it is worse in trunk, Rik.
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

alpine

  • Hero Member
  • *****
  • Posts: 1139
Re: Strange behaviour of BOOLEAN type
« Reply #10 on: May 30, 2024, 10:11:53 am »
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).
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

vladbfg

  • Newbie
  • Posts: 4
Re: Strange behaviour of BOOLEAN type
« Reply #11 on: May 30, 2024, 11:22:47 am »
If it useful here asm code when [].a : bool  (bool type, not boolean, from unit windows)
Then result is True

alpine

  • Hero Member
  • *****
  • Posts: 1139
Re: Strange behaviour of BOOLEAN type
« Reply #12 on: May 30, 2024, 12:00:48 pm »
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.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

jamie

  • Hero Member
  • *****
  • Posts: 6302
Re: Strange behaviour of BOOLEAN type
« Reply #13 on: May 30, 2024, 12:32:21 pm »
(K=1)

Does that work?
The only true wisdom is knowing you know nothing

Thaddy

  • Hero Member
  • *****
  • Posts: 14825
  • Censorship about opinions does not belong here.
Re: Strange behaviour of BOOLEAN type
« Reply #14 on: May 30, 2024, 12:42:53 pm »

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.
« Last Edit: May 30, 2024, 12:57:04 pm by Thaddy »
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

 

TinyPortal © 2005-2018