On 7 December 2017 at 20:28, Martin Sebor <mse...@gmail.com> wrote: > On 12/07/2017 06:46 AM, Christophe Lyon wrote: >> >> Hi Martin, >> >> >> On 6 December 2017 at 00:51, Jeff Law <l...@redhat.com> wrote: >>> >>> On 12/05/2017 04:47 PM, Martin Sebor wrote: >>>> >>>> PR middle-end/82646 - bogus -Wstringop-overflow with >>>> -D_FORTIFY_SOURCE=2 on strncpy with range to a member array, >>>> >>>> The bug points out a false positive in a call to strncpy() when >>>> _FORTIFY_SOURCE is defined that doesn't exist otherwise. >>>> >>>> The problem is that __builtin_strncpy buffer overflow checking >>>> is done along with the expansion of the intrinsic in one place >>>> and __builtin___strncpy_chk is handled differently in another, >>>> and the two are out of sync. >>>> >>>> The attached patch corrects the choice of arguments used for >>>> overflow detection in __builtin___strncpy_chk and aligns >>>> the diagnostics between the two intrinsics. >>>> >>>> Martin >>>> >>>> gcc-82646.diff >>>> >>>> >>>> PR tree-optimization/82646 - bogus -Wstringop-overflow with >>>> -D_FORTIFY_SOURCE=2 on strncpy with range to a member array >>>> >>>> gcc/ChangeLog: >>>> >>>> PR tree-optimization/82646 >>>> * builtins.c (maybe_emit_chk_warning): Use size as the bound for >>>> strncpy, not maxlen. >>>> >>>> gcc/testsuite/ChangeLog: >>>> >>>> PR tree-optimization/82646 >>>> * gcc.dg/builtin-stringop-chk-1.c: Adjust. >>>> * gcc.dg/builtin-stringop-chk-9.c: New test. >>> >>> OK. >>> >> >> The new test fails on 32 bits platforms (arm, x86_32, aarch64 ilp32): >> FAIL: gcc.dg/builtin-stringop-chk-9.c (test for warnings, line 125) >> FAIL: gcc.dg/builtin-stringop-chk-9.c (test for warnings, line 133) >> FAIL: gcc.dg/builtin-stringop-chk-9.c (test for warnings, line 141) >> FAIL: gcc.dg/builtin-stringop-chk-9.c (test for warnings, line 149) > > > I believe these failures were due to bug 83296 that Richard fixed > earlier today. With the change in my tree, the test passes for > me with the arm-linux-gnueabi cross-compiler. Can you please > try again and let me know if the failures persist on any of your > targets? >
Indeed I can see it was fixed between r255460 and r255467, and Richard's patch is in the range (r255466). Thanks, Christophe > Thanks > Martin
