[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83215 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed on trunk.
[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83215 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Nov 20 09:31:06 2018 New Revision: 266305 URL: https://gcc.gnu.org/viewcvs?rev=266305=gcc=rev Log: 2018-11-20 Richard Biener PR middle-end/83215 * alias.c (component_uses_parent_alias_set_from): Remove alias-set zero and TYPE_TYPELESS_STORAGE case both already handled in other ways. * g++.dg/tree-ssa/pr83215.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr83215.C Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83215
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-11-16
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
So in the end it is
tree
component_uses_parent_alias_set_from (const_tree t)
{
...
if (get_alias_set (TREE_TYPE (TREE_OPERAND (t, 0))) == 0)
found = t;
that causes this. The above is required for may_alias annotated types
(so history tells me, but the testcase added for the change doesn't fail
when removing the above). Today we handle may_alias via
reference_alias_ptr_type_1 running into a dereference and checking the
pointer for a ref-all type.
[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83215 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- The key here is that "mytest" has alias-set zero. It has that because aggregate copying of it has to transfer whatever is in 'buf'. But if "mytest" has alias-set zero that means any component of it has that as well. So this correctness fix is really tied to how we need to handle aggregate copying of structs. I don't like that (and I simply blame the C++ standards commitee). It's a really bad choice for optimization. Note making the C++ FE do sth "special" for aggregate copying works only sofar as the middle-end also sometimes generates such copying (argument copying during inlining, etc).
[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83215 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- What I've wondered here is because we know the offset and size of the m->a access, even when the containing structure is TYPE_TYPELESS_STORAGE, we could prove that this offset/size in the structure doesn't and can't overlap with any area of the aggregate that has or could have TYPE_TYPELESS_STORAGE array, and ignore the TYPE_TYPELESS_STORAGE for that access.
