This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed
- From: "jsm28 at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 31 Mar 2005 10:09:25 -0000
- Subject: [Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed
- References: <20041005234326.17855.rth@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-31 10:09 -------
[resend of comment#6 which did not get emailed out]
The reason I don't consider compiling into an abort to be suitable here is that
the problem could in principle arise with more complicated code where the
pointer in the array reference isn't immediately syntactically from a non-lvalue
array but has been through other assignments, casts, etc., the optimizers then
removing these so that at some point an assignment to such an array needs to be
expanded. Ultimately I think these cases may most reliably be handled by having
the front end create explicit addressable temporaries for every non-lvalue
structure containing an array (mapping non-lvalue-struct to *(tmp =
non-lvalue-struct, &tmp)), but I think putting the special cases in the
gimplifier makes more sense in the context of fixing now a regression we have now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855