This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH,fortran] Handle BOZ in accordance to Fortran 2018 standard
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.