[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #11 from John jwmwalrus at gmail dot com --- 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.
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #8 from John jwmwalrus at gmail dot com --- 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)
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (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.
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- 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, /
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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.
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Thu Mar 26 02:44:34 2015 New Revision: 221682 URL: https://gcc.gnu.org/viewcvs?rev=221682root=gccview=rev Log: 2015-03-25 Jerry DeLisle jvdeli...@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
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed. No test case needed.
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (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.
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541
--- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
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. */
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-24 Summary|namelist regression |[5 Regression] namelist ||regression Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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).
