I made a merge request that removes the comparison against -1.
x86_64-win64 and i386-win32 pass without any regressions, so the reason
behind the change still eludes me. Maybe my fix for #39646 removes the
need for it?
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/418
Kit
On
I didn't see a mention of it in this discussion thread, but dividing the
largest negative integer by -1 does cause an overflow error of some sort,
because of two's complement.
Just to make sure, do (min_int div -1) and (min_int mod -1) behave the same
way before and after this proposed change? And
Thank you! I knew it must have been something simple like that!
I just did a quick test with x86 assembly language - this is the code
that used to run for dividing min_int by -1:
MOV EAX, $8000
NEG EAX
EAX contains $8000 as a result. When using IDIV:
MOV EAX, $8000
MOV EDX, $FF
FWIW in 3.2.2 I don't see the -1 check and the idiv causes an int overflow
exception. But silently returning 0 for min_int div -1 feels very wrong imo.
> On 15/05/2023 18:43 CEST Kirinn via fpc-devel
> wrote:
>
>
> I didn't see a mention of it in this discussion thread, but dividing the
> la
> FWIW in 3.2.2 I don't see the -1 check and the idiv causes an int overflow
> exception. But silently returning 0 for min_int div -1 feels very wrong IMO.
Pardon, debugger fooled me - I was meant to say "silently returning min_int".
> > On 15/05/2023 18:43 CEST Kirinn via fpc-devel
> > wrote: