[PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON
Steve Kargl
sgk@troutmask.apl.washington.edu
Thu Oct 1 16:30:00 GMT 2015
On Thu, Oct 01, 2015 at 03:29:05PM +0200, Mikael Morin wrote:
> Le 01/10/2015 14:16, Mikael Morin a écrit :
> > Le 01/10/2015 02:07, Steve Kargl a écrit :
> >> On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote:
> >>> Patch built and regression tested on x86_64-*-freebsd.
> >>> OK to commit?
> >>>
> >>> The patch prevents the dereferencing of a NULL pointer
> >>> by jumping out of the cleanup of a list of COMMON blocks.
> >>>
> > Hold on, I believe p should be present in the common symbol list pointed
> > by p->common.
> s/p->common/p->common_block/
> > And by the way, if we are in gfc_restore_last_undo_checkpoint, we have
> > found something bogus enough to backtrack, so hopefully an error has
> > already been prepared (but maybe not emitted).
> > I will investigate more.
> >
> It seems the error [1] is reported in gfc_add_in_common, between the
> time the symbol's common_block pointer is set and the time the symbol is
> added to the list.
> As the program goes straight to clean-up/return upon error, this interim
> state is not fixed and poses problem.
>
> So we need to reduce the interim time to zero or fix the state upon error.
> I propose the following, which delays setting the common_block after
> error_checking (I believe it is not used in that time).
>
> Regression-tested on x86_64-unknown-linux-gnu. OK for trunk?
>
I'm fine with your patch, although I find the error message
to be somewhat confusing as no procedure appears in COMMON.
The call-stmt in the code is the start of an execution-construct.
A common-stmt is not allowed in an execution-construct. At
least, that's how I intepret the BNF in 2.1 of F2008.
--
Steve
More information about the Fortran
mailing list