View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010545 | FPC | Compiler | public | 2008-01-03 20:17 | 2011-02-04 19:13 |
| Reporter | Bad Guy | Assigned To | Jonas Maebe | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 2.2.0 | ||||
| Summary | 0010545: bitshift operations are not handled properly for LongInt | ||||
| Description | When 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 Information | Noiced when dug up old signal processing code, that worked fine on turbo pascal (back in the days). | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | |||||
| FPCOldBugId | |||||
| FPCTarget | |||||
| Attached Files |
| ||||
| related to | 0018685 | closed | Jonas Maebe | Bit shift operations on QWord again |
|
2008-01-03 20:17
|
|
|
|
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. |
|
|
> 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 |
| 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 |
