diff options
author | Jan Beulich <jbeulich@suse.com> | 2025-01-06 16:01:07 +0100 |
---|---|---|
committer | Jan Beulich <jbeulich@suse.com> | 2025-01-06 16:01:07 +0100 |
commit | 30200464e9dd7903be8f186ea137b7982f812670 (patch) | |
tree | f6e15a0db753b3377ee8b16dc8c3451b477fb4fa /gdb/python/py-param.c | |
parent | 8ac42dbf5001416e6b741c5361be14186afde5b0 (diff) | |
download | binutils-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