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
