[Bug fortran/52469] New: Defining function pointer interface

[Bug fortran/52469] New: Defining function pointer interface

[palott at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

             Bug #: 52469
           Summary: Defining function pointer interface
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: palott@gmail.com


iMac% gfortran -v -save-temps -c  examfun1.f90           
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.3.0
Configured with: ../gcc-4.7-20120204/configure --enable-languages=c,fortran
Thread model: posix
gcc version 4.7.0 20120204 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.3' '-v' '-save-temps' '-c'
'-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/f951 examfun1.f90 -fPIC
-quiet -dumpbase examfun1.f90 -mmacosx-version-min=10.7.3 -mtune=core2 -auxbase
examfun1 -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin11.3.0/4.7.0/finclude -o examfun1.s
GNU Fortran (GCC) version 4.7.0 20120204 (experimental)
(x86_64-apple-darwin11.3.0)
    compiled by GNU C version 4.7.0 20120204 (experimental), GMP version 4.3.1,
MPFR version 2.4.1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.7.0 20120204 (experimental)
(x86_64-apple-darwin11.3.0)
    compiled by GNU C version 4.7.0 20120204 (experimental), GMP version 4.3.1,
MPFR version 2.4.1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
examfun1.f90: In function ‘test_proc_ptr’:
examfun1.f90:74:0: internal compiler error: tree check: expected function_type
or method_type, have pointer_type in gimplify_call_expr, at gimplify.c:2436
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/52469] Defining function pointer interface

[palott at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

--- Comment #1 from palott at gmail dot com 2012-03-03 16:35:14 UTC ---
Created attachment 26817
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26817
simple example defining a function pointer interface and calling function

Defining func interface and type in the module leads to gfortran error in
latest release. This example compiles fine in earlier releases. Inserting these
definitions within the program test_proc_ptr, works okay in both releases.

  pointer :: func
  interface
     function func (z)
        real :: func
        real, intent (in) :: z
     end function func
  end interface

  type Contains_f_ptr
     procedure (func), pointer, nopass :: my_f_ptr
  end type Contains_f_ptr

[Bug fortran/52469] [4.6/4.7/4.8 Regression] Defining function pointer interface

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-03-04
                 CC|                            |burnus at gcc dot gnu.org
            Summary|Defining function pointer   |[4.6/4.7/4.8 Regression]
                   |interface                   |Defining function pointer
                   |                            |interface
     Ever Confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-03-04 22:37:59 UTC ---
The ICE appeared between 

gcc version 4.6.0 20100723 (experimental) [trunk revision 162456] (GCC) (OK)

and

gcc version 4.6.0 20100901 (experimental) [branch fortran-dev revision 163718]
(GCC)

[macbook] f90/bug% /opt/gcc/gcc4.6d/bin/gfortran pr52469.f90
pr52469.f90: In function 'test_proc_ptr':
pr52469.f90:74:0: internal compiler error: in aggregate_value_p, at
function.c:1971

The error with the current trunk is

pr52469.f90: In function 'test_proc_ptr':
pr52469.f90:74:0: internal compiler error: tree check: expected function_type
or method_type, have pointer_type in gimplify_call_expr, at gimplify.c:2437

and with revision 184852 configured with --enable-checking=release

pr52469.f90: In function 'test_proc_ptr':
pr52469.f90:60:0: error: non-function in gimple call
D.1883 = D.1882 (&C.1873);

pr52469.f90:60: confused by earlier errors, bailing out

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid, wrong-code
   Target Milestone|---                         |4.8.0
            Summary|[4.6/4.7/4.8 Regression]    |[4.6/4.7/4.8 Regression]
                   |Defining function pointer   |-fwhole-file bug: Wrong
                   |interface                   |backend_decl for result of
                   |                            |PPC function

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-05 08:19:15 UTC ---
The following is mishandled:

  write (6, *)  NewType(2) % my_f_ptr (3.0)

That generates the following code (dump of the internal format:
-fdump-tree-original):

      real(kind=4) <T4aa> (real(kind=4) & restrict) D.1870;
      static real(kind=4) C.1869 = 3.0e+0;

      D.1870 = newtype[1].my_f_ptr (&C.1869);
      _gfortran_transfer_real_write (&dt_parm.0, &D.1870, 4);

The problem is that the temporary variable "D.1870" is a function pointer
instead of a "real(kind=4)".


That seems to be one bug in the -fwhole-file handling. Seemingly, for the
result the backend_decl of the symbol and not its result value is pulled in.

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-05 20:31:58 UTC ---
WITH -fno-whole-file:

(gdb) b trans-expr.c:2249
...
Breakpoint 1, get_proc_ptr_comp (e=0x16d6420) at
/projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:2249
2249      e2->expr_type = old_type;
(gdb) p debug_tree (comp_se.expr->typed.type)
 <function_type 0x2aaaacfb8b28
    type <real_type 0x2aaaacea1e70 real(kind=4) SF


WITH -fwhole-file:

(gdb) p debug_tree (comp_se.expr->typed.type)
 <pointer_type 0x2aaaacfb8bd0
    type <function_type 0x2aaaacfb8b28
        type <real_type 0x2aaaacea1e70 real(kind=4) SF


 * * *

Ignoring the difference, I tried:

--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2250,2 +2250,4 @@ get_proc_ptr_comp (gfc_expr *e)
   gfc_free_expr (e2);
+  if (POINTER_TYPE_P (TREE_TYPE (comp_se.expr)))
+    return comp_se.expr; 
   return build_fold_addr_expr_loc (input_location, comp_se.expr);


However, that leads to a segfault at run time in the WRITE line - even though
the dump looks OK:

      real(kind=4) D.1871;
      static real(kind=4) C.1870 = 3.0e+0;
      D.1871 = newtype[1].my_f_ptr (&C.1870);
      _gfortran_transfer_real_write (&dt_parm.0, &D.1871, 4);

 * * *

I tried to find out what's the difference between -f(no-)whole file, but so far
without success. "gfc_get_ppc_type" is in both cases only called once and
returns a
 <pointer_type 0x2aaaacfb8bd0
    type <function_type 0x2aaaacfb8b28

Once, it is called directly:
  gfc_get_symbol_decl -> gfc_sym_type -> gfc_typenode_for_spec
  -> gfc_get_derived_type

And once indirectly:

  gfc_get_symbol_decl -> gfc_sym_type -> gfc_typenode_for_spec
  -> gfc_get_derived_type -> gfc_get_module_backend_decl ->
gfc_get_derived_type

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid, wrong-code   |ice-on-valid-code
             Status|NEW                         |ASSIGNED

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-08 11:32:50 UTC ---
The problem already occurs for gfc_get_derived_type's call to gfc_get_ppc_type,
which calls in turn gfc_get_function_type.

For -fno-whole-file), gfc_get_function_type returns the function decl, for
-fwhole-file it returns a pointer to the function decl.

