User account creation filtered due to spam.

Bug 52585 - Wrong result for ASSOCIATED with dummy procedure pointer
Summary: Wrong result for ASSOCIATED with dummy procedure pointer
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 53556 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-14 13:24 UTC by Mat Cross
Modified: 2012-06-02 21:05 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mat Cross 2012-03-14 13:24:16 UTC
$ uname -a
Linux stonehenge 3.2.9-2.fc16.x86_64 #1 SMP Mon Mar 5 20:55:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ gfortran --version
GNU Fortran (GCC) 4.8.0 20120314 (experimental) [trunk revision 185372]

$ cat p_assoc.f90
module m0
abstract interface
  subroutine sub
  end subroutine sub
end interface
interface
  subroutine s(ss)
    import sub
    procedure(sub), pointer, intent(in) :: ss
  end subroutine s
end interface
end module m0
use m0, only : sub, s
procedure(sub) :: sub2, pp
pointer :: pp
pp => sub2
if (.not. associated(pp,sub2)) stop 'FAIL'
call s(pp)
end
subroutine s(ss)
  use m0, only : sub
  procedure(sub), pointer, intent(in) :: ss
  procedure(sub) :: sub2
  if (.not. associated(ss,sub2)) stop 'FAIL2'
end subroutine s
subroutine sub2
end subroutine sub2

$ gfortran p_assoc.f90 ; ./a.out
STOP FAIL2
Comment 1 Tobias Burnus 2012-03-14 14:32:59 UTC
Thanks for the report!

It does not loose the pointer association state - it just takes (internally) the wrong address as -fdump-tree-original shows.

It has the correct result for the main program/caller:
  void (*<T4ac>) (void) pp;
  pp = sub2;
  if (pp != sub2 || pp == 0B)
    _gfortran_stop_string (&"FAIL"[1]{lb: 1 sz: 1}, 4);


But in subroutine s, it uses the wrong address:

  s (void (*<T4ac>) (void) * ss)
  {
    if (ss != sub2 || ss == 0B)
      _gfortran_stop_string (&"FAIL2"[1]{lb: 1 sz: 1}, 5);

The "ss != sub2  || ss = 0B" should have been a "*ss != sub2 || *ss == 0B" in this C-like dump.
Comment 2 Tobias Burnus 2012-03-14 14:41:05 UTC
I think one needs something like the following for both the first and the second argument.

      if (arg1->expr->symtree->n.sym->attr.proc_pointer
          && arg1->expr->symtree->n.sym->attr.dummy)
        arg1se.expr = build_fold_indirect_ref_loc (input_location,
                                                   arg1se.expr);
Comment 3 Tobias Burnus 2012-03-17 17:04:03 UTC
Author: burnus
Date: Sat Mar 17 17:03:59 2012
New Revision: 185485

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185485
Log:
2012-03-17  Tobias Burnus  <burnus@net-b.de>

        PR fortran/52585
        * trans-intrinsic.c (gfc_conv_associated): Fix handling of
        procpointer dummy arguments.

2012-03-17  Tobias Burnus  <burnus@net-b.de>

        PR fortran/52585
        * gfortran.dg/proc_ptr_36.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_36.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/testsuite/ChangeLog
Comment 4 Tobias Burnus 2012-03-17 17:55:58 UTC
FIXED on the trunk (GCC 4.8).

Thanks for the report!
Comment 5 janus 2012-06-02 21:05:12 UTC
*** Bug 53556 has been marked as a duplicate of this bug. ***