[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #14 from Martin Sebor --- Both Warray-bounds-8 and Wstringop-overflow-3.C pass with the Darwin cross now. Both the Darwin cross and a native GCC 10 now also issue the same warnings for the test case in comment #7. With the cross I see a bunch of failures in a few other tests (below) but those should get their own bug(s). c-c++-common/Warray-bounds-2.c c-c++-common/Warray-bounds.c gcc.dg/Warray-bounds-31.c gcc.dg/Wstringop-overflow-13.c
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #13 from Martin Sebor --- Author: msebor Date: Fri Nov 1 21:09:20 2019 New Revision: 277728 URL: https://gcc.gnu.org/viewcvs?rev=277728=gcc=rev Log: PR middle-end/91679 - missing -Warray-bounds accessing a member array in a local buffer PR middle-end/91647 - new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C PR middle-end/91463 - missing -Warray-bounds accessing past the end of a statically initialized flexible array member PR middle-end/92312 - bogus -Wstringop-overflow storing into a trailing array backed by larger buffer gcc/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-family/c-pretty-print.c (direct_abstract_declarator): Print bound in zero-length arrays. * gcc/c-family/c.opt (-Wzero-length-bounds): New option. * gcc/doc/invoke.texi (-Wzero-length-bounds): Document. * gimple-match-head.c (try_conditional_simplification): Use memcpy instead of a hand-rolled loop to avoid PR 92323. * tree-vrp.c (vrp_prop::check_array_ref): Handle trailing arrays with initializers. (vrp_prop::check_mem_ref): Handle declared struct objects. * tree.c (last_field): New function. (array_at_struct_end_p): Handle MEM_REF. (get_initializer_for): New helper. (component_ref_size): Add argument. Rename locals. Call get_initializer_for instead of fold_ctor_reference. Correct handling of flexible array members. * wide-int.h (generic_wide_int ::sign_mask): Assert invariant. gcc/testsuite/ChangeLog: PR middle-end/91679 PR middle-end/91647 PR middle-end/91463 PR middle-end/92312 * c-c++-common/Warray-bounds-2.c: Disable VRP. Adjust expected messages. * g++.dg/warn/Warray-bounds-8.C: Remove xfails. * gcc.dg/Warray-bounds-48.c: New test. * gcc.dg/Warray-bounds-49.c: New test. * gcc.dg/Wstringop-overflow-16.c: Adjust text of expected messages. * gcc.dg/Wstringop-overflow-21.c: New test. * gcc.dg/Wzero-length-array-bounds.c: New test. * gcc.dg/pr36902.c: Remove xfail. * gcc.dg/strlenopt-57.c: Add an expected warning. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-48.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-49.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c trunk/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/gimple-match-head.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-2.c trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-8.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-16.c trunk/gcc/testsuite/gcc.dg/pr36902.c trunk/gcc/testsuite/gcc.dg/strlenopt-57.c trunk/gcc/tree-vrp.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/wide-int.h
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Iain Sandoe --- this is now fixed on trunk
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #11 from Iain Sandoe --- with the path applied on x86_64-darwin16 (same results for c++98 / c++17 unless the line count in the test has changed, this is a progression - three fewer fails - but it seems 3 different ones) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 16) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 24) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 25) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 26) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 35) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 36) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 37) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 46) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 47) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 48) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 58) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 59) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 68) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 311) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 314) XPASS: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 pr91463 (test for warnings, line 318) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 336) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 352) FAIL: g++.dg/warn/Warray-bounds-8.C -std=gnu++14 (test for warnings, line 366) no change here FAIL: g++.dg/warn/Wstringop-overflow-3.C -std=gnu++14 (test for warnings, line 333) FAIL: g++.dg/warn/Wstringop-overflow-3.C -std=gnu++14 (test for warnings, line 349) FAIL: g++.dg/warn/Wstringop-overflow-3.C -std=gnu++14 (test for warnings, line 363)
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #10 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00425.html
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91679 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #9 from Martin Sebor --- I'm enhancing -Warray-bounds as mentioned at the end of comment #6. The patch I'm testing also includes a solution for pr91679.
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 --- Comment #8 from Iain Sandoe --- (In reply to Martin Sebor from comment #7) > Thanks, the trailing 10 in x86_64-apple-darwin10 makes the difference! hmm, something's odd then, 'x86_64-apple-darwin' works for me (I put a number out of habit more than necessity, in the host-only case***) $ ./gcc/xgcc -v Using built-in specs. COLLECT_GCC=./gcc/xgcc Target: x86_64-apple-darwin Configured with: ../src/configure --prefix=/home/iains/gcc-trunk/darwin --target=x86_64-apple-darwin *** having said that, I do recommend putting something between 10 and 18 there if you are building any libs, since some of them make dumb assumptions absent a darwin version. However, I don't expect you're building any libs - since that would require the SDK headers and Mach-O 'binutils' neither of which you (probably) have. Thanks for the explanation - I wonder what happens for Linux when you use -fpic -mcmodel=medium?
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647
--- Comment #7 from Martin Sebor ---
Thanks, the trailing 10 in x86_64-apple-darwin10 makes the difference!
Here's a small test case copied from the one around line 335 in
g++.dg/warn/Warray-bounds-8.C, and its output with the cross:
void sink (void*);
struct B0
{
char n;
char a[0];// { dg-message "destination object declared
here" }
B0 () { a[0] = 0; } // { dg-warning "\\\[-Wstringop-overflow" }
};
void gb0 (void)
{
struct B0 b0;
sink ();
}
$ /build/x86_64-apple-darwin10/gcc-svn/gcc/xgcc -B
/build/x86_64-apple-darwin10/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
In constructor 'B0::B0()',
inlined from 'void gb0()' at t.C:16:13:
t.C:10:16: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
10 | B0 () { a[0] = 0; } // { dg-warning
"\\\[-Wstringop-overflow" }
| ~^~~
and with a Linux native GCC:
$ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
t.C: In function ‘void gb0()’:
t.C:10:14: warning: array subscript 0 is above array bounds of ‘char [0]’
[-Warray-bounds]
10 | B0 () { a[0] = 0; } // { dg-warning
"\\\[-Wstringop-overflow" }
| ~~~^
t.C:8:8: note: while referencing ‘B0::a’
8 | char a[0];// { dg-message "destination object
declared here" }
|^
The difference between the two is that with the cross the store is a MEM_REF
that the -Warray-bounds warning doesn't handle:
gb0 ()
{
struct B0 b0;
[local count: 1073741824]:
MEM[(char *) + 1B] = 0;
sink ();
b0 ={v} {CLOBBER};
return;
}
while with the native GCC the store is an ARRAY_REF that -Warray-bounds does
handle:
gb0 ()
{
struct B0 b0;
[local count: 1073741824]:
b0 ={v} {CLOBBER};
b0.a[0] = 0;
sink ();
b0 ={v} {CLOBBER};
return;
}
The MEM_REF is introduced during the early sra pass which the native compiler
decides not to run because the B0 ctor doesn't pass the
ipa_sra_preliminary_function_checks: it thinks the function cannot be local.
This is based on the result of cgraph_node_cannot_be_local_p_1, specifically
the value of node->same_comdat_group which is null with the native GCC and
non-null with darwin:
cgraph_node_cannot_be_local_p_1 (cgraph_node *node, void *)
{
return !(!node->force_output
&& ((DECL_COMDAT (node->decl)
&& !node->forced_by_abi
&& !node->used_from_object_file_p ()
&& !node->same_comdat_group)
|| !node->externally_visible));
}
I can't say I know why that is but the difference seems gratuitous.
That aside, ideally, both warnings would handle both forms of accesses but as
they don't share code so they improve independently, leading to these kinds of
inconsistencies. I will look into improving -Warray-bounds to handle the
MEM_REF case as well.
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Richard Biener changed: What|Removed |Added Summary|new FAILs for |[10 Regression] new FAILs |Warray-bounds-8 and |for Warray-bounds-8 and |Wstringop-overflow-3.C |Wstringop-overflow-3.C --- Comment #6 from Richard Biener --- new FAILs are a regression even if they never passed
[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91647 Iain Sandoe changed: What|Removed |Added Target||*-*-apple-darwin* Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2019-09-03 CC||msebor at gcc dot gnu.org Host||*-*-apple-darwin* Ever confirmed|0 |1 Target Milestone|--- |10.0 Build||*-*-apple-darwin* --- Comment #1 from Iain Sandoe --- this is independent of arch, OS version or m64/m32 note that Darwin is fPIC by default. it's reproducible on a stage1, so should be possible on a cross (w/out needing 'binptils') it looks like the Warray-bounds-8 is always producing: "is above array bounds of" and Wstringop-overflow-3.C is producing: "writing 1 byte into a region of size 0"
