[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977 --- Comment #5 from JunMa --- (In reply to Martin Sebor from comment #4) > You're right that the conversion from int128_t to unsigned long can result > in truncation, so the range of the result is that of unsigned long. Yet I > suspect that relying on it is more likely unintentional and a bug. The > question in my mind is whether narrowing int128_t conversions should be > diagnosed just in these contexts (i.e., -Wstringop-overflow) or in others as > well. We have no idea whether these truncations is intentional or not in gcc side, maybe we need a new option such as Wstringop-truncation to do this.
[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977 --- Comment #4 from Martin Sebor --- You're right that the conversion from int128_t to unsigned long can result in truncation, so the range of the result is that of unsigned long. Yet I suspect that relying on it is more likely unintentional and a bug. The question in my mind is whether narrowing int128_t conversions should be diagnosed just in these contexts (i.e., -Wstringop-overflow) or in others as well.
[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977 --- Comment #3 from JunMa --- (In reply to JunMa from comment #2) > After a bit more thinking, the behavior of gcc trunk is right. the range of > n_3 in truncation from int128 to long unsigned int equal to the range of > long unsigned int. for example: if n_3 = 0x1, then _1 is 0 which is > less than 7. > > so this is not a bug. sorry, when n_3 = 0x1000 , _1 is 0.
[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977 --- Comment #2 from JunMa --- After a bit more thinking, the behavior of gcc trunk is right. the range of n_3 in truncation from int128 to long unsigned int equal to the range of long unsigned int. for example: if n_3 = 0x1, then _1 is 0 which is less than 7. so this is not a bug.
[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977 JunMa changed: What|Removed |Added CC||JunMa at linux dot alibaba.com --- Comment #1 from JunMa --- in function f, the conversion of stmt _1 = (long unsigned int) n_3 is extending, while in function g, the conversion of stmt _1 = (long unsigned int) n_3 is truncating. For integer type truncation, gcc compute the range of target only if the range size of source is less than what the precision of the target type can represent. I think this can be relaxed when the target type of truncation is unsigned.
