At revision 136821 the following code: !module CHECK_SEM ! Submitted by Walt Brainerd, The Fortran Company ! GNU Fortran 95 (GCC 4.1.0 20050322 (experimental)) ! Windows XP ! Produces "a.exe has encountered a problem" window. ! Same problem if comments are removed so that ! the function is in a module. ! contains function CHECK_INTEGER4_RANK1 (EXPECTED, COMPUTED) integer(4), dimension(:), intent(in) :: EXPECTED, COMPUTED logical :: CHECK_INTEGER4_RANK1 CHECK_INTEGER4_RANK1 = all(COMPUTED == EXPECTED) end function CHECK_INTEGER4_RANK1 !end module CHECK_SEM program array_test !use CHECK_SEM logical :: CHECK_INTEGER4_RANK1 integer,dimension(-1:1,-1:1) :: mis1=1.1 logical,dimension(-1:1,-1:1) :: ml2=.true. print *, CHECK_INTEGER4_RANK1 (sum(mis1,dim=1,mask=ml2), (/8,5,12/)) end program array_test gives a "Bus error". The executable runs fine if I revert the patch.
(In reply to comment #0) > At revision 136821 the following code: Dominique, It runs fine for me on x86_ia64 - did you use any options? I've CC'd Jerry, since 136821 was his. Paul
(In reply to comment #1) > It runs fine for me on x86_ia64 - did you use any options? I have set the build to i686-apple-darwin9. The bus error comes with default (-m32 and no options), the test passes with -m64.
I can reproduce this on x86-64-linux by using the -m32 option.
When I revert just the files in my patch, the test case passes with -m32 and segfaults on -m64 at run time. I don't think this is related to 136821 directly. Looking at the -fdump-tree-original between -m32 and -m64, there are a large number of variables that change from kind=4 with -m32 to kind=8 with -m64. Something is definitely out of whack. This is looking like a Hiesenbug. I am going to need help to find this.
OK, with r136820 $ gfc -m64 -fbounds-check pr36553.f90 $ ./a.out At line 17 of file pr36553.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of array 'expected' (0/3329063047920841327) $ gfc -m32 -fbounds-check pr36553.f90 $ ./a.out T
I get in valgrind (trunk revision 136838) with -m32 and -m64 on x86-64-linux: ==3145== Invalid read of size 4 ==3145== at 0x804876D: check_integer4_rank1_ (test.f90:14) ==3145== by 0x80489E1: MAIN__ (test.f90:29) ==3145== by 0x8048AF8: main (fmain.c:21) However, this is not different from 4.3. Using NAG f95, I get: Warning: line 26: REAL value for INTEGER PARAMETER Error:Explicit interface required for CHECK_INTEGER4_RANK1 from ARRAY_TEST - argument EXPECTED (no. 1) is an assumed-shape array And for the contained procedure, I don't see any valgrind errors.
(In reply to comment #6) > However, this is not different from 4.3. Using NAG f95, I get: > Warning: line 26: REAL value for INTEGER PARAMETER > Error:Explicit interface required for CHECK_INTEGER4_RANK1 from ARRAY_TEST - > argument EXPECTED (no. 1) is an assumed-shape array duuuh! Lahey... Compiling program unit CHECK_INTEGER4_RANK1 at line 1: Compiling program unit array_test at line 19: 2615-S: "SOURCE.F90", line 29: The procedure 'CHECK_INTEGER4_RANK1' shall have an explicit interface, because it contains the assumed shape array 'EXPECTED'. The previous definition is in 'line 14'. 2615-S: "SOURCE.F90", line 29: The procedure 'CHECK_INTEGER4_RANK1' shall have an explicit interface, because it contains the assumed shape array 'COMPUTED'. The previous definition is in 'line 14'. Encountered 2 errors, 0 warnings, 0 informations in file SOURCE.F90. Compiling file SOURCE.F90. Another case where same file checking would come in handy. Compiling with -m32 on my system reproduces the bus error. Adding the interface, thusly: !module CHECK_SEM ! Submitted by Walt Brainerd, The Fortran Company ! GNU Fortran 95 (GCC 4.1.0 20050322 (experimental)) ! Windows XP ! Produces "a.exe has encountered a problem" window. ! Same problem if comments are removed so that ! the function is in a module. ! contains function CHECK_INTEGER4_RANK1 (EXPECTED, COMPUTED) integer(4), dimension(:), intent(in) :: EXPECTED, COMPUTED logical :: CHECK_INTEGER4_RANK1 CHECK_INTEGER4_RANK1 = all(COMPUTED == EXPECTED) end function CHECK_INTEGER4_RANK1 !end module CHECK_SEM program array_test !use CHECK_SEM logical :: CHECK_INTEGER4_RANK1 integer,dimension(-1:1,-1:1) :: mis1=1 logical,dimension(-1:1,-1:1) :: ml2=.true. interface function CHECK_INTEGER4_RANK1 (EXPECTED, COMPUTED) integer(4), dimension(:), intent(in) :: EXPECTED, COMPUTED logical :: CHECK_INTEGER4_RANK1 end function CHECK_INTEGER4_RANK1 end interface print *, CHECK_INTEGER4_RANK1 (sum(mis1,dim=1,mask=ml2), (/8,5,12/)) end program array_test Makes it work fine for -m32 and -m64. Dominique, if that does not do it for you, remodify the summary line and keywords as appropriate. Cheers Paul PS Jerry, sorry for fingering you falsely! :)
Dominique, any improvements here with -fwhole-file?
> Dominique, any improvements here with -fwhole-file? AFAICT the answer is no: the invalid code in comment #0 is not rejected (see comment #6 for the kind of expected diagnostic). I think this PR should be closed as invalid and a new one open against -fwhole-file with the keyword accept-invalid. BTW the "ice-on-invalid-code" does not seem correct: the "seg fault" (or "bus error") occurs at run time depending on the flags (and the revision). Note also that the result is mostly 'T' when the compiled code is executed (instead if 'F' when the comments for 'module' are removed) .
Still an issue with gcc version 4.6.0 20100520 (experimental) (GCC) Replaced ice-on-invalid with accepts-invalid keyword. The compiler is fine, the produced binary isn't - there should be no binary. Smaller testcase: real :: f print *, f( (/ 0.0, 1.0/) ) end function f(x) real, intent(in) :: x(:) ! assumed shape requires explicit interface in caller real :: f(size(x)) f = sin(x) ! array valued result requires explicit interface in caller end function What bothers me: how are we supposed to determine if an explicit interface would be required, if the function in questions is in a different compilation unit? Can -fwhole-program/-flto, or whatever else looks at the whole picture, tweaked to do that?
*** This bug has been marked as a duplicate of 31346 ***
Subject: Re: Missing interface not detected in call to same file function With -fwhole-file, we get for the short testcase: ../pr36553/pr36553.f90:2.9: print *, f( (/ 0.0, 1.0/) ) 1 Error: The reference to function 'f' at (1) either needs an explicit INTERFACE or the rank is incorrect Paul On Mon, May 24, 2010 at 12:34 AM, dfranke at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-23 22:34 ------- > > > *** This bug has been marked as a duplicate of 31346 *** > > > -- > > dfranke at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |DUPLICATE > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. >
(In reply to comment #12) > With -fwhole-file, we get for the short testcase: > > ../pr36553/pr36553.f90:2.9: > > print *, f( (/ 0.0, 1.0/) ) > 1 > Error: The reference to function 'f' at (1) either needs an explicit > INTERFACE or the rank is incorrect Argh! How did I miss that? Ok, if the array valued result is removed, it goes again unnoticed: real :: f print *, f( (/ 0.0, 1.0/) ) end function f(x) real, intent(in) :: x(:) ! assumed shape requires explicit interface in caller real :: f f = sum(x) end function