This is the mail archive of the gcc-patches@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] Remove LOOP_EXPR


In message <1062544886.6332.143.camel@frodo.toronto.redhat.com>, Diego Novillo 
writes:
 >On Tue, 2003-09-02 at 00:00, law@redhat.com wrote:
 >
 >> 	* cfgloop.h (create_loop_notes): Declare.
 >> 	* cfgloopmanip.c (create_loop_notes): New.
 >>
 >I'm seeing about 560 failures in gfortran when bootstrapped with
 >--enable-checking.  The test in create_loop_notes if finding unexpected
 >loop notes.
 >
 >#ifdef ENABLE_CHECKING
 >  /* Verify that there really are no loop notes.  */
 >  for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
 >    if (GET_CODE (insn) == NOTE
 >        && NOTE_LINE_NUMBER (insn) == NOTE_INSN_LOOP_BEG)
 >      abort ();
 >#endif
 >
 >They're being generated by stmt.c:expand_start_loop.  I am quite lost
 >around this code :)  So, could I ask one of you folks to take a look?
 >
 >The test case I was looking at is
 >gfortran.fortran-torture/compile/ambig.f90
 >
 >
 >Thanks.  Diego.
Err, ummm.

f951 craps out for me for any input.  

gfc_init_builtin_functions has some very obvious errors in it which causes
stack corruption, which in turn causes a segfault when gfc_init_builtin_funtions
returns.  Specifically it writes off the end of two local arrays.  Ugh.
Should be trivial to fix.


Anyway, the fundamental problem is that fortran loops aren't being
lowered because Zdenek didn't write code for that - all the code to
lower loops down to gotos is buried in c_gimplify_loop_expr, which is
(of course) never called for the new Fortran compiler.

Zdenek -- in the future, can you please start testing your patches with
g95 as well (I'll be doing the same).  This is especially important
as g95 has certain properties the other front-ends do not have
(namely it creates generic trees by default whereas other front-ends
have to convert their trees to generic).

As for how to fix this.  It seems to me that if the FE is creating a
LOOP_EXPR, then lowering the LOOP_EXPR to gimple is really language
independent.  Right?  In fact, given a generic LOOP_EXPR, shouldn't
all we have to do to lower that is create the LABEL_EXPR and GOTO_EXPR
to make the looping explicit in the IL?

[ ie, we don't have to wrry about break/continue as we do in the C
  front-end. ]

I'm going to continue to be quite busy with non-gcc things this week.  So
I would really appreciate it if you could address this Zdenek.

Jeff


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