I just repeated the test on i386-win32 and it's the same thing... with
one notable exception:
procedure DoDivMod(N, D: Int64; out Q, R: LongInt); noinline;
begin
Q := LongInt(N) div LongInt(D);
R := LongInt(N) mod LongInt(D);
end;
This reduces the operation to 32 bits, but does NOT
Hi Florian,
Can I have a specific code example where this is absolutely necessary,
and, if applicable, a target where it's known to cause a problem
otherwise? I've tried to create the example listed in the e-mail with
the following:
procedure DoDivMod(N, D: Int64; out Q, R: LongInt);
That's useful to know - thanks Florian. So it's possible to forego the
-1 check if no downsizing occurs.
I suppose it makes sense... if we go by the signed 64-bit equivalents,
$8000 div $ = $8000, which when
typecast to a LongInt does result in a
Am 19.05.23 um 21:14 schrieb J. Gareth Moreton via fpc-devel:
So I need to ask... should the check for a divisor of -1 still be
performed?
Yes. This is the result of "down sizing" a division. In case of
longint(int64 div int64) can be converted only into longint(int64) div
longint(int64) if
So I need to ask... should the check for a divisor of -1 still be
performed? The case of doing "min_int div -1", even with
unsigned-to-signed typecasting, seems very contrived and the programmer
should expect problems if "min_int" and "-1" appear as the operands. Is
there a specific example
Logically yes, but using 16-bit as an example, min_int is -32,768, and
signed 16-bit integers range from -32,768 to 32,767. So -32,768 ÷ -1 =
32,768, which is out of range. This is where the problem lies.
Internally, negation involves inverting all of the bits and then adding
1 (essentially
Le 16/05/2023 à 01:47, Stefan Glienke via fpc-devel a écrit :
min_int div -1
"min_int div -1" should give "- min_int" ?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 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
> >
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
>
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,
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?
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
Fair enough, but I would like an explanation as to why it's necessary,
because the reason for testing -1 in particular is very unclear, and I
wonder if there's a known misbehaviour with a particular division
function with -1.
Kit
On 11/05/2023 21:27, Wayne Sherman wrote:
On Thu, May 11,
On Thu, May 11, 2023 at 11:42 AM J. Gareth Moreton wrote:
> This is the code block in question (ncnv.pas, starting at line 3397)
The git "blame" function shows who last made changes:
https://gitlab.com/freepascal.org/fpc/source/-/blame/main/compiler/ncnv.pas?page=4#L3396
Most of that code was
This is the code block in question (ncnv.pas, starting at line 3397) -
if anyone can explain why it has to be set up this way, or add comments
to the code, I will be most grateful (it's run for the following node
types: subn, addn, muln, divn, modn, xorn, andn, orn, shln, shrn):
P.S. I found the code that adds the conditional checks; it's
"doremoveinttypeconvs" in the ncnv unit. However, it's very unclear as
to WHY it's doing it as there's no comments around the code block.
Kit
On 11/05/2023 15:39, J. Gareth Moreton via fpc-devel wrote:
It does seem odd. In a
It does seem odd. In a practical sense, the only time I can see -1
being a common input among other random numbers is if it's an error
value, in which case you would most likely do special handling rather
than pass it through a division operation. With the slowdown that comes
from additional
Looks like a rather disadvantageous way to avoid the idiv instruction because x
div -1 = -x and x mod -1 = 0.
I ran a quick benchmark doing a lot of integer divisions where sometimes
(randomly) the divisor was -1. When the occurence was rare enough (~5%) the
performance was not impacted, the
18 matches
Mail list logo
