From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6746 invoked by alias); 30 Dec 2004 17:27:42 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 6711 invoked by uid 48); 30 Dec 2004 17:27:37 -0000 Date: Thu, 30 Dec 2004 17:27:00 -0000 Message-ID: <20041230172737.6710.qmail@sourceware.org> From: "pinskia at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041216155140.19038.dje@gcc.gnu.org> References: <20041216155140.19038.dje@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB X-Bugzilla-Reason: CC X-SW-Source: 2004-12/txt/msg03966.txt.bz2 List-Id: ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-30 17:27 ------- (In reply to comment #31) > Subject: Re: [4.0 Regression] out-of ssa > causing loops to have more than one BB > Now if you think that PR is a trivial case that should be caught, then, > show me why and I'll take a closer look. The reason why it is not caught is because we don't cleanup the cfg while doing the loop optimizations, this has been fixed already on the tcb. Oh, by the way I see that sixtrack has regressed on x86 now with your patch applied, I think this is because we still have the same problem as before as ivopts puts the new instruction in an empty BB which becomes from not cleaning up the cfg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038