This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Possible patch for fortran/68078
- From: Fritz Reese <fritzoreese at gmail dot com>
- To: Louis Krupp <louis dot krupp at zoho dot com>
- Cc: fortran <fortran at gcc dot gnu dot org>
- Date: Thu, 15 Sep 2016 08:49:17 -0400
- Subject: Re: Possible patch for fortran/68078
- Authentication-results: sourceware.org; auth=none
- References: <1572c78cd91.bdb209569142.7490991715096244405@zoho.com>
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.
>