I will investigate this later tonight if I can.

This is due to revision r210934 (pr55117) from:

	* trans-io.c (nml_full_name, transfer_namelist_element): Insert
	a '+' rather then '%' to differentiate namelist variable names
	that are based on extended derived types.

this seems to have been done on purpose (I did not follow the discussion in the PR).

(In reply to Dominique d'Humieres from comment #2)
> This is due to revision r210934 (pr55117) from:
> 
> 	* trans-io.c (nml_full_name, transfer_namelist_element): Insert
> 	a '+' rather then '%' to differentiate namelist variable names
> 	that are based on extended derived types.
> 
> this seems to have been done on purpose (I did not follow the discussion in
> the PR).

Yes, it was done on purpose to differentiate two possible representation of derived type namelists with extended types.  I have a patch in mind.

This fixes it:

Index: io/write.c
===================================================================
--- io/write.c	(revision 221571)
+++ io/write.c	(working copy)
@@ -1704,10 +1704,11 @@
   size_t clen;
   index_type elem_ctr;
   size_t obj_name_len;
-  void * p ;
+  void * p;
   char cup;
   char * obj_name;
   char * ext_name;
+  char * q;
   size_t ext_name_len;
   char rep_buff[NML_DIGITS];
   namelist_info * cmp;
@@ -1745,6 +1746,8 @@
       for (dim_i = len; dim_i < clen; dim_i++)
 	{
 	  cup = toupper ((int) obj->var_name[dim_i]);
+	  if (cup == '+')
+	    cup = '%';
 	  write_character (dtp, &cup, 1, 1, NODELIM);
 	}
       write_character (dtp, "=", 1, 1, NODELIM);
@@ -1894,6 +1897,9 @@
 		}
 
 	      ext_name[tot_len] = '\0';
+	      for (q = ext_name; *q; q++)
+		if (*q == '+')
+		  *q = '%';
 
 	      /* Now obj_name.  */

> This fixes it: ...

Confimed (the patch in comment 4 does not apply cleanly and needs some minor surgery) and it regtest without regression.

Thanks for quick fix.

Author: jvdelisle
Date: Thu Mar 26 02:44:34 2015
New Revision: 221682

URL: https://gcc.gnu.org/viewcvs?rev=221682&root=gcc&view=rev
Log:
2015-03-25 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/65541
	* io/write.c (nml_write_obj): Convert '+' to '%' before emitting
	object names in namelists.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/write.c

Fixed. No test case needed.

Hi,

It seems that some testing was required after all.  With the latest gcc snapshot from Debian (20150329-1) I still get the same output from the test code:

$ ll `which gfortran-5.0 `
lrwxrwxrwx 1 root staff 35 Feb 26 11:01 /usr/local/bin/gfortran-5.0 -> ../../lib/gcc-snapshot/bin/gfortran*
$ gfortran-5.0 test_namelist.f90 
$ ./a.out 
$ cat some.dat 
&SOME
 A+T2+T1%I=          0,
 A+T2+J=          0,
 A+K=          0,
 /


In my actual code, what fails is READING a namelist generated by a previous version of gfortran, so maybe that needs some checking as well?


System and compiler information follows:

$ lsb_release -rd && gfortran-5.0 -v
Description:	Debian GNU/Linux 8.0 (jessie)
Release:	8.0
Using built-in specs.
COLLECT_GCC=gfortran-5.0
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20150329-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.0.0 20150329 (experimental) [trunk revision 221764] (Debian 20150329-1)

(In reply to John from comment #8)
> Hi,
> 
> It seems that some testing was required after all.  With the latest gcc
> snapshot from Debian (20150329-1) I still get the same output from the test
> code:
> 
Full testing was done. For me here, if you do not explicitly set the LD_LIBRARY_PATH its possible to compile with one version of gfortran and execute with another library.  So, try it with -static to make sure that is not the issue.

Also I did confirm with your example in your original post here that output from 5. is compatible with 4.9 and the 4.9 compiled with -static could actually read correctly output generated by 5.0. My comment about testing relates to not being able to run 4.9 and 5.0 automatically in our test suite.

If you still see a problem, let me know, maybe there is something else going on.

For the record, my results with trunk:

$ gfc pr65541.f90
$ ./a.out 
$ cat some.dat 
&SOME
 A%T2%T1%I=          0,
 A%T2%J=          0,
 A%K=          0,
 /

Yes, -static does the trick when it comes to the namelist ---although, in the actual program, I get an obscure error when I try to invoke C's execv/waitpid.

Thanks a lot for the help provided, and sorry for the inconvenience.