https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64336
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-12-17
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This sounds like a bug in whatever sets TREE_READONLY on the MEM_REF.
Apparently build2_stat sets read_only = 1 and clears it if the arguments aren't
read-only, but that of course makes no sense for MEM_REF, even if the arguments
are TREE_READONLY, that has nothing to do with TREE_READONLY of the MEM_REF
itself. So, perhaps:
--- gcc/tree.c.jj 2014-12-15 10:36:23.000000000 +0100
+++ gcc/tree.c 2014-12-17 10:48:07.216729576 +0100
@@ -4352,7 +4352,7 @@ build2_stat (enum tree_code code, tree t
arguments are as well. */
constant = (TREE_CODE_CLASS (code) == tcc_comparison
|| TREE_CODE_CLASS (code) == tcc_binary);
- read_only = 1;
+ read_only = TREE_CODE_CLASS (code) != tcc_reference;
side_effects = TREE_SIDE_EFFECTS (t);
PROCESS_ARG (0);
? INDIRECT_REF in build1_stat also sets TREE_READONLY to 0...
