#include <string> #include <map> const std::string &usage (); void foo () { std::map < std::string, int >best_scores; const std::map < std::string, int >::const_iterator current_best = best_scores.find (usage ()); if (0 < current_best->second) best_scores[usage ()] = 0; } yields: LC_ALL=C g++ -S -O2 -Wall ai.C ai.C: In function 'void foo()': ai.C:11: warning: dereferencing pointer '<anonymous>' does break strict-aliasing rules /usr/lib/gcc/i386-redhat-linux/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:259: note: initialized from here I'll attach another testcase which doesn't include any headers and triggers 3 warnings.
Created attachment 17307 [details] ai.C LC_ALL=C ./cc1plus -O2 -Wall -quiet /tmp/ai.C /tmp/ai.C: In function 'void foo()': /tmp/ai.C:2615: warning: dereferencing pointer '__x.15' does break strict-aliasing rules /tmp/ai.C:2479: note: initialized from here /tmp/ai.C:2653: warning: dereferencing pointer '<anonymous>' does break strict-aliasing rules /tmp/ai.C:2342: note: initialized from here /tmp/ai.C:2615: warning: dereferencing pointer '<anonymous>' does break strict-aliasing rules /tmp/ai.C:2281: note: initialized from here Not sure if these are bugs in the aliasing code or libstdc++ headers.
I believe all 3 are the same issue. static const_reference _S_value (_Const_Base_ptr __x) { return static_cast < _Const_Link_type > (__x)->_M_value_field; } casts pointer to _Rb_tree_node_base to pointer to pointer to _Rb_tree_node <_Val> and then dereferences it. Given that: template < typename _Val > struct _Rb_tree_node:public _Rb_tree_node_base { ... }; at least the initial portion of the structs is the same. _S_value is called by _S_key with the same argument, which is called from _M_lower_bound template (_Link_Type aka. _Rb_tree_node_base isn't const in that pointer anymore).
We have been through this already and I'm really surprised the spurious warnings are still there. See middle-end/38477 and middle-end/38937.
The key question is whether the bogus warning could indicate a potential for miscompilation. If it's "just" a bogus warning, then it's going to annoy and confuse people, but not result in too much damage. But, if this means that we're likely to miscompile things, then we have a worse problem. Of course, until someone demonstrates an actual miscompilation, that's perhaps something of a theoretical problem. I'll leave this as P3 until we know more.
The reason it got reported to me is package(s) failing to build with -Werror, nothing wrong in the application code (the bug is supposedly either in the aliasing code, FE or libstdc++-v3 headers) and no obvious way to work around the warning.
This warning is only emitted if points-to analysis pruned the points-to set to empty. Thus, the pointer as far as PTA is concerned does not point to anything. On alias-improvements branch this results in stores and loads from it vanishing. On the trunk we fall back to pt_anything in this case. Generally the warning hints at real problems, either in the compiler or in user code. There are known problems with boost and its interesting use of placement new (we still do not handle placement new properly). I will have a look here.
Thanks Richard.
Ok, that was easy. I thought I had fixed that already... what happens is that we warn if we pruned the points-to set to { NULL } as well (I have a patch for emitting 'dereferencing NULL pointer', but that triggers in dead code during bootstrap). Likely this case is from dead code as well. All cases look like <bb 13>: SR.124_23 = &__y_22->D.15162; D.17759_25 = (struct _Rb_tree_node *) &best_scores._M_t._M_impl._M_header; D.17760_26 = &D.17759_25->D.15162; if (SR.124_23 == D.17760_26) goto <bb 19>; else goto <bb 14>; <bb 14>: __x.43_27 = (const struct _Rb_tree_node *) SR.124_23; # VUSE <D.17842_279(ab), SMT.310_289(ab), SMT.314_293(ab)> D.18448_101 = D.15081_1->_M_dataplus._M_p; D.18449_102 = (struct _Rep *) D.18448_101; D.18450_103 = D.18449_102 + -12; # VUSE <SMT.311_290(ab), SMT.312_291(ab)> D.18451_104 = D.18450_103->D.11464._M_length; # __size_296 = VDEF <__size_282(ab)> __size = D.18451_104; # VUSE <SMT.310_289(ab), SMT.312_291(ab)> D.18452_105 = __x.43_27->_M_value_field.first._M_dataplus._M_p; where __x.43_27 is the offending pointer here. __y_22 points to { NULL best_scores.32+32 }, best_scores.32+32 may not be accessed through __x.43_27 and so is pruned. I have a patch.
Fixed.
Subject: Bug 39207 Author: rguenth Date: Tue Feb 17 13:38:06 2009 New Revision: 144228 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144228 Log: 2009-02-17 Richard Guenther <rguenther@suse.de> PR tree-optimization/39207 * tree-ssa-structalias.c (find_what_p_points_to): Do not emit strict-aliasing warnings for pointers pointing to NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
Unfortunately I'm still seeing these warnings on the original unreduced testcase. I'll attach them momentarily.
Created attachment 17320 [details] ai2.ii.bz2 Original (almost) unreduced testcase. The: warning: dereferencing pointer '<anonymous>' does break strict-aliasing rules warnings are now gone, but the: warning: dereferencing pointer '__x.1949' does break strict-aliasing rules (9 of them) are not. cc1plus -m32 -O2 -Wall -quiet to reproduce.
Created attachment 17321 [details] ai3.ii.bz2 Slightly reduced.
Created attachment 17322 [details] glibmm.ii.bz2 Testcase from another package. Similarly to the ai* (wesnoth-1.5), in this case also some warnings went away with yesterday's fix, but not all.
*sigh* Looks like PR39074. I chickened out to backport this from a-i branch... I'll have a second look.
Ok, a backported patch fixes all three new testcases. I was avoiding the backport to avoid late performance and/or compile-time regressions, so I'll give the patch (and one accompanied change that went to the branch to fix performance regressions) some performance testing.
Subject: Bug 39207 Author: rguenth Date: Thu Feb 19 10:12:25 2009 New Revision: 144292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144292 Log: 2009-02-19 Richard Guenther <rguenther@suse.de> PR tree-optimization/39207 PR tree-optimization/39074 * tree-ssa-structalias.c (storedanything_id, var_storedanything, storedanything_tree): New. (do_ds_constraint): Simplify ANYTHING shortcutting. Update the STOREDANYTHING solution if the lhs solution contains ANYTHING. (build_succ_graph): Add edges from STOREDANYTHING to all non-direct nodes. (init_base_vars): Initialize STOREDANYTHING. (compute_points_to_sets): Free substitution info after building the succ graph. (ipa_pta_execute): Likewise. * gcc.dg/torture/pr39074.c: New testcase. * gcc.dg/torture/pr39074-2.c: Likewise. * gcc.dg/torture/pr39074-3.c: Likewise. * tree-ssa-structalias.c (struct variable_info): Add may_have_pointers field. (do_ds_constraint): Do not add to special var or non-pointer field solutions. (type_could_have_pointers): Split out from ... (could_have_pointers): ... here. For arrays use the element type. (create_variable_info_for): Initialize may_have_pointers. (new_var_info): Likewise. (handle_lhs_call): Make the HEAP variable unknown-sized. (intra_create_variable_infos): Use a type with pointers for PARM_NOALIAS, make it unknown-sized. Added: trunk/gcc/testsuite/gcc.dg/torture/pr39074-2.c trunk/gcc/testsuite/gcc.dg/torture/pr39074-3.c trunk/gcc/testsuite/gcc.dg/torture/pr39074.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
Fixed again.