Recent

Author Topic: Bug in exception handling for Single type in 32bit FPC  (Read 2403 times)

ad1mt

  • Sr. Member
  • ****
  • Posts: 332
    • Mark Taylor's Home Page
Bug in exception handling for Single type in 32bit FPC
« on: December 15, 2023, 12:53:19 am »
I am considering reporting a bug in FPC.
Here is a topic I created in FPC general...
  https://forum.lazarus.freepascal.org/index.php/topic,65519.0.html
This discusses problems I had getting exceptions to work with single types in the 32bit Windows compiler.
The problem is now solved, but it required specialist knowledge of Intel CPUs and assembly that I did not have.
I don't think the average Free Pascal user should be required to have this specialised knowledge in order to get exceptions working with single types. For those users, exception handling with single types is, in effect, broken.
I consider this to be a bug. It seems to me that {$SAFEFPUEXCEPTIONS ON} should be set by default. Expert users who know what they are doing could turn it off if they desired. I'm interested to know what the developers here think.
I would also like to ask how I go about reporting this as a bug. I am registered on GitLab, but could not figure out which project to select.
Thanks for all the hard work the FPC developers do... it is very much appreciated.
EDIT - I originally implied that the problem happened with all float types, but it is only the Single type that is affected.
« Last Edit: December 15, 2023, 10:47:09 am by ad1mt »

TRon

  • Hero Member
  • *****
  • Posts: 4377
Re: Float type exception bug in FPC
« Reply #1 on: December 15, 2023, 12:58:34 am »
I would also like to ask how I go about reporting this as a bug. I am registered on GitLab, but could not figure out which project to select.
Look at your left when viewing this forum. Under the category Free Pascal is a link named Bug tracker. Click it and you will be directed to gitlab bugtracker of the Free Pascal project. On your top right is a button "new issue" that you can click. It then ask for your credentials. see also https://wiki.freepascal.org/How_do_I_create_a_bug_report and gitlab has step by step instructions on the in and outs regarding generating bugreports as well.
Today is tomorrow's yesterday.

Bart

  • Hero Member
  • *****
  • Posts: 5575
    • Bart en Mariska's Webstek
Re: Bug in exception handling for Single type in 32bit FPC
« Reply #2 on: December 15, 2023, 04:07:03 pm »
AFAIK this behaviour is Delphi compatible and documented.

Bart

ad1mt

  • Sr. Member
  • ****
  • Posts: 332
    • Mark Taylor's Home Page
Re: Bug in exception handling for Single type in 32bit FPC
« Reply #3 on: December 15, 2023, 05:01:23 pm »
AFAIK this behaviour is Delphi compatible and documented.
Can you give me references please?  Thanks.
But even if it is Delphi compatible, I still think its very problematic behaviour, because it means that Free Pascal generated code is broken unless the user takes special action.
« Last Edit: December 15, 2023, 05:57:11 pm by ad1mt »

PascalDragon

  • Hero Member
  • *****
  • Posts: 6039
  • Compiler Developer
Re: Bug in exception handling for Single type in 32bit FPC
« Reply #4 on: December 19, 2023, 10:56:39 pm »
But even if it is Delphi compatible, I still think its very problematic behaviour, because it means that Free Pascal generated code is broken unless the user takes special action.

As mentioned in the other threads: this is by design and won't be changed. There is no need to file a bug report.

ad1mt

  • Sr. Member
  • ****
  • Posts: 332
    • Mark Taylor's Home Page
Re: Bug in exception handling for Single type in 32bit FPC
« Reply #5 on: December 20, 2023, 03:07:14 pm »
Here is a small program that shows the problem. To see the problem, you *must* compile this with the 32bit compiler. Everything works correctly on the 64bit compiler:
Code: Pascal  [Select][+][-]
  1. program test_single_7;
  2. uses    math;
  3. var
  4. R:single;
  5. got_exception:boolean=false;
  6. begin
  7. R:= 9**9;
  8. try
  9.   R:= R*R*R*R*R;
  10.   except
  11.     got_exception:= true;
  12.     writeln('1st exception arrived ok');
  13.   end;
  14. if (not got_exception) then writeln('1st exception failed to happen');
  15. try
  16.   R:= 9**2;
  17.   except
  18.     writeln('got 2nd exception - this is incorrect');
  19.   end;
  20. end.
