https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54848
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |easyhack
Summary|-ftrapv doesn't work when |Narrowing of operations
|assigning to an integer |suppresses overflows that
|with smaller size |would trap with -ftrapv
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the first testcase the frontend applies narrowing:
short int c = (short int) ((unsigned short) a + (unsigned short) b);
which makes the possibly overflowing operation a) not actually overflow,
b) carried out in an unsigned type, thus not subject to -ftrapv
There is interpretational leeway with respect to whether -ftrapv should
preserve all overflows (and thus traps) that would occur in the abstract
machine or not. Consider
int main()
{
0x70000000 + 0x50000000;
}
should that trap at runtime? When optimizing?
The second testcase has the same issue - the frontend elides integer
promotion and thus performs an unsigned short multiplication which is
not subject to -ftrapv.
-fsanitize=undefined avoids such narrowing which in these cases happen
in convert.cc:do_narrow where the sanitize exemptions could be extended
to also cover -ftrapv. If anybody cares.
