Bug 40591 - Procedure(interface): Rejected if interface is indirectly hostassociated
Summary: Procedure(interface): Rejected if interface is indirectly hostassociated
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2009-06-29 17:07 UTC by Tobias Burnus
Modified: 2010-07-10 16:46 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-07-08 09:48:15


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2009-06-29 17:07:07 UTC
The following program fails with:

    procedure(sub), pointer :: pptr2
                                    1
Error: Interface 'sub' of procedure 'pptr2' at (1) must be explicit


The question is whether it is valid or not. As both NAG f95 and ifort reject it (g95 accepts it), it might be invalid.


However, if one uncomments pptr1: gfortran, NAG f95 and g95 accept pptr1 and pptr2 -- while ifort continues to reject pptr2 only. Thus it might be valid at the end.


program main
!  procedure(sub), pointer :: pptr1
!  nullify (pptr1)
contains
  subroutine test()
    procedure(sub), pointer :: pptr2
    nullify (pptr2)
  end subroutine test
  subroutine sub()
  end subroutine sub
end program main
Comment 1 Paul Thomas 2009-07-07 05:01:00 UTC
(In reply to comment #0)
> The following program fails with:
> 
>     procedure(sub), pointer :: pptr2
>                                     1
> Error: Interface 'sub' of procedure 'pptr2' at (1) must be explicit
> 
> 
> The question is whether it is valid or not. As both NAG f95 and ifort reject it
> (g95 accepts it), it might be invalid.

Although I can find nowhere in the standards that says that it is valid, I believe that by the normal rules of host association of procedures, it must be.

gfortran accepts it if 'test' and 'sub' are interchanged.

I have put it on my todo list.

Cheers

Paul
Comment 2 Paul Thomas 2009-07-08 04:38:24 UTC
Subject: Bug 40591

Author: pault
Date: Wed Jul  8 04:38:06 2009
New Revision: 149362

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149362
Log:
2008-07-08  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40591
	* decl.c (match_procedure_interface):  Correct the association
	or creation of the interface procedure's symbol.

2008-07-08  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40591
	* gfortran.dg/proc_ptr_21.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_21.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/testsuite/ChangeLog

Comment 3 Paul Thomas 2009-07-08 09:48:15 UTC
Well..... I suppose that I should accept the bug :-)

I will commit the fix to 4.4 over the weekend, so please try to test it to destruction on 4.5.

Paul
Comment 4 Dominique d'Humieres 2009-07-08 11:47:08 UTC
It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and Intel64(?), see

http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00755.html
http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00078.html
Comment 5 Tobias Burnus 2009-07-08 12:37:16 UTC
(In reply to comment #4)
> It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and
> Intel64(?), see

I can - somewhat - reproduce it. It does not fail but valgrind shows (x86-64-linux and i686-linux):

==32231== Conditional jump or move depends on uninitialised value(s)
==32231==    at 0x80485A2: test.1513 (proc_ptr_21.f90:26)
==32231==    by 0x8048548: MAIN__ (proc_ptr_21.f90:8)
==32231==    by 0x80485F4: main (proc_ptr_21.f90:8)

That is solved by adding:
   i = 0
to subroutine test (while any other number causes the abortion).
Comment 6 Paul Thomas 2009-07-08 13:28:14 UTC
(In reply to comment #5)

> That is solved by adding:
>    i = 0
> to subroutine test (while any other number causes the abortion).
> 

Indeed - that was in the test originally; I do not know what happened to it. I'll put it right tonight.

Thanks

Paul
Comment 7 Dominique d'Humieres 2009-07-08 13:31:18 UTC
pr40683 is a duplicate.
Comment 8 janus 2009-07-20 09:24:44 UTC
I guess everything is fixed now. Can we close this PR?
Comment 9 Daniel Franke 2010-05-07 20:30:46 UTC
(In reply to comment #8)
> I guess everything is fixed now. Can we close this PR?

Ping?
Comment 10 Paul Thomas 2010-05-08 14:05:55 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I guess everything is fixed now. Can we close this PR?
> 
> Ping?
>

Note that I did not apply the patch to 4.4 as I said that I would.  What do you think?

Cheers

Paul
Comment 11 Paul Thomas 2010-07-10 16:46:35 UTC
(In reply to comment #10)

> Note that I did not apply the patch to 4.4 as I said that I would.  What do you
> think?

4.4 is sufficiently different from 4.5/6 that I am closing this as fixed.

Paul