[Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366 Andrew Benson abenson at caltech dot edu changed: What|Removed |Added CC||abenson at caltech dot edu --- Comment #16 from Andrew Benson abenson at caltech dot edu 2012-04-10 21:06:13 UTC --- The following compiles with -std=f2003 and runs successfully (using gfortran 4.8 r186145) with the a=b line in, but if I switch it for the a%d=b%d line I get a Variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator error: module testMod implicit none public t type t integer :: i end type t type c class(t), allocatable :: d end type c end module testMod program testProg use testMod implicit none type(t) :: f type(c) :: a,b allocate(b%d,source=f) b%d%i=12345 a=b !! THIS COMPILES OK ! a%d=b%d !! THIS DOES NOT write (0,*) a%d%i write (0,*) b%d%i end program testProg Since d is polymorphic both should be disallowed with -std=f2003 (and both allowed under F2008 I think).
[Bug fortran/52909] New: Procedure pointers not private to modules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52909 Bug #: 52909 Summary: Procedure pointers not private to modules Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu The following code won't compile with the latest gfortran (or with 4.6 and 4.7). The two procedure pointers should be private to their respective modules so there should be no symbol conflict. module Module1 implicit none private procedure(), pointer :: procPtr = null() end module Module1 module Module2 implicit none private procedure(), pointer :: procPtr = null() end module Module2 program Test use Module1 use Module2 implicit none end program Test $ gfortran -v Using built-in specs. COLLECT_GCC=/home/abenson/gcc4.7/bin/gfortran COLLECT_LTO_WRAPPER=/home/abenson/gcc4.7/libexec/gcc/x86_64-unknown-linux- gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc4.7/configure --prefix=/home/abenson/gcc4.7 --enable- languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson/gcc4.7 -- with-mpc=/home/abenson/gcc4.7 --with-mpfr=/home/abenson/gcc4.7 Thread model: posix gcc version 4.8.0 20120407 (experimental) (GCC) $ gfortran test.F90 /tmp/ccuQNbu2.s: Assembler messages: /tmp/ccuQNbu2.s:13: Error: symbol `procptr' is already defined
[Bug fortran/52729] New: Symbol has no implicit type in SELECT TYPE block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52729 Bug #: 52729 Summary: Symbol has no implicit type in SELECT TYPE block Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu The following fails to compile with the latest gfortran 4.8 (r185768): module testMod type testType end type testType contains subroutine testSub() implicit none procedure(double precision ), pointer :: r class(testType ), pointer :: testObject double precision :: testVal select type (testObject) class is (testType) testVal=testFunc() r = testFunc end select return end subroutine testSub double precision function testFunc() implicit none return end function testFunc end module testMod $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/libexec/gcc/x86_64-unknown-linux- gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/home/abenson --enable- languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson --with- mpc=/home/abenson --with-mpfr=/home/abenson Thread model: posix gcc version 4.8.0 20120324 (experimental) (GCC) $ gfortran -c test.F90 -o test.o test.F90:16.23: testVal=testFunc() 1 Error: Symbol 'testfunc' at (1) has no IMPLICIT type Removing the r = line, removing the select type, class is and end select lines or moving testFunc before testSub in the file all allow the code to compile successfully.
[Bug fortran/51754] [OOP] ICE on valid with class arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51754 --- Comment #13 from Andrew Benson abenson at caltech dot edu 2012-02-06 04:14:15 UTC --- I'll look forward to trying using class arrays again in my code.
[Bug fortran/51754] New: [OOP] ICE on valid with class arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51754 Bug #: 51754 Summary: [OOP] ICE on valid with class arrays Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu This test case gives an ICE on valid related to class arrays: module test private type :: componentB end type componentB type :: treeNode class(componentB), allocatable, dimension(:) :: componentB end type treeNode contains function BGet(self) implicit none class(componentB), pointer :: BGet class(treeNode), intent(in) :: self select type (self) class is (treeNode) BGet = self%componentB(1) end select return end function BGet end module test $ gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc-4.7/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc-4.7/libexec/gcc/x86_64-unknown-linux- gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/opt/gcc-4.7 --enable- languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.7.0 20120103 (experimental) (GCC) $ gfortran -c test.F90 -o test.o test.F90: In function ‘bget’: test.F90:19:0: internal compiler error: in gfc_conv_descriptor_offset, at fortran/trans-array.c:210 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. If I remove the allocatable I instead get: $ gfortran -c test.F90 -o test.o f951: 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. If I remove the dimension(:) and change the pointer association to: BGet = self%componentB then it compiles successfully.
[Bug libgomp/51298] libgomp team_barrier locking failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51298 Andrew Benson abenson at caltech dot edu changed: What|Removed |Added CC||abenson at caltech dot edu --- Comment #3 from Andrew Benson abenson at caltech dot edu 2011-12-15 07:09:32 UTC --- Is/was this bug also present in 4.6.0?
[Bug fortran/50974] New: ICE on invalid on function used as variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50974 Bug #: 50974 Summary: ICE on invalid on function used as variable Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu Calling a function without the trailing () causes an ICE in gfortran 4.7.0 (r180805). For example: module Test_Mod implicit none private contains double precision function Func1() implicit none Func1=Func2 return end function Func1 double precision function Func2(arg1) implicit none double precision, intent(in) :: arg1 Func2=arg1 end function Func2 end module Test_Mod $ gfortran -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.7/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/usr/local/gcc-4.7 --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.7.0 2002 (experimental) (GCC) $ gfortran -c test.F90 -o test.o test.F90: In function ‘func1’: test.F90:7:0: error: invalid types in conversion to floating point real(kind=8) real(kind=8) (*T44f) (real(kind=8) restrict) __result_func1.0 = (real(kind=8)) func2; test.F90:7:0: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Adding () to the call to Func2 correctly results in an error being reported. This bug seems similar to Bug 40678 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40678 which was present in 4.1, 4.2 and 4.3 but went away in 4.4 and 4.5 (not sure about 4.6).
[Bug fortran/50659] New: ICE on invalid with procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 Bug #: 50659 Summary: ICE on invalid with procedure interface Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu :: arrSize end module Size_Mod module Test_Mod ! use Size_Mod !! Works if module used here. implicit none private public :: Init, Proc1 contains subroutine Init(Proc_Get) implicit none procedure(Proc1), pointer, intent(inout) :: Proc_Get return end subroutine Init function Proc1(arg1) result (res) use Size_Mod !! Fails if module used here. implicit none double precision, dimension(arrSize) :: res double precision, intent(in) :: arg1 return end function Proc1 end module Test_Mod $ gfortran -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.7/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7/libexec/gcc/i686-pc-linux- gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/usr/local/gcc-4.7 --enable- languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.7.0 20111007 (experimental) (GCC) $ gfortran -c test.F90 -o test.o f951: internal compiler error: in replace_symbol, at fortran/expr.c:4155 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The code is presumably invalid, because the arrSize variable (defined in Size_Mod) isn't in scope where Proc1 is used as a procedure interface - moving the use Size_Mod so that arrSize is in scope throughout the Test_Mod module makes the ICE go away. The ICE also seems to occur in 4.6.1. Interestingly, 4.4.5 compiles without complaint, unless I remove Proc1 from the public statement in which case it instead complains Error: Interface 'proc1' of procedure 'proc_get' at (1) must be explicit. My understanding is that Proc1 should have an explicit interface as it's in a module.
[Bug fortran/50227] New: ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 Bug #: 50227 Summary: ICE on valid with allocatable class component Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu Created attachment 25128 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25128 Contains the files which constitute the test cases. The attached code causes an ICE with gfortran 4.7 r178129. Note that if I combine the code in the two files into a single file (as in the attached combined.F90), and compile that it works without any problem. $ gfortran -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.7/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7/libexec/gcc/i686-pc-linux- gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/usr/local/gcc-4.7 --enable- languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.7.0 20110827 (experimental) (GCC) $ gfortran -c module.F90 -o module.o $ gfortran -c program.F90 -o program.o program.F90: In function ‘test’: program.F90:4:0: 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. $ gfortran -c combined.F90 -o combined.o
[Bug fortran/50227] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #1 from Andrew Benson abenson at caltech dot edu 2011-08-29 16:08:59 UTC --- Created attachment 25129 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25129 Further reduced test case from Janus Weil This is a further reduced test case created by Janus Weil.
[Bug fortran/50227] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #2 from Andrew Benson abenson at caltech dot edu 2011-08-29 16:11:25 UTC --- Original report on gfortran mailing list: http://gcc.gnu.org/ml/fortran/2011-08/msg00233.html
[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 Andrew Benson abenson at caltech dot edu changed: What|Removed |Added CC||abenson at caltech dot edu --- Comment #7 from Andrew Benson abenson at caltech dot edu 2011-08-23 19:54:07 UTC --- The following (reduced from the FoX library m_common_attrs.F90) seems to cause an ICE with gfortran 4.7.0 (r177982) - Dominique Dhumieres suggests that this is probably related to r177970. module m_common_attrs implicit none type dict_item end type dict_item type dict_item_ptr type(dict_item), pointer :: d = null() end type dict_item_ptr contains subroutine add_item_to_dict() type(dict_item_ptr), pointer :: tempList(:) integer :: n allocate(tempList(0:n+1)) end subroutine add_item_to_dict end module m_common_attrs # gfortran -c test.f90 f951: 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. # gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gcc-trunk/bin/../libexec/gcc/i686-pc-linux- gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc4.7/configure --prefix=/usr/local/gcc-trunk --enable- languages=c,c++,fortran --disable-multilib --with-gmp=/usr/local --with- mpc=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.7.0 20110823 (experimental) (GCC)
[Bug fortran/47767] New: SELECT TYPE fails to execute correct TYPE IS block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47767 Summary: SELECT TYPE fails to execute correct TYPE IS block Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu Created attachment 23363 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23363 Test case to reproduce the bug. The attached code should execute the contents of the TYPE IS block and print correct, but fails to do so, falling through to the CLASS DEFAULT block and printing incorrect. There are a number of ways to avoid the bug and get the output 'correct': * removing the 'private' statement * removing the 'public' statement * removing the 'baseNode' component * removing the unneeded module 'merger_tree_build' Compiled using r170207 of gfortran 4.6.0 $ gfortran selectTypeFail.F90 -o selectTypeFail.exe -g -fbacktrace -v Driving: gfortran selectTypeFail.F90 -o selectTypeFail.exe -g -fbacktrace -v -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.6/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++,fortran --disable-multilib --with-gmp=/usr/local --with-mpc=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.6.0 20110216 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/f951 selectTypeFail.F90 -cpp=/tmp/ccro8Gvw.f90 -quiet -v selectTypeFail.F90 -quiet -dumpbase selectTypeFail.F90 -mtune=generic -march=pentiumpro -auxbase selectTypeFail -g -version -fbacktrace -fintrinsic-modules-path /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/finclude -o /tmp/ccguPzRS.s GNU Fortran (GCC) version 4.6.0 20110216 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.6.0 20110216 (experimental), GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/finclude /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/include /usr/local/include /usr/local/gcc-trunk/include /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/include-fixed /usr/include End of search list. GNU Fortran (GCC) version 4.6.0 20110216 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.6.0 20110216 (experimental), GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' as --32 -o /tmp/ccZqndJg.o /tmp/ccguPzRS.s Reading specs from /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' COMPILER_PATH=/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/:/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/:/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'selectTypeFail.exe' '-g' '-fbacktrace' '-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/local/gcc-trunk/libexec/gcc/i686-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o selectTypeFail.exe /usr/lib/crt1.o /usr/lib/crti.o /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/crtbegin.o -L/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0 -L/usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/../../.. /tmp/ccZqndJg.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/gcc-trunk/lib/gcc/i686-pc-linux-gnu/4.6.0/crtend.o /usr/lib/crtn.o $ selectTypeFail.exe incorrect
[Bug fortran/47767] [OOP] SELECT TYPE fails to execute correct TYPE IS block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47767 --- Comment #3 from Andrew Benson abenson at caltech dot edu 2011-02-16 23:17:49 UTC --- I can confirm that this patch resolves the problem in the application from which my original test case was derived.
