Isolated from webkit2gtk3 package: $ cat webkit.ii # 1 "" 3 typedef int a; namespace b { template <typename c> void d(c); } enum e { f }; void *operator new(a, e, void *g) { return g; } template <typename, a, typename = int, a = 6> class h; template <typename i> struct j { static void k(i *l, i *m, i *aa) { while (l != m) { new (f, aa) i; ++aa; ++l; } } }; template <typename i> struct n { static void k(i *l, i *m, i *aa) { j<i>::k(l, m, aa); } }; class C { public: ac(); unsigned o; unsigned ad; }; template <typename i> class p : C { public: d(p af, a, a) { af.ac(); i *q = af.r(), *a = q; n<i>::k(0, s, a); b::d(o); } C::ad; a s; i *r() { return reinterpret_cast<i *>(ah); } int ah[]; }; class t; template <typename, int, typename, int> class h : p<t> { typedef p ae; public: h(); h &operator=(h &&); d(h &af) { ae::d(af, ad, ad); } }; template <typename i, a v, typename w, a u> h<i, v, w, u> &h<i, v, w, u>::operator=(h &&af) { d(af); } class t { public: t() : x(){} * x; }; class D { void aj(); h<int, 1> ak; }; void D::aj() { ak = {}; } $ g++ webkit.ii -O3 -Werror -Wall -std=c++14 -c -Wstringop-overflow -fpermissive In member function ‘void D::aj()’: cc1plus: error: ‘void* __builtin_memset(void*, int, long unsigned int)’ writing 8 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] cc1plus: all warnings being treated as errors
What kind of obfuscator did this go through?
(In reply to Marc Glisse from comment #1) > What kind of obfuscator did this go through? Most likely used creduce to reduce the failure. NOTE sometimes creduce reduced are reduced into invalid/undefined code.
(In reply to Andrew Pinski from comment #2) > Most likely used creduce to reduce the failure. creduce didn't use to produce such awful code. Part is because of -fpermissive, but part seems to be because the reducer (creduce?) did a bad job (reusing the same name for several things, missing simplifications). Anyway, we end up with something like: if(n!=0)memset(p,n,) where p points after the end, and the argument of memset is always non-0, but quite artificially so. Arguably, ldist could have produced just memset(p,n,) without the condition, and we wouldn't have the bad warning.
Created attachment 46319 [details] Unreduced test-case Yes, I used creduce. I'm attaching unreduced test-case.
Thanks. The unreduced file does not reproduce for me. But anyway, we warn for things like int a[1]; void f(int n){ for(int i=0;i<n;++i) a[i+1]=0; } where we just don't know that the branch n!=0 is dead. I have no idea what can be done about that...
The warning for the test case has disappeared with the commit below. I'm not sure the test case should be added to the test suite as is, with all the problems. commit dbd595151e5d560aa8aa80198b35b9a3da311e4d Author: Richard Biener <rguenther@suse.de> Date: Fri May 24 11:31:11 2019 +0000 re PR middle-end/90607 (gcc.dg/pr53265.c FAILs) 2019-05-24 Richard Biener <rguenther@suse.de> PR testsuite/90607 * tree-loop-distribution.c (struct partition): Add location member. (partition_alloc): Initialize all fields. (generate_memset_builtin): Use the location recorded in the partition for the generated call. (generate_memcpy_builtin): Likewise. (classify_partition): Record the location of a single store as location for the partition. * gcc.dg/pr53265.c: Amend for new expected diagnostic. From-SVN: r271601