This is absolutely distrastrous if you are trying to write rubust and bug-free code. This is a trivial example, but consider the consequences if the code was extremely complex. It would be a nightmare to debug. But more importantly, it would be impossible to get the logic working correctly.
Also please consider the consequences for beginner programmers, trying out Pascal for the first time. Free Pascal is the best compiler available, and problems like this will discourage those people from looking at Pascal. Do you really expect beginner programmers to know and understand the low-level complexities of Intel CPUs, in order to get their code to work correctly?

EDIT - it also appears to be a regression... code generated by the 32bit FPC v3.2.0 behaves correctly, i.e. in the above program the 1st exception arrives.

Your point that every float calculation requires an fwait is not correct.
An fwait is only required for the Single type, is only required inside a try...except statement, and only at the end of the try clause of the statement, like this:
Code: Text  [Select][+][-]
  1. try
  2. single:= (9 ** 9);
  3. single:= (single * single);
  4. single:= (single ** single);
  5. <--- fwait only needs to be inserted here
  6. except writeln('exception')
  7. end;

There many, many features of the Pascal language that slow down execution a little. But that is a small price to pay for the benefits of reliable, easy to debug programs.
« Last Edit: December 21, 2023, 10:11:16 am by ad1mt »

Thaddy

  • Hero Member
  • *****
  • Posts: 17420
  • Ceterum censeo Trumpum esse delendum (Tnx Charlie)
Re: Bug in exception handling for Single type in 32bit FPC
« Reply #6 on: December 20, 2023, 04:15:56 pm »
Sigh,
1. fwait is only not nessecary on single threaded programs.
2. It is documented that multiplication by single values are expanded to double. That needs to be the case by logic.

So, basically, you are talking nonsense here.
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

ad1mt

  • Sr. Member
  • ****
  • Posts: 332
    • Mark Taylor's Home Page
Re: Bug in exception handling for Single type in 32bit FPC
« Reply #7 on: January 05, 2024, 10:45:18 am »
I have question about this. I just compiled and ran the above test program on a 32bit Raspberry Pi running Linux, and it runs fine. And from reading the documentation about the SAFEFPUEXECEPTIONS switch, this problem only happens with Intel CPUs running in X86 mode.

If I am designing a library that is intended to be portable across all environments/CPUs/OS, I need to be aware of issues like this. The problem is that I don't have access to all those environments/CPUs/OS, and my knowledge of the low-level quirks of them is limited (I am aware of endian-ness and word-size, but not much else).

Can anyone recommended any reading/documentation that would help me to be aware of all the possible problems my library might encounter? Especially relating to Free Pascal. I would imagine the compiler developers would have encountered & fixed these kinds of problems.
Thanks.

Thaddy

  • Hero Member
  • *****
  • Posts: 17420
  • Ceterum censeo Trumpum esse delendum (Tnx Charlie)
Re: Bug in exception handling for Single type in 32bit FPC
« Reply #8 on: January 05, 2024, 12:45:27 pm »
IIRC this is 16 bit and 32 bit Intel, so it is CPU dependent.
It simply inserts an asm fwait instruction, so any errors can be propagated.It does not hurt to leave SafeFPUExceptions in your global code, because it is silently ignored for any other CPU than Intel cpu's that need it.

In general there are a few things to consider for multi-platform code.
1. Not every code works on any platform, although the main ones, Linux and Windows, the code should work on both if you do not use specific low-level units or units that are specified for a platform.
2. Use VM's and cross-compile
3. Use only high level standard libraries. These are prepared for cross platform.
4. Make use of judicious compiler directives. Do not over do it.
5. Do not use any assembler.
6. Know wht you are doing. Make sure you what a platform is capable of. What its limitations are.

I use Raspberry Pies a lot and with the above in mind I almost never run into problems unless I forgot to read the documentation.
4. Do not expect the code to work on all platforms

And it is definitely not a bug. It is well documented. E.g. don't expect the pin lay-out of a RPi to be compatible with other Pin layouts. They even differ between RPi versions.

To summarize:
1. Know the CPU
2. If you compile for a specific CPU mark your code with platform.
3. generic code, meant to be cross platform can only be written if you are aware of the platform specific issues. E.g. You can' t expect an AVR to run a fully fledged Lazarus GUI apllication.

Note that the above also goes for most other languages, like C or C++.
« Last Edit: January 05, 2024, 01:02:22 pm by Thaddy »
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

 

TinyPortal © 2005-2018