This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: On types, types, types


On Monday 28 June 2004 02:43, Steve Kargl wrote:
> On Mon, Jun 28, 2004 at 01:39:16AM +0200, Steven Bosscher wrote:
> > On Monday 28 June 2004 01:27, Paul Brook wrote:
> >
> > Bud, Kargl, I would really appreciate if you could test and make sure
> > that the patch doesn't break anything for you before I commit it.
>
> I applied the patch, gmake bubblestrap, and ran the gfortran
> testsuite.  There were no new failures with your patch.  This
> is on IA32 FreeBSD.
>
> My private test suite is failing with
>
> surface.f90:13: internal compiler error: in gfc_add_modify_expr,
>  at fortran/trans.c:156
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> *** Error code 1 (continuing)
>
> This is a new failure caused/related to your patch.  Here's a
> cutdown test case

Yes, thanks.  I didn't really expect that this wouldn't uncover some
other bug somewhere.  You tripped the abort in gfc_add_modify_expr.

> subroutine surface(fname)
>   implicit none
>   character*80, intent(in) :: fname
>   integer ios
>   open(unit = 1, file = fname, iostat = ios, status = 'old')
> end subroutine surface

This makes us die in set_string because the rhs and lhs of the assignment
don't have the same type:


Breakpoint 4, set_string (block=0x7fbffff1a0, postblock=0x7fbffff190, var=0x2a959ec9a0,
    var_len=0x2a959eca80, e=0x406f8580) at ../../mainline/gcc/fortran/trans-io.c:421
421           gfc_conv_string_parameter (&se);
(gdb) call debug_generic_expr (io)
_gfortran_ioparm<D416>.file<D372>
(gdb) call debug_generic_expr (se.expr)
fname<D443>
(gdb) call debug_tree (io->common.type)
 <pointer_type 0x2a955a4000
    type <integer_type 0x2a95593540 int1 QI
        size <integer_cst 0x2a95591510 constant invariant 8>
        unit size <integer_cst 0x2a95591540 constant invariant 1>
        align 8 symtab 0 alias set -1 precision 8 min <integer_cst 0x2a955914b0 -128> max <integer_cst 0x2a955914e0 127>
        pointer_to_this <pointer_type 0x2a955a4000>>
    unsigned DI
    size <integer_cst 0x2a9559a090 type <integer_type 0x2a955992a0 bit_size_type> constant invariant 64>
    unit size <integer_cst 0x2a9559a150 type <integer_type 0x2a955991c0> constant invariant 8>
    align 64 symtab 0 alias set -1>
(gdb) call debug_tree (se.expr->common.type)
 <reference_type 0x2a959f6380
    type <array_type 0x2a959f62a0
        type <integer_type 0x2a95593540 int1 QI
            size <integer_cst 0x2a95591510 constant invariant 8>
            unit size <integer_cst 0x2a95591540 constant invariant 1>
            align 8 symtab 0 alias set -1 precision 8 min <integer_cst 0x2a955914b0 -128> max <integer_cst 0x2a955914e0 127>
            pointer_to_this <pointer_type 0x2a955a4000>>
        string-flag BLK
        size <integer_cst 0x2a959f04e0 constant invariant 640>
        unit size <integer_cst 0x2a959ebe40 constant invariant 80>
        align 8 symtab 0 alias set -1
        domain <integer_type 0x2a959f61c0 type <integer_type 0x2a95593b60 int8>
            DI
            size <integer_cst 0x2a95591930 constant invariant 64>
            unit size <integer_cst 0x2a95591a80 constant invariant 8>
            align 64 symtab 0 alias set -1 precision 64 min <integer_cst 0x2a959f2f60 1> max <integer_cst 0x2a959f5540 80>> reference_to_this <reference_type 0x2a959f6380>>
    unsigned DI
    size <integer_cst 0x2a9559a090 type <integer_type 0x2a955992a0 bit_size_type> constant invariant 64>
    unit size <integer_cst 0x2a9559a150 type <integer_type 0x2a955991c0> constant invariant 8>
    align 64 symtab 0 alias set -1>
(gdb)

Paul, is an assignment of a reference type to a pointer type OK?
fold_converting it makes us produce the following, in which the
cast looks very odd to me,

;; Function surface (surface_)

surface (fname, _fname)
{
  int4 ios;
  int1 * fname.0;

  _gfortran_filename = "t.f90";
  _gfortran_line = 5;
  _gfortran_ioparm.unit = 1;
  fname.0 = (int1 *)fname;
  _gfortran_ioparm.file = fname.0;
  _gfortran_ioparm.file_len = 80;
  _gfortran_ioparm.status = "old";
  _gfortran_ioparm.status_len = 3;
  _gfortran_ioparm.iostat = &ios;
  _gfortran_st_open ();
  return;
}

Anyway, with that fold_convert call inserted:

-------------------------------------------
Index: trans-io.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fortran/trans-io.c,v
retrieving revision 1.7
diff -c -3 -p -r1.7 trans-io.c
*** trans-io.c  22 Jun 2004 03:07:01 -0000      1.7
--- trans-io.c  28 Jun 2004 07:33:54 -0000
*************** set_string (stmtblock_t * block, stmtblo
*** 418,424 ****
    else
      {
        gfc_conv_string_parameter (&se);
!       gfc_add_modify_expr (&se.pre, io, se.expr);
        gfc_add_modify_expr (&se.pre, len, se.string_length);
      }

--- 419,425 ----
    else
      {
        gfc_conv_string_parameter (&se);
!       gfc_add_modify_expr (&se.pre, io, fold_convert (TREE_TYPE (io), se.expr));
        gfc_add_modify_expr (&se.pre, len, se.string_length);
      }

-------------------------------------------

but I got the feeling this is definitely papering over something.

Thoughts?

Gr.
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]