Hi,
investigating bug #29760 I reduced bug to:

var
   c: currency;
   d: double;
begin
   c := 123.45;
   d := 100;
   writeln(c, '*', d, '=', c*d); // result of multiply is wrong = 123450000
end.

This happens only on Win64 with FPC 3.0

Can somebody please check and confirm ?

Thanks

-Laco.

If confirmed, then I think this is enough reason to start a 3.0.2 release :/

Michael.

I've fixed similar issue for ARM several months ago. http://bugs.freepascal.org/view.php?id=28748
But the bug possibly had affected all 64-bit integer currency targets.

Does the bug exist in trunk?

Yury.

This happens only on Win64 with FPC 3.0 Can somebody please check and confirm ?

compiled with official Lazarus 1.6 (SVN revision as displayed in the about box: 51630)
console output of your program is:

1.234500000000000000E+02* 1.0000000000000000E+002= 1.234500000000000000E+08

It really depends on the platform.

Linux, 64-bit prints with trunk:

1.234500000000000000E+02* 1.0000000000000000E+002= 1.234500000000000000E+04

And it prints the same with 3.0.0.

Michael.

Are there tests for compiler ?
Is it possible, that such bug is not noticed during preparation of release ? (or is it such special case, that this was not covered by existing test?) -Laco.

Yes, several thousands: a quick count says 5392.
you can find them in the tests directory of the fpc SVN repository.

Is it possible, that such bug is not noticed during preparation of release ? (or is it such special case, that this was not covered by existing test?)

Presumably the implementation of the currency type predates the testsuite.

Michael.

123450000

1.234500000000000000E+04

And it prints the same with 3.0.0.

It's probably more related to whether the system has Extended or not. On Linux x86_64 we use the FPU and thus the 80-bit floating point types, on Win64 we don't. Would be interesting to see the results on other platforms that don't have an 80-bit type (e.g. ARM).

Regards,
Sven

about box: 51630)

> console output of your program is: > > 1.234500000000000000E+02* 1.0000000000000000E+002=

1.234500000000000000E+08

Are there tests for compiler ? Is it possible, that such bug is not noticed during preparation of

release ?

(or is it such special case, that this was not covered by existing test?)

There are many and they are run every night for quite some platforms. It could however be that this specific case was never tested.

Regards,
Sven

Faulty on RPi2 but not on AMD64.

fpc test.pas
Free Pascal Compiler version 3.0.0 [2015/12/25] for arm Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for ARMHF
Compiling test.pas
Assembling program
Linking test
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? 11 lines compiled, 1.3 sec
0 1> ./test
1.234500000000000000E+02* 1.0000000000000000E+002= 1.234500000000000000E+08

fpc test.pas
Free Pascal Compiler version 3.0.1 [2015/08/31] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for x86-64
Compiling test.pas
Linking test
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? 10 lines compiled, 0.4 sec
0 1> ./test.pas
-bash: ./test.pas: Permission denied
126 1> ./test
1.234500000000000000E+02* 1.0000000000000000E+002= 1.234500000000000000E+04

I've tested FPC trunk on win64 and it works correctly.

1.234500000000000000E+02* 1.0000000000000000E+002= 1.234500000000000000E+04

Looks like my fix in r32054 also applies for this case. The bug affected all targets where currency is 64-bit integer.

Yury.

1.234500000000000000E+04

Looks like my fix in r32054 also applies for this case. The bug affected

all targets where currency is 64-bit integer.

Then that indeed applies for Win64 as well.

Regards,
Sven

Maybe time to start thinking about 3.0.2, then.
This is not a minor bug.

Michael.

As I see there are some test units, which try do complex testing of given subject (tint, ttrunc, tround etc.) and then there are "ad-hoc" test units (name begins with "tw"+number), which more or less react only to given bug. (so until bug is reported no test exists). I do not know if there is somebody who really knows what is in these "tw" test units ? (I doubt that somebody can remember what is in thousand of files)

So wouldn't be better have less bigger test units for example "tcurrency" which will do complex testing for for example all math.operations with currency data type ?
(as opposed to have lot of fragments in lot of anonymous files)

-Laco.

IMO it is serious bug and users should be informed, that upgrading to FPC 3.0 (on some platforms) can leads to serious problems when currency and double are involved. (but who knows where all around it can pop up? ... we know at least about sqlDB, but there may be other libraries, components which are affected)

May be we should put warning at: http://wiki.freepascal.org/User_Changes_3.0 and
http://wiki.freepascal.org/Lazarus_1.6.0_release_notes

-Laco.

release ?

> > (or is it such special case, that this was not covered by existing

test?)

> > There are many and they are run every night for quite some platforms. It

could however be that this specific case was never tested.

> As I see there are some test units, which try do complex testing of given

subject (tint, ttrunc, tround etc.) and then there are "ad-hoc" test units (name begins with "tw"+number), which more or less react only to given bug. (so until bug is reported no test exists).

I do not know if there is somebody who really knows what is in these "tw"

test units ? (I doubt that somebody can remember what is in thousand of files)

We add the examples that are provided on bug reports as tests to avoid regressions.

So wouldn't be better have less bigger test units for example "tcurrency"

which will do complex testing for for example all math.operations with currency data type ?

(as opposed to have lot of fragments in lot of anonymous files)

Feel free to write such a test.

Regards,
Sven

Please update the wiki!

Ondrej

See attached file. Is this way or not (may be that somewhat must be IFDEFed for platforms where given data type does not exists?) ? (as I do not know compiler internals, I do not know which makes sense to test and which is redundant or irrelevant)
-Laco.

Dňa 11.3.2016 o 8:07 Ondrej Pokorny napísal(a):

But what is the correct information:

"FPC 3.0 has bug, which causes that mathematical operations involving currency and double data types give wrong results on platforms where currency is internaly represented as Int64 (f.e. Win64)" ?

-laco.

Updated file.
If you find it useful add it please to "tests/test" and/or replace "tw28748.pp" (as it is subset of this)
Or give mee feedback what should be changed, added or so. -Laco.

LacaK wrote

Updated file. If you find it useful add it please to "tests/test" and/or replace "tw28748.pp" (as it is subset of this) Or give mee feedback what should be changed, added or so.

tests/test/cg/taddcurr.pp contains already most of those tests in a systematic way. I think what's may be missing is a systematic test for converting currency to floating point types. We already have such tests for converting integer types to floating point types in tests/test/cg/tcnvint4.pp , but it seems there's no similar test yet for converting floating/fixed point types to floating point.

Jonas

Dňa 11.3.2016 o 14:19 Jonas Maebe napísal(a):

this test was added after FPC 3.0 release ? If yes, then okay. If not then this test is not sufficient to catch above mentioned bug

okay, you know better. I leave up to you or somebody more experienced to add this tests ... I believe it is not so much work either.

Thanks
-Laco.

No, this test is much older. That test already checks adding/subtracting/multiplying and dividing currency values. Your test checks the same with integer/double, but that merely adds type conversions from double/integer to currency. It's this type conversion that is broken in FPC 3.0, and hence that's what should be tested.

Jonas

Ok, then I have questions:

1. Is there any example of test, which tests others type conversions, which I can adapt to currency ?
2. Or is there someone more experienced than me, who is willing write such test ?
3. Is it possible at least as temporary solution copy/paste "my tests" to tw28748.pp ?

I think, that it is reasonable make steps that will prevent same error to raise again in future ...

Thanks
-Laco.