[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate

2009-03-27 Thread davidxl at gcc dot gnu dot org


--- 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

2009-03-27 Thread rguenth at gcc dot gnu dot org


-- 

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

2009-03-25 Thread rguenth at gcc dot gnu dot org


--- 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

2009-03-24 Thread davidxl at gcc dot gnu dot org


--- 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

2009-03-24 Thread davidxl at gcc dot gnu dot org


--- 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

2009-03-24 Thread rguenth at gcc dot gnu dot org


--- 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

2009-03-24 Thread rguenth at gcc dot gnu dot org


--- 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

2009-03-24 Thread davidxl at gcc dot gnu dot org


--- 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

2009-03-24 Thread davidxl at gcc dot gnu dot org


--- 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