[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 --- 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: UNCONFIRME

[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 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 ca

[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: UNCONFIR

[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 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 abo

[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 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 d

[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 Stat

[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 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 repl

[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 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

[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

[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

[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: U

[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

[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 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

[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 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 > > Tobia

[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 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

[Bug fortran/45170] [F2003] allocatable character lengths

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #30 from Damian Rouson 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

[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 changed: What|Removed |Added CC||damian at rouson dot net --- Comment #2

[Bug fortran/45170] [F2003] allocatable character lengths

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #21 from Damian Rouson 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 pr

[Bug fortran/45170] [F2003] allocatable character lengths

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Damian Rouson changed: What|Removed |Added CC||damian at rouson dot net --- Comment #19

[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

[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 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 b

[Bug fortran/37336] Fortran 2003: Finish derived-type finalization

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Damian Rouson changed: What|Removed |Added CC||damian at rouson dot net --- Comment #6

[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 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 l

[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

[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 d

[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 int

[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&qu

[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 y

[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 h

[Bug fortran/42207] New: Compile-time errors on typed allocation and pointer function result assignment

mal 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/42167] New: TYPE IS and CLASS IS expect arguments after a type named after a function

3 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

ity: 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

ity: 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

ED 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:

[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

[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

[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 #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=14933&action=view) Please see the README file in the attached bzipped archive & search the file disperse.out for the text &q

[Bug fortran/34765] New: erroneous intrinsic assignment call

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/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=14474&action=view) The offending procedure is "transform_to_spectral_from()" in chebyshev.f90. The text of the erro

[Bug fortran/33986] New: internal compiler error on integer assignment

: 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 do