[fpc-devel] bug: Inc(v,i)/Dec(v,i)

[Hans-Peter Diettrich]

Marcel Martin wrote:

> > I cannot see any correspondence, when one form produces overflows,
> > whereas the other form doesn't.
> 
> It shouldn't. Under the same circumstances, both have to
> raise overflows. Here, it's not the overflow rules that are
> inconsistent but the way they are implemented by such or
> such compiler.

Yes, and no compiler should raise an overflow, IMO.

> > 2) The overflow only occurs for special, machine specific conditions.
> > The writer of high level language code IMO can expect that no machine
> > specific details will influence the behaviour of his code, else the
> > compiler at least must issue appropriate warnings.
> 
> I agree. But what is the link with the fact that in no case
> the compiler should code a "Inc(x,-1)" as a "Dec(x,1)"?

As already mentioned, a compiler has to produce correct code, and a
correct implementation will either reject an increment of -1 for
unsigned variables, or will produce correct code that does not raise an
overflow.
> 
> > Since I don't have the current FPC compiler, I refer to D4 in this
> > (hopefully) last example:
> 
> This list is named "fpc-devel" ;-)

Yes, I know, but I could not get the latest version already (small
bandwidth).

> > type
> >   TCard = 0..1000; //or 0..$FFFFFFFF or 0..$8000
> > var
> >   x: TCard;
> > const
> >   c = -1;
> > begin
> >   x := 5;
> >   x := x + c;
> >   Inc(x, c);
> > end;
> >
> > Here no overflow occurs, at least not in D4.
> 
> No more with FPC. But with {$R+}, FPC will raise a range
> check error if the resulting x is not in 0..1000. (For Delphi,
> I don't know, it's too boring to get the generated assembler
> code.)

The range check is okay, it was never under question ;-)


> > An overflow occurs only in
> > the special case where the upper bound of the type is $FFFFFFFF, in
> > general when the highest bit in the highest byte of the memory
> > representation is part of the type. Would you call this an expected
> > behaviour?
> 
> Yes. Because I know that overflows only occur with 'native'
> types :-)

Okay, that's somewhat reasonable ;-)


> >>We have a big, BIG, communication problem...
> >
> >
> > I realized already that we are talking about different things :-(
> > I'm talking about computation in general, you're talking about machine
> > specific number representations and calculations.
> 
> We are talking about "Should the compiler replace "Inc(x,-1)"
> by "Dec(x,1)?" The answer is no.

Even if *your* answer is no, my answer still is yes.

 
> > Please check your arguments with regards to unsigned types in general,
> > i.e. any zero-based integer type.
> 
> With your example? If the same rules would apply for both user
> defined types and native types, in "x := x + c", the compiler
> should regard c = -1 as c = 1000 (since the range 0..1000 is
> the one of the residues modulo 1001). So "x := x + c" should be
> coded as x := x + 1000 (or an error should be raised because -1
> is not in 0..1000) and if x > 0, with {$Q+}, the operation
> should raise an overflow.

That's a bit weird, isn't it? If you argue with modulo arithmetic, you
should know that overflows or range errors cannot occur then. But Pascal
doesn't use modulo arithmetic, so your arguments simply don't apply.

DoDi