This is just a reminder bug to make sure that I and/or Paul T. don't lose it as it will cause an ICE once I fix the double decl issue as we will be start to inline this function and fail Testcase: function a(b) REAL ::b b = 2.0 a = 1.0 end function program gg real :: h h = a(); end program gg
Here is another testcase (which ICEs currently but for a different reason): program main character (5) :: a = 'hello' call test ((/a/)) end program main subroutine test (a) character (5) :: a if (a .ne. 'hello') call abort end subroutine test The corrected form of this testcase is: program main character (5) :: a = 'hello' call test ((/a/)) end program main subroutine test (a) character (5) :: a(1) if (a(1) ne. 'hello') call abort end subroutine test ----- This testcase comes from HJL not even thinking about types of arguments to subroutines (IFort accepts the code too though Lahey's rejects it). I know just about as much Fortran as HJL does (maybe I can guess about how stuff like this is just wrong).
Subject: Re: accepts invalid fortran, different dummy types/number pinskia at gcc dot gnu dot org wrote: >------- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 01:37 ------- >Here is another testcase (which ICEs currently but for a different reason): >program main > character (5) :: a = 'hello' > call test ((/a/)) >end program main > > > I am very much aware of this, its friends and its cousins. Paul
*** Bug 27594 has been marked as a duplicate of this bug. ***
*** Bug 27586 has been marked as a duplicate of this bug. ***
*** Bug 27587 has been marked as a duplicate of this bug. ***
*** Bug 28443 has been marked as a duplicate of this bug. ***
*** Bug 28809 has been marked as a duplicate of this bug. ***
*** Bug 31149 has been marked as a duplicate of this bug. ***
This probably will work automatically if inter-file checking is implemented, but if not, here is an invalid example which should be rejected: --------- SUBROUTINE PHLOAD (READER,*) IMPLICIT NONE EXTERNAL READER CALL READER (*1) 1 RETURN 1 END SUBROUTINE program test EXTERNAL R call PHLOAD (R, 1) CALL PHLOAD (R, 2) END program test --------- Should give the error (cf. NAG f95): Error: y.f: Argument no. 2 in reference to PHLOAD from TEST is not a label
*** Bug 32170 has been marked as a duplicate of this bug. ***
Subject: Bug 26227 Author: pault Date: Mon Mar 30 19:35:14 2009 New Revision: 145314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145314 Log: 2009-03-30 Paul Thomas <pault@gcc.gnu.org> PR fortran/22571 PR fortran/26227 PR fortran/24886 * symbol.c : Add gfc_global_ns_list. * decl.c (add_global_entry): Set the namespace ('ns') field. * gfortran.h : Add the resolved field to gfc_namespace. Add the namespace ('ns') field to gfc_gsymbol. Add flag_whole_file to gfc_option_t. Add the prototype for gfc_free_dt_list. * lang.opt : Add the whole-file option. * invoke.texi : Document the whole-file option. * resolve.c (resolve_global_procedure): If the fwhole-file option is set, reorder gsymbols to ensure that translation is in the right order. Resolve the gsymbol's namespace if that has not occurred and then check interfaces. (resolve_function): Move call to resolve_global_procedure. (resolve_call): The same. (resolve_codes): Store the current labels_obstack. (gfc_resolve) : Return if the namespace is already resolved. trans-decl.c (gfc_get_extern_function_decl): If the whole_file option is selected, use the backend_decl of a gsymbol, if it is available. parse.c (add_global_procedure, add_global_program): If the flag whole-file is set, add the namespace to the gsymbol. (gfc_parse_file): On -fwhole-file, put procedure namespaces on the global namespace list. Rearrange to do resolution of all the procedures in a file, followed by their translation. * options.c (gfc_init_options): Add -fwhole-file. (gfc_handle_option): The same. 2009-03-30 Paul Thomas <pault@gcc.gnu.org> PR fortran/22571 * gfortran.dg/whole_file_1.f90: New test. PR fortran/26227 * gfortran.dg/whole_file_2.f90: New test. * gfortran.dg/whole_file_3.f90: New test. PR fortran/24886 * gfortran.dg/whole_file_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_1.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_2.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_3.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
After the commit in comment #11, the following code gives an ICE with -fwhole-file: [ibook-dhum] f90/bug% cat arr_fun.f90 function test(n) real, dimension(2) :: test integer :: n test = n ! print *, test return end function test program arr real, dimension(2) :: res res = test(2) print *, res end program [ibook-dhum] f90/bug% gfc -fwhole-file arr_fun.f90 arr_fun.f90: In function 'arr': arr_fun.f90:8: internal compiler error: in fold_convert, at fold-const.c:2547 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. It's a little bit late for further investigation, but the flag is probably the cause of 11 ICE in my tests. I may have also false positives or strange error messages. I'll try to sort my mess tomorrow morning.
This is now real, dimension(2) :: test integer :: n test = n ! print *, test return end function test program arr real, dimension(2) :: res res = test(2) print *, res end program ig25@linux-fd1f:/tmp> gfortran -fwhole-file gurgl.f90 gurgl.f90:10.6: res = test(2) 1 Fehler: The reference to function 'test' at (1) either needs an explicit INTERFACE or the rank is incorrect Should we close this?
(In reply to comment #13) > Should we close this? Yes, this is testcase gfortran.dg/whole_file_2.f90. Closing.