View Issue Details

IDProjectCategoryView StatusLast Update
0035272FPCCompilerpublic2020-05-27 21:11
Reporternanobit Assigned ToJonas Maebe  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformwin32OSWindows 
Product Version3.0.4 
Fixed in Version3.3.1 
Summary0035272: longbool xor
DescriptionBoolean operations on longbools should operate logically (non-bitwise).
But xor returns the bitwise xor which can be the negation of the correct result.

var b1, b2, b3: longbool;
b1 := longbool(1); b2 := longbool(2);
b3 := b1 or b2; // gives -1 (True); would be 3 if bitwise
b3 := b1 and b2; // gives -1 (True); would be 0 (False) if bitwise
b3 := not b2; // gives 0 (False); would be -3 (True) if bitwise
b3 := b1 xor b2; // gives 3 (bitwise): dword(b3) := dword(b1) xor dword(b2);
b3 := boolean(b1) xor boolean(b2); // correctly gives 0 (False)

(b1 xor b2) returns True (this says: inputs are different),
xor fails to see that both inputs are logical equal (True, True)
(b1 and b2) correctly says, they are logical equal (True, True).
TagsNo tags attached.
Fixed in Revision42167
FPCOldBugId
FPCTarget-
Attached Files

Activities

nanobit

2019-03-25 14:31

reporter   ~0115040

Don't get confused by the verbosity of the test,
I really mean only the xor operator is buggy:)
Gives wrong result if the True ordinalities are different.

Jonas Maebe

2019-06-02 22:04

manager   ~0116539

"and" was similarly broken if full boolean evaluation was enabled.

nanobit

2020-05-26 10:00

reporter   ~0123071

Just now I noticed, this AND bug ((b1 and b2) returns false) occurs also
under Short-circuit evaluation {$b-}
IF the mode is -O2 or larger.

Jonas Maebe

2020-05-26 20:10

manager   ~0123077

Did you test that with trunk? Because the test program I added for this bug also tests AND with short circuit boolean evaluation and it works fine with -O2 for me (https://svn.freepascal.org/svn/fpc/trunk/tests/webtbs/tw35272.pp). If you can still reproduce it, please provide a test program.

nanobit

2020-05-27 01:56

reporter   ~0123090

Last edited: 2020-05-27 02:14

View 2 revisions

Tested some earlier trunk version, result was ok.
I have the same code except that I use function results instead of constants,
because the optimizer can remove much code at compiletime.

Updated now to latest FPC 3.2:
"xor" fails under {$b-} and {$b+}, all O-levels
"and" fails under {$b-} level -O2, O3, O4
"and" fails under {$b+}, all O-levels

Jonas Maebe

2020-05-27 21:11

manager   ~0123101

The fix for this bug is indeed not in 3.2.

Issue History

Date Modified Username Field Change
2019-03-25 12:03 nanobit New Issue
2019-03-25 14:31 nanobit Note Added: 0115040
2019-06-02 22:04 Jonas Maebe Assigned To => Jonas Maebe
2019-06-02 22:04 Jonas Maebe Status new => resolved
2019-06-02 22:04 Jonas Maebe Resolution open => fixed
2019-06-02 22:04 Jonas Maebe Fixed in Version => 3.3.1
2019-06-02 22:04 Jonas Maebe Fixed in Revision => 42167
2019-06-02 22:04 Jonas Maebe FPCTarget => -
2019-06-02 22:04 Jonas Maebe Note Added: 0116539
2020-05-26 10:00 nanobit Note Added: 0123071
2020-05-26 10:18 NoName Status resolved => new
2020-05-26 10:18 NoName Resolution fixed => reopened
2020-05-26 20:10 Jonas Maebe Status new => resolved
2020-05-26 20:10 Jonas Maebe Resolution reopened => fixed
2020-05-26 20:10 Jonas Maebe Note Added: 0123077
2020-05-27 01:56 nanobit Note Added: 0123090
2020-05-27 02:14 nanobit Note Edited: 0123090 View Revisions
2020-05-27 21:11 Jonas Maebe Note Added: 0123101