This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] g95 SEGV building libgfortran


On Friday 05 September 2003 1:36 pm, Diego Novillo wrote:
> On Thu, 2003-09-04 at 17:57, Paul Brook wrote:
> > My vote is to leave LOOP_EXPRs in the interface to the frontends (ie
> > GENERIC). Otherwise we're going to end up with large amounts of
> > lowering code duplicated between the different frontends.
>
> Yes.  LOOP_EXPR should remain in GENERIC.  However, the problem here is
> that I think tree_rest_of_compilation should be the one calling the
> gimplifier.
>
> Paul, IIUC, the Fortran FE does not call the gimplifier directly, but
> calls t_r_o_c?  At the moment, each front end is calling the gimplifier
> on its own.  When compiling Fortran, the optimizers are now being fed
> GENERIC trees.  That is not right.

Correct.

> I'm OK with removing LOOP_EXPR from GIMPLE, but it should remain in
> GENERIC.  The problem now is making sure all the FEs call into the
> gimplifier via a common interface.  tree_rest_of_compilation seems a
> good candidate.
>
> Richard, can t_r_o_c be that interface now?  If not, the Fortran FE
> should be calling into the gimplifier on its own until we fix the
> missing bits.

I've a big stack of other patches waiting to be applied, so I'll probably 
add a call to the gimplifier as a temporary fix.

I haven't checked recently, but last time I looked the tree optimizers still 
had issues with nested functions, so I might end up disabling them 
altogether. Which reminds me, I had a testcase fo these which I never 
checked in. I'll see if I can dig it up (unless someone else already put 
one in).

Paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]