aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-param.c
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2025-01-06 16:01:07 +0100
committerJan Beulich <jbeulich@suse.com>2025-01-06 16:01:07 +0100
commit30200464e9dd7903be8f186ea137b7982f812670 (patch)
treef6e15a0db753b3377ee8b16dc8c3451b477fb4fa /gdb/python/py-param.c
parent8ac42dbf5001416e6b741c5361be14186afde5b0 (diff)
downloadbinutils-30200464e9dd7903be8f186ea137b7982f812670.zip
binutils-30200464e9dd7903be8f186ea137b7982f812670.tar.gz
binutils-30200464e9dd7903be8f186ea137b7982f812670.tar.bz2
gas: special-case division / modulo by ±1
Dividing the largest possible negative value by -1 generally is UB, for the result not being representable at least in commonly used binary notation. This UB on x86, for example, is a Floating Point Exception on Linux, i.e. resulting in an internal error (albeit only when sizeof(valueT) == sizeof(void *); the library routine otherwise involved apparently deals with the inputs quite okay). Leave original values unaltered for division by 1; this may matter down the road, in case we start including X_unsigned and X_extrabit in arithmetic. For the same reason treat modulo by 1 the same as modulo by -1. The quad and octa tests have more relaxed expecations than intended, for X_unsigned and X_extrabit not being taken into account [yet]. The upper halves can wrongly end up as all ones (for .octa, when !BFD64, even the upper three quarters). Yet it makes little sense to address this just for div/mod by ±1. quad-div2 is yet more special, to cover for most 32-bit targets being unable to deal with forward-ref expressions in .quad even when BFD64; even ones being able to (like x86) then still don't get the values right.
Diffstat (limited to 'gdb/python/py-param.c')
0 files changed, 0 insertions, 0 deletions