[Bug fortran/36403] New: [4.4 Regression] Some fortran tests using eoshift fail on SH

[Bug fortran/36403] New: [4.4 Regression] Some fortran tests using eoshift fail on SH

[kkojima at gcc dot gnu dot org]

Several fortran tests using eoshift fail for SH.  The typical one is

gfortran.dg/char_length_8.f90  -O0  execution test

and its reduced testcase is

  CHARACTER(LEN=3), DIMENSION(10) :: Z
  call test_eoshift
contains
  subroutine test_eoshift 
    CHARACTER(LEN=1), DIMENSION(10) :: chk
    chk(1:8) = "5"
    chk(9:10) = " "
    Z(:)="456"
    if (any (EOSHIFT(Z(:)(2:2),2) .ne. chk)) call abort 
  END subroutine
END

It seems that a variable on stack is clobbered by the call of
_gfortran_eoshift0_4_char and it's resulting a segfault.

In .003t.original tree dump, that call

    _gfortran_eoshift0_4_char (&atmp.8, 1, &atmp.4, &C.651, 0B, 0B, 1);

has 7 arguments, but it doesn't match with the prototype of

  void                                                                        \
  eoshift0_##N##_char (gfc_array_char *ret,                                   \
                       GFC_INTEGER_4 ret_length __attribute__((unused)),      \
                       const gfc_array_char *array,                           \
                       const GFC_INTEGER_##N *pshift,                         \
                       const char *pbound,                                    \
                       const GFC_INTEGER_##N *pdim,                           \
                       GFC_INTEGER_4 array_length,                            \
                       GFC_INTEGER_4 bound_length __attribute__((unused)))    \
  {                                                                           \
    eoshift0 (ret, array, *pshift, pbound, pdim ? *pdim : 1,                  \
              array_length, " ", 1);                                          \
  }                                                                           \

in libgfortran/intrinsics/eoshift0.c which has 8 arguments.
Then the caller gives the stack area only for 7 arguments, but
the callee assumes the stack area is reserved for 8 arguments
and uses them for temporary purpose in the failing case.


-- 
           Summary: [4.4 Regression] Some fortran tests using eoshift fail
                    on SH
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh4-unknown-linux-gnu


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2008-06-02 11:29 -------
It's a front-end issue: as the BOUNDARY character argument is not present, its
length is not appended to the argument list as it should. I guess we need to
add a gfc_conv_intrinsic_eoshift function in trans-intrinsic.c to take care of
EOSHIFT.


-- 

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|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-06-02 11:29:59
               date|                            |


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.0


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[domob at gcc dot gnu dot org]

------- Comment #2 from domob at gcc dot gnu dot org  2008-07-24 17:03 -------
Isn't this maybe a general problem about optional string arguments?  Or is this
really a eoshift-specific problem?  I'm just thinking about a general solution
for this kind of problem if it isn't; in that case it would of course be a bit
ugly to have a gfc_conv_intrinsic_xxx function just for each intrinsic that
might get optional string arguments...


-- 


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2008-07-27 13:52 -------
> Isn't this maybe a general problem about optional string arguments?
> Or is this really a eoshift-specific problem? I'm just thinking about a 
> general solution for this kind of problem if it isn't.

I think this might be a more general problem, but it is not trivially solvable.
For external procedures, if the interface is available (as required for
optional arguments), the length is also present if the actual argument is
missing.

For intrinsic functions there exists also a formal argument list, but for
EOSHIFT's ARRAY/BOUNDARY argument it is ts.type == BT_REAL. (EOSHIFT allows
numeric types [real, integer, complex] and the character types.) And as the
actual argument is NULL, its type can also not be used to know that the string
length has to be passed.

I therefore think FX's solution of adding a gfc_conv_intrinsic_eoshift is OK.
The alternative would be to add a specific function with BT_CHARACTER type to
the generic function "EOSHIFT". I'm not sure how to do this best.

For fixing it using gfc_conv_intrinsic_eoshift:

a) Check other intrinsic functions, which take an optional argument which is of
character type.

b) At least for the test case, the following if matches in trans-intrinsics.c's
fc_conv_intrinsic_function:

  if (expr->rank > 0 && !expr->inline_noncopying_intrinsic)
    {
      lib = gfc_is_intrinsic_libcall (expr);
      if (lib != 0)
        {
          if (lib == 1)
            se->ignore_optional = 1;
          gfc_conv_intrinsic_funcall (se, expr);
          return;
        }
    }

Thus adding a "case GFC_ISYM_EOSHIFT:" in the switch block does not make sense.
(I think boundary needs to be an array and thus the if above always matches.)

c) I think the function should be called conv_intrinsic_eoshift w/o gfc_ as it
is not exported.

In conv_intrinsic_eoshift I think one can add as first line:

   if (expr->value.function.actual->expr->ts.type != BT_CHARACTER)
     {
        gfc_conv_intrinsic_funcall (se, expr);
        return;
     }

Or one covers both cases in that function. (One can check the actual argument
type here because the first argument, ARRAY, must be present and BOUNDARY has
the same type as ARRAY.)


-- 


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[domob at gcc dot gnu dot org]

------- Comment #4 from domob at gcc dot gnu dot org  2008-07-28 18:41 -------
Thanks for all the hints, Tobias!  I've had a look through the F2003 standard
about intrinsics taking optional char arguments, and it seems as though PACK
and RESHAPE would suffer from the same problem as EOSHIFT does (optional string
argument whose type is not even specified as to be always string), and tests
showed that here too the call to the library function has one less argument
when the optional string argument is not present...  This is probably a problem
there, too, isn't it?

None of those have their own conv_intrinsic_ functions at the moment (for all
of them the if matches, as they all return non-scalar values).  Is it ok if I
try to write one generic conv-function for this case and call it for all the
three intrinsics?


-- 


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[domob at gcc dot gnu dot org]

-- 

domob at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-06-02 11:29:59         |2008-07-28 18:41:59
               date|                            |


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2008-07-28 20:04 -------
> and it seems as though PACK and RESHAPE would suffer from the same problem as 
> EOSHIFT does
Seems so. I glanced through F2008 CD but I could not find more potential
problems.

> Is it ok if I try to write one generic conv-function for this case and call it
> for all the three intrinsics?
Yes, of cause. Seemingly all of them have the pattern
type of the first argument = type of one of the latter arguments.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[domob at gcc dot gnu dot org]

------- Comment #6 from domob at gcc dot gnu dot org  2008-07-29 09:12 -------
Subject: Bug 36403

Author: domob
Date: Tue Jul 29 09:11:51 2008
New Revision: 138234

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138234
Log:
2008-07-29  Daniel Kraft  <d@domob.eu>

        PR fortran/36403
        * trans-intrinsic.c (conv_generic_with_optional_char_arg):  New method
        to append a string-length even if the string argument is missing, e.g.
        for EOSHIFT.
        (gfc_conv_intrinsic_function):  Call the new method for EOSHIFT, PACK
        and RESHAPE.

2008-07-29  Daniel Kraft  <d@domob.eu>

        PR fortran/36403
        * gfortran.dg/char_eoshift_5.f90:  New test.
        * gfortran.dg/intrinsic_optional_char_arg_1.f90:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/char_eoshift_5.f90
    trunk/gcc/testsuite/gfortran.dg/intrinsic_optional_char_arg_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH

[domob at gcc dot gnu dot org]

------- Comment #7 from domob at gcc dot gnu dot org  2008-07-29 09:17 -------
Fixed.


-- 

domob at gcc dot gnu dot org changed:

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


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