[Bug fortran/28722] New: Fortran front-end produces mismatch trees

[Bug fortran/28722] New: Fortran front-end produces mismatch trees

[pinskia at gcc dot gnu dot org]

/src/gcc/local/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90: In
function 'option_stopwatch_s':^M
/src/gcc/local/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:63:
error: statement types mismatch^M
(*D.1170)[S.73D.1171]{lb: 0 sz: _a.72D.1168} = (*D.1173)[S.74D.1174];^M
^M
charD.14[1:_aD.1051]^M
charD.14[1:6]^M
/src/gcc/local/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90:63:
internal compiler error: verify_stmts failed^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <URL:http://gcc.gnu.org/bugs.html> for instructions.^M

FAIL: gfortran.dg/actual_array_constructor_1.f90  -O0  (internal compiler
error)
FAIL: gfortran.dg/actual_array_constructor_1.f90  -O0  (test for excess errors)


-- 
           Summary: Fortran front-end produces mismatch trees
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 22368
             nThis:


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2006-08-18 18:28 -------
Andrew,

How, when and where does this happen, please?

Paul 


-- 


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-18 19:13 -------
This happens when the first patch in PR 22368 is added.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|                            |i686-pc-linux-gnu


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]



------- Comment #3 from fxcoudert at gcc dot gnu dot org  2006-10-02 15:24 -------
Here's a detailed analysis of the current testsuite failures with Andrew's
patches from PR22368 (all patches applied) on i686-linux.

First testcase (from actual_array_constructor_1.f90):

  subroutine bar(a)
    character(len=*) :: a
    call foo((/ a, 'g' /))
  end

The error message issued is
actual_array_constructor_1.f90: In function ‘bar’:
actual_array_constructor_1.f90:3: error: statement types mismatch
(*D.941)[S.9D.942]{lb: 0 sz: _a.8D.939} = D.946;

charD.14[1:_aD.902]
charD.14[1:1]
actual_array_constructor_1.f90:3: internal compiler error: verify_stmts failed



Second testcase:

  interface
    pure function double (string)
      character (len = *), intent (in) :: string
      character (len = len (string)) :: double
    end function double
  end interface

  print *, f5("foo")

contains
  function f5 (string)
    character (len = *) :: string
    character (len = len (double (string))) :: f5
    f5 = ''
  end function f5

end

returns (at -O1):

char_result_1.f90: In function ‘MAIN__’:
char_result_1.f90:1: error: statement types mismatch
D.949_16 = stringD.939_11;

charD.14[1:3] &
charD.14[1:_stringD.907] &
char_result_1.f90:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


Third testcase:

  real c
  if (loc(c) == 0) call abort
  end

produces:

loc_2.f90: In function ‘MAIN__’:
loc_2.f90:2: error: types mismatch in comparsion
<unnamed type>

int4D.2

D.903 == 0;

loc_2.f90:2: internal compiler error: verify_stmts failed



Fourth testcase:

  call foo("g")
contains
  subroutine foo (s)
    character(*), optional :: s
    if (present(s)) call abort
  end subroutine
end

produces

missing_optional_dummy_1.f90: In function ‘MAIN__’:
missing_optional_dummy_1.f90:1: error: types mismatch in comparsion
charD.14[1:_sD.904] *

charD.14[1:1] *

sD.913_1 != 0B;

missing_optional_dummy_1.f90:1: internal compiler error: verify_stmts failed


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-10-02 15:24:35
               date|                            |


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[fxcoudert at gcc dot gnu dot org]

------- Comment #4 from fxcoudert at gcc dot gnu dot org  2006-10-30 08:30 -------
(In reply to comment #3)
>   real c
>   if (loc(c) == 0) call abort
>   end

This one has been fixed on mainline.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-10-02 15:24:35         |2006-10-30 08:30:34
               date|                            |


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[tobi at gcc dot gnu dot org]

------- Comment #5 from tobi at gcc dot gnu dot org  2007-03-21 14:54 -------
Behavior is different with today's mainline on i386-darwin.

Without optimization the first one gives an error further down the line, and
the other three pass:
1.f90:3: internal compiler error: in simplify_subreg, at simplify-rtx.c:4671
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

With optimization, the first three pass, and the fourth gives the same error
that FX has seen.


-- 

tobi at gcc dot gnu dot org changed:

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


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[tobi at gcc dot gnu dot org]

------- Comment #6 from tobi at gcc dot gnu dot org  2007-03-21 15:04 -------
I don't understand why it fails in the fourth case.  The comparison it seems to
complain about is generated via
  return build2 (NE_EXPR, boolean_type_node, decl,
                 fold_convert (TREE_TYPE (decl), null_pointer_node));
(trans-expr.c:141) which looks like it gets the types right.  Replacing the
call to fold_convert with an equivalent call to build_int_cst doesn't help
either, BTW.


-- 


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[pault at gcc dot gnu dot org]

------- Comment #7 from pault at gcc dot gnu dot org  2007-04-10 09:28 -------
(In reply to comment #6)
Tobi,

> (trans-expr.c:141) which looks like it gets the types right.  Replacing the
> call to fold_convert with an equivalent call to build_int_cst doesn't help
> either, BTW.

Does casting the decl to be of the same type as null_pointer_node help?
ie;

  decl = fold_convert (TREE_TYPE (null_pointer_node), decl);

  return build2 (NE_EXPR, boolean_type_node, decl, null_pointer_node);

Paul


-- 


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2007-08-24 16:03 -------
None of the testcases in comment #3 fail on the mainline configured with
--enable-checking=yes,types.  So either this bug is fixed or the patches from
Andrew did some slightly different checking.  Or both ;)


-- 


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

[Bug fortran/28722] Fortran front-end produces mismatch trees

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-11-02 14:55 -------
Type-checking is now in mainline, and PR31608 is tracking the last remaining
failure exposed in the testsuite. Closing this PR.


-- 

fxcoudert at gcc dot gnu dot org changed:

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


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