[Patch, Fortran] PR40881 - Add two F95 obsolescence warnings

[Tobias Burnus]

On 08/09/2012 02:13 PM, Mikael Morin wrote:
> On 08/08/2012 19:12, Tobias Burnus wrote:
>> With this patch, I think the only unimplemented obsolescence warning is for
>> "(8) Fixed form source -- see B.2.7."
>>
>> For the latter, I would like to see a possibility to silence that
>> warning, given that there is substantial code around, which is in fixed
>> form but otherwise a completely valid and obsolescent-free code.
> We could silence it with explicit -ffixed-form.

That won't work. The driver ("gfortran") automatically adds the flag 
when compiling ".f" files. Thus, from within the compile ("f951") those 
are indistinguishable. Besides, many Makefiles have the same compiler 
flags for fixed and free form as (most) compilers automatically choose 
the right source form based on the file extension.

> Regarding the general design, I'm not sure it makes sense to distinguish between ST_LABEL_DO_TARGET and ST_LABEL_ENDDO_TARGET.

I concur. I changed it and also added a comment to gfortran.h.

>> @@ -3825,8 +3828,11 @@ parse_executable (gfc_statement st)
>>   	case ST_NONE:
>>   	  unexpected_eof ();
>>   
>> -	case ST_FORMAT:
>>   	case ST_DATA:
>> +	  gfc_notify_std (GFC_STD_F95_OBS, "DATA statement at %C after the "
>> +					   "first executable statement");
>> +	  /* Fall through.  */
>> +	case ST_FORMAT:
>>   	case ST_ENTRY:
>>   	case_executable:
>>   	  accept_statement (st);
> This diagnostic is more appropriate in verify_st_order (which needs to
> be called then).

I disagree. Initially, I thought that verify_st_order is the right place 
- and discovered then that it doesn't get called after the first 
executable statement. Thus, I added it to parse_executable.

Given that DATA is the only statement, which can also occur in the 
execution section and that its validity depends on the compile flags, it 
also would need a special handling in verify_st_order.

Calling verify_st_order from parse_executable only for ST_DATA is kind 
of pointless while calling it always, leads to quite some overhead, 
requires that one keeps track of the previous state (which is required 
by verify_st_order but otherwise not needed in the execution section).

Thus, I really prefer the current solution.

>>   	case ST_LABEL_TARGET:
>> +	case ST_LABEL_ENDDO_TARGET:
>>   	  if (lp->referenced == ST_LABEL_FORMAT)
>>   	    gfc_error ("Label %d at %C already referenced as a format label",
>>   		       labelno);
>>   	  else
>>   	    lp->defined = ST_LABEL_TARGET;
> I think it should be `lp->defined = type;' here.

I think the current code is okay due to the required ordering, e.g. the 
termination label for a DO block has to come after the DO block. But I 
concur that using "= type" is cleaner.

Thus, I removed ST_LABEL_ENDDO_TARGET, use "=type" and added a comment, 
but I didn't do the verify_st_order change.

Build and regested on x86-64-linux.
OK for the trunk?

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obsolescent-v2.diff
Type: text/x-patch
Size: 10978 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20120814/7638822f/attachment.bin>