[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-20 16:16:43 UTC ---
(In reply to comment #2)
> Why are you calling this a workaround.  It looks like it is fixing
> a bug in the user's program.

In an ideal world, all code would use only standard Fortran and fixing the code
would be trivial. However, in a real world, we live with more or less common
vendor extensions which are used by real programs, even if there is now a
better standard-conform replacement. I am sure that version of namelist
predates Fortran 90.

If the bug reporter can, I think he should convert all the input files to the
Fortran 90 syntax of namelists. However, one needs to be careful to not
inadvertently to change the meaning (e.g. remove the wrong "(1)") and it might
affect many files.


> I'm also not sure why you call this a regression.

That's simple: It worked before, now it stopped. As the vendor extension is
very common - it works at least with PGI, Intel, g95, gfortran (before the
2010-10), Sun, Open64, Pathf95 and crayftn, it makes sense to regard this as
supported vendor extension. (I am sure more compiler support it, but I don't
have access to them.)

A different example would be:
  &nml tag = string /
which is only supported by ifort. All other compilers fail as "string" is not
quoted. If gfortran had supported such a feature as only compiler or as one of
very few compilers, I would agree that breaking it, would probably fall into
the WONTFIX category.