[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
Martin Sebor changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE |---
--- Comment #7 from Martin Sebor ---
The root cause in this case or the solution are not the same as in bug 94675.
The MEM_REF type is the type of the access, so it's correct to rely on it for
the size of the access. The problem here is that the first MEM_REF pointer
operand doesn't point to the actual destination of the access: it points to one
member of the struct but as a result of adding the offset to it the access is
actually to the subsequent member. It's as if the final store in valid code
like this:
struct S { char i; char a[8], b[8]; };
void g (struct S *p)
{
typedef __attribute__ ((vector_size (8))) char V;
char *pa = p->a + 8;
char *pb = p->b;
*(V*)pb = (V) {0}; // pb points to p->b
}
were transformed into:
pa_2 = [(void *)p_1(D) + 9B];
MEM[(V *)pa_2] = { 0, 0, 0, 0, 0, 0, 0, 0 }; // but here store is into
(p->a + 9)
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- Fundamentally if we're relying on the type of the MEM_REF, then we're going to run into problems. It simply does not map back to what the user originally wrote. That's the key issue Richi and Jakub are raising. pr94675 is another recently reported example. In that case as well FRE creates a MEM_REF from address arithmetic, but the type isn't useful and leads to a false positive out of bounds array warning. Forwprop can do this stuff as well, and I suspect if we were to dig elsewhere we'd find more examples. While I don't want to lose these warnings, they are proving problematical in the MEM_REF cases and I'm wondering if we need a distinct knob to disable them in the MEM_REF cases given the fundamental incompatibility between giving good diagnostics and the actions of various optimization passes. In the immediate term I'm going to mark this as a dup of 94675 (and any others I encounter in my BZ wanderings). *** This bug has been marked as a duplicate of bug 94675 ***
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 --- Comment #5 from Martin Sebor --- We want stores by user code to be diagnosed based on strict language rules (e.g., accessing a member via a reference to another member). To do that we either have to teach the middle end to avoid taking shortcuts that make the IL look like invalid user code, or be able to apply more permissive rules for stores synthesized by it. I assume the former is what you meant by "modify the into _REF[..., off]." My comment was in support of that because, provided the latter part actually meant "_REF[something, offsetoff (typeof (something), field)], it could be added to and subtracted from to obtain pointers to any other member of "something." (In contrast, + N is only valid for N <= sizeof something.field (flexible arrays aside)).
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 --- Comment #4 from Jakub Jelinek --- I don't see how it makes a difference between whether it is a store created by the vectorizer or some original user store. What matters is what ADDR_EXPR picks up SCCVN for the base, and it will pick up the first one which has the same value; if there are multiple fields starting at the same address, it can pick any of them.
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 --- Comment #3 from Martin Sebor --- Using the base object in the MEM_REF instead of the member when accessing another member should certainly fix it. Another option might be to somehow mark up these synthesized stores (e.g., by setting some currently unused bit) to make it clear they were emitted for valid source code. I'd prefer the former option since that would preserve the validity (in the C/C++ sense) of the source code.
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- We must have dups for this, the warning relies on something that the IL doesn't provide. fre4 changes: _8 = [(struct A *)_5 + 8B].strA; std::__cxx11::basic_string::_M_assign (_8, ); [local count: 1073741824]: _9 = [(struct A *)_5 + 8B].arr; - _31 = [(struct A *)_5 + 8B]; - _29 = _31 + 32; - _24 = + 33; - _21 = _29 - _24; + _29 = _8 + 32; + _21 = _29 - [(void *) + 33B]; ... - vectp.110_64 = + 32; - _69 = [(struct A *)_5 + 8B]; - vectp.113_68 = _69 + 32; - vect__13.111_67 = MEM [(const char *)vectp.110_64]; - MEM [(char *)vectp.113_68] = vect__13.111_67; - vectp.109_66 = vectp.110_64 + 16; - vectp.112_71 = vectp.113_68 + 16; - ivtmp_74 = 1; + vect__13.111_67 = MEM [(const char *) + 32B]; + MEM [(char *)_29] = vect__13.111_67; + vectp.112_71 = _29 + 16; and the warning warns because it thinks the store uses the strA + 32 pointer to store the 16 bytes (vectorized), but the user code doesn't do that, only the value numbering found that the value is equal to that. Perhaps SCCVN could try to modify the into _REF[..., off] if it decides to reuse it in some context that doesn't use the same field base, but not sure how hard would that be.
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Last reconfirmed||2020-04-20 CC||marxin at gcc dot gnu.org Known to fail||10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|[10 Regression] Implicit|[10 Regression] Implicit |assignment operator |assignment operator |triggers stringop-overflow |triggers stringop-overflow |warning |warning since ||r10-5451-gef29b12cfbb4979a --- Comment #1 from Martin Liška --- Confirmed, started with r10-5451-gef29b12cfbb4979a.
