On 01/17/2017 08:26 AM, Jeff Law wrote:
On 01/16/2017 05:06 PM, Martin Sebor wrote:
The test case submitted in bug 79095 - [7 regression] spurious
stringop-overflow warning shows that GCC optimizes some loops
into calls to memset with size arguments in excess of the object
size limit. Since such calls will unavoidably lead to a buffer
overflow and memory corruption the attached patch detects them
and replaces them with a trap. That both prevents the buffer
overflow and eliminates the warning.
But doesn't the creation of the bogus memset signal an invalid
transformation in the loop optimizer? ie, if we're going to convert a
loop into a memset, then we'd damn well better be sure the loop bounds
are reasonable.
I'm not sure that emitting the memset call is necessarily a bug in
the loop optimizer (which in all likelihood wasn't written with
the goal of preventing or detecting possible buffer overflows).
The loop with the excessive bound is in the source code and can
be reached given the right inputs (calling v.resize(v.size() - 1)
on an empty vector. It's a lurking bug in the program that, if
triggered, will overflow the vector and crash the program (or worse)
with or without the optimization.
What else could the loop optimizer could do in this instance?
I suppose it could just leave the loop alone and avoid emitting
the memset call. That would avoid the warning but mask the
problem with the overflow. In my mind, preventing the overflow
given that we have the opportunity is the right thing to do.
That is, after all, the goal of the warning.
As I mentioned privately yesterday, I'm actually pleasantly
surprised that it's helped identify this opportunity in GCC itself.
My hope was to eventually go and find the places where GCC emits
potentially out of bounds calls (based on user inputs) and fix them
to emit better code on the assumption that they can't be valid or
replace them with traps if they could happen in a running program.
It didn't occur to me that the warning itself would help find them.
Martin
