[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 --- Comment #7 from Damian Rouson damian at rouson dot net --- Any updates on this PR? I'm teaching a graduate course on modern Fortran and will be using this feature in class. It would be great to have an open-source compiler that supports the feature.
[Bug fortran/57093] New: Seg fault on internal output to a character scalar coarray
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57093 Bug #: 57093 Summary: Seg fault on internal output to a character scalar coarray Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net $ cat co_hello.f90 program main ! len25 produces the expected result len=25 seg faults character(len=25), allocatable :: greeting[:] allocate(greeting[*]) write(greeting,(a)) z end $ gfortran -fcoarray=single co_hello.f90 $ ./a.out a.out(35951) malloc: *** error for object 0x7fc5ba404c20: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x1055d2e62 #1 0x1055d362e #2 0x7fff90ae6949 Abort trap: 6 $ gfortran --version GNU Fortran (MacPorts gcc49 4.9-20130414_0) 4.9.0 20130414 (experimental)
[Bug fortran/56929] [OOP] [F08] ICE on dummy argument child class with coarray inside parent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56929 --- Comment #5 from Damian Rouson damian at rouson dot net 2013-04-13 15:53:51 UTC --- Thanks for the amazingly fast response! Possibly this sets a record: 11.5 hours from submitting the report to the application of a patch to the trunk. Any chance this patch can also be applied to the 4.8 branch?
[Bug fortran/56929] New: ICE on dummy argument child class with coarray inside parent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56929 Bug #: 56929 Summary: ICE on dummy argument child class with coarray inside parent Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net $ cat all.f90 module parent_coarray_component type parent real, allocatable :: dummy[:] end type type, extends(parent) :: child end type contains subroutine do_something(this) class(child) this end end $ gfortran -fcoarray=single -c all.f90 all.f90: In function '__copy_parent_coarray_component_Child': all.f90:9:0: internal compiler error: Segmentation fault: 11 class(child) this ^ all.f90:9:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 Damians-MacBook-Pro-2:coarrayBurgers rouson$ gfortran --version GNU Fortran (MacPorts gcc48 4.8-20130321_0) 4.8.0 20130321 (prerelease)
[Bug fortran/55905] [OOP] [F008] ICE for polymorphic dummy argument with an allocatable coarray component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55905 --- Comment #2 from Damian Rouson damian at rouson dot net 2013-01-25 21:32:40 UTC --- Hi Janus, I've added Karla Morris to the cc list for this bug. She discovered it independently so I guess this one is now stumbling block for two projects. Any thoughts about a fix? Damian
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #5 from Damian Rouson damian at rouson dot net 2013-01-20 18:59:54 UTC --- Hi Janus and Tobias, We're moving toward an internal release of the open-source package that exposed this bug. Any chance of this being fixed in the near future? The lead developer Karla Morris is cc'd on this. Damian
[Bug fortran/55905] New: ICE for polymorphic dummy argument with an allocatable coarray component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55905 Bug #: 55905 Summary: ICE for polymorphic dummy argument with an allocatable coarray component Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net $ cat dummy_with_coarray_component.f90 module foo_module type foo logical, allocatable :: x[:] end type contains subroutine bar(this) class(foo) this end end $ gfortran -c -fcoarray=single dummy_with_coarray_component.f90 dummy_with_coarray_component.f90: In function '__copy_foo_module_Foo': dummy_with_coarray_component.f90:7:0: internal compiler error: Segmentation fault: 11 class(foo) this ^ dummy_with_coarray_component.f90:7:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 $ gfortran --version GNU Fortran (MacPorts gcc48 4.8-20121223_0) 4.8.0 20121223 (experimental)
[Bug fortran/55854] ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 --- Comment #4 from Damian Rouson damian at rouson dot net 2013-01-03 18:11:56 UTC --- Apparently an ICE also occurs if the argument intent is removed but type is replaced by class. See below. Is this fixed by the patch in comment 3? Damian $ cat ice_on_class_dummy_with_unlimited.f90 implicit none type foo class(*), allocatable :: bar end type contains integer function foobar(this) class(foo) :: this end function end $ gfortran ice_on_class_dummy_with_unlimited.f90 ice_on_class_dummy_with_unlimited.f90: In function 'MAIN__': ice_on_class_dummy_with_unlimited.f90:8:0: internal compiler error: Segmentation fault: 11 end function ^ ice_on_class_dummy_with_unlimited.f90:8:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 $ gfortran --version GNU Fortran (MacPorts gcc48 4.8-20121223_0) 4.8.0 20121223 (experimental)
[Bug fortran/55854] ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 --- Comment #6 from Damian Rouson damian at rouson dot net 2013-01-03 19:12:09 UTC --- Awesome -- thanks! Please let me know once this hits the trunk so I can request an update of the macports build and try it out. Damian (In reply to comment #5) (In reply to comment #4) Apparently an ICE also occurs if the argument intent is removed but type is replaced by class. See below. Is this fixed by the patch in comment 3? Seems to be fixed by the patch, which has been submitted at http://gcc.gnu.org/ml/fortran/2013-01/msg00017.html
[Bug fortran/55854] New: ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 Bug #: 55854 Summary: ICE on intent(out) dummy argument with unlimited polymorphic component Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net As demonstrated below, having an intent(out) dummy argument with an unlimited polymorphic component generates an internal compiler error with a December 23 build of gfortran 4.8: $ cat ice_on_intent_out_with_unlimted.f90 type foo class(*), allocatable :: x end type contains subroutine bar(this) type(foo), intent(out) :: this end end $ gfortran ice_on_intent_out_with_unlimted.f90 ice_on_intent_out_with_unlimted.f90: In function 'bar': ice_on_intent_out_with_unlimted.f90:5:0: internal compiler error: Segmentation fault: 11 subroutine bar(this) ^ ice_on_intent_out_with_unlimted.f90:5:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 $ gfortran --version GNU Fortran (MacPorts gcc48 4.8-20121223_0) 4.8.0 20121223 (experimental)
[Bug fortran/55603] New: Memory leak in intrinsic assignment of allocatable derived type function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 Bug #: 55603 Summary: Memory leak in intrinsic assignment of allocatable derived type function result Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net valgrind reports a memory leak in the code below. FY, this is a greatly simplified version of the actual use case. In the intended use case, the bar procedure is type-bound and is invoked via a type-bound generic operator that appears in a longer expression composed of various user-defined operators. Damian $ gfortran --version GNU Fortran (MacPorts gcc48 4.8-20121202_0) 4.8.0 20121202 (experimental) $ cat leak.f90 type foo end type type(foo) a a = bar() contains function bar() type(foo), allocatable :: bar allocate(bar) end function end $ gfortran leak.f90 $ valgrind ./a.out ==5151== Memcheck, a memory error detector ==5151== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==5151== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==5151== Command: ./a.out ==5151== --5151-- ./a.out: --5151-- dSYM directory is missing; consider using --dsymutil=yes ==5151== ==5151== HEAP SUMMARY: ==5151== in use at exit: 1,998 bytes in 33 blocks ==5151== total heap usage: 49 allocs, 16 frees, 5,706 bytes allocated ==5151== ==5151== LEAK SUMMARY: ==5151==definitely lost: 1 bytes in 1 blocks ==5151==indirectly lost: 0 bytes in 0 blocks ==5151== possibly lost: 0 bytes in 0 blocks ==5151==still reachable: 1,997 bytes in 32 blocks ==5151== suppressed: 0 bytes in 0 blocks ==5151== Rerun with --leak-check=full to see details of leaked memory ==5151== ==5151== For counts of detected and suppressed errors, rerun with: -v ==5151== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug fortran/55297] New: 4.8 Regression: type-bound operator clashes with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55297 Bug #: 55297 Summary: 4.8 Regression: type-bound operator clashes with abstract interface Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net $ cat athlete.f90 module athlete_module type athlete contains procedure :: negative generic :: operator(-) = negative end type abstract interface integer function sum_interface(this) import athlete class(athlete) this end function end interface contains integer function negative(this) class(athlete) ,intent(in) :: this end function end module $ gfortran-mp-4.7 -c athlete.f90 $ gfortran-mp-4.8 -c athlete.f90 athlete.f90:5.29: generic :: operator(-) = negative 1 Error: Entity 'negative' at (1) is already present in the interface wlan-clients-2916:gnu rouson$ gfortran-mp-4.8 --version GNU Fortran (MacPorts gcc48 4.8-20121021_0) 4.8.0 20121021 (experimental)
[Bug fortran/52158] New: Regression on character function with gfortran 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52158 Bug #: 52158 Summary: Regression on character function with gfortran 4.7 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net A build from a snapshot of the development branch as of February 4 appears to have a regression on deferred-length character functions. The text below shows a test that compiles with gcc 4.6.2 but not with 4.7. $ cat character_function.F90 module foo_class implicit none type foo contains procedure :: bar end type contains function bar(this) class(foo) :: this character(:), allocatable :: bar end function end module $ /opt/local/bin/gfortran-mp-4.6 -c character_function.F90 $ /opt/local/bin/gfortran-mp-4.7 -c character_function.F90 character_function.F90:9.22: class(foo) :: this 1 Error: Deferred-length character component 'bar' at (1) is not yet supported $ /opt/local/bin/gfortran-mp-4.7 --version GNU Fortran (GCC) 4.7.0 20120204 (experimental) Damian
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 --- Comment #9 from Damian Rouson damian at rouson dot net 2012-01-02 17:01:47 UTC --- Thanks for the fix! I'm very excited about the way 4.7 is shaping up. It appears this will be a very significant release for those interested in the more advanced capabilities of OOP. Damian
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #31 from Damian Rouson damian at rouson dot net 2011-11-17 01:43:38 UTC --- This is awesome news! :D On Wed, Nov 16, 2011 at 1:54 PM, burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #30 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-16 21:54:10 UTC --- FIXED on the 4.7 trunk. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 --- Comment #4 from Damian Rouson damian at rouson dot net 2011-10-31 02:06:36 UTC --- Thanks for the update. The same error occurs when a defined assignment is added: $ cat abstract_field_expression.F90 module field_module implicit none type ,abstract :: field contains procedure(field_op_real) ,deferred :: multiply_real procedure(field_eq_field) ,deferred :: assign generic :: operator(*) = multiply_real generic :: assignment(=) = assign end type abstract interface function field_op_real(lhs,rhs) import :: field class(field) ,intent(in) :: lhs real ,intent(in) :: rhs class(field) ,allocatable :: field_op_real end function subroutine field_eq_field(lhs,rhs) import :: field class(field) ,intent(inout) :: lhs class(field) ,intent(in) :: rhs end subroutine end interface end module program main use field_module implicit none class(field) ,pointer :: u u = (u)*2. end program $ gfortran abstract_field_expression.F90 abstract_field_expression.F90:29.6: u = (u)*2. 1 Error: Operands of binary numeric operator '*' at (1) are CLASS(field)/REAL(4) $ gfortran --version GNU Fortran (GCC) 4.6.2 20111019 (prerelease)
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #30 from Damian Rouson damian at rouson dot net 2011-08-30 18:46:42 UTC --- Just out curiosity, what's the reason for the real::rnd line in the helloworld testcase? I don't see rnd used anywhere. Damian On Tue, Aug 30, 2011 at 8:34 AM, kargl at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #29 from kargl at gcc dot gnu.org 2011-08-30 15:34:06 UTC --- Author: kargl Date: Tue Aug 30 15:34:01 2011 New Revision: 178329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178329 Log: 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * trans-stmt.c (gfc_trans_allocate): Evaluate the substring. 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * gfortran.dg/allocate_with_source_2.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328 Damian Rouson damian at rouson dot net changed: What|Removed |Added CC||damian at rouson dot net --- Comment #2 from Damian Rouson damian at rouson dot net 2011-08-10 04:46:08 UTC --- i think the code below is another example of this bug. Any chance this will be resolved in 4.7? (The NAG Fortran and IBM XL Fortran compilers compile the code without error): $ cat integrand.F90 module foo_module type ,abstract :: foo contains procedure(t_interface) ,deferred :: t procedure(assign_interface) ,deferred :: assign procedure(multiply_interface) ,deferred :: multiply generic :: operator(*) = multiply generic :: assignment(=) = assign end type abstract interface function t_interface(this) import :: foo class(foo) :: this class(foo), allocatable ::t_interface end function function multiply_interface(lhs,rhs) import :: foo class(foo), allocatable :: multiply_interface class(foo), intent(in) :: lhs real, intent(in) :: rhs end function subroutine assign_interface(lhs,rhs) import :: foo class(foo), intent(in) :: rhs class(foo), intent(inout) :: lhs end subroutine end interface contains subroutine bar(x,dt) class(foo) :: x real, intent(in) :: dt x = x%t()*dt end subroutine end module $ gfortran -c integrand.F90 integrand.F90:32.8: x = x%t()*dt 1 Error: Operands of binary numeric operator '*' at (1) are CLASS(foo)/REAL(4) $ gfortran --version GNU Fortran (GCC) 4.6.1 20110325 (prerelease) Copyright (C) 2011 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Damian Rouson damian at rouson dot net changed: What|Removed |Added CC||damian at rouson dot net --- Comment #19 from Damian Rouson damian at rouson dot net 2011-08-09 02:09:56 UTC --- Comment 9 states that gfortran does not yet support function result variables which are character(len=:), pointer. Presumably this also implies a lack of support for replacing these with allocatable, deferred-length character variables. I'm adding the case below because it produces an ICE with gfortran 4.6.1: $ cat speaker.F90 module speaker_class type speaker contains procedure :: speak end type contains function speak(this) class(speaker) ,intent(in) :: this character(:) ,allocatable :: speak end function subroutine say_something(somebody) class(speaker) :: somebody print *,somebody%speak() end subroutine end module $ gfortran -c speaker.F90 speaker.F90: In function 'say_something': speaker.F90:13:0: internal compiler error: in fold_convert_loc, at fold-const.c:1906 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ gfortran --version GNU Fortran (GCC) 4.6.1 20110325 (prerelease) Copyright (C) 2011 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #21 from Damian Rouson damian at rouson dot net 2011-08-09 04:26:45 UTC --- Thanks but even the version with the extraneous garbage was reduced relative to what I really want to do (which includes making the speaker type abstract and the speak type-bound procedure deferred with a specified abstract interface) so having the reduced case doesn't help much. Regardless, hopefully you'll agree that an ICE is a compiler bug. I guess the question is whether it is another example of Bug 45170 or should be submitted as a separate bug.
[Bug fortran/48654] New: ICE on return of derived type with allocatable-length character component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48654 Summary: ICE on return of derived type with allocatable-length character component Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net Created attachment 24022 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24022 A more involved example that is closer to the intended use. gfortran 4.6 give an ICE on the code below (and on the attached more involved example): $ cat message.F90 module message_module type message character(:) ,allocatable :: string end type contains type(message) function new_message() end function end module $ gfortran -c message.F90 message.F90:6:0: internal compiler error: in gfc_get_derived_type, at fortran/trans-types.c:2298 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ gfortran --version GNU Fortran (GCC) 4.6.1 20110325 (prerelease) Copyright (C) 2011 Free Software Foundation, Inc.
[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897 --- Comment #6 from Damian Rouson damian at rouson dot net 2010-12-13 15:16:42 UTC --- Janus, Thanks for finding the relevant language in the standard. In case it helps, what I submitted originally was a reduced example of code written by Jim Xia, who is member of both the IBM compiler test team and the Fortran standards committee. IBM XL Fortran 13.1 calls the defined assignment in my original example (and interestingly in Janus's reduced example, although it appears from what you wrote that it is not required to do so in your reduced example). Unfortunately, Jim is on vacation, so I probably won't be able to find out soon what part of the standard he was relying upon when he wrote the relevant code, but I know he gave it a a lot of thought becasue that code plays a central role in an algorithm that he developed with us for the open-source ForTrilinos package (http://trilinos.sandia.gov/download/trilinos-10.6.html). Every derived type in ForTrilinos extends a derived type analogous to the parent type in my original posting. The defined assignment is needed for a reference counting scheme to prevent memory management problems. If the compiler does not call the defined assignment, it would have significant downstream implications for all ForTrilinos derived types and for all user-defined types that aggregate or extend ForTrilinos derived types. Damian
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Damian Rouson damian at rouson dot net changed: What|Removed |Added CC||damian at rouson dot net --- Comment #6 from Damian Rouson damian at rouson dot net 2010-12-02 04:35:39 UTC --- The test case below is a test of finalization of a concrete component of an abstract type when a type that extends the abstract type goes out of scope. I'm working on determining how many times the final subroutine should be called -- certainly at least once to finalize the new_child function result when it goes out of scope after the assignment. module finalizable_component_module implicit none type finalizable_component contains final :: finalize end type contains subroutine finalize(this) type(finalizable_component) :: this print *,'subroutine finalize called' end subroutine end module module abstract_parent_module use finalizable_component_module implicit none type ,abstract :: abstract_parent type(finalizable_component) :: foo end type end module module child_module use abstract_parent_module implicit none type, extends(abstract_parent) :: child end type contains type(child) function new_child() end function end module program main use child_module implicit none type(child) :: infant infant = new_child() end
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427 --- Comment #19 from Damian Rouson damian at rouson dot net 2010-09-28 18:38:12 UTC --- Could someone please comment on the relevance (or lack thereof) of the component being public in the example I submitted? My real goal is to have all data components private, but I left that out in the test case I submitted. The question of whether the code would still be valid appears to be a sticking point in getting one vendor to support the requested feature.
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #17 from damian at rouson dot net 2010-07-31 02:30 --- Tobias, Thanks for your continued efforts on this. It will ultimately have a huge impact on the usability of gfortran for my purposes. I look forward to hearing more when you get back to it or when others do. Since there are regressions, I assume I won't get access to your patch just by doing an update using macports (my preferred method for building), but I look forward to trying it out once it's available. Damian (In reply to comment #16) Remove assignment. I think I won't work on this in the next weeks and New is better in allowing others to pick it up. If not, I will look at it again later. The patch of attachment 20714 [edit] plus the fix in comment 15 (plus the test cases at the bottom of attachment 20696 [edit]) mostly work OK - except for a handful regressions. The implementation was using DT-name as generic function and created the derived type gfc_symbol using the suffix @. It was suggested to do the following - which might be cleaner: - Create the dt name as generic function (as before) - Use ns-derived_types to save the derived types (instead of generating another symbol) I think one can mostly recycle the resolve.c part of the patch - and the gfc_convert_to_structure_constructor's part in primary.c (one can probably get rid of gfc_match_structure_constructor after some modifications). However, all the rest has to be adapted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/42385] [OOP] poylmorphic operators do not work
--- Comment #1 from damian at rouson dot net 2010-05-21 14:01 --- As suggested by Janus and Paul, I'm adding the additional test case below. Note that the first two pointer assignments in main are not necessary to demonstrate the linking problem. I put them there (1) to give more detail about what I was trying to do and (2) because deleting those leaves pointless code since there would be no reason to do the the third assignment without doing the first two. $cat link_demo.f03 module field_module implicit none type ,abstract :: field contains procedure(field_eq_field) ,deferred :: assign generic :: assignment(=) = assign end type abstract interface subroutine field_eq_field(lhs,rhs) import :: field class(field) ,intent(out) :: lhs class(field) ,intent(in) :: rhs end subroutine end interface end module module periodic_field_module use field_module ,only : field implicit none type ,extends(field) :: periodic_field real :: f=0. contains procedure :: assign = copy end type contains function new_periodic_field() type(periodic_field) ,pointer :: new_periodic_field allocate(new_periodic_field) end function subroutine copy(lhs,rhs) class(field) ,intent(in) :: rhs class(periodic_field) ,intent(out) :: lhs select type(rhs) class is (periodic_field) lhs%f = rhs%f class default stop 'periodic_field%copy: unsupported right-hand-side class.' end select end subroutine end module program main use field_module use periodic_field_module implicit none class(field) ,pointer :: u,f u = new_periodic_field() f = new_periodic_field() f = u end program $ gfortran link_demo.f03 Undefined symbols: _field_eq_field_, referenced from: _MAIN__ in ccFO42I9.o ld: symbol(s) not found collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42385
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #5 from damian at rouson dot net 2010-05-04 14:25 --- (In reply to comment #4) What a horrible rule... I'm not sure why you don't like it, but the reason for the rule is to have the ability to overload the intrinsic structure constructors. The intrinsic structure constructors are virtually useless for object-oriented programming (OOP) because they can't be used if the type has private data (required by the information-hiding philosophy of OOP) unless all components have default initializations (which only helps in trivial cases). It's standard in C++ (and I'd guess in most other OOP languages) for constructors to have the same name as the type. What could be more clear to the reader than type(vector) :: f f = vector(1.0,2.0) Once one adopts this approach, it touches every type you develop, so a compiler that doesn't support it becomes useless unless you're willing to change every constructor name to suit that particular compiler. It's already supported by IBM XL Fortran (my primary development platform), by Cray, by NAG (I think), and Intel has promised to support it in its next release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #6 from damian at rouson dot net 2009-11-30 00:51 --- (In reply to comment #5) (In reply to comment #3) So how do I switch to 64-bit mode? On x86_64-apple-darwin* it is the default, so I assume you are using i686-apple-darwin*. In this case you need a multlib build and you compile with -m64. Switching to x86_64-apple-darwin9 worked! What does the 9 mean? Since I'm running OS X 10.5.8, I first tried 10.5.8 and 10, but neither worked. Damian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #7 from damian at rouson dot net 2009-11-30 01:16 --- Janus, Although the new reduced case compiles fine in 64-bit mode, I run into linking problems as soon as I add program main; end program to the end of it: Undefined symbols: _vtab$bar.1550, referenced from: ___m_MOD_new_bar in ccQEi2ET.o ld: symbol(s) not found collect2: ld returned 1 exit status Looking back through my e-mails, I see that you told me on 11/21 that Paul's TBP patch had not yet been applied to the branch or the trunk. From the above results, I assume that's still the case. Damian (In reply to comment #4) (In reply to comment #2) On darwin, the errors appear only in 32 bit mode. Yes, I can confirm this on x86_64-apple-darwin10.2.0. Also, I just ran the fortran testsuite for the fortran-dev branch on darwin, but saw no failures. Here is a reduced test case: module m implicit none type foo end type type ,extends(foo) :: bar end type contains function new_bar() class(foo) ,pointer :: new_bar allocate(bar :: new_bar) end function end module Important: This only happens inside a module. If I remove the module m/end module in the example, the error goes away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug fortran/42207] New: Compile-time errors on typed allocation and pointer function result assignment
After a fresh fortran-dev checkout, configure, make, and make install, the first two modules below compile correctly, while the third produces the the compile-time errors shown. The two offending lines are the allocate statement and the subsequent pointer assignment, both in the new_bar function. Based on the error message, this is related to vtabs. Apparently the error is platform-dependent since Janus reports compiling similar code with no problem. Damian $ cat foo.f03 module foo_module implicit none type foo end type end module $ cat bar.f03 module bar_module use foo_module implicit none type ,extends(foo) :: bar end type contains function bar_() type(bar) ,pointer :: bar_ bar_ = null() end function end module $ cat bar_factory.f03 module bar_factory_module implicit none type bar_factory contains procedure :: new_bar end type contains function new_bar(this) use bar_module use foo_module class(bar_factory), intent(in) :: this class(foo) ,pointer :: new_bar allocate(bar :: new_bar) new_bar = bar_() end function end module $ gfortran -c foo.f03 $ gfortran -c bar.f03 $ gfortran -c bar_factory.f03 /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:37:non-relocatable subtraction expression, _vtab$bar.1525 minus L001$pb /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:37:symbol: _vtab$bar.1525 can't be undefined in a subtraction expression /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:35:non-relocatable subtraction expression, _vtab$bar.1525 minus L001$pb /var/folders/aN/aNwnamXwF00CoxUk5fEVmU+++TM/-Tmp-//cciAcMyX.s:35:symbol: _vtab$bar.1525 can't be undefined in a subtraction expression -- Summary: Compile-time errors on typed allocation and pointer function result assignment Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: Mac OS X 10.5.8 GCC host triplet: Mac OS X 10.5.8 GCC target triplet: Mac OS X 10.5.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug fortran/42207] Compile-time errors on typed allocation and pointer function result assignment
--- Comment #3 from damian at rouson dot net 2009-11-29 02:50 --- (In reply to comment #2) On darwin, the errors appear only in 32 bit mode. I am sure that I have already seen such errors in the past, but I cannot remember where or when!-( Thanks for all of your help. So how do I switch to 64-bit mode? Damian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
[Bug fortran/42167] New: TYPE IS and CLASS IS expect arguments after a type named after a function
When the argument to a TYPE IS construct is a function result variable with the same name as the encompassing function, the compiler interprets the variable as a function invocation and fails without arguments. The code below produces the error message below the code. Also, replacing TYPE IS with CLASS IS produces the same result. Damian $ cat select_type.f03 module bar_module implicit none type :: bar real ,dimension(:) ,allocatable :: f contains procedure :: total end type contains function total(lhs,rhs) class(bar) ,intent(in) :: lhs class(bar) ,intent(in) :: rhs class(bar) ,pointer :: total select type(rhs) type is (bar) allocate(bar :: total) select type(total) type is (bar) total%f = lhs%f + rhs%f end select end select end function $ gfortran -c select_type.f03 select_type.f03:18.25: select type(total) 1 Error: Function 'total' requires an argument list at (1) select_type.f03:20.17: total%f = lhs%f + rhs%f 1 Error: 'total' at (1) is not a variable select_type.f03:22.7: end select 1 Error: Expecting END FUNCTION statement at (1) -- Summary: TYPE IS and CLASS IS expect arguments after a type named after a function Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: Mac OS X 10.5.8 GCC host triplet: Mac OS X 10.5.8 GCC target triplet: Mac OS X 10.5.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42167
[Bug fortran/42051] New: ICE on allocatable array TBP result
Gfortran 4.5.0 20091106 (with Janus's patch for PR42048) produces the following on the code below: gfortran -c field_grid.f03 field_grid.f03: In function output: field_grid.f03:27:0: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:550 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. module grid_module implicit none type grid real ,dimension(1) :: x=1. contains procedure :: return_x end type contains function return_x(this) result(this_x) class(grid) ,intent(in) :: this real ,dimension(1) :: this_x this_x = this%x end function end module module field_module use grid_module, only : grid implicit none type field type(grid) :: mesh contains procedure :: output end type contains subroutine output(this) class(field) ,intent(in) :: this real ,dimension(:) ,allocatable :: x x=this%mesh%return_x() end subroutine end module -- Summary: ICE on allocatable array TBP result Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: Mac OS X 10.5 GCC host triplet: Mac OS X 10.5 GCC target triplet: Mac OS X 10.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/41556] New: Errors in applying operator/assignment to an abstract type
When defining an abstract type with generic operators that map to deferred bindings and using these operators in an expression, the development branch of gfortran 4.5.0 (20090925) gives the errors shown below the program below. In case it helps to know, IBM XL Fortran 12.1 compiles the program without errors or warnings. Damian $ cat abstract_algebra.f03 module abstract_algebra implicit none private public :: rescale public :: object type ,abstract :: object contains procedure(assign_interface) ,deferred :: assign procedure(product_interface) ,deferred :: product generic :: assignment(=) = assign generic :: operator(*) = product end type abstract interface function product_interface(lhs,rhs) result(product) import :: object class(object) ,intent(in) :: lhs class(object) ,allocatable :: product real ,intent(in) :: rhs end function subroutine assign_interface(lhs,rhs) import :: object class(object) ,intent(inout) :: lhs class(object) ,intent(in):: rhs end subroutine end interface contains subroutine rescale(operand,scale) class(object):: operand real ,intent(in) :: scale operand = operand*scale ! preferred implementation operand = operand%product(scale) ! alternate implementation end subroutine end module $ /usr/local/gfortran/bin/gfortran-4.5 -c abstract_algebra.f03 abstract_algebra.f03:9.54: procedure(assign_interface) ,deferred :: assign 1 Error: Assignment operator interface at (1) must not redefine an INTRINSIC type assignment abstract_algebra.f03:34.14: operand = operand*scale ! preferred implementation 1 Error: Operands of binary numeric operator '*' at (1) are CLASS(object)/REAL(4) abstract_algebra.f03:35.14: operand = operand%product(scale) 1 Error: ABSTRACT INTERFACE 'product_interface' must not be referenced at (1) $ /usr/local/gfortran/bin/gfortran-4.5 --version GNU Fortran (GCC) 4.5.0 20090925 (experimental) -- Summary: Errors in applying operator/assignment to an abstract type Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: Mac OS X 10.5.8 GCC host triplet: Mac OS X 10.5.8 GCC target triplet: Mac OS X 10.5.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41556
[Bug fortran/39427] New: Error on generic name equivalent to type name in same module
The Fortran 2003 standard Section C.1.6 allows a generic procedure to have the same name as a type , but gfotran gives Error: DERIVED attribute of 'foo' conflicts with PROCEDURE attribute at (1) on the following code: module foo_module type foo integer :: bar end type interface foo procedure constructor end interface contains type(foo) function constructor() constructor%bar = 1 end function end module I use this style throughout a textbook I'm writing because it seems like a natural way to extend the intrinsic structure constructor syntax. A more extensive example of this technique is also in Figure 17.1 of Metcalf, Reid Cohen. Damian -- Summary: Error on generic name equivalent to type name in same module Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: Using built-in specs. Target: i386-apple-darwin8.10.1 Configured GCC host triplet: Using built-in specs. Target: i386-apple-darwin8.10.1 Configured GCC target triplet: Using built-in specs. Target: i386-apple-darwin8.10.1 Configured http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/34765] erroneous intrinsic assignment call
-- damian at rouson dot net changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34765
[Bug fortran/34765] erroneous intrinsic assignment call
--- Comment #5 from damian at rouson dot net 2008-01-13 16:40 --- I was trying to demonstrate multiple instances of the bug. Based on comment #4, I realize that the compiler performed correctly in at least 3 of the 4 instances. I will now attempt to verify whether the 4th instance is actually a bug. My apologies about the other three. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34765
[Bug fortran/34765] erroneous intrinsic assignment call
--- Comment #6 from damian at rouson dot net 2008-01-13 17:59 --- It turns out this is not a gfortran bug. My apologies for any time wasted. -- damian at rouson dot net changed: What|Removed |Added CC||damian at rouson dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34765
[Bug fortran/34765] New: erroneous intrinsic assignment call
The attached code demonstrates several circumstances wherein gfortran executes an intrinsic assignment of a derived type when a defined (overloaded) assignment is required. Specifically, the subroutines complex_array_equals_Field() and field_equals_Field() in the Field_Class module (file field.f90) should be called for the assignments near the text gfortran_bug in the file statistics.f90. -- Summary: erroneous intrinsic assignment call Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net 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=34765
[Bug fortran/34765] erroneous intrinsic assignment call
--- Comment #1 from damian at rouson dot net 2008-01-13 01:24 --- Created an attachment (id=14933) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14933action=view) Please see the README file in the attached bzipped archive search the file disperse.out for the text gfortran_bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34765
[Bug fortran/33986] New: internal compiler error on integer assignment
An internal compiler results from assigning an integer constant to an integer variable in Fortran on Mac OS X. The problem occurs inside a wrapper for a FFT procedure. I've read the instructions, but I don't see how to attach the code to this submission. -- Summary: internal compiler error on integer assignment Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: i386-apple-darwin8.10.1 GCC host triplet: i386-apple-darwin8.10.1 GCC target triplet: i386-apple-darwin8.10.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33986
[Bug fortran/33986] internal compiler error on integer assignment
--- Comment #1 from damian at rouson dot net 2007-11-02 22:35 --- Created an attachment (id=14474) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14474action=view) The offending procedure is transform_to_spectral_from() in chebyshev.f90. The text of the error message follows: chebyshev.f90: In function 'transform_to_spectral_from': chebyshev.f90:1130: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [chebyshev.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33986
