Bug 43146

Summary:	Character constant declared in a module does not transfer correctly
Product:	gcc	Reporter:	Wirawan Purwanto <wirawan0>
Component:	fortran	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	gcc-bugs, toolchain
Priority:	P3
Version:	4.4.1
Target Milestone:	---
Host:	x86_64-pc-linux-gnu	Target:	x86_64-pc-linux-gnu
Build:		Known to work:
Known to fail:		Last reconfirmed:
Attachments:	valgrind --leak-check=full output

Description Wirawan Purwanto 2010-02-22 21:07:00 UTC

Please compile the following snippet and watch that ch10 is printed as ASCII NUL (redirect to text file and see the produced characters, or use `./a.out | od -t x1' for even quicker result):

module blahblah
 character(len=1), parameter :: ch10 = char(10)
end module

program testme3
 use blahblah
 implicit none
 character(len=100) :: message

 !write(message, '(a,a)') ch10,'invars1m : enter jdtset='
 write(6, '(a,a)') ch10,'invars1m : enter jdtset='
 !write(6,'(A)') message
end program

It would have been OK if the ch10 is defined in the main program (or whatever subprogram block using it), but it is not OK if we import using "use" statement like above. This used not to be a problem with GCC 4.3.2.

I am using Sabayon Linux 5.0 (derivative of Gentoo Linux) on an X86-64 platform.

Comment 1 kargls 2010-02-22 21:19:09 UTC

You may need to update to a newer version of gfortran.

troutmask:sgk[207] gfc4x -o z j.f90 && ./z | od -t x1
0000000    0a  69  6e  76  61  72  73  31  6d  20  3a  20  65  6e  74  65
0000020    72  20  6a  64  74  73  65  74  3d  0a                        
0000032
troutmask:sgk[208] gfc44 -o z j.f90 && ./z | od -t x1
0000000    0a  69  6e  76  61  72  73  31  6d  20  3a  20  65  6e  74  65
0000020    72  20  6a  64  74  73  65  74  3d  0a                        
0000032
troutmask:sgk[209] gfc43 -o z j.f90 && ./z | od -t x1
0000000    0a  69  6e  76  61  72  73  31  6d  20  3a  20  65  6e  74  65
0000020    72  20  6a  64  74  73  65  74  3d  0a                        
0000032

troutmask:sgk[211] gfc4x --version
GNU Fortran (GCC) 4.5.0 20100111 (experimental)

troutmask:sgk[212] gfc44 --version
GNU Fortran (GCC) 4.4.3 20091216 (prerelease)

troutmask:sgk[213] gfc43 --version
GNU Fortran (GCC) 4.3.5 20091216 (prerelease)

Comment 2 Tobias Burnus 2010-02-23 08:54:04 UTC

(In reply to comment #1)
> troutmask:sgk[209] gfc43 -o z j.f90 && ./z | od -t x1
> 0000000    0a  69  6e  76  61  72  73  31  6d  20  3a  20  65  6e  74  65
> 0000020    72  20  6a  64  74  73  65  74  3d  0a                        
> 0000032

Same result also with gcc version 4.2.1  and gcc version 4.1.2 20070115 - and for comparison with NAG f95.

You wrote that you have 4.4.1 installed. Can you give more information? For a starter, what does  gfortran -v  show? What does ./a.out | od -t x1 show?

Steve tested with:
> troutmask:sgk[212] gfc44 --version
> GNU Fortran (GCC) 4.4.3 20091216 (prerelease)

I also tested with 4.4.4 20100223 and 4.4.2 [gcc-4_4-branch revision 155966] (SUSE Linux).

Comment 3 Wirawan Purwanto 2010-02-23 15:52:57 UTC

Here's my activity log. It's using gcc 4.4.3 that I just compiled yesterday. It's still yielding char(0) instead of char(10). Weird.

~/toys/gfortran/ch10 $ cat testme5.F90 
module blahblah
 character(len=1), parameter :: ch10 = char(10)
end module

program testme3
 use blahblah
 implicit none
 character(len=100) :: message

 !write(message, '(a,a)') ch10,'invars1m : enter jdtset='
 write(6, '(a,a)') ch10,'invars1m : enter jdtset='
 !write(6,'(A)') message
end program

~/toys/gfortran/ch10 $ x86_64-pc-linux-gnu-gfortran -v testme5.F90 && ./a.out | od -t x1
Driving: /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/x86_64-pc-linux-gnu-gfortran -v testme5.F90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/python --enable-objc-gc --enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3 p1.0'
Thread model: posix
gcc version 4.4.3 (Gentoo 4.4.3 p1.0) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/f951 testme5.F90 -cpp /home/wirawan/tmp/cc40casZ.f90 -quiet -v testme5.F90 -D_FORTIFY_SOURCE=2 -quiet -dumpbase testme5.F90 -mtune=generic -auxbase testme5 -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/finclude -o /home/wirawan/tmp/ccsvKVRO.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/finclude
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include-fixed
 /usr/include
End of search list.
GNU Fortran (Gentoo 4.4.3 p1.0) version 4.4.3 (x86_64-pc-linux-gnu)
	compiled by GNU C version 4.4.3, GMP version 4.3.1, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy -o /home/wirawan/tmp/ccWqEc1C.o /home/wirawan/tmp/ccsvKVRO.s
GNU assembler version 2.20 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.20
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/crtbegin.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../.. /home/wirawan/tmp/ccWqEc1C.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/crtend.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crtn.o
0000000 00 69 6e 76 61 72 73 31 6d 20 3a 20 65 6e 74 65
0000020 72 20 6a 64 74 73 65 74 3d 0a
0000032

Comment 4 kargls 2010-02-23 17:16:09 UTC

(In reply to comment #3)
> Here's my activity log. It's using gcc 4.4.3 that I just compiled yesterday.
> It's still yielding char(0) instead of char(10). Weird.
> 

Can you add the -fdump-tree-original option and post the output?

I see

testme3 ()
{
  {
    struct __st_parameter_dt dt_parm.0;

    dt_parm.0.common.filename = &"j.f90"[1]{lb: 1 sz: 1};
    dt_parm.0.common.line = 11;
    dt_parm.0.format = &"(a,a)"[1]{lb: 1 sz: 1};
    dt_parm.0.format_len = 5;
    dt_parm.0.common.flags = 4096;
    dt_parm.0.common.unit = 6;
    _gfortran_st_write (&dt_parm.0);
    _gfortran_transfer_character (&dt_parm.0, &"\n"[1]{lb: 1 sz: 1}, 1);
    _gfortran_transfer_character (&dt_parm.0, &"invars1m : enter jdtset="[1]{lb: 1 sz: 1}, 24);
    _gfortran_st_write_done (&dt_parm.0);
  }
}

which clearly has a '\n' character in the transfer.

Comment 5 Wirawan Purwanto 2010-02-23 17:49:33 UTC

Here's the dump content. Indeed it misses the "\n" stuff.

~/toys/gfortran/ch10 $ cat testme5.F90.003t.original
testme3 ()
{
  static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};

  _gfortran_set_options (8, (void *) &options.0);
  {
    struct __st_parameter_dt dt_parm.1;

    dt_parm.1.common.filename = &"testme5.F90"[1]{lb: 1 sz: 1};
    dt_parm.1.common.line = 11;
    dt_parm.1.format = &"(a,a)"[1]{lb: 1 sz: 1};
    dt_parm.1.format_len = 5;
    dt_parm.1.common.flags = 4096;
    dt_parm.1.common.unit = 6;
    _gfortran_st_write (&dt_parm.1);
    _gfortran_transfer_character (&dt_parm.1, &""[1]{lb: 1 sz: 1}, 1);
    _gfortran_transfer_character (&dt_parm.1, &"invars1m : enter jdtset="[1]{lb: 1 sz: 1}, 24);
    _gfortran_st_write_done (&dt_parm.1);
  }
}



BTW I recompiled gcc 4.4.3 (vanilla version from gcc site) on an Ubuntu 8.04 box, and it did not have problem like this. Seems like this is a Gentoo-specific problem? I started seeing this problem from a completely different thread, here:

http://bugs.gentoo.org/show_bug.cgi?id=249493

I'll ping the gentoo folks to see if they can help as well.

Wirawan

Comment 6 kargls 2010-02-23 18:29:33 UTC

(In reply to comment #5)
> Here's the dump content. Indeed it misses the "\n" stuff.
> 
> ~/toys/gfortran/ch10 $ cat testme5.F90.003t.original

Can you rename the file to testme5.f90 and try again?
The .F90 extension will cause gfortran to invoke the
preprocessor.  I'm curious to see if this is related
to it.

Comment 7 Wirawan Purwanto 2010-02-23 18:38:55 UTC

There are no changes if I compiled with *.f90 instead of *.F90 extension.

Wirawan

Comment 8 Tobias Burnus 2010-02-24 10:46:40 UTC

(In reply to comment #7)
> There are no changes if I compiled with *.f90 instead of *.F90 extension.

Another idea - can you compile with "valgrind"? That is:
  gfortran -v <file.f90>
find the line containing the call to f951 and then run:
  valgrind /some/path/f951 .... many arguments ...

Maybe that finds some uninitialized variables. Otherwise, it seems to be a very elusive bug - it works with many GCC versions on Ubuntu, openSUSE and FreeBSD, but it fails on Gentoo.

Comment 9 Wirawan Purwanto 2010-02-26 16:06:22 UTC

Here's a brief run with valgrind 3.5.0: I had to recompile glibc (2.10.1) with "splitdebug" feature in Gentoo OS for it to work.

~/toys/gfortran/ch10 $ valgrind  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/f951 testme5.noppx.f90 -quiet -dumpbase testme5.noppx.f90 -mtune=generic -auxbase testme5.noppx -version -o testme5.noppx.s -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/finclude
==7813== Memcheck, a memory error detector
==7813== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==7813== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==7813== Command: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/f951 testme5.noppx.f90 -quiet -dumpbase testme5.noppx.f90 -mtune=generic -auxbase testme5.noppx -version -o testme5.noppx.s -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/finclude
==7813== 
GNU Fortran (Gentoo 4.4.3 p1.0) version 4.4.3 (x86_64-pc-linux-gnu)
	compiled by GNU C version 4.4.3, GMP version 4.3.1, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
==7813== 
==7813== HEAP SUMMARY:
==7813==     in use at exit: 427,388 bytes in 1,287 blocks
==7813==   total heap usage: 2,829 allocs, 1,542 frees, 1,405,467 bytes allocated
==7813== 
==7813== LEAK SUMMARY:
==7813==    definitely lost: 160 bytes in 2 blocks
==7813==    indirectly lost: 0 bytes in 0 blocks
==7813==      possibly lost: 16,128 bytes in 4 blocks
==7813==    still reachable: 411,100 bytes in 1,281 blocks
==7813==         suppressed: 0 bytes in 0 blocks
==7813== Rerun with --leak-check=full to see details of leaked memory
==7813== 
==7813== For counts of detected and suppressed errors, rerun with: -v
==7813== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

Comment 10 Wirawan Purwanto 2010-02-26 16:08:13 UTC

Created attachment 19970 [details]
valgrind --leak-check=full output

I attach this as a more verbose report. Not sure if it is of any use.

Comment 11 kargls 2010-02-26 17:36:26 UTC

(In reply to comment #10)
> Created an attachment (id=19970) [edit]
> valgrind --leak-check=full output
> 
> I attach this as a more verbose report. Not sure if it is of any use.

I don't know how gentoo packages gcc, but are you sure

GNU Fortran (Gentoo 4.4.3 p1.0) version 4.4.3 (x86_64-pc-linux-gnu)
	compiled by GNU C version 4.4.3, GMP version 4.3.1,
        MPFR version 2.4.1-p5.

==7819==    by 0x50851B8: __gmp_default_allocate (in /usr/lib64/libgmp.so.3.5.0)
==7819==    by 0x4E55B51: mpfr_init2 (in /usr/lib64/libmpfr.so.1.2.0)

that these 2 libraries correspond to the versions that gfortran
was compiled against.

I think you have a gentoo bug, here.  You already demonstrated
that if you compile gcc yourself that you get a working gfortran.

Comment 12 Wirawan Purwanto 2010-02-26 18:50:40 UTC

I'm positive that the libraries used for compilation and running are the same. The package was built on my own computer. I'm posting this bug at gentoo bugzilla (http://bugs.gentoo.org/show_bug.cgi?id=306833) . Still waiting for a response, though.

Comment 13 Paul Thomas 2010-03-27 19:11:02 UTC

Can we close this one, guys?

Paul

Comment 14 kargls 2010-03-27 21:22:55 UTC

(In reply to comment #13)
> Can we close this one, guys?
> 
> Paul
> 

Sure.  I think that we've demonstrated that
it is a gentoo issue.

Comment 15 Wirawan Purwanto 2010-03-28 23:01:33 UTC

Yes, just close it. I'm waiting the gentoo folks to find out which patch was causing this error. It was so slow there...

Comment 16 Daniel Franke 2010-04-27 19:42:23 UTC

Closing then.

Comment 17 Mike Frysinger 2010-06-10 07:22:26 UTC

vanilla gcc-4.4.x shows the same behavior if you were to use the same configure options as Gentoo.  specifically, --disable-checking seems to cause this.

i dont have the ability to re-open this bug since i didnt file it ...