[PATCH,fortran] Handle BOZ in accordance to Fortran 2018 standard

[Steve Kargl]

On Sat, Jul 20, 2019 at 10:12:07AM -0700, Jerry DeLisle wrote:
> On 7/17/19 8:32 PM, Steve Kargl wrote:
> > I will be away until Monday.  Plenty of time for a review.
> > 
> > 
> 
> ---snip --
> 
> Something not quite right here in this comment.
> 
> 
> +/* A BOZ literal constant can appear in a limited number of contexts.
> +   gfc_invalid_boz() is a help function to simplify error/warning generation.
> +   Note, gfortran accepts the nonstandard 'X' for 'Z' the nonstandard
>                                                        ^<<< in >>?
> +   suffix location.  If -fallow-invalid-boz is used, then issue a warning;
> +   otherwise issue an error.  */
> 

Whoops forgot to fix this before committing.  I'll fix shortly.

> 
> +  /* FIXME BOZ.  What to do with complex?  */
> 
> Is your question here regarding whether to treat the two real storage locations 
> as one single area and pad? Or to duplicate one BOZ pattern into each? Or 
> require two BOZ patterns to be provided? or something else?
> 

Old comment.  I remove shortly.  The issue center arounds
complex(z'1234',z'4567').  This is now rejected as there is
no information on how to convert the BOZ.


> --- snip ---
> 
> -
> +  /* FIXME BOZ.  */
>     if (!gfc_in_match_data ()
>         && (!gfc_notify_std(GFC_STD_F2003, "BOZ used outside a DATA "
> -			  "statement at %C")))
> -      return MATCH_ERROR;
> +			  "statement at %L", &e->where)))
> +    return MATCH_ERROR;
> 
> Maybe expand the comment a bit to better hint at the issue.
> 

Whoops. Again, committed before fixing.  I'll update shortly.

> --- snip ---
> 
> The patch applies cleanly and tests OK on my machines here. I am very much in 
> favor of deprecating LONG and SHORT which are way too ambiguous.
> 
> I say OK to commit.
> 

Thanks.  Committed.

-- 
Steve