[Bug fortran/34868] New: Internal error compiler errror appears.

[Bug fortran/34868] New: Internal error compiler errror appears.

[yamagen at coral dot t dot u-tokyo dot ac dot jp]

Following preprocessed program can not be compiled with "-ff2c" option due to
the internal compiler error (all the messages are listed below test.f).

----beginning of test.f----
      function f(a)
      implicit none
      complex(8)         :: f
      real(8),intent(in) :: a(:)
      f=cmplx(0d0,0d0,8)
      end function f
----end of test.f----

% gfortran -O0 -ff2c -c test.f
test.f: In function 'f':
test.f:5: internal compiler error: in convert_memory_address, at explow.c:325
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: Internal error compiler errror appears.
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: yamagen at coral dot t dot u-tokyo dot ac dot jp
 GCC build triplet: powerpc-apple-darwin8.10.0
  GCC host triplet: powerpc-apple-darwin8.11.0
GCC target triplet: powerpc-apple-darwin8.10.0


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

[Bug fortran/34868] Internal error compiler errror appears.

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2008-01-19 11:34 -------
Confirmed on darwin9 (ppc/intel) with adifferent error:

pr34868.f90: In function 'f':
pr34868.f90:5: internal compiler error: in gimplify_expr, at gimplify.c:6285


-- 


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

[Bug fortran/34868] Internal error compiler errror appears with -ff2c

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-01-19 12:11 -------
  complex(kind=8) __result_f;

  *__result_f = 0.0;
  return __result_f;

:)

Well that is obviously wrong.


Also is there a reason why you are using -ff2c anyways?  It does change the ABI
slightly.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-19 12:11:47
               date|                            |
            Summary|Internal error compiler     |Internal error compiler
                   |errror appears.             |errror appears with -ff2c


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2008-01-19 12:43 -------
Without -ff2c, gfortran uses (-fdump-tree-original):
  complex(kind=8) __result_f;
  __result_f = __complex__ (0.0, 0.0);

but for -ff2c it looks odd:

f (a)
{
  complex(kind=8) __result_f;

  *__result_f = 0.0;
  return __result_f;
}

Besides, the complex result should not be returned as function result but as
additional parameter. At least this is what the gfortran manual claims:

"The calling conventions used by g77 (originally implemented in f2c) require
functions that return type default REAL to actually return the C type double,
and functions that return type COMPLEX to return the values via an extra
argument in the calling sequence that points to where to store the return
value"

g77 manual: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Functions.html


But it would be better if you could avoid the option -ff2c; it is much less
tested, incompatible to almost all other Fortran compilers including g77 with
the -fno-f2c compiler option.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|powerpc-apple-darwin8.10.0  |
   GCC host triplet|powerpc-apple-darwin8.11.0  |
 GCC target triplet|powerpc-apple-darwin8.10.0  |
   Last reconfirmed|2008-01-19 12:11:47         |2008-01-19 12:43:02
               date|                            |
            Summary|Internal error compiler     |ICE with -ff2c for function
                   |errror appears with -ff2c   |returning a complex number


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[yamagen at coral dot t dot u-tokyo dot ac dot jp]

------- Comment #4 from yamagen at coral dot t dot u-tokyo dot ac dot jp  2008-01-21 02:57 -------
Thank you very much for your comments.

First I answer to you why I would like to use -ff2c option.
The reason is that I would like to use "-framework vecLib".
In the URL
   
http://developer.apple.com/hardwaredrivers/ve/errata.html#fortran_conventions ,
Apple said
"The FORTRAN entry points in Mac OS X's vecLib adhere to the call/return
conventions of g77."
When I tried compile & linking vecLib without "-ff2c" option,
the double complex function "zdotu" does not work correctly.
Then I tried "-ff2c" option and found this issue.

Honestly saying, I don't know well about the calling convention ( nor "C"
langueage ),
but, I have tried "f2c test2.f"

----test2.f----
      function f(a)
      implicit none
      complex*16 f
      real*8     a(*)
      f=(0d0,0d0)
      end
--------------

Then the resultant C source is
/* Double Complex */ VOID f_(doublecomplex * ret_val, doublereal *a)
{
    /* Parameter adjustments */
    --a;

    /* Function Body */
     ret_val->r = 0.,  ret_val->i = 0.;
} /* f_ */

So it seems to me that the current functionality of the gfortran is different
from that of f2c, isn't it?

And, I'm wondering why changing the pseudo-size array "a(:)" to the variable
"a"
makes "test.f" to be compiled with "-ff2c" option without internal error.

# Anyway, I just want to use vecLib without degrading the portability of my
fortran fource code.
# (I know a work-around, calling zdotu as subroutine with one extra argument
receiving the result.
# But this work-around degrades the portability. )
# Does anyone know the tips for this issue?


-- 


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2008-01-21 07:41 -------
> Then the resultant C source is
>    VOID f_(doublecomplex * ret_val, doublereal *a)

Indeed this is f2c (and g77 -ff2c) syntax.

> So it seems to me that the current functionality of the gfortran is different
> from that of f2c, isn't it?

The functionality is not really different (except that gfortran supports much
more), but the calling is indeed different. All (most) modern compilers,
including gfortran, generate such a prototype:
  complex double f_ (double *a)

> And, I'm wondering why changing the pseudo-size array "a(:)" to the
> variable "a"

This rings a bell. And indeed the patch for PR 34848 [attachment 14978] fixes
this problem (but it causes some other regressions, see PR 34848).

