[Bug fortran/29806] Error if CONTAINS is present without SUBPROGRAM

2006-11-12 Thread erik dot edelmann at iki dot fi
--- Comment #1 from erik dot edelmann at iki dot fi 2006-11-13 07:42 --- Isn't this going to be allowed in F2008? (Perhaps it already is in F2003 -- I'm too lazy to check.) We should print an error message if strict standard conformance is requested, but since it is going to be valid

[Bug fortran/28660] New: Spurious warning: 'ubound.6' is used uninitialized in this function

2006-08-09 Thread erik dot edelmann at iki dot fi
: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: erik dot edelmann at iki dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660

[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function

2006-08-09 Thread erik dot edelmann at iki dot fi
--- Comment #2 from erik dot edelmann at iki dot fi 2006-08-09 10:54 --- (In reply to comment #1) Actually this is worse than what is said here, this is wrong code. In a prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not know at the time we allocate r

[Bug fortran/24503] varying string length character function result

2005-10-27 Thread erik dot edelmann at iki dot fi
--- Comment #5 from erik dot edelmann at iki dot fi 2005-10-27 09:25 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-10/msg00587.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24503

[Bug fortran/24503] varying string length character function result

2005-10-24 Thread erik dot edelmann at iki dot fi
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-24 12:53 --- (In reply to comment #1) Here is what I get with the mainline of GCC: In file t.f90:12 PUBLIC :: s_to_c 1 Error: 'string' is a PRIVATE type and cannot be a dummy argument of 's_to_c', which

[Bug fortran/24426] gfortran ICE for valid derived type definition with default initialization

2005-10-21 Thread erik dot edelmann at iki dot fi
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-21 12:03 --- (In reply to comment #0) It reminds me a bit of bug 16606 but is different as the compiler crashes. It's indeed basically the same problem as in PR 16606; we assign a default initializer to variables of derived

[Bug fortran/24426] gfortran ICE for valid derived type definition with default initialization

2005-10-21 Thread erik dot edelmann at iki dot fi
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-21 14:57 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-10/msg00481.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24426

[Bug fortran/21625] Nested derived type pointer component not initialized on ALLOCATE

2005-10-18 Thread erik dot edelmann at iki dot fi
--- Comment #6 from erik dot edelmann at iki dot fi 2005-10-18 20:50 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01079.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21625

[Bug fortran/21625] Nested derived type pointer component not initialized on ALLOCATE

2005-10-17 Thread erik dot edelmann at iki dot fi
--- Comment #5 from erik dot edelmann at iki dot fi 2005-10-17 13:14 --- Working on a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21625

[Bug fortran/22273] problem to declare a character variable link to an intent(out) object

2005-10-13 Thread erik dot edelmann at iki dot fi
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-13 14:49 --- Patch posted here: http://gcc.gnu.org/ml/fortran/2005-10/msg00292.html -- erik dot edelmann at iki dot fi changed: What|Removed |Added

[Bug fortran/21625] Nested derived type pointer component not initialized on ALLOCATE

2005-10-12 Thread erik dot edelmann at iki dot fi
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-12 12:00 --- *** Bug 23924 has been marked as a duplicate of this bug. *** -- erik dot edelmann at iki dot fi changed: What|Removed |Added

[Bug fortran/23924] No initialization of derived type pointers/allocatables when allocated

2005-10-12 Thread erik dot edelmann at iki dot fi
--- Comment #4 from erik dot edelmann at iki dot fi 2005-10-12 12:00 --- *** This bug has been marked as a duplicate of 21625 *** -- erik dot edelmann at iki dot fi changed: What|Removed |Added

[Bug fortran/21625] Nested derived type pointer component not initialized on ALLOCATE

2005-10-12 Thread erik dot edelmann at iki dot fi
--- Comment #4 from erik dot edelmann at iki dot fi 2005-10-12 12:09 --- I think that this PR is just a symptom of a more general problem: components (of any kind) of a derived type are not initialized when a pointer/allocatable variable of derived type is allocated. Also see PR 23924

[Bug fortran/24245] -fdump-parse-tree gives ICE for CONTAINED functions

2005-10-12 Thread erik dot edelmann at iki dot fi
--- Comment #4 from erik dot edelmann at iki dot fi 2005-10-12 12:54 --- (In reply to comment #3) Testing a patch. Patch posted here: http://gcc.gnu.org/ml/fortran/2005-10/msg00229.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245

[Bug fortran/24245] -fdump-parse-tree gives ICE for CONTAINED functions

2005-10-11 Thread erik dot edelmann at iki dot fi
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-11 18:11 --- Testing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245

[Bug fortran/24245] New: -fdump-parse-tree gives ICE for CONTAINED functions

2005-10-06 Thread erik dot edelmann at iki dot fi
Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: erik dot edelmann at iki dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245

[Bug fortran/24245] -fdump-parse-tree gives ICE for CONTAINED functions

2005-10-06 Thread erik dot edelmann at iki dot fi
--- Comment #1 from erik dot edelmann at iki dot fi 2005-10-06 20:38 --- I think the ICE comes from dump-parse-tree.c/show_symtree() at the line gfc_status ( from namespace %s, st-n.sym-ns-proc_name-name); because st-n.sym-ns-proc_name is NULL for st-n.sym = 'hu'. -- http

[Bug fortran/18568] pointers in derived data types do not transmit shape of pointed to arrays - bug or non-standard feature?

2005-10-05 Thread erik dot edelmann at iki dot fi
--- Comment #2 from erik dot edelmann at iki dot fi 2005-10-05 21:38 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00171.html -- erik dot edelmann at iki dot fi changed: What|Removed |Added

[Bug fortran/20541] TR 15581: ALLOCATABLE components

2005-09-29 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-29 19:48 --- (In reply to comment #5) Working on a patch. Turned out to be much more work than I first thought. I'll leave it for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/20541] TR 15581: ALLOCATABLE components

2005-09-27 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-27 15:21 --- Working on a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug fortran/23843] Access restrictions on derived types in modules too strict.

2005-09-21 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-21 20:36 --- Patch posted to the mailing list here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01359.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23843

[Bug fortran/23924] New: No initialization of derived type pointers/allocatables when allocated

2005-09-16 Thread erik dot edelmann at iki dot fi
: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: erik dot edelmann at iki dot fi CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23924

[Bug fortran/23924] No initialization of derived type pointers/allocatables when allocated

2005-09-16 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16 21:59 --- (In reply to comment #1) Hmm, I get: In file t.f90:2 type t 1 Error: Pointer assignment target is neither TARGET nor POINTER at (1) Oh! I'm terribly sorry; I used a locally modifieded

[Bug fortran/15975] ICE in trans-array.c pointer array initialization stuff

2005-09-16 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16 23:07 --- Patch posted to mailinglist: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01032.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15975

[Bug fortran/16606] gfortran error with a valid derived type definition

2005-09-16 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-16 23:08 --- Patch posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01032.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606

[Bug fortran/15809] ICE Using Pointer Functions

2005-09-06 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-06 21:10 --- With my patch, the reduced testcase by Tobi compiles, but this slightly longer testcase doesn't: $ cat bug7.f90 SUBROUTINE A(p,LEN) CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p

[Bug fortran/15809] ICE Using Pointer Functions

2005-09-02 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-02 11:56 --- (In reply to comment #9) According to Erik Richard's patch for PR15326 fixes one of those two bugs (I assume the latter?), adding the dependency so that we will keep track of this. Yes, it's the latter

[Bug fortran/15809] ICE Using Pointer Functions

2005-08-30 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-08-30 20:28 --- Hmm ... With current version of gfortran (4.1.0 20050830), the reduced testcase by Tobias gives the error message bug.f90: In function 'a': bug.f90:3: internal compiler error: in gfc_trans_deferred_array

[Bug fortran/17740] ICE in gfc_trans_arrayfunc_assign, at fortran/trans-expr.c:2011

2005-08-23 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-08-23 19:54 --- A patch for this bug has been posted to the mailing list: http://gcc.gnu.org/ml/fortran/2005-08/msg00406.html -- What|Removed |Added

[Bug fortran/20363] interface body has incorrect scope

2005-07-28 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-28 09:06 --- (In reply to comment #12) interfaces. This brings me to a question: what is a named interface? I This is a nameless interface, isn't it? module snafu interface subroutine really_snafu

[Bug fortran/22146] ICE when calling ELEMENTAL subroutines

2005-07-28 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-28 11:46 --- (In reply to comment #2) A discussion on the mailing list on this bug here: http://gcc.gnu.org/ml/fortran/2005-06/msg00485.html Sorry about the above. That mailing list discussion is about a different

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

2005-07-28 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-28 11:50 --- This bug has been briefly discussed on the mailing list: http://gcc.gnu.org/ml/fortran/2005-06/msg00485.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925

[Bug fortran/20363] interface body has incorrect scope

2005-07-27 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-27 13:00 --- (In reply to comment #7) Subject: Re: interface body has incorrect scope Paul, do you have any idea what find_special could be intended for? It seems obvious that it does the wrong thing in the case

[Bug fortran/20363] interface body has incorrect scope

2005-07-11 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-11 19:52 --- Erik, Have you checked the parse tree for this? It looks OK, from a very casual look, but the parse tree would be the clincher. After comments from Tobi I posted a new patch here: http

[Bug fortran/22146] ICE when calling ELEMENTAL subroutines

2005-07-01 Thread erik dot edelmann at iki dot fi
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-01 09:49 --- A discussion on the mailing list on this bug here: http://gcc.gnu.org/ml/fortran/2005-06/msg00485.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22146