[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #8 from davidxl at gcc dot gnu dot org 2009-03-27 18:28 --- See r145118 for the fix. -- davidxl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-25 12:12 --- Well, DECL_NO_TBAA_P is a hack and poorly implemented. Fallout expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #1 from davidxl at gcc dot gnu dot org 2009-03-24 17:50 --- Created an attachment (id=17538) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17538action=view) Test case -- davidxl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davidxl at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-03-24 17:51 --- Created an attachment (id=17539) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17539action=view) patch file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-24 17:55 --- It might be better to place the check after the loop (and put an assert in set_copy_of_val that triggers the copy may not happen). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-03-24 17:56 --- Btw, it shouldn't really happen that we are not allowed to copyprop PHI arguments. It hints at some inconsistency in the IL instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #5 from davidxl at gcc dot gnu dot org 2009-03-24 21:25 --- (In reply to comment #3) It might be better to place the check after the loop (and put an assert in set_copy_of_val that triggers the copy may not happen). This sounds good. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #6 from davidxl at gcc dot gnu dot org 2009-03-24 21:33 --- (In reply to comment #4) Btw, it shouldn't really happen that we are not allowed to copyprop PHI arguments. It hints at some inconsistency in the IL instead. This sounds good. David(In reply to comment #4) Btw, it shouldn't really happen that we are not allowed to copyprop PHI arguments. It hints at some inconsistency in the IL instead. Yes I suspect that too, but this is an independent issue. As long as the check is done in replace_uses_in (tree-ssa-propagate), it should be done in the copy chain computation -- at least it should be done in line 742 of tree-ssa-copy.c (copy_prop_visit_cond_stmt), which was my original fix. By the way, the check that fails in may_propagate_copy is -- which looks hairy. If you think it is ok, I can file a different bug to track this. else if (!MTAG_P (SSA_NAME_VAR (dest)) !MTAG_P (SSA_NAME_VAR (orig)) (DECL_NO_TBAA_P (SSA_NAME_VAR (dest)) != DECL_NO_TBAA_P (SSA_NAME_VAR (orig Thanks, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548