The reason is that for -fwhole-file, "sym" (sym->name == "func") already has a
backend_decl - one which has a pointer.

 * * *

Actually, the example source code is rather tricky:

  pointer :: func
  interface
     function func (z)
        real :: func
        real, intent (in) :: z
     end function func
  end interface

This declares a procedure pointer "func", i.e. it's the same as:

  abstract interface
     function template (z)
        real :: template
        real, intent (in) :: z
     end function template
  end interface
  procedure(template), pointer :: func


But at the same time, the original "func" is used as:

  type Contains_f_ptr
     procedure (func), pointer, nopass :: my_f_ptr
  end type Contains_f_ptr

Where "func" denotes the interface to which the procedure pointer points to
(i.e. "template" in the modified exampled). In trans-type.c, the proc pointer
is completely unexpected and thus it fails.

It should be possible to modify the example such that it also fails with
-fno-whole-file.


Draft patch:

--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2680,3 +2694,7 @@ gfc_get_function_type (gfc_symbol * sym)
   if (sym->backend_decl)
-    return TREE_TYPE (sym->backend_decl);
+    {
+      if (sym->attr.proc_pointer)
+       return TREE_TYPE (TREE_TYPE (sym->backend_decl));
+      return TREE_TYPE (sym->backend_decl);
+    }

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-08 19:36:53 UTC ---
Author: burnus
Date: Thu Mar  8 19:36:43 2012
New Revision: 185109

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

        PR fortran/52469
        * trans-types.c (gfc_get_function_type): Handle backend_decl
        of a procedure pointer.

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

        PR fortran/52469
        * gfortran.dg/proc_ptr_34.f90


Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_34.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-10 08:18:40 UTC ---
Author: burnus
Date: Sat Mar 10 08:18:31 2012
New Revision: 185170

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

        PR fortran/52469
        * trans-types.c (gfc_get_function_type): Handle backend_decl
        of a procedure pointer.

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

        PR fortran/52469
        * gfortran.dg/proc_ptr_34.f90


Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/proc_ptr_34.f90
Modified:
    branches/gcc-4_7-branch/gcc/fortran/ChangeLog
    branches/gcc-4_7-branch/gcc/fortran/trans-types.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-10 09:20:27 UTC ---
Author: burnus
Date: Sat Mar 10 09:20:22 2012
New Revision: 185173

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

        PR fortran/52469
        * trans-types.c (gfc_get_function_type): Handle backend_decl
        of a procedure pointer.

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

        PR fortran/52469
        * gfortran.dg/proc_ptr_34.f90: New.


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/proc_ptr_34.f90
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/trans-types.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52469

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-10 09:21:57 UTC ---
FIXED on the trunk and on the 4.6 and 4.7 branches (in time for the 4.7.0rc2).

Thanks for the bug report!