-ftrapv

From 3.17 Options for Code Generation Conventions

-ftrapv

This option generates traps for signed overflow on addition, subtraction, multiplication operations. The options -ftrapv and -fwrapv override each other, so using -ftrapv -fwrapv on the command-line results in -fwrapv being effective. Note that only active options override, so using -ftrapv -fwrapv -fno-wrapv on the command-line results in -ftrapv being effective.

#pragma GCC optimize("trapv")

My 1st programming language was FORTRAN. Exceptions Crashes occurring on overflow or underflow were guaranteed as a feature of the language. When I learned "C" I was shocked to learn that the compiled code behavior for overflow or underflow of signed values was undefined.

It looks like -ftrapv can create this situation for "C" programs. The trap is not an exception trap, but a call to abort(). Which isn't too unlike what FORTRAN would have done. With the Arduino ESP8266 Core, the abort() call lands in core_esp8266_postmortem.cpp. The GCC Library libgcc/libgcc2.c appears to make the call. Buildin functions __builtin_add_overflow, __builtin_sub_overflow, __builtin_mul_overflow, ... look interesting.

A failure start off like this:

User exception (panic/abort/assert)
--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Abort called

>>>stack>>>

ctx: cont
sp: 3fffff10 end: 3fffffc0 offset: 0000

References: https://stackoverflow.com/questions/38960763/ftrapv-and-fwrapv-which-is-better-for-efficiency

Something to look at later.

-Wshift-count-negative and -Wshift-count-overflow

The behavior is undefined and I think with Xtensa op-codes a large shift left looks like a circular shift.

This has some good stuff: https://codeforces.com/blog/entry/15547

Hmm, these appear to default. See GCC Warning Options