View Issue Details

IDProjectCategoryView StatusLast Update
0010545FPCCompilerpublic2011-02-04 19:13
ReporterBad Guy Assigned ToJonas Maebe  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product Version2.2.0 
Summary0010545: bitshift operations are not handled properly for LongInt
DescriptionWhen used on "integer" or "shortint" variables, SHR and SHL operates as expected: perform arhithmetic shifting with MSB duplication/stuffing that is required for negative number handling.

However when variable is defined as "longint" - operation result is wrong due to some strange 31-bit wraparound.


Added a small program to verify problem.
Additional InformationNoiced when dug up old signal processing code, that worked fine on turbo pascal (back in the days).
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Relationships

related to 0018685 closedJonas Maebe Bit shift operations on QWord again 

Activities

2008-01-03 20:17

 

int_shr.pas (277 bytes)

Jonas Maebe

2008-01-03 20:40

manager   ~0017068

Last edited: 2008-01-03 23:27

You are misinterpreting the results you get: a SHR is /always/ unsigned in TP/FPC/Delphi. The difference in output from different compilers only depends on whether it's a 16/32/64 bit compiler. The reason is that when performing a SHL/SHR, the compiler will first convert the value to the native word size (except if the value >= the native word size, in which case it's left alone), and then perform the shift.

So in TP (a 16 bit compiler), a shr of a byte or shortint is actually calculated as a logical shr (and never an arithmetic shr) of a 16 bit integer, in FPC for 32 bit platforms and Delphi a shr of a byte, shortint, smallint and word is calculated as a shr of a longint, and in FPC for 64 bit platforms a shr of all values except for qwords are calculated as a shr of an int64. The result of the shr operation is of that same calculation type, regardless of the original input type.

Edit: and so if you assign the result back to a smaller type (and have range checking turned off), a shr of a negative value whose type is smaller than the native bit size, will behave as if an arithmetic shr was performed. But in practice you actually have an undetected range error.

Jonas Maebe

2011-02-04 19:13

manager   ~0045785

> and in FPC for 64 bit platforms a shr of all values except for
> qwords are calculated as a shr of an int64.

This turns out to be not entirely correct, see 0018685

Issue History

Date Modified Username Field Change
2008-01-03 20:17 Bad Guy New Issue
2008-01-03 20:17 Bad Guy File Added: int_shr.pas
2008-01-03 20:40 Jonas Maebe Status new => resolved
2008-01-03 20:40 Jonas Maebe Resolution open => no change required
2008-01-03 20:40 Jonas Maebe Assigned To => Jonas Maebe
2008-01-03 20:40 Jonas Maebe Note Added: 0017068
2008-01-03 23:27 Jonas Maebe Note Edited: 0017068
2008-04-13 10:14 Jonas Maebe Status resolved => closed
2011-02-03 19:18 Florian Relationship added related to 0018685
2011-02-04 19:13 Jonas Maebe Note Added: 0045785