2018-05-21 0:19 GMT+02:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > On Sun, May 20, 2018 at 09:44:47PM +0200, Janus Weil wrote: >> >> >> The patch still regtests cleanly. Ok for trunk? >> > >> > Patch looks good to me. The only thing that worries me is >> > whether the patch will cause the SPEC benchmark to throw >> > an error or warning that it did not before. As I don't have >> > SPEC benchmark and it cost $$$, I'm not going to let it >> > bother too much. >> >> Unfortunately I don't have access to SPEC either. Is anyone in a >> position to check this? > > We'll find out evidently as one of the C/C++ developers run SPEC.
Ok, we have plenty of time to fix up things before the next release anyway. >> If it is indeed a problem, I could remove the warning for the F2018 >> deleted features with default flags (-std=gnu). However, I'd only like >> to do that if it's really necessary. > > I would rather see the warnings to encourage users to fix > their codes. Me too. Good that we can agree on something for once ;) >> >> Btw, with the arrival of the F2018 standard, I wonder whether it >> >> actually makes sense to keep the option -std=f2008ts, or to remove it >> >> in favor of -std=f2018, since the two Technical Specifications covered >> >> by this flag are now part of F2018 (and pretty much the main part!). >> >> Any opinions on this? >> > >> > I think that f2008ts can go away. We may need to do this >> > in two step as some users may have f2008ts hardcoded in >> > Makefiles. Probably, issue warning for -std=2008ts and >> > map it to -std=2018 for a brief period (3 to 6 months?) >> > and then finally remove it. >> >> Yes, I agree that it would be a good idea to keep -std=f2008ts as an >> alias for f2018 for a while (possibly until the next release, 9.0), >> and document is as deprecated. I can take care of removing the >> GFC_STD_F2008_TS macro in a follow-up patch. > > Sounds good to me. > >> Actually there is one other thing I do not like about my previous >> patch: The duplication of GFC_STD_* flags in gfc_match_stopcode. To >> get rid of this, I'm introducing additional macros in libgfortran.h, >> see new patch in the attachment. I hope you agree that this is an >> improvement. (Again: Regtests cleanly.) > > Again, looks good. Thanks. I have committed this version of the patch as r260433. > Welcome back to gfortran development. Well, I do have a continued interest in improving gfortran. As usual, I cannot make any promises (too many boundary conditions), but I will certainly try to make the occasional contribution if I find the time. It would be amazing to finally have complete Fortran 2003 support with gfortran-9. I guess we're really only a handful of PRs away from that goal now. Many of the small F2018 improvements should not be too hard to implement either. Cheers, Janus
