On 06/11/2018 03:25 PM, Jeff Law wrote:
On 05/14/2018 04:41 PM, Martin Sebor wrote:
r256683 committed to GCC 8 to avoiding duplicate instances of
-Wstringop-overflow warnings on some targets has the unintended
side-effect of suppressing even singleton instances of the warning
in cases such as 'strcat (strcpy (buf, "hello "), "world!")' when
_FORTIFY_SOURCE is defined.
The attached patch restores the warning for the trunk.
Since this is a regression in a security feature and the warning
isn't prone to false positives (I don't think I've seen any when
_FORTIFY_SOURCE is defined), I'd also like the fix considered for
the 8 branch.
Thanks
Martin
gcc-85259.diff
PR tree-optimization/85259 - Missing -Wstringop-overflow= since r256683
gcc/ChangeLog:
PR tree-optimization/85259
* builtins.c (compute_objsize): Handle constant offsets.
* gimple-ssa-warn-restrict.c (maybe_diag_offset_bounds): Return
true iff a warning has been issued.
* gimple.h (gimple_nonartificial_location): New function.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Call
gimple_nonartificial_location and handle -Wno-system-headers.
(handle_builtin_stxncpy): Same.
gcc/testsuite/ChangeLog:
PR tree-optimization/85259
* gcc.dg/Wstringop-overflow-5.c: New test.
* gcc.dg/Wstringop-overflow-6.c: New test.
OK for the trunk.
On retesting the patch I noticed a failure in one of the test
cases it adds. It turns out that a recent change made to improve
code generation (r261061) has resulted in transforming one of
the strcat calls in the test into a MEM_REF, which defeats
the -Wstringop-overflow checker (the checker only looks at
built-ins, not MEM_REF expressions). It feels like one step
forward and one step back with these MEM_REFs. I've xfailed
the test case until the -Wstringop-overflow checker is made
smarter and opened bug 86121 to track this regression.
(Though, IMO, GCC should check calls to make sure they're
valid before transforming them into MEM_REFs and only do
the transformation if it is within the bounds of the objects .)
The general guidance we've received is to not try and fix these on the
release branches. However, I think this one deserves an exception to
the general guidance. So OK for the gcc-8 branch.
Okay. (GCC 8 is not affected by the above.)
Martin
