On Wed, 16 Feb 2005 15:13:09 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 16, 2005 at 05:44:44PM -0500, Jason Merrill wrote: >> On Wed, 16 Feb 2005 14:34:59 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote: >> >> > A binary search has led to the cause of a serious regression on >> > mainline with gfortran at *all optimization levels (ie., -O0, -O1 >> > and -O2)*. The problematic commit is >> > >> > 2005-02-13 Jason Merrill <[EMAIL PROTECTED]> >> > >> > PR mudflap/19319 >> > * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return >> > slot explicit. >> >> I reverted this change shortly after the commit. Have you tested again >> with updated sources? >> >> I plan to commit a corrected version today. > > I noticed the problem early yesterday morning and have since been > trying to determine the (quilty) commit. A binary search and > make bootstrap can be a length process :-) I'll update to HEAD > and see what happens. Thanks for the note. If it was still broken yesterday morning, it wouldn't have been the above change, as I reverted it on Sunday. That leaves the fold_indirect_ref changes, which I reapplied on Monday. Those changes are merely expanding INDIRECT_REF folding to occur during gimplification. My guess would be that the fortran front end is doing something inappropriate with pointers, but it's hard to say without a testcase. Could someone on the fortran team take a look at this and/or point me at a testcase I can just feed to the compiler to see the problem? Jason
