I am reposting this bug onto Gentoo bugzilla because the bug seems to exist on Gentoo-based systems only. See the examples below. 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 (Ubuntu LInux). Also other people on the GCC bugzilla reported that they did not see the problem. I thought this was a problem with GCC 4.4.1 that I had; but it turned out that GCC 4.4.3 (I just built it myself) also had the same issue. However, if ch10 is defined to be a printable character, e.g. char(32) or char(65), then this problem would not have appeared. I am using Gentoo 10.0 on an X86-64 platform. Reproducible: Always Steps to Reproduce: TESTCASE 1. 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(6, '(a,a)') ch10,'invars1m : enter jdtset=' end program TESTCASE 2 A reduced testcase is like this: ~/toys/gfortran/ch10 $ cat testme7.F90 module blahblah character(len=1), parameter :: ch10 = char(32) end module subroutine xx(z) use blahblah implicit none character(len=1) :: z z = ch10 end subroutine Here, gcc -S gives: ~/toys/gfortran/ch10 $ gfortran -S testme7.F90 && cat testme7.s .file "testme7.F90" .text .globl xx_ .type xx_, @function xx_: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 movq %rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 movq %rdi, -8(%rbp) movl %esi, -12(%rbp) movq -8(%rbp), %rax movb $0, (%rax) leave ret .cfi_endproc .LFE0: .size xx_, .-xx_ .ident "GCC: (Gentoo 4.4.3 p1.0) 4.4.3" .section .note.GNU-stack,"",@progbits The last statement before "leave" says that the resulting z is assigned a value of NULL instead of "\n" (ASCII 10). THe error was firstly observed in abinit build on gentoo: http://bugs.gentoo.org/show_bug.cgi?id=249493
Created attachment 221153 [details] emerge --info output I originally started out with Sabayon, but then forked from them by continuing to build my own package a la Gentoo--thus, the bug was reported against gentoo and not sabayon.
gfortan version info: ~/toys/gfortran/ch10 $ gfortran -v 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)
OK. No progress yet. :( Now I am building gcc 4.4.3 plain vanilla on my gentoo box. I used the gcc-4.4.3 that I built on this machine using the following ebuild: EBUILD gcc-4.4.3.ebuild 2362 RMD160 dcb7e675c30d26fbc714fb27a4935773b74b8bc1 SHA1 da0c26e43e3a10829c345260e834504b36534eee SHA256 bf25a37a1461a1c9e269c926896a8f54490a37a33a4527965cfe4bd37a4eae24 The output of gcc -v is: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/usr/local/gcc-4.4.3 --enable-languages=c,fortran,c++ Thread model: posix gcc version 4.4.3 (GCC) I compiled testme7.F90 that I supplied in an earlier communication and here's the result: ~/toys/gfortran/ch10/gfortran-4.4.3-vanilla-gentoo $ cat testme7.s .file "testme7.F90" .text .globl xx_ .type xx_, @function xx_: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 movq %rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 movq %rdi, -8(%rbp) movl %esi, -12(%rbp) movq -8(%rbp), %rax movb $10, (%rax) leave ret .cfi_endproc .LFE0: .size xx_, .-xx_ .ident "GCC: (GNU) 4.4.3" .section .note.GNU-stack,"",@progbits Voila! It is correct now. Thus there must be a bug somewhere in the patched GCC 4.4.3 in Gentoo version.
(In reply to comment #3) For me vanilla did not help. Since it appears it's going to take me some time before I report all the details properly, I'll at least mention one observation for now: Gfortrans up to 4.3.x work well for me, 4.4.x does not. Both *.s and *.mod formats changed between 4.3 and 4.4, the important change being the way character constants are saved in the fortran modules. Up to 4.3 series, gfortran used to simply save all the characters in the modules as they were. 4.4 series saves printable characters as they are, while non-printable ones are saved as escaped unicode strings, char(10) becoming '\U0000000a'. Apparently, gfortran does not parse well the modules it has itself created. When I edited the blahblah.mod created by `gfortran -S testme7.F90`, replacing the escape string by the character itself, subsequent `gfortran -S testme7.F90` produced the correct testme7.s
Created attachment 234815 [details] 306833.F90: fortran test case to summarize, this test case with gcc-4.4.[0-4] results in: $ gfortran-4.4.4 306833.F90 $ ./a.out | od -t x1 -N 1 0000000 00 that 00 should be 0a. gcc-4.3.x and gcc-4.5.x results in correct output. x86 and x86_64 behave the same way.
vanilla gcc-4.4.4 (no Gentoo patches) gives same behavior. trick seems to be in the configure options used. specifically, --disable-checking.
cc back amd64 if you need our support.
seems to be working for me with newer libs. presumably a bug in gmp/mpfr that is now fixed.
