[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #17 from domob at gcc dot gnu dot org 2008-11-13 17:16 --- Unassigning myself. Mikael will probably want to take the missing part on with his pending patch :) -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|domob at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #1 from domob at gcc dot gnu dot org 2008-11-15 08:30 --- I'll take this one on. Reading quickly through the thread gives me the impression that it is not 100% agreed upon that this should in every case be an error (although of course nearly so). But I guess we want to reject it anyways, don't we? Or should we do something like warn on std=gnu and reject for std=f95? -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-15 08:30:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/38152] New: ICE for procedure pointer assignment
The following (possibly invalid) program ICEs: MODULE m IMPLICIT NONE PROCEDURE(test), POINTER :: procptr CONTAINS SUBROUTINE test () IMPLICIT NONE CALL bar (test) procptr => test END SUBROUTINE test END MODULE m The ICE is however not related to the missing RECURSIVE and can be reproduced with valid code, see below. -- Summary: ICE for procedure pointer assignment Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #1 from domob at gcc dot gnu dot org 2008-11-16 09:27 --- Daniel Kraft wrote: > > I'm working out a test-case for PR 37779 and came across the following > > program, which ICEs for today's trunk gfortran: > > > > SUBROUTINE test () > > IMPLICIT NONE > > procptr => test If one moves the procedure-pointer declaration in the subroutine, it works. The difference of the -fdump-tree-original/gimple is: + void (*) (void) procptr; The failing assert in make_decl_rtl is: /* A weak alias has TREE_PUBLIC set but not the other bits. */ gcc_assert (TREE_CODE (decl) != VAR_DECL || TREE_STATIC (decl) || TREE_PUBLIC (decl) || DECL_EXTERNAL (decl) || DECL_REGISTER (decl)); > > Is this already a known bug? Sorry that I don't have an overview... > > If not, I'll file a report. Please do so, I think it is not known. By the way, the following also fails: module m procedure(), pointer :: procptr end module m use m external foo procptr => foo end with Error: 'procptr' in the pointer assignment at (1) cannot be an l-value since it is a procedure I think the "proc_ptr" attribute is not properly saved in the .mod file. Tobias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #4 from domob at gcc dot gnu dot org 2008-11-24 13:12 --- Subject: Bug 37779 Author: domob Date: Mon Nov 24 13:10:37 2008 New Revision: 142158 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142158 Log: 2008-11-24 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37779 * resolve.c (resolve_procedure_expression): New method. (resolve_variable): Call it. (resolve_actual_arglist): Call gfc_resolve_expr for procedure arguments. 2008-11-24 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37779 * gfortran.dg/c_funloc_tests.f03: Added missing `RECURSIVE'. * gfortran.dg/c_funloc_tests_2.f03: Ditto. * gfortran.dg/recursive_check_4.f03: New test. * gfortran.dg/recursive_check_5.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_check_4.f03 trunk/gcc/testsuite/gfortran.dg/recursive_check_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_funloc_tests.f03 trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_2.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/38252] New: Empty function with CONTAINS triggers Internal Error
This program gives an "Internal Error" pointing at the CONTAINS: INTEGER FUNCTION test () CONTAINS END FUNCTION test It works with gfortran 4.3.1. Replacing the FUNCTION by a SUBROUTINE gets rid of the error. Additionally, this program also works: FUNCTION test () INTEGER :: test CONTAINS END FUNCTION test -- Summary: Empty function with CONTAINS triggers Internal Error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #5 from domob at gcc dot gnu dot org 2008-11-30 20:37 --- Subject: Bug 37779 Author: domob Date: Sun Nov 30 20:36:10 2008 New Revision: 142299 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142299 Log: 2008-11-30 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37779 * gfortran.h (struct gfc_entry_list): Fixed typo in comment. * resolve.c (is_illegal_recursion): New method. (resolve_procedure_expression): Use new is_illegal_recursion instead of direct check and handle function symbols correctly. (resolve_actual_arglist): Removed useless recursion check. (resolve_function): Use is_illegal_recursion instead of direct check. (resolve_call): Ditto. 2008-11-30 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37779 * gfortran.dg/recursive_check_1.f: Changed expected error message to the more general new one. * gfortran.dg/recursive_check_2.f90: Ditto. * gfortran.dg/entry_18.f90: Ditto. * gfortran.dg/recursive_check_4.f03: Do "the same" check also for FUNCTIONS, as this is different in details from SUBROUTINES. * gfortran.dg/recursive_check_6.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_check_6.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/entry_18.f90 trunk/gcc/testsuite/gfortran.dg/recursive_check_1.f trunk/gcc/testsuite/gfortran.dg/recursive_check_2.f90 trunk/gcc/testsuite/gfortran.dg/recursive_check_4.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #6 from domob at gcc dot gnu dot org 2008-11-30 20:40 --- This second commit detects cases like the one mentioned by Tobias in comment #2 on trunk/4.4 I'm going to work on a optional runtime-recursion checking feature now as last part for this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/32626] Run-time check for recursive functions
--- Comment #1 from domob at gcc dot gnu dot org 2008-12-01 07:25 --- Taking this on, as addition to PR 37779 about compile-time recursion checking. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-10-25 15:23:24 |2008-12-01 07:25:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32626
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #7 from domob at gcc dot gnu dot org 2008-12-01 07:27 --- Closing, for runtime-recursion checking I accepted PR 32626. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/32626] Run-time check for recursive functions
--- Comment #2 from domob at gcc dot gnu dot org 2008-12-07 16:17 --- Unassigning myself, Tobias has a working patch posted for 4.5. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|domob at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32626
[Bug fortran/37423] Fortran 2003: DEFERRED bindings not yet implemented
--- Comment #1 from domob at gcc dot gnu dot org 2008-12-07 17:12 --- A proposed patch for 4.5 can be found at: http://gcc.gnu.org/ml/fortran/2008-12/msg00109.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37423
[Bug fortran/38137] MERGE: -fbounds-check runtime check for same string length
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-07 17:42:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38137
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #6 from domob at gcc dot gnu dot org 2008-12-10 08:44 --- I did post it to the mailing list some time ago and there was a little discussion, IIRC, but no definite "review" or OK for it. But I can re-post it (or we welcome your opinions), of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug fortran/38137] MERGE: -fbounds-check runtime check for same string length
--- Comment #2 from domob at gcc dot gnu dot org 2008-12-17 10:18 --- Added the runtime check for -fbounds-check. Thus fixed on trunk (4.4), closing. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38137
[Bug fortran/31822] Missing run-time bound checks for character pointer => target
--- Comment #3 from domob at gcc dot gnu dot org 2008-12-17 10:14 --- Thanks for the analysis, Tobias, I will then take this on as supplement to PR 38137. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-09 22:52:00 |2008-12-17 10:14:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/38137] MERGE: -fbounds-check runtime check for same string length
--- Comment #1 from domob at gcc dot gnu dot org 2008-12-17 10:17 --- Subject: Bug 38137 Author: domob Date: Wed Dec 17 10:16:28 2008 New Revision: 142791 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142791 Log: 2008-12-17 Daniel Kraft PR fortran/38137 * trans-intrinsic.c (conv_same_strlen_check): New method. (gfc_conv_intrinsic_merge): Call it here to actually do the check. 2008-12-17 Daniel Kraft PR fortran/38137 * gfortran.dg/merge_char_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/merge_char_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38137
[Bug fortran/31822] Missing run-time bound checks for character pointer => target
--- Comment #4 from domob at gcc dot gnu dot org 2008-12-18 10:07 --- Subject: Bug 31822 Author: domob Date: Thu Dec 18 10:05:54 2008 New Revision: 142808 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142808 Log: 2008-12-18 Daniel Kraft PR fortran/31822 * gfortran.h (gfc_check_same_strlen): Made public. * trans.h (gfc_trans_same_strlen_check): Made public. * check.c (gfc_check_same_strlen): Made public and adapted error message output to be useful not only for intrinsics. (gfc_check_merge): Adapt to gfc_check_same_strlen change. * expr.c (gfc_check_pointer_assign): Use gfc_check_same_strlen for string length compile-time check. * trans-expr.c (gfc_trans_pointer_assignment): Add runtime-check for equal string lengths using gfc_trans_same_strlen_check. * trans-intrinsic.c (gfc_trans_same_strlen_check): Renamed and made public from conv_same_strlen_check. (gfc_conv_intrinsic_merge): Adapted accordingly. 2008-12-18 Daniel Kraft PR fortran/31822 * gfortran.dg/char_pointer_assign_2.f90: Updated expected error message to be more detailed. * gfortran.dg/char_pointer_assign_4.f90: New test. * gfortran.dg/char_pointer_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_4.f90 trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/31822] Missing run-time bound checks for character pointer => target
--- Comment #5 from domob at gcc dot gnu dot org 2008-12-18 10:12 --- Fixed on trunk/4.4. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/37746] bounds check of string dummy arguments
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-10-12 11:33:42 |2008-12-20 19:08:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #8 from domob at gcc dot gnu dot org 2008-12-21 18:46 --- Subject: Bug 37605 Author: domob Date: Sun Dec 21 18:45:17 2008 New Revision: 142866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142866 Log: 2008-12-21 Arjen Markus Daniel Kraft PR fortran/37605 * gfortran.texi: Fixed some typos and some minor style improvements. * intrinsic.texi: Some clarifications and typo-fixes. * invoke.texi: Better documenation of the behaviour of the -fdefault-*-8 options and some other fixes. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug libfortran/38654] Fortran I/O speedup
--- Comment #1 from domob at gcc dot gnu dot org 2008-12-28 17:38 --- I did once write a floating-point parser for FreeWRL. I can dig it out so we can try to compare it to gfortran's current one, but I've no idea whether it is fast or not (although I tried at that time to write it as fast as possible). Would that help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38654
[Bug libfortran/38654] Fortran I/O speedup
--- Comment #4 from domob at gcc dot gnu dot org 2008-12-28 21:27 --- Created an attachment (id=16998) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16998&action=view) Number parsing routines Sorry for the spam, but this is the parser-code for numbers I promised; it's just a part out of FreeWRL's CFuncs/CParseLexer.c which was mostly written by myself. The code cut here is, except the two JAS-comments which are trivial and will be reverted anyways, fully written by myself and under my copyright, so I think this should not give any problems. I'm going to rework it anyway, though :) If I find some time and the right places, I will make a full patch for gfortran and do some benchmarks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38654
[Bug fortran/24886] different character length in actual and formal argument not detected
--- Comment #8 from domob at gcc dot gnu dot org 2009-01-03 19:08 --- Runtime checking is PR 37746, BTW, I'm working on it and have a pending patch. Would this fix this bug or should we wait for the whole-file checking? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug fortran/37746] bounds check of string dummy arguments
--- Comment #5 from domob at gcc dot gnu dot org 2009-01-04 08:40 --- *** Bug 35943 has been marked as a duplicate of this bug. *** -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
[Bug fortran/35943] -fbounds-check: actual character string shorter than dummy
--- Comment #1 from domob at gcc dot gnu dot org 2009-01-04 08:40 --- *** This bug has been marked as a duplicate of 37746 *** -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35943
[Bug fortran/37746] bounds check of string dummy arguments
--- Comment #6 from domob at gcc dot gnu dot org 2009-01-04 08:41 --- Here's a patch: http://gcc.gnu.org/ml/fortran/2008-12/msg00273.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #7 from domob at gcc dot gnu dot org 2009-01-13 19:47 --- Created an attachment (id=17090) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17090&action=view) Another test case This seems to be yet another test triggering this ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38831] New: ICE in bitmap_first_set_bit for procptr and C binding
The attached program gives an ICE:
bash-3.2# gfortran-dev reduced.f03
reduced.f03: In function 'mysql_library_shutdown':
reduced.f03:24: internal compiler error: in bitmap_first_set_bit, at
bitmap.c:770
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
when compiled with gfortran 4.4 trunk. Adding a "=> NULL()" to the procptr
declaration makes it compile, and commenting out any of the three lines of code
in the function bodies gives the ICE of PR 38152 instead.
--
Summary: ICE in bitmap_first_set_bit for procptr and C binding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38831
[Bug fortran/38831] ICE in bitmap_first_set_bit for procptr and C binding
--- Comment #1 from domob at gcc dot gnu dot org 2009-01-13 19:56 --- Created an attachment (id=17091) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17091&action=view) Test case This is the program ICE'ing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38831
[Bug fortran/38849] New: ICE in fold_convert with C_F_POINTER and C binding
This program gives an ICE when compiled with gfortran 4.4 trunk:
FUNCTION myfortran_error ()
USE ISO_C_BINDING
IMPLICIT NONE
CHARACTER(LEN=5) :: myfortran_error
CHARACTER(KIND=C_CHAR, LEN=5), POINTER :: chararr
TYPE(C_PTR) :: c_str
c_str = C_NULL_PTR
CALL C_F_POINTER (c_str, chararr)
myfortran_error(1:1) = chararr(1)
END FUNCTION myfortran_error
bash-3.2# gfortran-dev reduced.f03
reduced.f03: In function 'myfortran_error':
reduced.f03:8: internal compiler error: in fold_convert, at fold-const.c:2649
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
gfortran 4.3 compiles it but fails with an undefined reference to `chararr_'.
Actually I'm not proficient with C binding, so I would not bet the code above
is legal or doing "correct" things with the pointers... However, it should not
ICE.
--
Summary: ICE in fold_convert with C_F_POINTER and C binding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38849
[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts
--- Comment #5 from domob at gcc dot gnu dot org 2009-01-20 09:47 --- (In reply to comment #2) > http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141516 ? > Seems to be my fault, quite plausibly :D I will work on this. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-16 21:38:10 |2009-01-20 09:47:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
[Bug fortran/38887] [4.4 Regression] run-time abort for MVBITS with run-time zero sized array arguments
--- Comment #3 from domob at gcc dot gnu dot org 2009-01-20 09:44 --- I will work on this. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-16 21:48:38 |2009-01-20 09:44:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38887
[Bug fortran/38887] [4.4 Regression] run-time abort for MVBITS with run-time zero sized array arguments
--- Comment #4 from domob at gcc dot gnu dot org 2009-01-21 13:35 --- Subject: Bug 38887 Author: domob Date: Wed Jan 21 13:34:55 2009 New Revision: 143541 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143541 Log: 2009-01-21 Daniel Kraft * trans-stmt.c (gfc_conv_elemental_dependencies): Cleaned up comment. 2009-01-21 Daniel Kraft PR fortran/38887 * runtime/in_unpack_generic.c (internal_unpack): Return instead of abort when called with empty array. * m4/in_unpack.m4: Ditto. * generated/in_unpack_i1.c: Regenerated. * generated/in_unpack_i2.c: Regenerated. * generated/in_unpack_i4.c: Regenerated. * generated/in_unpack_i8.c: Regenerated. * generated/in_unpack_i16.c: Regenerated. * generated/in_unpack_r4.c: Regenerated. * generated/in_unpack_r8.c: Regenerated. * generated/in_unpack_r10.c: Regenerated. * generated/in_unpack_r16.c: Regenerated. * generated/in_unpack_c4.c: Regenerated. * generated/in_unpack_c8.c: Regenerated. * generated/in_unpack_c10.c: Regenerated. * generated/in_unpack_c16.c: Regenerated. 2009-01-21 Daniel Kraft PR fortran/38887 * gfortran.dg/mvbits_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mvbits_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/in_unpack_c10.c trunk/libgfortran/generated/in_unpack_c16.c trunk/libgfortran/generated/in_unpack_c4.c trunk/libgfortran/generated/in_unpack_c8.c trunk/libgfortran/generated/in_unpack_i1.c trunk/libgfortran/generated/in_unpack_i16.c trunk/libgfortran/generated/in_unpack_i2.c trunk/libgfortran/generated/in_unpack_i4.c trunk/libgfortran/generated/in_unpack_i8.c trunk/libgfortran/generated/in_unpack_r10.c trunk/libgfortran/generated/in_unpack_r16.c trunk/libgfortran/generated/in_unpack_r4.c trunk/libgfortran/generated/in_unpack_r8.c trunk/libgfortran/m4/in_unpack.m4 trunk/libgfortran/runtime/in_unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38887
[Bug fortran/38887] [4.4 Regression] run-time abort for MVBITS with run-time zero sized array arguments
--- Comment #5 from domob at gcc dot gnu dot org 2009-01-21 13:37 --- Fixed on trunk by converting the abort() call in internal_unpack to a return (this is also what the "real" unpack library call does). -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38887
[Bug fortran/38936] F2003: ASSOCIATE construct
--- Comment #1 from domob at gcc dot gnu dot org 2009-01-22 17:27 --- I always liked the idea of associate... Maybe I'll volunteer to work on it for gfortran, but don't take my word on it ;) And of course, things like CLASS get higher priority. -- domob at gcc dot gnu dot org changed: What|Removed |Added CC| |domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #14 from domob at gcc dot gnu dot org 2009-01-25 07:47 --- *** Bug 38831 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38831] ICE in bitmap_first_set_bit for procptr and C binding
--- Comment #5 from domob at gcc dot gnu dot org 2009-01-25 07:47 --- (In reply to comment #4) > Works for me at r143643. > Duplicate of PR 38152? Works for me now, too. Thanks for pointing this out, I'll close it as duplicate. *** This bug has been marked as a duplicate of 38152 *** -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38831
[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts
--- Comment #6 from domob at gcc dot gnu dot org 2009-01-25 08:36 --- (In reply to comment #4) > in gfc_conv_elemental_dependencies which then in > gfc_trans_allocate_array_storage gets accessed as: > tmp = TREE_TYPE (initial); /* Pointer to descriptor. */ > gcc_assert (TREE_CODE (tmp) == POINTER_TYPE); > tmp = TREE_TYPE (tmp); /* The descriptor itself. */ > tmp = gfc_get_element_type (tmp); This is very likely the problem here; I guess 'tmp' should get integer_type instead of record_type, too, and the code above misses to do so. When I wrote this fragment, it was more or less just a trial-and-error process as I (still) don't know the backend-stuff quite well; I will try to get the correct sequence which will hopefully fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts
--- Comment #7 from domob at gcc dot gnu dot org 2009-01-27 18:08 --- Subject: Bug 38883 Author: domob Date: Tue Jan 27 18:07:54 2009 New Revision: 143707 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143707 Log: 2009-01-27 Daniel Kraft PR fortran/38883 * trans-stmt.c (gfc_conv_elemental_dependencies): Create temporary for the real type needed to make it work for subcomponent-references. 2009-01-27 Daniel Kraft PR fortran/38883 * gfortran.dg/mvbits_6.f90: New test. * gfortran.dg/mvbits_7.f90: New test. * gfortran.dg/mvbits_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mvbits_6.f90 trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90 trunk/gcc/testsuite/gfortran.dg/mvbits_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts
--- Comment #8 from domob at gcc dot gnu dot org 2009-01-27 18:10 --- Fixed on trunk. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
[Bug fortran/40045] ICE with type extension and -fdump-parse-tree
--- Comment #4 from domob at gcc dot gnu dot org 2009-05-06 15:01 --- Yes, that sounds like a problem caused by my patch; it did change the structure of storing the type-bounds, so maybe simply changing the if to the one shown by Tobias was wrong. I will look into this! -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-06 15:01:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40045
[Bug fortran/22552] Would like warning when an undeclared function is called
--- Comment #5 from domob at gcc dot gnu dot org 2009-05-14 13:48 --- Created an attachment (id=17865) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17865&action=view) Latest patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
[Bug fortran/22552] Would like warning when an undeclared function is called
--- Comment #6 from domob at gcc dot gnu dot org 2009-05-14 13:49 --- Created an attachment (id=17866) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17866&action=view) ChangeLog for patch posted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22552
[Bug fortran/40045] ICE with type extension and -fdump-parse-tree
--- Comment #5 from domob at gcc dot gnu dot org 2009-05-14 20:03 --- Subject: Bug 40045 Author: domob Date: Thu May 14 20:02:46 2009 New Revision: 147540 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147540 Log: 2009-05-14 Daniel Kraft PR fortran/40045 * dump-parse-tree.c (show_typebound): Fix missing adaption to new type-bound procedure storage structure. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40045
[Bug fortran/40045] ICE with type extension and -fdump-parse-tree
--- Comment #6 from domob at gcc dot gnu dot org 2009-05-14 20:05 --- Fixed (not addressing the "related" part in comment #2, but Janus promised to work on it). -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40045
[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-10 10:52 --- Subject: Bug 37425 Author: domob Date: Mon Aug 10 10:51:46 2009 New Revision: 150622 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150622 Log: 2009-08-10 Daniel Kraft PR fortran/37425 * gfortran.dg/typebound_operator_1.f03: New test. * gfortran.dg/typebound_operator_2.f03: New test. 2009-08-10 Daniel Kraft PR fortran/37425 * gfortran.h (struct gfc_namespace): New fields tb_uop_root and tb_op. (gfc_find_typebound_user_op): New routine. (gfc_find_typebound_intrinsic_op): Ditto. (gfc_check_operator_interface): Now public routine. * decl.c (gfc_match_generic): Match OPERATOR(X) or ASSIGNMENT(=). * interface.c (check_operator_interface): Made public, renamed to `gfc_check_operator_interface' accordingly and hand in the interface as gfc_symbol rather than gfc_interface so it is useful for type-bound operators, too. Return boolean result. (gfc_check_interfaces): Adapt call to `check_operator_interface'. * symbol.c (gfc_get_namespace): Initialize new field `tb_op'. (gfc_free_namespace): Free `tb_uop_root'-based tree. (find_typebound_proc_uop): New helper function. (gfc_find_typebound_proc): Use it. (gfc_find_typebound_user_op): New method. (gfc_find_typebound_intrinsic_op): Ditto. * resolve.c (resolve_tb_generic_targets): New helper function. (resolve_typebound_generic): Use it. (resolve_typebound_intrinsic_op), (resolve_typebound_user_op): New. (resolve_typebound_procedures): Resolve operators, too. (check_uop_procedure): New, code from gfc_resolve_uops. (gfc_resolve_uops): Moved main code to new `check_uop_procedure'. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_1.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
[Bug fortran/37427] Passed-object dummy argument should be polymorphic
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-10 10:57 --- After Janus' recent check-in of CLASS parsing, this behaviour is fixed (though CLASS is not really polymorphic). I'm not sure if we should close this or keep open until CLASS is fully implemented. Janus, feel free to close it if you think that's ok. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|domob at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427
[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators
--- Comment #2 from domob at gcc dot gnu dot org 2009-08-10 11:08 --- After the check-in now, type-bound operators are parsed/checked correctly, but can not be called for now. I'll work on that as a follow-up patch. This means that the test-case given in the report works, but of course I'll keep the PR open until type-bound operators are fully supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
[Bug fortran/41023] New: Inconsistent error locations for wrong interfaces with overloaded operators
When defining an OPERATOR(...) for intrinsic operators or ASSIGNMENT(=), the interface of the provided procedure must match certain characteristics (like one or two dummy arguments, being a FUNCTION/SUBROUTINE, respectively, and so on). For a wrong interface, gfortran correctly prints an error message. The source location this is associated to is however quite inconsistent and misleading. For instance with the example: MODULE m IMPLICIT NONE TYPE t INTEGER :: num END TYPE t INTERFACE OPERATOR(+) MODULE PROCEDURE myplus END INTERFACE OPERATOR(+) CONTAINS INTEGER FUNCTION myplus (a, b, c) TYPE(t), INTENT(IN) :: a, b, c myplus = a%num + b%num + 42 END FUNCTION myplus END MODULE m I get this error: [/tmp]# gfortran-dev test.f03 test.f03:14.25: INTEGER FUNCTION myplus (a, b, c) 1 Error: Operator interface at (1) has the wrong number of arguments It is of course right, but I would expect at least a reference to where myplus is actually defined as OPERATOR(+). On the other hand, for MODULE m IMPLICIT NONE TYPE t INTEGER :: num END TYPE t INTERFACE OPERATOR(+) MODULE PROCEDURE myplus END INTERFACE OPERATOR(+) CONTAINS SUBROUTINE myplus (a, b) TYPE(t), INTENT(IN) :: a, b END SUBROUTINE myplus END MODULE m I get: [/tmp]# gfortran-dev test.f03 test.f03:9.27: MODULE PROCEDURE myplus 1 Error: Intrinsic operator interface at (1) must be a FUNCTION Which is quite better, in my opinion. I suggest we change the error location in every case to the MODULE PROCEDURE line, which is more reasonable IMHO as well as consistent. Alternatively, we could also reference both locations (but should also do this in both cases to stay consistent). -- Summary: Inconsistent error locations for wrong interfaces with overloaded operators Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023
[Bug fortran/41023] Inconsistent error locations for wrong interfaces with overloaded operators
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-10 11:18 --- The same holds for type-bound operators, see for instance gcc/testsuite/gfortran.dg/typebound_operator_2.f03 for the current "inconsistent" locations. But as the checking code is mainly shared, a fix will probably do both in one. I think though that this should be verified (e.g. by adapting the mentioned test-case to the new error locations which will be necessary anyways). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41023
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #4 from domob at gcc dot gnu dot org 2008-08-22 07:14 --- Subject: Bug 32095 Author: domob Date: Fri Aug 22 07:13:25 2008 New Revision: 139425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139425 Log: 2008-08-22 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/32095 PR fortran/34228 * gfortran.h (in_prefix): New global. (gfc_check_symbol_typed), (gfc_check_expr_typed): New methods. * array.c (match_array_element_spec): Check that bounds-expressions don't have symbols not-yet-typed in them. * decl.c (var_element): Check that variable used is already typed. (char_len_param_value): Check that expression does not contain not-yet-typed symbols. (in_prefix): New global. (gfc_match_prefix): Record using `in_prefix' if we're at the moment parsing a prefix or not. * expr.c (gfc_expr_check_typed): New method. * parse.c (verify_st_order): New argument to disable error output. (check_function_result_typed): New helper method. (parse_spec): Check that the function-result declaration, if given in a prefix, contains no not-yet-typed symbols when the IMPLICIT rules are parsed. * symbol.c (gfc_check_symbol_typed): Check that a symbol already has a type associated to it, otherwise use the IMPLICIT rules or signal an error. 2008-08-22 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/32095 PR fortran/34228 * gfortran.dg/used_before_typed_1.f90: New test. * gfortran.dg/used_before_typed_2.f90: New test. * gfortran.dg/used_before_typed_3.f90: New test. * gfortran.dg/array_constructor_26.f03: Add -std=gnu to not enable legacy-behaviour for the new check. * gfortran.dg/array_constructor_27.f03: Ditto. * gfortran.dg/blockdata_4.f90: Ditto. * gfortran.dg/bound_2.f90: Reordered declarations to satisfy the check. * gfortran.dg/result_in_spec_1.f90: Ditto. * gfortran.dg/argument_checking_7.f90: Adapted expected error messages. Added: trunk/gcc/testsuite/gfortran.dg/used_before_typed_1.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_2.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/argument_checking_7.f90 trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03 trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03 trunk/gcc/testsuite/gfortran.dg/blockdata_4.f90 trunk/gcc/testsuite/gfortran.dg/bound_2.f90 trunk/gcc/testsuite/gfortran.dg/result_in_spec_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug fortran/34228] -std=f* should diagnose used but later typed variables
--- Comment #4 from domob at gcc dot gnu dot org 2008-08-22 07:14 --- Subject: Bug 34228 Author: domob Date: Fri Aug 22 07:13:25 2008 New Revision: 139425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139425 Log: 2008-08-22 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/32095 PR fortran/34228 * gfortran.h (in_prefix): New global. (gfc_check_symbol_typed), (gfc_check_expr_typed): New methods. * array.c (match_array_element_spec): Check that bounds-expressions don't have symbols not-yet-typed in them. * decl.c (var_element): Check that variable used is already typed. (char_len_param_value): Check that expression does not contain not-yet-typed symbols. (in_prefix): New global. (gfc_match_prefix): Record using `in_prefix' if we're at the moment parsing a prefix or not. * expr.c (gfc_expr_check_typed): New method. * parse.c (verify_st_order): New argument to disable error output. (check_function_result_typed): New helper method. (parse_spec): Check that the function-result declaration, if given in a prefix, contains no not-yet-typed symbols when the IMPLICIT rules are parsed. * symbol.c (gfc_check_symbol_typed): Check that a symbol already has a type associated to it, otherwise use the IMPLICIT rules or signal an error. 2008-08-22 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/32095 PR fortran/34228 * gfortran.dg/used_before_typed_1.f90: New test. * gfortran.dg/used_before_typed_2.f90: New test. * gfortran.dg/used_before_typed_3.f90: New test. * gfortran.dg/array_constructor_26.f03: Add -std=gnu to not enable legacy-behaviour for the new check. * gfortran.dg/array_constructor_27.f03: Ditto. * gfortran.dg/blockdata_4.f90: Ditto. * gfortran.dg/bound_2.f90: Reordered declarations to satisfy the check. * gfortran.dg/result_in_spec_1.f90: Ditto. * gfortran.dg/argument_checking_7.f90: Adapted expected error messages. Added: trunk/gcc/testsuite/gfortran.dg/used_before_typed_1.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_2.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/argument_checking_7.f90 trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03 trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03 trunk/gcc/testsuite/gfortran.dg/blockdata_4.f90 trunk/gcc/testsuite/gfortran.dg/bound_2.f90 trunk/gcc/testsuite/gfortran.dg/result_in_spec_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34228
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #5 from domob at gcc dot gnu dot org 2008-08-22 07:16 --- Fixed. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug fortran/34228] -std=f* should diagnose used but later typed variables
--- Comment #5 from domob at gcc dot gnu dot org 2008-08-22 07:17 --- Fixed. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34228
[Bug fortran/30239] duplicate data type assignment not detected
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-12-17 20:15:55 |2008-08-22 07:18:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug fortran/30239] duplicate data type assignment not detected
--- Comment #5 from domob at gcc dot gnu dot org 2008-08-22 11:40 --- What's with this PR, do you have any decision? I'm not sure about a `fixed' warning, as this seems to be not common with gfortran, right? But I'd suggest maybe a -Wsurprising warning, so that at least -Wall will notify about this thing together with -pedantic or -std=*. What do you think about this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug fortran/30239] duplicate data type assignment not detected
--- Comment #7 from domob at gcc dot gnu dot org 2008-08-22 20:37 --- Subject: Bug 30239 Author: domob Date: Fri Aug 22 20:36:12 2008 New Revision: 139499 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139499 Log: 2008-08-22 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/30239 * symbol.c (gfc_add_type): Warn on -Wsurprising if a function-result type is re-declared but neither -pedantic nor -std=f* is given and so this is no error. * invoke.texi (-Wsurprising): Document this new behaviour. Added: trunk/gcc/testsuite/gfortran.dg/duplicate_type_1.f90 trunk/gcc/testsuite/gfortran.dg/duplicate_type_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug fortran/30239] duplicate data type assignment not detected
--- Comment #8 from domob at gcc dot gnu dot org 2008-08-22 20:38 --- I think we can fix this now, added a -Wsurprising warning. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug fortran/37222] New: Gfortran's check when overriding type-bound procedures is incomplete
In 4.5.6.2 of the draft F2003 standard ("Type-bound procedure overriding") a
list of conditions is given that an overriding type-bound procedure must
satisfy; the checks that function result characteristics and characteristics of
corresponding dummy arguments are the same are incomplete in the current
implementation. This corresponds to two FIXME's in resolve.c /
check_typebound_overrid.
At the moment, only gfc_compare_types is called; among the items that fail to
be checked are rank, array shape (if known), ALLOCATABLE/POINTER attributes and
INTENT declarations.
--
Summary: Gfortran's check when overriding type-bound procedures
is incomplete
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222
[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-22 11:58:44 |2008-08-30 14:21:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37193
[Bug fortran/37297] New: Ambiguity check for F2003 GENERIC bindings is not yet fully conformant
In the current implementation of GENERIC type-bound procedures the check if two specific targets of a GENERIC binding could be ambiguous (see standard 16.2.3 Restrictions on generic declarations) is not conformant with this section as it does not handle passed-objects at the moment. The following code is accepted: MODULE m TYPE t CONTAINS PROCEDURE, PASS :: proc1 PROCEDURE, NOPASS :: proc2 GENERIC :: gen => proc1, proc2 END TYPE t CONTAINS SUBROUTINE proc1 (me) IMPLICIT NONE TYPE(t) :: me END SUBROUTINE proc1 SUBROUTINE proc2 () IMPLICIT NONE END SUBROUTINE proc2 END MODULE m PROGRAM main USE m IMPLICIT NONE TYPE(t) :: myobj CALL myobj%gen () END PROGRAM main While the CALL in the main-program would fit to both specific targets. -- Summary: Ambiguity check for F2003 GENERIC bindings is not yet fully conformant Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37297
[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-01 13:44 --- Subject: Bug 37193 Author: domob Date: Mon Sep 1 13:43:10 2008 New Revision: 139866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139866 Log: 2008-09-01 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37193 * module.c (read_module): Initialize use_only flag on used symbols. 2008-09-01 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37193 * gfortran.dg/use_rename_4.f90: New test. * gfortran.dg/use_rename_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_rename_4.f90 trunk/gcc/testsuite/gfortran.dg/use_rename_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37193
[Bug fortran/37228] F2008: Support g0. edit descriptor
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 08:51 --- Subject: Bug 37228 Author: domob Date: Tue Sep 2 08:50:13 2008 New Revision: 139886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139886 Log: 2008-09-01 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/37228 * io.c (check_format): Allow specifying precision with g0 format. 2008-09-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/37301 PR libfortran/37228 * io/io.h (write_real_g0): Declare new function to handle g0.d format. * io/transfer.c (formatted_transfer_scalar): Use new function. * io/format.c (parse_format_list): Enable g0.d. * io/write.c (write_a_char4): Delete unused var. (set_fnode_default): New function to set the default fnode w, d, and e factored from write_real. (write_real): Use new factored function. (write_real_g0): New function that sets d to that passed by g0.d format specifier and set format to ES. Default values for w and e are used from the new function, set_fnode_default. 2008-09-01 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/37228 * gfortran.dg/fmt_g0_4.f08: Revised test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_g0_4.f08 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37228
[Bug fortran/37301] libgfortran/io/write.c:304: warning: unused variable 'j'
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 08:51 --- Subject: Bug 37301 Author: domob Date: Tue Sep 2 08:50:13 2008 New Revision: 139886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139886 Log: 2008-09-01 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/37228 * io.c (check_format): Allow specifying precision with g0 format. 2008-09-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/37301 PR libfortran/37228 * io/io.h (write_real_g0): Declare new function to handle g0.d format. * io/transfer.c (formatted_transfer_scalar): Use new function. * io/format.c (parse_format_list): Enable g0.d. * io/write.c (write_a_char4): Delete unused var. (set_fnode_default): New function to set the default fnode w, d, and e factored from write_real. (write_real): Use new factored function. (write_real_g0): New function that sets d to that passed by g0.d format specifier and set format to ES. Default values for w and e are used from the new function, set_fnode_default. 2008-09-01 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/37228 * gfortran.dg/fmt_g0_4.f08: Revised test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_g0_4.f08 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37301
[Bug fortran/37336] New: Fortran 2003: Finish derived-type finalization
Derived-type finalization as defined in Fortran 2003 is at the moment partially implemented in gfortran. FINAL bindings are parsed and stored/loaded in .mod module files, but finalizers are not yet executed and a not-yet-implemented error appears on using FINAL. -- Summary: Fortran 2003: Finish derived-type finalization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
-- domob at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-02 17:05 --- Created an attachment (id=16196) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16196&action=view) Proposed patch implementing the main part This is an experimental patch that implements the logic to create code finalizing a given entity. Only with this patch, this is however never called; this is merely a preparation for a full implementation of derived-type finalization. This patch was posted to the mailing lists as http://gcc.gnu.org/ml/fortran/2008-08/msg00042.html. It is a split-off from an experimental full finalization patch posted as http://gcc.gnu.org/ml/fortran/2008-06/msg00254.html and follow-up discussion. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 17:08 --- For the needed parts to actually call finalizers building upon the attached patch from comment #1, some means for temporary-creation before trans are needed to handle things like: x = foo (x) or foo (bar ()) Some ideas were posted to the mailing list as http://gcc.gnu.org/ml/fortran/2008-08/msg00026.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug fortran/37099] [4.3, 4.4 regression] Wrong results when comparing a character array to a character expression
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-12 19:41:55 |2008-09-02 18:04:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-03 12:27 --- Subject: Bug 37193 Author: domob Date: Wed Sep 3 12:25:57 2008 New Revision: 139936 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139936 Log: 2008-08-30 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37193 * module.c (read_module): Initialize use_only flag on used symbols. 2008-08-30 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37193 * gfortran.dg/use_rename_4.f90: New test. * gfortran.dg/use_rename_5.f90: New test. 2008-06-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36371 * gfortran.dg/data_array_5.f90: New test. 2008-06-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36371 * expr.c (gfc_check_assign): Change message and locus for error when conform == 0. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/data_array_5.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_4.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_5.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/expr.c branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37193
[Bug fortran/36371] [4.3 Regression] Wrong locus for errors in DATA statement
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-03 12:27 --- Subject: Bug 36371 Author: domob Date: Wed Sep 3 12:25:57 2008 New Revision: 139936 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139936 Log: 2008-08-30 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37193 * module.c (read_module): Initialize use_only flag on used symbols. 2008-08-30 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37193 * gfortran.dg/use_rename_4.f90: New test. * gfortran.dg/use_rename_5.f90: New test. 2008-06-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36371 * gfortran.dg/data_array_5.f90: New test. 2008-06-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/36371 * expr.c (gfc_check_assign): Change message and locus for error when conform == 0. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/data_array_5.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_4.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_5.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/expr.c branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36371
[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-03 12:28 --- Fixed on 4.4 and 4.3. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37193
[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-07-06 19:48:56 |2008-09-04 13:12:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36746
[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-04 17:14 --- Shouldn't for this code: IMPLICIT TYPE(t)(x) DIMENSION x(:) x get the implicit type on the DIMENSION statement and this be thus equivalent to TYPE(t) :: x DIMENSION x(:) (if that's a legal way to specify DIMENSION, I'm not sure)? Thinking of PR 32095 and without knowing what the standard says about this, I'd suppose it is so. This would mean the following is illegal: IMPLICIT TYPE(t) (x) DIMENSION x(:) INTEGER :: x Is this true? And is it ok to break code like that (I haven't tested if it's accepted at the moment)? If it is, I would suggest to do implicit typing on DIMENSION statements and try if this solves this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36746
[Bug fortran/37099] [4.3, 4.4 regression] Wrong results when comparing a character array to a character expression
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-04 19:17 --- Subject: Bug 37099 Author: domob Date: Thu Sep 4 19:16:13 2008 New Revision: 139997 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139997 Log: 2008-09-04 Daniel Kraft <[EMAIL PROTECTED]> * PR fortran/37099 * expr.c (simplify_const_ref): Update expression's character length when pulling out a substring reference. 2008-09-04 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37099 * gfortran.dg/string_compare_1.f90: New text. * gfortran.dg/string_compare_2.f90: New text. * gfortran.dg/string_compare_3.f90: New text. Added: trunk/gcc/testsuite/gfortran.dg/string_compare_1.f90 trunk/gcc/testsuite/gfortran.dg/string_compare_2.f90 trunk/gcc/testsuite/gfortran.dg/string_compare_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-04 20:23 ---
I'll try to find something about this in the standard. But you think DIMENSION
(and friends) is legally apply-able ("applicable"?) to symbols that are
declared later with their type? Hm... I hope to find out :)
Otherwise I'll try to fix this bug the conservative way ;) Thanks for your
comments!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36746
[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-05 11:57 --- Subject: Bug 36746 Author: domob Date: Fri Sep 5 11:56:23 2008 New Revision: 140034 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140034 Log: 2008-09-05 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/36746 * primary.c (gfc_match_rvalue): Removed logic to handle implicit typing to a derived-type if a component reference is found. (gfc_match_varspec): Moved it here. 2008-09-05 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/36746 * gfortran.dg/implicit_derived_type_1.f90: New test. * gfortran.dg/used_before_typed_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/implicit_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36746
[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-05 11:58 --- Fixed on trunk. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36746
[Bug fortran/35837] rej.valid: Host-associated SAVEd variable and PURE function
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-05 22:57:37 |2008-09-05 12:48:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35837
[Bug fortran/35837] rej.valid: Host-associated SAVEd variable and PURE function
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-05 20:53 --- Subject: Bug 35837 Author: domob Date: Fri Sep 5 20:51:50 2008 New Revision: 140046 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140046 Log: 2008-09-05 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/35837 * resolve.c (resolve_types): Restore gfc_current_ns on exit. * symbol.c (gfc_save_all): Removed blank line. 2008-09-05 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/35837 * gfortran.dg/save_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/save_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35837
[Bug fortran/35837] rej.valid: Host-associated SAVEd variable and PURE function
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-05 20:55 --- Fixed for trunk. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35837
[Bug fortran/37400] [4.4 Regression] implicit character(len=*,kind=kind('A')) (Q) ... no longer gives the right answer.
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-07 08:34 ---
(In reply to comment #1)
> The problem is that for
>implicit character(len=*,kind=kind('A')) (Q)
> the length of the first parameter string is used everywhere. The following
> fixes it, but I have no idea why it is a regression / why it worked before.
Could this have something to do with my used-before-typed patch that might have
changed a little when/why symbols get their IMPLICIT type? Other than that, I
can't imagine anything, either.
But your patch looks good, just intuitively...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37400
[Bug fortran/37199] array assignment from function writes out of bounds
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-22 11:57:37 |2008-09-07 14:04:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
[Bug fortran/37199] array assignment from function writes out of bounds
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-07 14:46 --- parm.12.dim[0].ubound = D.1541; parm.12.dim[0].stride = NON_LVALUE_EXPR ; parm.12.data = (void *) &(*ifm.11)[0]; parm.12.offset = NON_LVALUE_EXPR ; D.1547 = MAX_EXPR <(parm.12.dim[0].ubound - parm.12.dim[0].lbound) + 1, 0>; -D.1548 = D.1547 + -1; +D.1548 = D.1547 + -2; atmp.13.dtype = 281; atmp.13.dim[0].stride = 1; atmp.13.dim[0].lbound = 0; atmp.13.dim[0].ubound = D.1548; This one (from the diffs on my machine) is the problematic one. The value subtracted should be -1 independently of the lower bound. D.1548 will later be used in calculating the size of the temporary allocated, and for a lower-bound of 2, for instance, one element will be missing (for lower-bound 3 it would be 2 elements). I'm not yet completely sure what the problem is for a lower bound of 0 or -1, though. There, too much memory is allocated and the atmp's (the result array's) upper bound is too large. But I'll try to locate the problem in gfortran now and fix it and see what this does for all kinds of bounds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
[Bug fortran/37199] array assignment from function writes out of bounds
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-07 19:00 --- program bounds_issue real, pointer :: pdf0(:) allocate(pdf0(0:282)) pdf0 = f(pdf0) contains function f(x) real, intent(in) :: x(0:) ! x(1:), f(1:...) works real :: f(0:ubound(x,dim=1)) ! x(-1:), f(-1:...) crashes f = 0.0 end function end program bounds_issue --- For the temporary array holding the result and the loop assigning back to pdf0, the bounds of f(0:ubound(x,dim=1)) are used. The interface mapping of x in the upper bound however does not supply an array-spec to the symbol, and thus UBOUND(x) returns the number of elements in x rather than the real upper bound matching the fixed lower-bound of 0 as for an entity not being a full array. Thus, the loop starts at 0 because of the constant lower bound but runs one element too far because the upper bound is evaluated as if the lower was 1. This leads to the segfault in any case but when 1 is indeed the lower bound. It seems to be possible to simply copy the array-spec to new_sym in gfc_add_interface_mapping, I'm working this out at the moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
[Bug fortran/37412] No error on repeated declaration
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-08 06:36 --- IIRC, this behaviour is due to a patch I submitted some time ago. Maybe I could change this warning into an error even for non-standard conforming mode in case the length or a kind parameter differs. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37412
[Bug fortran/37099] [4.3, 4.4 regression] Wrong results when comparing a character array to a character expression
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-08 07:57 --- Subject: Bug 37099 Author: domob Date: Mon Sep 8 07:55:49 2008 New Revision: 140101 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140101 Log: 2008-09-04 Daniel Kraft <[EMAIL PROTECTED]> * PR fortran/37099 * expr.c (simplify_const_ref): Update expression's character length when pulling out a substring reference. 2008-09-04 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37099 * gfortran.dg/string_compare_1.f90: New text. * gfortran.dg/string_compare_2.f90: New text. * gfortran.dg/string_compare_3.f90: New text. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/string_compare_1.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/string_compare_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/string_compare_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
[Bug fortran/37099] [4.3, 4.4 regression] Wrong results when comparing a character array to a character expression
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-08 07:57 --- Fixed on trunk and 4.3 -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
[Bug fortran/36167] ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-08 08:28 --- Dominique reported that my pending patch for PR 37199 fixes this problem, too, and a test confirms this for me. Reading the commets, it seems quite plausible to me that the ICE here is caused because of the missing array spec after interface mapping. After checking in my patch, I will try to fully understand what the problem here is and if it is really fixed with my patch. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-05-07 14:07:21 |2008-09-08 08:28:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36167
[Bug fortran/37199] array assignment from function writes out of bounds
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 09:18 --- Subject: Bug 37199 Author: domob Date: Mon Sep 8 09:17:27 2008 New Revision: 140102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140102 Log: 2008-09-08 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37199 * trans-expr.c (gfc_add_interface_mapping): Set new_sym->as. (gfc_map_intrinsic_function): Added checks against NULL bounds in array specs. 2008-09-08 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/37199 * gfortran.dg/array_function_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_function_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
[Bug fortran/36167] ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 13:52 --- Subject: Bug 36167 Author: domob Date: Mon Sep 8 13:51:26 2008 New Revision: 140107 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140107 Log: 2008-09-08 Daniel Kraft <[EMAIL PROTECTED]> PR fortran/36167 * gfortran.dg/array_function_3.f90: New test. * gfortran.dg/save_3.f90: Added cleanup-modules directive. * gfortran.dg/string_compare_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/array_function_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/save_3.f90 trunk/gcc/testsuite/gfortran.dg/string_compare_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36167
[Bug fortran/36167] ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-08 13:54 --- This was apparently really fixed by my patch for PR 37199, I committed the test-case attached to trunk. Marking fixed. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36167
[Bug fortran/37423] Fortran 2003 DEFERRED bindings not yet implemented
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-08 14:06:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37423
[Bug fortran/37423] New: Fortran 2003 DEFERRED bindings not yet implemented
In the current implementation of Fortran 2003 type-bound procedures, DEFERRED bindings are not yet implemented. The DEFERRED type attribute will be parsed but results in an immediate error. -- Summary: Fortran 2003 DEFERRED bindings not yet implemented Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37423
[Bug fortran/37425] New: Fortran 2003: GENERIC bindings as operators
GENERIC type-bound procedures are currently implemented in gfortran, but only by name and not as operators as in the following example (the polymorphic passed-object problem included): MODULE m IMPLICIT NONE TYPE :: t INTEGER :: i CONTAINS PROCEDURE :: assign_t_from_int PROCEDURE :: equals_t_int GENERIC :: ASSIGNMENT(=) => assign_t_from_int GENERIC :: OPERATOR(==) => equals_t_int END TYPE t CONTAINS SUBROUTINE assign_t_from_int (me, i) IMPLICIT NONE TYPE(t), INTENT(OUT) :: me INTEGER, INTENT(IN) :: i me = t (i) END SUBROUTINE assign_t_from_int LOGICAL FUNCTION equals_t_int (me, i) IMPLICIT NONE TYPE(t) :: me INTEGER :: i equals_t_int = (me%i == i) END FUNCTION equals_t_int END MODULE m -- Summary: Fortran 2003: GENERIC bindings as operators Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-08 14:14:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
[Bug fortran/37427] New: Passed-object dummy argument should be polymorphic
As polymorphic entities are not implemented in gfortran, the handling of passed-object dummy arguments allows (or requires) them to be declared non-polymorphic (TYPE(t)) while they should in fact be CLASS(t): MODULE m TYPE :: t CONTAINS PROCEDURE :: proc END TYPE t CONTAINS SUBROUTINE proc (me) TYPE(t) :: me ! should be CLASS(t) :: me END SUBROUTINE proc END MODULE m -- Summary: Passed-object dummy argument should be polymorphic Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427
[Bug fortran/37427] Passed-object dummy argument should be polymorphic
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-08 15:12:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427
[Bug fortran/37427] Passed-object dummy argument should be polymorphic
-- domob at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427
