[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #5 from eedelman at gcc dot gnu dot org 2007-06-03 19:28 --- I never seem to get time to do anything about this bug, so I'll better unassign it from me. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|eedelman at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #3 from eedelman at gcc dot gnu dot org 2007-05-28 15:41 --- (In reply to comment #2) Created an attachment (id=13618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618action=view) [edit] decl.c patch (not check-gfortran tested) Erik, are you still working on this? Officially, yes :-) I.e., I began, but now I haven't had time to look at it for a couple of weeks. Just go ahead and fix it if you are interested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #4 from eedelman at gcc dot gnu dot org 2007-05-28 18:51 --- (In reply to comment #3) (In reply to comment #2) Created an attachment (id=13618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13618action=view) [edit] decl.c patch (not check-gfortran tested) Erik, are you still working on this? Officially, yes :-) I.e., I began, but now I haven't had time to look at it for a couple of weeks. Just go ahead and fix it if you are interested. Just to add one more data point: It's not just procedure arguments that are problematic; it's expression like foo%array(variable) in general, where foo is a PARAMETER. E.g. this piece of code is also rejected: SUBROUTINE cdf_beta() TYPE :: the_distribution INTEGER :: parameters(1) END TYPE the_distribution TYPE (the_distribution), PARAMETER :: the_beta = the_distribution((/0/)) INTEGER :: which, pooh which = 1 pooh = the_beta%parameters(which) END SUBROUTINE cdf_beta erik:~/gcc$ gfortran pr31564.f90 pr31564.f90:12.8: pooh = the_beta%parameters(which) 1 Error: Incompatible ranks 0 and 1 in assignment at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/31564] Error: Type/rank mismatch in argument
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-13 19:39:56 |2007-04-22 18:49:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/30003] Expressions with side effects in array references
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-12-02 22:28 --- I thought I would have time to do something about this bug, but I will not; not in the next few weeks/months. I therefore unassign it from me. My appologies to those who expected to be fixed soon. If it's still unfixed (and unassigned) when I get time again, I'll pick it up again. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|eedelman at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30003
[Bug fortran/30003] New: Expressions with side effects in array references
(This bug was discovered during a discussion on the mailinglist starting here: http://gcc.gnu.org/ml/fortran/2006-11/msg00636.html) This short program erik:~$ cat foo.f90 program foo implicit none integer :: a(5), b(3) b = [ 1, 2, 3 ] a(1:bar(3)) = b contains integer function bar(n) integer, intent(in) :: n print *, 'Hello!' bar = n end function bar end program foo should, when compiled and run, call bar() once, and, hence, print 'hello!' once. But when compiled without -fbounds-check, it doesn't print anything: erik:~$ gfortran foo.f90 erik:~$ a.out This is because gfortran will actually never evaluate the expression of the size of the LHS; it will just assume the LHS has the same size as the RHS. That would be OK if the expression of the size didn't have side effects, but in a case like this, it gives wrong results. If we compile with -fbounds-check, it gets really strange: erik:~$ gfortran foo.f90 -fbounds-check erik:~$ a.out Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Here, bar() is called 13 times! This is because bar() is called separately for every check that the value of bar() is within bounds etc. Again, this would be OK (albeit a bit inefficient) if bar() had no side effects, but with side effects it gives wrong results. Also consider the case where bar():s result value depends on e.g. a SAVEd variable, so that it returns different values every time it's called (even if called with the same argument). That could give _really_ wierd behaviour. -- Summary: Expressions with side effects in array references Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: eedelman at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30003
[Bug fortran/29630] Unclassifiable statement with vector subscripts in initialization
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-11-08 21:14 --- Subject: Bug 29630 Author: eedelman Date: Wed Nov 8 21:14:06 2006 New Revision: 118598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118598 Log: fortran/ 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-11-08 21:14 --- Subject: Bug 29679 Author: eedelman Date: Wed Nov 8 21:14:06 2006 New Revision: 118598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118598 Log: fortran/ 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-11-08 21:19 --- Subject: Bug 29679 Author: eedelman Date: Wed Nov 8 21:19:01 2006 New Revision: 118599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118599 Log: 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29630] Unclassifiable statement with vector subscripts in initialization
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-11-08 21:19 --- Subject: Bug 29630 Author: eedelman Date: Wed Nov 8 21:19:01 2006 New Revision: 118599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118599 Log: 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-11-08 21:19 --- fixed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29630] Unclassifiable statement with vector subscripts in initialization
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-11-08 21:20 --- fixed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29630] Unclassifiable statement with vector subscripts in initialization
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-11-06 22:19 --- Subject: Bug 29630 Author: eedelman Date: Mon Nov 6 22:18:54 2006 New Revision: 118528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118528 Log: fortran/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. * gfortran.dg/initialization_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-11-06 22:19 --- Subject: Bug 29679 Author: eedelman Date: Mon Nov 6 22:18:54 2006 New Revision: 118528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118528 Log: fortran/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. * gfortran.dg/initialization_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29699] ICE in trans-decl.c
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-11-03 23:20 --- Confirmed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-03 23:20:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29699
[Bug fortran/29679] New: Inability to get shapes correct in initializations
In this code, the shape of 'a1(1,1:3)' in the initialization of b1 should be 3, but it is appearantly '1 3', i.e. we fail to remove the '1' from the shape-list. erik:~/gcc$ cat bug.f90 program init implicit none integer, parameter :: a1(2,6) = reshape([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12], [2,6]) integer :: b1(3) = a1(1,1:3) end program init erik:~/gcc$ gfortran bug.f90 In file bug.f90:5 integer :: b1(3) = a1(1,1:3) 1 Error: different shape for Array assignment at (1) on dimension 1 (3/1) -- Summary: Inability to get shapes correct in initializations Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: eedelman at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org OtherBugsDependingO 29630 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug fortran/29630] New: Unclassifiable statement with vector subscripts in initialization
erik:~/gcc$ cat bug.f90 program init implicit none integer, parameter :: a1(6) = [1, 2, 3, 4, 5, 6] integer, parameter :: b1(3) = a1([1,2,3]) end program init erik:~/gcc$ gfortran bug.f90 In file bug.f90:4 integer, parameter :: b1(3) = a1([1,2,3]) 1 Error: Unclassifiable statement at (1) -- Summary: Unclassifiable statement with vector subscripts in initialization Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: eedelman at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29393] Vector subscript rejected
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-10-24 17:01 --- Subject: Bug 29393 Author: eedelman Date: Tue Oct 24 17:01:30 2006 New Revision: 118008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118008 Log: fortran/ 2006-10-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/29393 * expr.c (simplify_parameter_variable): Keep rank of original expression. Testsuite/ 2006-10-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/29393 * gfortran.dg/initialize_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug fortran/29393] Vector subscript rejected
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-10-24 20:40 --- Subject: Bug 29393 Author: eedelman Date: Tue Oct 24 20:40:19 2006 New Revision: 118010 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118010 Log: fortran/ 2006-10-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/29393 * expr.c (simplify_parameter_variable): Keep rank of original expression. testsuite/ 2006-10-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/29393 * gfortran.dg/initialize_2.f90: New. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug fortran/29393] Vector subscript rejected
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-10-24 20:45 --- Subject: Bug 29393 Author: eedelman Date: Tue Oct 24 20:45:29 2006 New Revision: 118011 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118011 Log: fortran/ 2006-10-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/29393 * expr.c (simplify_parameter_variable): Keep rank of original expression. testsuite/ 2006-10-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/29393 * gfortran.dg/initialize_2.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/initialization_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug fortran/29393] Vector subscript rejected
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-08 21:31:18 |2006-10-21 19:26:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug fortran/25217] Derived type dummy argument having intent(out) attribute
--- Comment #7 from eedelman at gcc dot gnu dot org 2006-08-20 16:24 --- (In reply to comment #6) Eric, can this bug be closed as FIXED now? Yes, I would say so. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #19 from eedelman at gcc dot gnu dot org 2006-08-20 17:38 --- Created an attachment (id=12106) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12106action=view) Updated patch Fixes the conflicts with recently committed patches. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Attachment #12060|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/25217] Derived type dummy argument having intent(out) attribute
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-08-19 21:06 --- Subject: Bug 25217 Author: eedelman Date: Sat Aug 19 21:05:59 2006 New Revision: 116261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116261 Log: fortran/ 2006-08-19 Erik Edelmann [EMAIL PROTECTED] PR fortran/25217 * resolve.c (resolve_fl_variable): Set a default initializer for derived types with INTENT(OUT) even if 'flag' is true. * trans-expr.c (gfc_conv_function_call): Insert code to reinitialize INTENT(OUT) arguments of derived type with default initializers. testsuite/ 2006-08-19 Erik Edelmann [EMAIL PROTECTED] PR fortran/25217 * gfortran.dg/derived_init_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/derived_init_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
[Bug fortran/25217] Derived type dummy argument having intent(out) attribute
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-08-19 21:31 --- Subject: Bug 25217 Author: eedelman Date: Sat Aug 19 21:31:47 2006 New Revision: 116262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116262 Log: fortran/ 2006-08-20 Erik Edelmann [EMAIL PROTECTED] PR fortran/25217 * resolve.c (resolve_fl_variable): Set a default initializer for derived types with INTENT(OUT) even if 'flag' is true. * trans-expr.c (gfc_conv_function_call): Insert code to reinitialize INTENT(OUT) arguments of derived type with default initializers. testsuite/ 2006-08-20 Erik Edelmann [EMAIL PROTECTED] PR fortran/25217 * gfortran.dg/derived_init_2.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_init_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
[Bug fortran/28416] ICE on allocatable codes
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-08-14 19:50 --- Fixed on 4.2. (No need to fix it on 4.1, since allocatable dummies aren't supported there.) -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #17 from eedelman at gcc dot gnu dot org 2006-08-10 20:23 --- Created an attachment (id=12060) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12060action=view) New version. Yup, the previous patch wasn't complete (it lacked libgfortran/intrinsics/move_alloc.c); this one should be better. It also addresses the issue pointed out by Thomas Koenig at 2006-05-09. Thanks for testing! -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Attachment #12049|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #15 from eedelman at gcc dot gnu dot org 2006-08-09 21:55 --- Created an attachment (id=12049) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12049action=view) Updated patch Fix the problem reported by Jack. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Attachment #11975|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-07-30 21:38 --- Created an attachment (id=11975) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11975action=view) Latest version Fixed a bunch of problems, added some documentation, and moved MOVE_ALLOC to a file of it's own. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/28416] ICE on allocatable codes
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-07-24 20:16 --- Subject: Bug 28416 Author: eedelman Date: Mon Jul 24 20:15:59 2006 New Revision: 115721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115721 Log: fortran/ 2006-07-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/28416 * trans-array.c (gfc_conv_array_parameter): Give special treatment for ALLOCATABLEs if they are themselves dummy variables. testsuite/ 2006-07-24 Erik Edelmann [EMAIL PROTECTED] PR fortran/28416 * gfortran.dg/allocatable_dummy_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_dummy_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug fortran/25217] Derived type dummy argument having intent(out) attribute
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-09 07:48:40 |2006-07-18 18:28:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
[Bug fortran/28416] ICE on allocatable codes
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-07-18 18:45 --- (In reply to comment #3) The fix, as described on the list, is to be found in the latest patch to PR20541 - the TR15581 story. It includes the corrections to the going-out-of-scope cleanup, as well. I am sorry that I cannot deal with it; I hope that Erik is in a position to do so. I'll see what I can do about it. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-18 10:42:03 |2006-07-18 18:45:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug libfortran/27360] Memory leaks when reading logicals
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-04-30 18:05 --- (In reply to comment #4) Subject: Bug number PR27360 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01152.html Works for me. Thanks for the quick fix! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27360
[Bug libfortran/27360] New: Memory leaks when reading logicals
It seems that the io library is leaking memory when reading logicals, as
demonstrated by the small program below; when running, the program uses more
and more memory until it's killed. I don't see this behaviour with data types
other than logicals.
erik:/var/tmp$ cat memoryleak.f90
program memoryleak
implicit none
logical :: foo
integer :: ios
ios = 0
do while (ios == 0)
read (*, *, iostat=ios) foo
end do
end program memoryleak
erik:/var/tmp$ gfortran memoryleak.f90
erik:/var/tmp$ awk 'BEGIN{while (1) print F}' | a.out
Killed
--
Summary: Memory leaks when reading logicals
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eedelman at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27360
[Bug fortran/20541] TR 15581: ALLOCATABLE components
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/16136] Conflicting attributes ALLOCATABLE, DUMMY (F2003)
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-03-06 12:52 --- Works on mainline (will become 4.2). Will (probably) not be backported to 4.1. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16136
[Bug fortran/16136] Conflicting attributes ALLOCATABLE, DUMMY (F2003)
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-03-05 19:24 --- Subject: Bug 16136 Author: eedelman Date: Sun Mar 5 19:24:48 2006 New Revision: 111741 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111741 Log: fortran/ 2005-03-05 Erik Edelmann [EMAIL PROTECTED] PR fortran/16136 * symbol.c (conf_std): New macro. (check_conflict): Use it to allow ALLOCATABLE dummy arguments for F2003. * trans-expr.c (gfc_conv_function_call): Pass the address of the array descriptor when dummy argument is ALLOCATABLE. * interface.c (compare_allocatable): New function. (compare_actual_formal): Use it. resolve.c (resolve_deallocate_expr, resolve_allocate_expr): Check that INTENT(IN) variables aren't (de)allocated. * gfortran.texi (Fortran 2003 status): List ALLOCATABLE dummy arguments as supported. testsuite/ 2005-03-05 Erik Edelmann [EMAIL PROTECTED] PR fortran/16136 * allocatable_dummy_1.f90: New. * allocatable_dummy_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/allocatable_dummy_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16136
[Bug fortran/16136] Conflicting attributes ALLOCATABLE, DUMMY (F2003)
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16136
[Bug fortran/26409] [4.2 regression] ICE on Assumed shape nested subroutine
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-02-23 14:11 --- For me, on Linux/x86, it works with revision 111200, but ICEs with 111300 and 111387. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug fortran/26409] [4.2 regression] ICE on Assumed shape nested subroutine
--- Comment #7 from eedelman at gcc dot gnu dot org 2006-02-23 22:31 --- A few binary search steps later: Works with revision 111270, fails with 111271. It seems to be related to the patch 2006-02-19 H.J. Lu [EMAIL PROTECTED] * resolve.c (resolve_contained_functions): Call resolve_entries first. (resolve_types): Remove calls to resolve_entries and resolve_contained_functions. (gfc_resolve): Call resolve_contained_functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug fortran/26201] [4.1 regression] __convert_i4_i8 written to a module.
--- Comment #12 from eedelman at gcc dot gnu dot org 2006-02-20 18:50 --- (In reply to comment #11) (In reply to comment #10) With this fix, trunk is now once again able to compile VASP. Too bad it seems to be a bit late to get into 4.1. Maybe 4.1.1? Actually it looks like it was approved for 4.1 (after RC1 was out which it is already): http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01574.html Yep. The patch was small and simple enough that I dared to ask RM Mark M if it was OK. And he said yes, so I intend to commit it to 4.1 later tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug fortran/26201] [4.1 regression] __convert_i4_i8 written to a module.
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-02-20 20:06 --- Subject: Bug 26201 Author: eedelman Date: Mon Feb 20 20:06:49 2006 New Revision: 111311 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111311 Log: fortran/ 2006-02-20 Erik Edelmann [EMAIL PROTECTED] PR fortran/26201 * intrinsic.c (gfc_convert_type_warn): Call gfc_intrinsic_symbol() on the newly created symbol. testsuite/ 2006-02-20 Erik Edelmann [EMAIL PROTECTED] PR fortran/26201 * gfortran.dg/convert_1.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/convert_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug fortran/26201] [4.1/4.2 regression] __convert_i4_i8 written to a module.
--- Comment #9 from eedelman at gcc dot gnu dot org 2006-02-19 17:23 --- Subject: Bug 26201 Author: eedelman Date: Sun Feb 19 17:23:07 2006 New Revision: 111270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111270 Log: fortran/ 2006-02-19 Erik Edelmann [EMAIL PROTECTED] PR fortran/26201 * intrinsic.c (gfc_convert_type_warn): Call gfc_intrinsic_symbol() on the newly created symbol. testsuite/ 2006-02-19 Erik Edelmann [EMAIL PROTECTED] PR fortran/26201 * gfortran.dg/convert_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/convert_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug fortran/26201] [4.1/4.2 regression] __convert_i4_i8 written to a module.
--- Comment #7 from eedelman at gcc dot gnu dot org 2006-02-18 19:52 --- Here's a small one-liner patch that I think fixes the bug. I'll post it to the mailing list later tonight if/when it passes regression testing. Index: gcc/fortran/intrinsic.c === --- gcc/fortran/intrinsic.c (revision 111236) +++ gcc/fortran/intrinsic.c (working copy) @@ -3428,6 +3428,7 @@ gfc_convert_type_warn (gfc_expr * expr, new-symtree-n.sym-attr.elemental = 1; new-symtree-n.sym-attr.pure = 1; new-symtree-n.sym-attr.referenced = 1; + gfc_intrinsic_symbol(new-symtree-n.sym); gfc_commit_symbol (new-symtree-n.sym); *expr = *new; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug fortran/26201] [4.1/4.2 regression] __convert_i4_i8 written to a module.
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-02-16 14:12 --- With Philippe's testcase, I can reproduce the problem on my system now. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug fortran/26201] [4.1/4.2 regression] __convert_i4_i8 written to a module.
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-02-15 21:20 --- I can't reproduce the problem with MUMPS on Linux/x86 (mainline revision 11, 4.1 revision 110989). Assuming that Steve used a 64 bit processor, it seems that for this code the bug is visible only on 64 bit systems. (The fact that problem occurs for the function __convert_i4_i8 also indicates that, since conversions from 4 byte to 8 byte integers happens more often on 64 bit systems than on 32 bit ones.) The VASP code I do not have available, so I can't test that one. (Since it is about reals rather than integers, it's not unlikely that that would be reproducable on 32 bit systems.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #7 from eedelman at gcc dot gnu dot org 2006-02-14 17:34 --- Subject: Bug 25806 Author: eedelman Date: Tue Feb 14 17:34:07 2006 New Revision: 110989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110989 Log: fortran/ 2006-02-14 Erik Edelmann [EMAIL PROTECTED] PR fortran/25806 * trans-array.c (gfc_trans_allocate_array_storage): New argument dealloc; free the temporary only if dealloc is true. (gfc_trans_allocate_temp_array): New argument bool dealloc, to be passed onwards to gfc_trans_allocate_array_storage. (gfc_trans_array_constructor, gfc_conv_loop_setup): Update call to gfc_trans_allocate_temp_array. * trans-array.h (gfc_trans_allocate_temp_array): Update function prototype. * trans-expr.c (gfc_conv_function_call): Set new argument 'dealloc' to gfc_trans_allocate_temp_array to false in case of functions returning pointers. (gfc_trans_arrayfunc_assign): Return NULL for functions returning pointers. testsuite/ 2006-02-14 Erik Edelmann [EMAIL PROTECTED] PR fortran/25806 * gfortran.dg/ret_pointer_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/ret_pointer_2.f90 - copied unchanged from r110893, trunk/gcc/testsuite/gfortran.dg/ret_pointer_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-array.h branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #8 from eedelman at gcc dot gnu dot org 2006-02-14 20:31 --- Fixed on 4.1 and mainline. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-02-12 17:34 --- Subject: Bug 25806 Author: eedelman Date: Sun Feb 12 17:34:15 2006 New Revision: 110893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110893 Log: fortran/ 2006-02-12 Erik Edelmann [EMAIL PROTECTED] PR fortran/25806 * trans-array.c (gfc_trans_allocate_array_storage): New argument dealloc; free the temporary only if dealloc is true. (gfc_trans_allocate_temp_array): New argument bool dealloc, to be passed onwards to gfc_trans_allocate_array_storage. (gfc_trans_array_constructor, gfc_conv_loop_setup): Update call to gfc_trans_allocate_temp_array. * trans-array.h (gfc_trans_allocate_temp_array): Update function prototype. * trans-expr.c (gfc_conv_function_call): Set new argument 'dealloc' to gfc_trans_allocate_temp_array to false in case of functions returning pointers. (gfc_trans_arrayfunc_assign): Return NULL for functions returning pointers. testsuite/ 2006-02-12 Erik Edelmann [EMAIL PROTECTED] PR fortran/25806 * gfortran.dg/ret_pointer_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ret_pointer_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug fortran/26201] [4.1/4/2 regression, fortran] __convert_i4_i8 written to a module.
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-02-09 19:12 --- Possibly related to the patch for PR 25716 (committed to mainline 2005-01-25). -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26201
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-02-06 21:51 --- A slightly improved form of the patch attached here earlier has been posted to the mailing list for review: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00394.html -- eedelman at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg00394.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-02-04 17:11 --- If I compile the original testcase with current mainline (revision 110561), the binary dies on execution with *** glibc detected *** double free or corruption (out): 0xbfc9d020 *** Aborted If I remove the line print*,x(5) the program runs and outputs 0.00 0.00 0.00 0.00 0.00 This trivial patch fixes the latter problem: - Index: trans-expr.c === --- trans-expr.c(revision 110590) +++ trans-expr.c(working copy) @@ -2912,6 +2912,9 @@ gfc_trans_arrayfunc_assign (gfc_expr * e if (gfc_ref_needs_temporary_p (expr1-ref)) return NULL; + if (expr2-symtree-n.sym-attr.pointer) +return NULL; + /* Check that no LHS component references appear during an array reference. This is needed because we do not have the means to span any arbitrary stride with an array descriptor. This check I'll try to see if I can fix the other problem too. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug fortran/25806] problems with functions returning array pointers?
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-02-04 20:52 --- Created an attachment (id=10777) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10777action=view) Patch to fix the bug. We also get into trouble if we try to pass the result of a pointer-to-array returning funtion as an argument to another procedure (e.g. call a_suborutine (x(5)) ) The problem, both for this case and print *, x(5) is that we try to free the temporary used to hold the result. This we mustn't do, since the temporary will be just a shallow copy of the resulting array. The attached patch fixes these problems, but is not yet well tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
[Bug fortran/26041] FORTRAN compiler won't compile the valid code
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-02-01 11:29 --- (In reply to comment #2) How about this? As far as I can see, this latter testcase is valid code. Confirmed. An additional comment: If I change the call to the generic subroutine bar_ in xxx to a call to the specific subroutine bar, I get In file hum.f90:26 call bar(self, z) 1 Error: Type/rank mismatch in argument 'self' at (1) which is also wrong. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2006-02-01 11:29:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug fortran/26038] FORTRAN segfault
--- Comment #8 from eedelman at gcc dot gnu dot org 2006-01-31 11:12 --- (In reply to comment #7) The original code looks like subroutine foo(self) character(*) :: self pointer :: self nullify(self) allocate(self) self = end subroutine Is this code valid? How can I make it valid? I think it's valid. (The length of 'self', which is needed at allocation, should be passed to foo by the caller. For example, the code below should print 5 10 on execution: --- module moo contains subroutine foo(self) character(*) :: self pointer :: self nullify(self) allocate(self) print *, len(self) end subroutine end module moo program hum use moo character(5), pointer :: p character(10), pointer :: q call foo(p) call foo(q) end program hum - ) -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-31 11:12:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-01-31 20:45 --- Subject: Bug 24266 Author: eedelman Date: Tue Jan 31 20:45:40 2006 New Revision: 110447 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110447 Log: fortran/ 2005-01-31 Erik Edelmann [EMAIL PROTECTED] PR fortran/24266 * trans-io.c (set_internal_unit): Check the rank of the expression node itself instead of its symbol. testsuite/ 2005-01-31 Erik Edelmann [EMAIL PROTECTED] PR fortran/24266 * gfortran.dg/arrayio_derived_2.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/arrayio_derived_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-io.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-01-31 21:19 --- Fixed on mainline and 4.1 -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-01-30 22:24 --- Subject: Bug 24266 Author: eedelman Date: Mon Jan 30 22:23:57 2006 New Revision: 110412 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110412 Log: fortran/ 2005-01-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/24266 * trans-io.c (set_internal_unit): Check the rank of the expression node itself instead of its symbol. testsuite/ 2005-01-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/24266 * gfortran.dg/arrayio_derived_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/arrayio_derived_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #18 from eedelman at gcc dot gnu dot org 2006-01-27 17:19 --- Subject: Bug 25716 Author: eedelman Date: Fri Jan 27 17:19:36 2006 New Revision: 110302 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110302 Log: fortran/ 2005-01-27 Erik Edelmann [EMAIL PROTECTED] PR fortran/25716 * symbol.c (free_old_symbol): New function. (gfc_commit_symbols): Use it. (gfc_commit_symbol): New function. (gfc_use_derived): Use it. * gfortran.h: Add prototype for gfc_commit_symbol. * intrinsic.c (gfc_find_function): Search in 'conversion' if not found in 'functions'. (gfc_convert_type_warn): Add a symtree to the new expression node, and commit the new symtree-n.sym. * resolve.c (gfc_resolve_index): Make sure typespec is properly initialized. testsuite/ 2005-01-27 Erik Edelmann [EMAIL PROTECTED] PR fortran/25716 * gfortran.dg/char_result_11.f90: Make it sensitive to PR 25716 on 32-bit systems too. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #17 from eedelman at gcc dot gnu dot org 2006-01-25 20:46 --- Subject: Bug 25716 Author: eedelman Date: Wed Jan 25 20:46:29 2006 New Revision: 110225 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110225 Log: fortran/ 2005-01-25 Erik Edelmann [EMAIL PROTECTED] PR fortran/25716 * symbol.c (free_old_symbol): New function. (gfc_commit_symbols): Use it. (gfc_commit_symbol): New function. (gfc_use_derived): Use it. * gfortran.h: Add prototype for gfc_commit_symbol. * intrinsic.c (gfc_find_function): Search in 'conversion' if not found in 'functions'. (gfc_convert_type_warn): Add a symtree to the new expression node, and commit the new symtree-n.sym. * resolve.c (gfc_resolve_index): Make sure typespec is properly initialized. testsuite/ 2005-01-25 Erik Edelmann [EMAIL PROTECTED] PR fortran/25716 * gfortran.dg/char_result_11.f90: Make it sensitive to PR 25716 on 32-bit systems too. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_result_11.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #10 from eedelman at gcc dot gnu dot org 2006-01-14 15:38 --- (In reply to comment #9) Attached a patch that fixes the problem on x86 and a cross-compiler to sparc64. I intend to contemplate it a bit further before I post it to the list for review. It doesn't seem to work for me (on the 4.1 branch): Executing on host: /opt/build/eric/gcc-4_1-branch/gcc/testsuite/../gfortran -B/opt/build/eric/gcc-4_1-branch/gcc/testsuite/../ /home/eric/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90 -O -pedantic-errors -S -o char_result_11.s(timeout = 300) /home/eric/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90: In function 'MAIN__': /home/eric/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90:101:error: void value not ignored as it ought to be /home/eric/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90:105:error: void value not ignored as it ought to be /home/eric/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90:107:error: void value not ignored as it ought to be /home/eric/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90:107:error: void value not ignored as it ought to be Bummer. Actually, I see that problem as well in my cross compiler. I must have been sloppy in my testing. I will attach an improved patch shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #11 from eedelman at gcc dot gnu dot org 2006-01-14 15:40 --- Created an attachment (id=10640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10640action=view) Improved patch -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Attachment #10639|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #13 from eedelman at gcc dot gnu dot org 2006-01-14 23:22 --- Created an attachment (id=10645) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10645action=view) Improved patch After some more testing, I found out that the previous patch still failed in some cases. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Attachment #10640|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #8 from eedelman at gcc dot gnu dot org 2006-01-14 00:12 --- Created an attachment (id=10639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10639action=view) Patch to fix the bug. Attached a patch that fixes the problem on x86 and a cross-compiler to sparc64. I intend to contemplate it a bit further before I post it to the list for review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-01-10 12:32 --- According to the mail http://gcc.gnu.org/ml/fortran/2006-01/msg00123.html, it fails on x86-64 and SPARC64 too. I don't see the error on Linux/x86. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25093] PUBLIC function of PRIVATE type
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-01-09 16:19 --- Subject: Bug 25093 Author: eedelman Date: Mon Jan 9 16:19:22 2006 New Revision: 109500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109500 Log: fortran/ 2005-01-09 Erik Edelmann [EMAIL PROTECTED] PR fortran/25093 * resolve.c (resolve_fntype): Check that PUBLIC functions aren't of PRIVATE type. testsuite/ 2005-01-09 Erik Edelmann [EMAIL PROTECTED] PR fortran/25093 * gfortran.dg/private_type_4.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/private_type_4.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25093
[Bug fortran/25093] PUBLIC function of PRIVATE type
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-01-09 16:21 --- Fixed on 4.1 and mainline. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25093
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-01-10 00:03 --- (In reply to comment #5) The limit was rose but we should be able to do better. Indeed. But the problem is not trivial. For a case like above, where the array is a variable, we can translate it to (program|function|subroutine) stuff integer :: i_do integer :: i(11) logical, save :: _i_initialized = .FALSE. if (.not._i_initialized) then i = (/ (i_do, i_do=1,11) /) _i_initialized = .TRUE. end if write (*,*) i end (program|function|subroutine) stuff (The _i_initialized variable is not needed in a main program, but it is in a procedure.) This far it isn't a huge problem, but when 'i' is a PARAMETER it gets more complicated. PARAMETERs are meant to be compile time constants. Let's say we have e.g. subroutine stuff integer :: i_do integer, parameter :: i(11) = whatever real(kind=i(1975)) :: a ... end subroutine stuff I can't at the moment think of a situation where we would need the entire array at the stage of compilation, but at least we need to be able to access individual elements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug fortran/25093] PUBLIC function of PRIVATE type
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-01-08 17:53 --- Subject: Bug 25093 Author: eedelman Date: Sun Jan 8 17:52:57 2006 New Revision: 109474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109474 Log: fortran/ 2005-01-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/25093 * resolve.c (resolve_fntype): Check that PUBLIC functions aren't of PRIVATE type. testsuite/ 2005-01-08 Erik Edelmann [EMAIL PROTECTED] PR fortran/25093 * gfortran.dg/private_type_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/private_type_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25093
[Bug fortran/25093] PUBLIC function of PRIVATE type
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-01-08 00:14 --- Working on a patch. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org Keywords|diagnostic |accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25093
[Bug fortran/25693] New: Missleading line number for 'unused variable' warnings
The line number given in warning messages for unused variables in a procedure with an internal procedure, is that of the first line of the internal procedure, instead of the host procedure. I find this a bit confusing: erik:~$ cat -n swap.f90 1 subroutine sort() 2 real :: a 3 4 contains 5 6 subroutine swap() 7 end subroutine swap 8 9 end subroutine sort erik:~$ gfortran -Wall -c swap.f90 swap.f90: In function 'sort': swap.f90:6: warning: unused variable 'a' (The optimal thing would of course be to give the line where the variable was declared, but since a variable can have several declarations (e.g. one for type and a separate one for dimension), this is not allways possible.) -- Summary: Missleading line number for 'unused variable' warnings Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25693
[Bug fortran/23675] ICE in gfc_finish_var_decl (string manipulation)
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-01-05 21:10 --- Subject: Bug 23675 Author: eedelman Date: Thu Jan 5 21:10:05 2006 New Revision: 109389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109389 Log: fortran/ 2006-01-05 Erik Edelmann [EMAIL PROTECTED] PR fortran/23675 * expr.c (gfc_expr_set_symbols_referenced): New function. * gfortran.h: Add a function prototype for it. * resolve.c (resolve_function): Use it for use associated character functions lengths. * expr.c, gfortran.h, resolve.c: Updated copyright years. testsuite/ 2006-01-05 Erik Edelmann [EMAIL PROTECTED] PR fortran/23675 gfortran.dg/char_result_11.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/char_result_11.f90 - copied unchanged from r109368, trunk/gcc/testsuite/gfortran.dg/char_result_11.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23675
[Bug fortran/23675] ICE in gfc_finish_var_decl (string manipulation)
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-01-05 21:17 --- Fixed on 4.1 and mainline, -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23675
[Bug fortran/23675] ICE in gfc_finish_var_decl (string manipulation)
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-01-04 20:41 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00079.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23675
[Bug fortran/23675] ICE in gfc_finish_var_decl (string manipulation)
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-01-05 00:22 --- Subject: Bug 23675 Author: eedelman Date: Thu Jan 5 00:22:39 2006 New Revision: 109368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109368 Log: 2006-01-05 Erik Edelmann [EMAIL PROTECTED] PR fortran/23675 * expr.c (gfc_expr_set_symbols_referenced): New function. * gfortran.h: Add a function prototype for it. * resolve.c (resolve_function): Use it for use associated character functions lengths. * expr.c, gfortran.h, resolve.c: Updated copyright years. testsuite/ 2006-01-05 Erik Edelmann [EMAIL PROTECTED] PR fortran/23675 gfortran.dg/char_result_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/char_result_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23675
[Bug fortran/25628] New: Runtime error on write to string of global variable length
$ cat bug.f90 module foo implicit none integer :: strlength = 20 contains subroutine bar() character(len=strlength) :: str write (str, *) 0 end subroutine bar end module foo program test_foo use foo implicit none strlength = 10 call bar() end program test_foo $ gfortran bug.f90 $ a.out At line 10 of file bug.f90 Fortran runtime error: End of record I see this behaviour with both 4.1 and mainline. (With 4.0 I get a segmentation fault at runtime instead.) -- Summary: Runtime error on write to string of global variable length Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25628
[Bug libfortran/25628] Runtime error on write to string of global variable length
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-01-01 19:27 --- (In reply to comment #1) Is this really a bug, changing the subroutine to: subroutine bar() character(len=10) :: str write (str, *) 0 end subroutine bar Also cause the problem, if I increase the size by a couple, it works. I think you are right. Closing as INVALID. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25628
[Bug fortran/25396] Operator overloading for array-valued functions gets shape incorrectly
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-12-30 15:02 --- Subject: Bug 25396 Author: eedelman Date: Fri Dec 30 15:02:44 2005 New Revision: 109171 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109171 Log: fortran/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * trans-decl.c(gfc_get_extern_function_decl): Don't set DECL_IS_PURE (fndecl) = 1 for return-by-reference functions. fortran/PR 25396 * interface.c (gfc_extend_expr): Initialize e-value.function.name to NULL. testsuite/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * gfortran-dg/pure_byref_3.f90: New. fortran/PR 25396 * gfortran.dg/userdef_operator_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pure_byref_3.f90 trunk/gcc/testsuite/gfortran.dg/userdef_operator_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25396
[Bug fortran/22607] Elemental character functions don't work
--- Comment #10 from eedelman at gcc dot gnu dot org 2005-12-30 15:02 --- Subject: Bug 22607 Author: eedelman Date: Fri Dec 30 15:02:44 2005 New Revision: 109171 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109171 Log: fortran/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * trans-decl.c(gfc_get_extern_function_decl): Don't set DECL_IS_PURE (fndecl) = 1 for return-by-reference functions. fortran/PR 25396 * interface.c (gfc_extend_expr): Initialize e-value.function.name to NULL. testsuite/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * gfortran-dg/pure_byref_3.f90: New. fortran/PR 25396 * gfortran.dg/userdef_operator_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pure_byref_3.f90 trunk/gcc/testsuite/gfortran.dg/userdef_operator_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug fortran/25396] Operator overloading for array-valued functions gets shape incorrectly
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-12-30 15:07 --- Subject: Bug 25396 Author: eedelman Date: Fri Dec 30 15:07:48 2005 New Revision: 109172 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109172 Log: fortran/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * trans-decl.c(gfc_get_extern_function_decl): Don't set DECL_IS_PURE (fndecl) = 1 for return-by-reference functions. fortran/PR 25396 * interface.c (gfc_extend_expr): Initialize e-value.function.name to NULL. testsuite/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * gfortran-dg/pure_byref_3.f90: New. fortran/PR 25396 * gfortran.dg/userdef_operator_1.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_byref_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/userdef_operator_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25396
[Bug fortran/22607] Elemental character functions don't work
--- Comment #11 from eedelman at gcc dot gnu dot org 2005-12-30 15:07 --- Subject: Bug 22607 Author: eedelman Date: Fri Dec 30 15:07:48 2005 New Revision: 109172 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109172 Log: fortran/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * trans-decl.c(gfc_get_extern_function_decl): Don't set DECL_IS_PURE (fndecl) = 1 for return-by-reference functions. fortran/PR 25396 * interface.c (gfc_extend_expr): Initialize e-value.function.name to NULL. testsuite/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * gfortran-dg/pure_byref_3.f90: New. fortran/PR 25396 * gfortran.dg/userdef_operator_1.f90: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_byref_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/userdef_operator_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug fortran/22607] Elemental character functions don't work
--- Comment #12 from eedelman at gcc dot gnu dot org 2005-12-30 15:11 --- Subject: Bug 22607 Author: eedelman Date: Fri Dec 30 15:11:15 2005 New Revision: 109173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109173 Log: fortran/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * trans-decl.c(gfc_get_extern_function_decl): Don't set DECL_IS_PURE (fndecl) = 1 for return-by-reference functions. fortran/PR 25396 * interface.c (gfc_extend_expr): Initialize e-value.function.name to NULL. testsuite/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * gfortran-dg/pure_byref_3.f90: New. fortran/PR 25396 * gfortran.dg/userdef_operator_1.f90: New. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pure_byref_3.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/userdef_operator_1.f90 Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/interface.c branches/gcc-4_0-branch/gcc/fortran/trans-decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug fortran/25396] Operator overloading for array-valued functions gets shape incorrectly
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-12-30 15:11 --- Subject: Bug 25396 Author: eedelman Date: Fri Dec 30 15:11:15 2005 New Revision: 109173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109173 Log: fortran/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * trans-decl.c(gfc_get_extern_function_decl): Don't set DECL_IS_PURE (fndecl) = 1 for return-by-reference functions. fortran/PR 25396 * interface.c (gfc_extend_expr): Initialize e-value.function.name to NULL. testsuite/ 2005-12-30 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * gfortran-dg/pure_byref_3.f90: New. fortran/PR 25396 * gfortran.dg/userdef_operator_1.f90: New. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/pure_byref_3.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/userdef_operator_1.f90 Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/interface.c branches/gcc-4_0-branch/gcc/fortran/trans-decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25396
[Bug fortran/22607] Elemental character functions don't work
--- Comment #13 from eedelman at gcc dot gnu dot org 2005-12-30 15:16 --- Now it should be fixed for all cases. Re-closing. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug fortran/23675] ICE in gfc_finish_var_decl (string manipulation)
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-12-30 22:44 --- The testcase compiles without error messages in 4.2.0 20051230 (I haven't tried with 4.1 or 4.0 yet). However, if I try to use IntToChar2 from another program unit, I get another error, so there's still a bug somewhere. E.g. for the program program test use cutils implicit none character(25) :: str str = IntToChar2(3) end program test I get erik:/home/gcc/head/test$ gfortran 23675.f90 23675.f90: In function 'MAIN__': 23675.f90:22: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:819 Possible workaround at the moment: Declare maxStringLength to be a PARAMETER -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23675
[Bug fortran/25396] Operator overloading for array-valued functions gets shape incorrectly
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-12-29 20:01 --- Working on a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25396
[Bug fortran/22607] Elemental character functions don't work
--- Comment #8 from eedelman at gcc dot gnu dot org 2005-12-29 20:52 --- It seems my patch fixed pure by-reference functions only for internal functions. Pure by-ref. module functions still doesn't work: erik:/home/gcc/head/test$ cat pure_byref_3.f90 module huj_mod contains pure function huj() integer :: huj(3) huj = (/1, 2, 3/) end function huj end module huj_mod program pure_byref_3 use huj_mod print *, huj() end program pure_byref_3 erik:/home/gcc/head/test$ gfortran pure_byref_3.f90 erik:/home/gcc/head/test$ a.out -1080540352 -1209060288 -1209060282 -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug fortran/25396] Operator overloading for array-valued functions gets shape incorrectly
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-12-29 20:57
---
I think this simple one-liner fixes the bug:
Index: interface.c
===
--- interface.c (revision 109139)
+++ interface.c (working copy)
@@ -1718,6 +1718,7 @@ gfc_extend_expr (gfc_expr * e)
e-value.function.actual = actual;
e-value.function.esym = NULL;
e-value.function.isym = NULL;
+ e-value.function.name = NULL;
if (gfc_pure (NULL) !gfc_pure (sym))
{
but because of PR 22607, I can't test it properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25396
[Bug fortran/22607] Elemental character functions don't work
--- Comment #9 from eedelman at gcc dot gnu dot org 2005-12-29 22:35 --- Patch posted here: http://gcc.gnu.org/ml/fortran/2005-12/msg00511.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug fortran/25396] Operator overloading for array-valued functions gets shape incorrectly
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-12-27 19:26 --- Confirmed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-27 19:26:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25396
[Bug fortran/25385] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1235
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-12-27 19:41 --- (In reply to comment #2) Created an attachment (id=10467) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10467action=view) [edit] m_mb_control.mod Fortran module needed by matiere.f When I try to compile matiere.f, with m_mb_control.mod in the cwd, I get erik:/var/tmp$ gfortran matiere.f Fatal Error: Reading module m_mb_control at line 125 column 2: Expected integer It seems to me that the .mod-file is corrupted. Could you send the source code of the module too, instead of just the .mod file? -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25385
[Bug fortran/25385] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1235
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-12-27 21:31 --- (In reply to comment #4) It seems to me that the .mod-file is corrupted. Could you send the source code of the module too, instead of just the .mod file? Never mind. I managed to reduce it to something that doesn't depend on any modules. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2005-12-27 21:31:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25385
[Bug fortran/25385] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1235
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2005-12-27 21:31:04 |2005-12-27 21:31:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25385
[Bug fortran/25385] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1235
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-12-27 21:53 --- (In reply to comment #5) Never mind. I managed to reduce it to something that doesn't depend on any modules. The reduced testcase is here: SUBROUTINE MATIERE() REAL :: XSNAK(2) XSNAK((/ 1, 2 /)) = 0.0 END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25385
[Bug fortran/18883] ICE in gfc_finish_var_decl
--- Comment #10 from eedelman at gcc dot gnu dot org 2005-12-27 22:09 --- (In reply to comment #9) Fixed on 4.1. Not yet fixed on 4.0, because it depends on PR 15326 which hasn't been fixed for 4.0. PR 15326 will not be fixed for 4.0, I presume, so neither will this. Thus I consider this as fixed it is going to get. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18883
[Bug fortran/25532] [gfortran, regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:269
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-12-26 21:20 --- Here's a reduced testcase: module ModelParams implicit none type ReionizationParams real :: fraction end type ReionizationParams type CAMBparams type(ReionizationParams) :: Reion end type CAMBparams type(CAMBparams) CP end module ModelParams module ThermoData use ModelParams implicit none contains subroutine inithermo() use ModelParams if (0 CP%Reion%fraction) then end if end subroutine inithermo subroutine SetTimeSteps if (0 CP%Reion%fraction) then end if end subroutine SetTimeSteps end module ThermoData -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25532
[Bug fortran/25532] [gfortran, regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:269
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-12-23 17:58 --- (In reply to comment #2) So it seems the problem was introduced within the last 24 hours. To be a bit more precise: works with revision 108902, ICE:s with revision 108943. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25532
[Bug fortran/25532] [gfortran, regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:269
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-12-22 19:49 --- With GNU Fortran 95 (GCC) 4.2.0 20051221 it works (I get a lot of 'undefined reference' messages, but no ICE:s). But with 20051222 I get the same ICE message that Martin gets. So it seems the problem was introduced within the last 24 hours. Confiremd. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-22 19:49:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25532
[Bug fortran/25423] Error with nested where statements
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-12-21 11:58 --- Subject: Bug 25423 Author: eedelman Date: Wed Dec 21 11:58:09 2005 New Revision: 108902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108902 Log: fortran/ 2005-12-21 Erik Edelmann [EMAIL PROTECTED] PR fortran/25423 * parse.c (parse_where_block): break instead of fall through after parsing nested WHERE construct. testsuite/ 2005-12-21 Erik Edelmann [EMAIL PROTECTED] PR fortran/25423 gfortran.dg/where_nested_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/where_nested_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25423
