Re: Possible patch for fortran/68078

[Louis Krupp <louis dot krupp at zoho dot com>]

Thanks!

I've been running vi, and if there's nothing but spaces on a line, it acts as if the last space isn't there.   I don't know if this is a new "feature" or something I've just noticed.  vim does the same thing.

I've attached an updated patch.

Louis


 ---- On Thu, 15 Sep 2016 05:49:17 -0700 Fritz Reese <fritzoreese@gmail.com> wrote ---- 
 > It might be worth filling in the right locations for the new blocks (?): 
 >  
 > diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c 
 > @@ -7048,7 +7048,9 @@ cond_init (gfc_code *code, gfc_expr *e, int pointer, gfc_e 
 >    init_st->expr2 = init_e; 
 >  
 >    block = gfc_get_code (EXEC_IF); 
 > +  block->loc = code->loc; 
 >    block->block = gfc_get_code (EXEC_IF); 
 > +  block->block->loc = code->loc; 
 >    block->block->expr1 = cond; 
 >    block->block->next = init_st; 
 >    block->next = code->next; 
 >  
 >  
 > Minor nit, trailing whitespace: 
 >  
 > --- gcc/fortran/resolve.c       (revision 240152) 
 > +++ gcc/fortran/resolve.c       (working copy) 
 > ... 
 > +  block->block->expr1 = cond; 
 > +  block->block->next = init_st; 
 > +  block->next = code->next; 
 > +  <<<<< Trailing whitespace. 
 > +  code->next = block; 
 >  
 > Otherwise it looks fine to me. So long as the system(s) to test 
 > support(s) setrlimit() (which should be true for POSIX systems). 
 >  
 > --- 
 > Fritz Reese 
 >  
 > (P.S. I can't officially approve the patch, I'm just providing feedback.) 
 >  
 > On Thu, Sep 15, 2016 at 2:11 AM, Louis Krupp <louis.krupp@zoho.com> wrote: 
 > > Verify that allocation was successful before assigning default initialization values to components of the allocated object (or array of > objects or pointer to an object).   The change could probably have been made while parsing or at translation.  This patch does it in > the resolution phase.  It seemed like a good idea. 
 > > 
 >

Attachment: patch.txt
Description: Text document