[Bug fortran/40820] New: gfortran does not recognize -Wno-unused-parameters
According to GCC manual, the -Wno-blah option should be there to negate the -Wblah option. I notice that gcc 4.3.2 and gcc 4.4.0 does not support -Wno-unused-parameters option. Please add this to the command-line option of f951. Thanks, Wirawan -- Summary: gfortran does not recognize -Wno-unused-parameters Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wirawan0 at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40820
[Bug fortran/40820] gfortran does not recognize -Wno-unused-parameters
--- Comment #2 from wirawan0 at gmail dot com 2009-07-21 19:34 ---
Just to clarify: you might misunderstand this. In Fortran, -Wunused-parameters
is used to issue a warning whenever a constant (which in Fortran called
"PARAMETER") is declared but not used. It has nothing to do with function's
parameters in the usual ("C") sense.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40820
[Bug fortran/40820] gfortran does not recognize -Wno-unused-parameters
--- Comment #4 from wirawan0 at gmail dot com 2009-07-23 16:03 --- Sorry for my confusion. It turned out that the option -Wno-unused-parameter (no s) did work on 4.3.2. Marking this bug as invalid. -- wirawan0 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40820
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #1 from wirawan0 at gmail dot com 2007-08-01 20:00 --- Created an attachment (id=14006) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14006&action=view) Failing testcase with higher-dimensional b array I found that the result of conjg(transpose(a)) is also wrong if b is a part of higher-dimensional array (see testcase): b(:,:,i) = conjg(transpose(a)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug fortran/32962] New: b = conjg(transpose(a)) is erroneous if b is an allocatable array
It turns out that bug #31994 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994) has not been fully resolved! I found another testcase that would fail gcc 4.2.1, namely if the destination of the expression is an allocatable array. Use the following testcase: program testcase complex(kind=8), allocatable :: a(:,:), b(:,:) allocate(a(2,2)) allocate(b(2,2)) a(1,1) = 2 a(2,1) = 3 a(1,2) = 7 a(2,2) = 11 b = conjg(transpose(a)) ! This does NOT work with gcc 4.2.1 print *, 'original = ', a print *, 'WRONG conjg(transpose(a)) = ', b end program OBSERVATIONS: * The bug appears regardless whether a is allocatable or not. * The bug does not appear if b is NOT an allocatable array, e.g. a complex(kind=8),dimension(2,2) in the testcase above. * The bug does not appear if we reverse the order of expression to: b = transpose(conjg(a)) . -- Summary: b = conjg(transpose(a)) is erroneous if b is an allocatable array Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wirawan0 at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #3 from wirawan0 at gmail dot com 2007-08-01 20:02 --- Created an attachment (id=14007) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14007&action=view) Magically successful testcase! And by the way, if BOTH b and a are part of higher-dimensional arrays (see testcase), then b(:,:,1) = conjg(transpose(a(:,:,1))) magically works again! Wirawan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug c++/35008] New: Bug in processing nested typedef in nested template class in method definition
The following testcase fails to compile:
template struct outer1
{
typedef int my_value_type; // define a nested datatype
template struct inner1
{
typedef outer1 myboss;
// borrow the boss's datatype << -- don't reduce or change this one:
typedef typename myboss::my_value_type my_value_type;
my_value_type return_x();
};
};
// g++ 4 choked on this one:
template
template
typename outer1::template inner1::my_value_type
outer1::inner1::return_x()
{
return 4;
}
void testme()
{
outer1::inner1 Inner1;
int rslt = Inner1.return_x(); // to instantiate and cause error
}
It is basically like this:
* outer1 class template has a nested datatype called "my_value_type"
* inner1 borrows the "my_value_type" from outer1 (its parent)
Then when we want to instantiate return_x() above, g++ gives the following
error:
template-typename4.cpp:19: error: prototype for typename
outer1::inner1::my_value_type
outer1::inner1::return_x() does not match any in class
outer1::inner1
template-typename4.cpp:10: error: candidate is: typename
outer1::my_value_type outer1::inner1::return_x()
template-typename4.cpp:19: error: template definition of non-template typename
outer1::inner1::my_value_type
outer1::inner1::return_x()
I can work around this by changing line 18 above:
typename outer1::template inner1::my_value_type
to
typename outer1::my_value_type
then it would compile. But I think this is a bug. It used to compile with g++
3. Other compilers such as Intel C++ (version 9.1), PGI C++ 7 all accept this
language construct.
--
Summary: Bug in processing nested typedef in nested template
class in method definition
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wirawan0 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35008
[Bug c++/35008] Bug in processing nested typedef in nested template class in method definition
--- Comment #3 from wirawan0 at gmail dot com 2008-01-29 15:00 --- Created an attachment (id=15047) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15047&action=view) Sample code to cause compilation error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35008
[Bug c++/35008] Bug in processing nested typedef in nested template class in method definition
--- Comment #2 from wirawan0 at gmail dot com 2008-01-29 14:59 --- The whole snippet must be included the (un)desirable error to show up. Let me give an attachment to make it clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35008
[Bug c++/35016] New: Bug in processing nested typedef in nested template class in method definition
The following testcase fails to compile:
template struct outer1
{
typedef int my_value_type; // define a nested datatype
template struct inner1
{
typedef outer1 myboss;
// borrow the boss's datatype << -- don't reduce or change this one:
typedef typename myboss::my_value_type my_value_type;
my_value_type return_x();
};
};
// g++ 4 choked on this one:
template
template
typename outer1::template inner1::my_value_type
outer1::inner1::return_x()
{
return 4;
}
void testme()
{
outer1::inner1 Inner1;
int rslt = Inner1.return_x(); // to instantiate and cause error
}
It is basically like this:
* outer1 class template has a nested datatype called "my_value_type"
* inner1 borrows the "my_value_type" from outer1 (its parent)
Then when we want to instantiate return_x() above, g++ gives the following
error:
template-typename4.cpp:19: error: prototype for typename
outer1::inner1::my_value_type
outer1::inner1::return_x() does not match any in class
outer1::inner1
template-typename4.cpp:10: error: candidate is: typename
outer1::my_value_type outer1::inner1::return_x()
template-typename4.cpp:19: error: template definition of non-template typename
outer1::inner1::my_value_type
outer1::inner1::return_x()
I can work around this by changing line 18 above:
typename outer1::template inner1::my_value_type
to
typename outer1::my_value_type
then it would compile. But I think this is a bug. It used to compile with g++
3. Other compilers such as Intel C++ (version 9.1), PGI C++ 7 all accept this
language construct.
--
Summary: Bug in processing nested typedef in nested template
class in method definition
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wirawan0 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35016
[Bug fortran/43146] New: Character constant declared in a module does not transfer correctly
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. -- Summary: Character constant declared in a module does not transfer correctly Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wirawan0 at gmail dot com GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #3 from wirawan0 at gmail dot com 2010-02-23 15:52 --- 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 -
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #5 from wirawan0 at gmail dot com 2010-02-23 17:49 ---
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #7 from wirawan0 at gmail dot com 2010-02-23 18:38 --- There are no changes if I compiled with *.f90 instead of *.F90 extension. Wirawan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #9 from wirawan0 at gmail dot com 2010-02-26 16:06 --- 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) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #10 from wirawan0 at gmail dot com 2010-02-26 16:08 --- Created an attachment (id=19970) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19970&action=view) valgrind --leak-check=full output I attach this as a more verbose report. Not sure if it is of any use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #12 from wirawan0 at gmail dot com 2010-02-26 18:50 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/43146] Character constant declared in a module does not transfer correctly
--- Comment #15 from wirawan0 at gmail dot com 2010-03-28 23:01 --- Yes, just close it. I'm waiting the gentoo folks to find out which patch was causing this error. It was so slow there... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
[Bug fortran/36632] New: OpenMP code segment with module variable causes Fortran compiler to crash
This testcase causes GNU Fortran versions shown below (as far as I know):
4.2.1
4.3.0
to crash with `internal compiler error'.
This testcase shows some "features" that must exist in order to cause the
compiler to fail:
- inside the OpenMP section, it accesses a module variable (ModuleVar)
- the enclosing subroutine (named `crash' in the testcase) contains one or more
nested subroutines/functions. If NO nested subroutine is defined inside the
function, then all is OK.
Some "invariants":
- the !$omp master directive is optional; the crash occurs regardless whether
it is present.
- the access mode of ModuleVar does not matter--it can be a write or a read
- the `subroutine' keyword can be replaced with `program', and it still
crashes.
Here's the gfortran output:
$ gfortran -c -fopenmp crash.f95
crash.f95:39: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ /usr/local/gcc-4.3.0/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 -fopenmp
crash.f95
crash blah
crash.f95: At top level:
crash.f95:39: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Here's the debugging output:
$ gdb /usr/local/gcc-4.3.0/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run -fopenmp crash.f95
Starting program: /usr/local/gcc-4.3.0/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951
-fopenmp crash.f95
crash blah
Program received signal SIGSEGV, Segmentation fault.
get_frame_type (info=0x0) at ../../gcc-4.3.0/gcc/tree-nested.c:198
198 tree type = info->frame_type;
(gdb) where
#0 get_frame_type (info=0x0) at ../../gcc-4.3.0/gcc/tree-nested.c:198
#1 0x082be86f in get_chain_decl (info=0x87ab180) at
../../gcc-4.3.0/gcc/tree-nested.c:304
#2 0x082bf872 in get_nonlocal_debug_decl (info=0x87ab180, decl=0xb7caa1b8) at
../../gcc-4.3.0/gcc/tree-nested.c:904
#3 0x082c11e4 in convert_nonlocal_omp_clauses (pclauses=,
wi=0xbfe1bfbc)
at ../../gcc-4.3.0/gcc/tree-nested.c:1181
#4 0x082c0e99 in convert_nonlocal_reference (tp=0xb7ccd5fc,
walk_subtrees=0xbfe1bec8, data=0xbfe1bfbc)
at ../../gcc-4.3.0/gcc/tree-nested.c:1099
#5 0x08382e8d in walk_tree_1 (tp=0xb7ccd5fc, func=0x82c0c80
, data=0xbfe1bfbc, pset=0x0, lh=0)
at ../../gcc-4.3.0/gcc/tree.c:8391
#6 0x082bfd30 in walk_stmts (wi=0xbfe1bfbc, tp=0xb7ccd5fc) at
../../gcc-4.3.0/gcc/tree-nested.c:640
#7 0x082bfefd in walk_stmts (wi=0xbfe1bfbc, tp=0xb7cab0e8) at
../../gcc-4.3.0/gcc/tree-nested.c:575
#8 0x082bfd78 in walk_stmts (wi=0xbfe1bfbc, tp=0xb7cd7d08) at
../../gcc-4.3.0/gcc/tree-nested.c:594
#9 0x082bffab in walk_body (callback=0x82c0c80 ,
info=0x0, stmt_p=0xb7caa1b8)
at ../../gcc-4.3.0/gcc/tree-nested.c:657
#10 0x082bffed in walk_all_functions (callback=0x82c0c80
, root=0x87ab180)
at ../../gcc-4.3.0/gcc/tree-nested.c:665
#11 0x082c00ca in lower_nested_functions (fndecl=0xb7cd7cb0) at
../../gcc-4.3.0/gcc/tree-nested.c:2001
#12 0x083cec09 in cgraph_finalize_function (decl=0xb7cd7cb0, nested=0 '\0') at
../../gcc-4.3.0/gcc/cgraphunit.c:620
#13 0x080de9bf in gfc_generate_function_code (ns=0x87aaa38) at
../../gcc-4.3.0/gcc/fortran/trans-decl.c:3376
#14 0x0809bdad in gfc_parse_file () at ../../gcc-4.3.0/gcc/fortran/parse.c:3579
#15 0x080c71c5 in gfc_be_parse_file (set_yydebug=0) at
../../gcc-4.3.0/gcc/fortran/f95-lang.c:260
#16 0x0828ef04 in toplev_main (argc=3, argv=0xbfe1c334) at
../../gcc-4.3.0/gcc/toplev.c:1042
#17 0x0810145f in main (argc=150994976, argv=0x0) at
../../gcc-4.3.0/gcc/main.c:35
Note that I built my own GCC on an Intel Pentium M laptop with Ubuntu 7.04
Linux, and using gmp version 4.2.2 and mpfr 2.3.1 .
--
Summary: OpenMP code segment with module variable causes Fortran
compiler to crash
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wirawan0 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36632
[Bug fortran/36632] OpenMP code with access to module variable causes Fortran compiler to crash
--- Comment #1 from wirawan0 at gmail dot com 2008-06-25 19:25 --- Created an attachment (id=15813) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15813&action=view) Fortran95 source code No postprocessing needed. To reproduce the error, use: gfortran -c -fopenmp crash.f95 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36632
[Bug fortran/36632] OpenMP code with access to module variable causes Fortran compiler to crash
--- Comment #3 from wirawan0 at gmail dot com 2008-07-02 14:43 --- This problem also occurs with gfortran 4.3.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36632
