Re: PR fortran/87919 patch for -fno-dec-structure

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Nov 08, 2018 at 12:09:33PM -0500, Fritz Reese wrote:
> I find "expand" a more helpful name than "set_bitflag_1" since it
> describes what the macro does. However, I don't think it makes too
> much of a difference so I'll follow your preference (but I'll use
> SET_BITFLAG2 since then the definition line fits in 80 characters).

Ok.

> > What about the
> >       /* Allow legacy code without warnings.  */
> >       gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL
> >         | GFC_STD_GNU | GFC_STD_LEGACY;
> >       gfc_option.warn_std &= ~(GFC_STD_LEGACY | GFC_STD_F95_DEL);
> > that is done for value, shouldn't set_dec_flags remove those
> > flags again?  Maybe not the allow_std ones, because those are set already by
> > default, perhaps just the warn_std flags?
> >
> 
> Sure. I wasn't convinced about this and how it might interplay with
> -std= so I left it alone, but I suppose it makes sense to unsuppress
> the warnings when disabling -fdec.

Perhaps it might be better not to change the allow_std/warn_std flags
during the option parsing, instead set or clear say flag_dec and
only when option processing is being finalized (gfc_post_options)
check if flag_dec is set and set those.  It would change behavior of
-fdec -std=f2018 and similar though.  Not sure what users expect.

> Strictly speaking it's not an exact copy because it omits the final {
> dg-output } check for the runtime warning, since the warning is
> supposed to occur in array_temporaries_2.f90 but not in the new case
> array_temporaries_5.f90. I assumed include would propagate the {
> dg-output } check -- upon actually testing this, it appears that is
> not the case. I find this misleading at a glance, but it works, so I
> don't mind this with an extra comment line.

Directives are only processed in the current file, so it doesn't really
matter what the included file has as directives.  One could even have the
included one be with expected dg-error lines and then include it in
the ones that don't expect any.

Anyway, that is all from me, I still don't want to stomp on Fortran
maintainer's review (use my global reviewer's rights for that) and
thus I'm deferring the review to them.  When committing, please make sure
to include Mark's email in the ChangeLog next to yours to credit him.

	Jakub