[fpc-devel] "Wrong" evaluation of longbool on AVR

[Christo Crause]

I am investigating test suite failures for the avr-embedded target.  The
first genuine failure is test/taddbool.pp (there are also a bunch of
incorrect exit values and other failures due to missing features such as
float, random, ansi/widestring etc.).  This test fails on the last
expression (longbool XOR longbool).  The following is a stripped down test
case illustrating the failure:

Program TAddBool;
var
 lb1, lb2: longbool;
begin
  lb1 := true;
  lb2 := true;
  if lb1 xor lb2 then
    Halt(1)
  else
    Halt(0);
end.

>From the node report (thanks Kit!) it appears that the compiler first
converts the longbools to boolean8, then perform the XOR, then convert the
boolean8 result back to longbool before evaluating the if condition.  In
this last type conversion there appear to be an error (with reference to
the attached assembler output): after label .Lj5 a 32 bit bool is recreated
from the result of the 8 bit XOR node.  Note that r18 contains the result
of the 8 bit XOR result, however registers r19 - r21 are used without
initialization.  R19 in this example contains the result of converting LB2
to an 8 bit bool, leading to the observed incorrect result.

Is this analysis correct?  If so, is this a code generation issue limited
to avr, or is it a higher level problem which affects other processor
types?  Would someone be willing to give me pointers on how to fix this if
the fix is not too involved?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190907/418aca66/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taddbool.s
Type: application/octet-stream
Size: 3666 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190907/418aca66/attachment.obj>