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?

Mikael


[1] Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' 
at (1)