[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-02-19 10:12 --- Fixed again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-19 10:12 --- 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 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-18 12:56 --- 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. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2009-02-17 10:41:14 |2009-02-18 12:56:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-18 10:54 --- *sigh* Looks like PR39074. I chickened out to backport this from a-i branch... I'll have a second look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #14 from jakub at gcc dot gnu dot org 2009-02-18 08:31 --- Created an attachment (id=17322) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17322&action=view) 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #13 from jakub at gcc dot gnu dot org 2009-02-18 08:24 --- Created an attachment (id=17321) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17321&action=view) ai3.ii.bz2 Slightly reduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #12 from jakub at gcc dot gnu dot org 2009-02-18 08:23 --- Created an attachment (id=17320) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17320&action=view) ai2.ii.bz2 Original (almost) unreduced testcase. The: warning: dereferencing pointer '' 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-18 08:20 --- Unfortunately I'm still seeing these warnings on the original unreduced testcase. I'll attach them momentarily. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-17 13:38 --- 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 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-17 13:38 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-17 10:59 ---
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
:
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 ;
else
goto ;
:
__x.43_27 = (const struct _Rb_tree_node *) SR.124_23;
# VUSE
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
D.18451_104 = D.18450_103->D.11464._M_length;
# __size_296 = VDEF <__size_282(ab)>
__size = D.18451_104;
# VUSE
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.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-17 10:53 --- Thanks Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-17 10:41 --- 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. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-17 10:41:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-17 07:14 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #4 from mmitchel at gcc dot gnu dot org 2009-02-17 02:53 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-16 21:53 --- 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. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-16 21:05 ---
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).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-16 19:30 --- Created an attachment (id=17307) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17307&action=view) 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 '' does break strict-aliasing rules /tmp/ai.C:2342: note: initialized from here /tmp/ai.C:2615: warning: dereferencing pointer '' 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
