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
