In many cases with GCC, optimizations that are implied by something like -O2 or -O3 can be
specifically disabled, or additional optimizations can be specifically enabled.
If either case is true of the pointer arithmetic optimization in the newer GCCs, then this
would seem to be a better case to put. The "insecurity" is optional and only there because the
user has stipulated (implicitly or explicitly) that it should be.
Alternatvely, it might be argued that this shouldn't be in GCC proper (it's not a compiler
function, it's a validation function) but in a distinct module which scanned for likely range
violations and other cadidates for problems - something akin to splint or the stanford checker
but restricted to cases that can be reliably detected. You could then run it independently or
as part of the toolchain.
A third option would be to modify a source-to-source compiler like OpenIMPACT to alter tests
that would be optimized this way into a more correct form that doesn't need optimizing by GCC.
A fourth option is to have bounds-checking at runtime be implicit and require that it be
explicitly excluded at compile-time. Alternatively, since runtime bounds-checking is already
available, state that its exclusion is a voluntary statement on the part of a developer that
the validation of pointers is not wanted.
In other words, this seems a non-argument on any meaningful timescale. There are way too many
ways for the GCC developers, other members of the open source community or the developers of
potentially suspect code to eliminate the problem one way or another. If there is a potential
problem, it is a potential problem by mutual agreement.