(Note that "a(:)" and "a(*)" make a huge difference: For "a(*)" the size/upper
bound of the array "a" is unknown and the array is contiguous, while for "a(:)"
the bounds and sizes are known and the array might be not contiguous in memory
(strides); additionally the interface of the procedure "f" needs then to be
known to the caller of "f".)


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |34848


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2008-01-31 15:36 -------
That one is not a regression. It happens because, when the a argument is an
assumed-shape array, gfc_return_by_reference() return 0 because
sym->attr.always_explicit is set for the function.

There are two interesting comments about that in trans-types.c:

  /* Possibly return complex numbers by reference for g77 compatibility.
     We don't do this for calls to intrinsics (as the library uses the
     -fno-f2c calling convention), nor for calls to functions which always
     require an explicit interface, as no compatibility problems can
     arise there.  */

  /* Special case: f2c calling conventions require that (scalar)
     default REAL functions return the C type double instead.  f2c
     compatibility is only an issue with functions that don't
     require an explicit interface, as only these could be
     implemented in Fortran 77.  */

So I guess the answer is: assumed-shape array and f2c calling conventions are
mutually incompatible. From that point, a few courses of action are possible.
The best of all, IMHO, is to document the fact and error out when someone tries
that thing. F2C callings conventions aren't, by definition, usable for F95
code.

PS: this is not a regression, the ICE was already in 4.1.2 and 4.2.2.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
      Known to fail|                            |4.1.2 4.2.2 4.3.0


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

------- Comment #7 from fxcoudert at gcc dot gnu dot org  2008-02-27 10:35 -------
Actually, after looking more in depth at the front-end code, we do a fairly
good job of supporting the use of f2c calling conventions for Fortran 95 code
(it's mainly handled by the use of sym->attr.always_explicit, which does the
trick very nicely. Following on that, I found that there is one place this use
of sym->attr.always_explicit is missing, and that's where the bug is triggered.
The following patch fixes it:

Index: trans-expr.c
===================================================================
--- trans-expr.c        (revision 132578)
+++ trans-expr.c        (working copy)
@@ -513,7 +513,8 @@
           /* Dereference scalar hidden result.  */
          if (gfc_option.flag_f2c && sym->ts.type == BT_COMPLEX
              && (sym->attr.function || sym->attr.result)
-             && !sym->attr.dimension && !sym->attr.pointer)
+             && !sym->attr.dimension && !sym->attr.pointer
+             && !sym->attr.always_explicit)
            se->expr = build_fold_indirect_ref (se->expr);

           /* Dereference non-character pointer variables. 


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
           Keywords|                            |patch
   Last reconfirmed|2008-01-19 12:43:02         |2008-02-27 10:35:14
               date|                            |
   Target Milestone|---                         |4.4.0


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2008-02-27 14:51 -------
There's more to it... using the "result" syntax for the function makes it fail
even with my patch:

function f(a) result(res)
  implicit none
  real(8), intent(in) :: a(:)
  complex(8) :: res

  res = cmplx(sum(a),product(a),8)
end function f


>From the tree dump:

f (a)
{
  complex(kind=8) res;
  [...]
  *res = NON_LVALUE_EXPR <val.4>;  // Ouch, that hurts
  [...]
  return res;
}


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2008-02-28 10:42 -------
(In reply to comment #8)
> There's more to it... using the "result" syntax for the function makes it fail
> even with my patch

That's because the result symbol is not marked with attr.always_explicit, only
the procedure symbol. I think it's more convenient to mark both:

Index: resolve.c
===================================================================
--- resolve.c   (revision 132611)
+++ resolve.c   (working copy)
@@ -106,7 +106,10 @@ resolve_formal_arglist (gfc_symbol *proc
   if (gfc_elemental (proc)
       || sym->attr.pointer || sym->attr.allocatable
       || (sym->as && sym->as->rank > 0))
-    proc->attr.always_explicit = 1;
+    {
+      proc->attr.always_explicit = 1;
+      sym->attr.always_explicit = 1;
+    }

   formal_arg_flag = 1;

@@ -187,7 +190,11 @@ resolve_formal_arglist (gfc_symbol *proc
       if ((sym->as && sym->as->rank > 0 && sym->as->type == AS_ASSUMED_SHAPE)
          || sym->attr.pointer || sym->attr.allocatable || sym->attr.target
          || sym->attr.optional)
-       proc->attr.always_explicit = 1;
+       {
+         proc->attr.always_explicit = 1;
+         if (proc->result)
+           proc->result->attr.always_explicit = 1;
+       }

       /* If the flavor is unknown at this point, it has to be a variable.
         A procedure specification would have already set the type.  */


-- 


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

------- Comment #10 from fxcoudert at gcc dot gnu dot org  2008-02-28 15:43 -------
Subject: Bug 34868

Author: fxcoudert
Date: Thu Feb 28 15:42:21 2008
New Revision: 132751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132751
Log:
        PR fortran/34868

        * trans-expr.c (gfc_conv_variable): Don't build indirect
        references when explicit interface is mandated.
        * resolve.c (resolve_formal_arglist): Set attr.always_explicit
        on the result symbol as well as the procedure symbol.

        * gfortran.dg/f2c_9.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/f2c_9.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

------- Comment #11 from fxcoudert at gcc dot gnu dot org  2008-02-28 15:44 -------
Fixed on mainline.


-- 

fxcoudert at gcc dot gnu dot org changed:

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


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