User account creation filtered due to spam.

Bug 43146 - Character constant declared in a module does not transfer correctly
Summary: Character constant declared in a module does not transfer correctly
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-22 21:07 UTC by Wirawan Purwanto
Modified: 2010-06-10 07:22 UTC (History)
2 users (show)

See Also:
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 (1.19 KB, text/plain)
2010-02-26 16:08 UTC, Wirawan Purwanto
Details

Note You need to log in before you can comment on or make changes to this bug.
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 kargl 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 kargl 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 kargl 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 kargl 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 kargl 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 ...