User Changes 2.2.0

About this page

Below you can find a list of intentional changes since the FPC 2.0.4 release which can change the behaviour of previously working code, along with why these changes were performed and how you can adapt your code if you are affected by them.

All systems

Floating point constants

• Old behaviour: all floating point constants were considered to be of the highest precision available on the target platform
• New behaviour: floating point constants are now considered to be of the lowest precision which doesn't cause data loss
• Example: 2.0 can be represented exactly using single, so it will be parsed as a single. 1.1 cannot be represented exactly in any IEEE floating point format, so it will be considered to be of the largest floating point type available
• Reason: Delphi compatibility, avoid wrong precision-loss warnings when doing things like "singler:=single1*2.0"
• Effect: some expressions, in particular divisions of integer values by floating point constants, may now default to a lower precision than in the past.
• Remedy: if more precision is required than the default, typecast the floating point constant to a higher precision type, e.g. extended(2.0)

RTLEventStartWait

• Old behaviour: you had to call RTLEventStartWait before calling RTLEventWaitFor
• New behaviour: RTLEventStartWait has been removed from the RTL
• Example: self-explanatory
• Reason: RTLEventStartWait only existed because the Unix implementation did not support persistent events. Now it does, so this routine is no longer necessary.
• Effect: code calling RTLEventStartWait will no longer compile
• Remedy: remove all calls to RTLEventStartWait from your code, they are no longer necessary

Unix

RTLEvent persistence

• Old behaviour: calling RTLEventSetEvent before another thread was waiting caused the event to be lost
• New behaviour: RTLEventSetEvent is now persistent, i.e. it's possible to send the event before another thread starts waiting and it won't be lost (calling RTLEventSetEvent multiple times does not cause multiple events to add up in a queue)
• Example: see above
• Reason: compatibility with behaviour under Windows
• Effect: see above
• Remedy: for non-persistent events, use the pthread_cond_signal/wait and related routines directly

PowerPC

Floating point calculations

• Old behaviour: all floating point calculations used to be performed using double precision
• New behaviour: floating point calculations involving only single precision values are now performed using single precision
• Example: singler:=(single1/single2+single3)*single4 used to be calculated using double precision, and only be rounded back to single precision during the assignment. Now the intermediate calculations will also be done using single precision.
• Reason: speed (in particular single precision divisions are much faster than double precision ones), compatibility with gcc behaviour
• Effect & Remedy: see "Floating point constants" section