https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- (In reply to Dominique d'Humieres from comment #8) > > The error I found is not just violating a constraint in f2008 or above. > > The same constraint with different wording is in f2003, f95 and f90. > > Agreed, so I removed the reference to f2008 from the summary. > > While playing with the patch in comment 4, I saw the following problems: > > (1) The behaviors of the frontend and the library are no longer consistent: > print "(AF9.6)", 'pi =',4*atan(1.0) > is accepted at compile time, but gives an error at runtime. > The error detection should probably be updated in the frontend. > > (2) The following tests fail > > FAIL: gfortran.dg/comma_format_extension_4.f -O* execution test > FAIL: gfortran.dg/dollar_edit_descriptor_2.f -O* execution test > FAIL: gfortran.dg/fmt_error_9.f -O* execution test > FAIL: gfortran.dg/fmt_g0_5.f08 -O* execution test > FAIL: gfortran.dg/fmt_t_2.f90 -*0 execution test > > I agree with the fixes at > > https://gcc.gnu.org/ml/fortran/2018-11/msg00123.html Yes I fixed those test cases with the patch because they are not standard conforming. I tried to make sure we were still testing the relevant features. > > although I would have added a { dg-options "-std=legacy" } to fmt_t_2.f90. > > (3) If the code is compiled with -std=legacy -pedantic, the format is > rejected at runtime (see pr88190). > > (4) It looks weird to use compile_options.warn_std instead of > compile_options.allow_std (see pr88190 again). > > An alternative patch is > > - /* Assume a missing comma, this is a GNU extension */ > - goto format_item_1; > + if (compile_options.allow_std & GFC_STD_GNU) > + /* Assume a missing comma, this is a GNU extension. */ > + goto format_item_1; > + format_error (dtp, tail, comma_missing); > > PRO > > (a) It does not change the behavior for -std=gnu or std=legacy. I presumed we did not want to allow the missing comma by default and since we cant currently do it with allow_std I opted for the warn_std as I did with pr78351. > (b) It is a simple fix of the above problems that gives the expected errors > with std=f*. > > AGAINST > > > If you want to allow any constraint violations I think that should be an > > option, not the default. > > It does not fix that. However if this is deemed important by a majority > (don't count me for it, but I won't fight), it would be quite easy to > replace GFC_STD_GNU with GFC_STD_LEGACY where appropriate once pr88190 will > be fixed. Yes easy to replace one way or the other. By the way, the behaviors between frontend and runtime have been around a long time. I opened a PR way back on this because it seemed so counterintuitive. If we really want to fix that issue flagged in your PR88190 we probably ought to write down for ourselves a description of the behaviors we want to see and document it and fix it once and for all. Even the -pedantic flag is a bit obtuse in my mind.
