Am 22.09.2017 um 17:28 schrieb Christo: > On Fri, 2017-09-22 at 07:10 +0200, Christo wrote: >> On Wed, 2017-09-20 at 12:36 +0200, Karoly Balogh (Charlie/SGR) wrote: >>> > > A complication I've noted is that enabling overflow checking doesn't > call the fpc_mul_byte_overflow function (as the naming convention > suggested), rather the generated code calls fpc_mul_byte and then check > the carry flag to determine whether an overflow occurred. Since the > function in generic.inc is plain pascal code there is no guarantee that > the carry flag will be set if an overflow should have occurred. I > assume that at a higher level the code generator assumes that a > hardware MUL instruction _will_ be used, leading to incorrect overflow > detection logic if a software helper is used. > > A similar situation exist for the current 16 bit software MUL case with > overflow checking. > > Any pointers on where to start looking to try and adapt the overflow > checking code generation?
AVR has no working overflow checking yet. Basically, tcg.a_op_reg_reg_reg_checkoverflow and tcg.a_op_conbst_reg_reg_checkoverflow need to be overridden and they have to set ovloc properly which is checked later on by g_overflowCheck_loc, _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
