Re: [fpc-devel] "Wrong" evaluation of longbool on AVR
On Sat, 7 Sep 2019, 22:20 Florian Klämpfl, wrote: > > Thanks for the analysis, I fixed it already, see r42938. > That was quick, thank you. > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Wrong" evaluation of longbool on AVR
Am 07.09.19 um 21:49 schrieb 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? Thanks for the analysis, I fixed it already, see r42938. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] "Wrong" evaluation of longbool on AVR
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? taddbool.s Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
