View Issue Details

IDProjectCategoryView StatusLast Update
0037816FPCCompilerpublic2020-10-04 12:17
ReporterWolfgang Helbig Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
PlatformimacOSmac os x 
Product Version3.2.0 
Summary0037816: computes unexpected result
DescriptionCompile and run the program below and wonder why.
$ cat overflow.p
{$MODE ISO}
{$Q+}
program ov(output);
begin
  writeln('maxint+1: ', maxint+1);
  writeln('(maxint+1)*(maxint+1): ', (maxint+1)*(maxint+1));
end.
$ fpc overflow.p
$ overflow
maxint+1: 2147483648
(maxint+1)*(maxint+1): 46116860184

Obviously, the integer range is overflowed, which is not reported by the run time system. According to section 8.2.1 of the Pascal User Manual and Report, the runtime system must report this arithmetic error.
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Activities

Florian

2020-09-26 15:49

administrator   ~0125875

The reference for the ISO implementation is the ISO standard. Where does it make a statement how integer overflows are handled? I didn't find anything.

nanobit

2020-09-27 08:30

reporter   ~0125892

Wolfgang, your report does not look like overflow, but like a printing error:
It shows truncated "46116860184" from correct int64 "4611686018427387904"

Sven Barth

2020-09-27 11:48

manager   ~0125895

Last edited: 2020-09-28 23:08

View 2 revisions

Mode ObjFPC correctly prints the second one as 4611686018427387904, so something truncates it in mode ISO...

Also please note that FPC uses the native Integer type as base, so on a 64-bit system it will only overflow if you overflow a 64-bit value. Otherwise you should expect range errors, but since you do not assign to anything there won't be any range error.

The following will correctly result in a warning (or an error if $R is enabled):

{$MODE iso}
{$Q+}
{.$R+}
program ov(output);
var
  i: Integer;
begin
  writeln('maxint+1: ', maxint+1);
  writeln('(maxint+1)*(maxint+1): ', (maxint+1)*(maxint+1));
  i := (maxint+1)*(maxint+1);
end.

Wolfgang Helbig

2020-09-28 10:09

reporter   ~0125917

Nanobit, you are right: This does not overflow in 64bit arithmetic, but it does overflow in 32 bit arithmetic and has to be reported by the runtime system in ISO pascal. I've choosen this example to demonstrate an overflow that will not be reported as a range check.

Thaddy de Koning

2020-09-28 10:24

reporter   ~0125918

Last edited: 2020-09-28 10:34

View 4 revisions

Overflows are CPU related (native integer type) , whereas rangecheck is type related.
That can make a huge difference.
See https://www.freepascal.org/docs-html/current/prog/progsu64.html#x71-700001.2.64

Additional to the documentation this also hold for 8 and 16 bit CPU's, since {$Q+} relies on the native integer type for the CPU.

nanobit

2020-09-28 10:52

reporter   ~0125919

Last edited: 2020-09-28 10:55

View 2 revisions

Wolfgang, the motivation (as Thaddy said too) behind EIntOverflow (215) is different:
EIntOverflow (incorrect result) refers to a limit of hardware or larger (emulation):
In an ideal environment the limit would be infinite, thus EIntOverflow would never happen, regardless of used types.
But ERangeError can/should happen on assign of correct! math-result to smaller type.

Florian

2020-09-29 18:46

administrator   ~0125967

> but it does overflow in 32 bit arithmetic and has to be reported by the runtime system in ISO pascal.

@Wolfgang: Can you please tell me section where this is decribed in the ISO standard so we get it done right? "Pascal User Manual and Report" is not the ISO Pascal standard document but something third party.

Wolfgang Helbig

2020-10-03 17:10

reporter   ~0126065

Sorry, I confine myself to Jensen, Wirth: "User Manual and report", 3rd edition, scrutinizing standard papers is not for me! Anyway, section 8.2.1, Arithmetic Operations reads:

"However, it the operands or results are not in the range of -maxint..maxint an implementation may choose either to perform the operation correctly or to treat the operation as an error."

And this seems perfectly implemented by FPC! Either some intermediate result is computed correctly even though the result is not in the integer range since FPC employs 64 bit integer operation, or it overflows the 64bit range, which the runtime will report as an overflow error, or the compiler triggers a range error if the result is assigned to an integer,
So with the R+ and Q+ everything is ok. You should not see a wrongly computed result!
But this issue started with precisely that error! It looked like the operation overflowed as if a wrong result was computed.

Wolfgang Helbig

2020-10-04 11:40

reporter   ~0126073

You'll find in of ISO 7185:1990, section 6.7.2.2, Arithmetic Operations :
"It shall be an error if an integer operation or function is not performed according to the mathematical rules for integer arithmetic."
And section 5.1, Processors demands that complient processors report any errors.

nanobit

2020-10-04 12:17

reporter   ~0126074

Sounds good, and we can deduce about integer-overflow:
In Pascal, for int64-typed input and for untyped const64-expressions
the minimum requirement is 64bit arithmetic, on all systems.
If the hardware is not sufficient, then math-emulation is used.
The objective is to increase the success rate of internal math-results (fewer EIntOverflow).
The trend continues: On cpu128, 128bit arithmetic would be used for up-to-int128 input.

32bit arithmetic is used only for up-to-int32-typed input on cpu32.
(This is just minimal (but fast) implementation)

Generally, software should not produce wrong arithmetic-results (overflows) on purpose,
but truncation/wrapping is defined only on assign to declared smaller target.

Issue History

Date Modified Username Field Change
2020-09-26 12:33 Wolfgang Helbig New Issue
2020-09-26 15:49 Florian Note Added: 0125875
2020-09-27 08:30 nanobit Note Added: 0125892
2020-09-27 11:48 Sven Barth Note Added: 0125895
2020-09-28 10:09 Wolfgang Helbig Note Added: 0125917
2020-09-28 10:24 Thaddy de Koning Note Added: 0125918
2020-09-28 10:30 Thaddy de Koning Note Edited: 0125918 View Revisions
2020-09-28 10:33 Thaddy de Koning Note Edited: 0125918 View Revisions
2020-09-28 10:34 Thaddy de Koning Note Edited: 0125918 View Revisions
2020-09-28 10:52 nanobit Note Added: 0125919
2020-09-28 10:55 nanobit Note Edited: 0125919 View Revisions
2020-09-28 23:08 Sven Barth Note Edited: 0125895 View Revisions
2020-09-29 18:46 Florian Note Added: 0125967
2020-09-29 18:47 Florian Status new => feedback
2020-09-29 18:47 Florian FPCTarget => -
2020-10-03 17:10 Wolfgang Helbig Note Added: 0126065
2020-10-03 17:10 Wolfgang Helbig Status feedback => new
2020-10-04 11:40 Wolfgang Helbig Note Added: 0126073
2020-10-04 12:17 nanobit Note Added: 0126074