Bug 34784

Another example in executable code

      MODULE s_TESTS
      IMPLICIT CHARACTER (P)
      CONTAINS
      subroutine simple (u,j1)
      optional ::  j1
      if (present (j1)) stop
      end subroutine
      END MODULE s_TESTS

This regression enters between 4.1/20050803 and 4.2/20061221.

gfc_check_constructor_type is applying the wrong type, because the intrinsic has not been resolved. (This is called from gfc_match_init_expr via gfc_resolve_expr.).

I'll continue to investigate but think that resolution and check_init_expr are occurring in the wrong order.

Cheers

Paul

I have a one line fix for this, which will be applied as obvious tomorrow morning.

Paul

Dang it!  I posted the fix for this one on PR34785.

It has to hold until the weekend for reasons described there.

Paul

Subject: Bug 34784

Author: pault
Date: Sun Jan 20 08:22:56 2008
New Revision: 131675

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131675
Log:
2008-01-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34784
	* array.c (gfc_check_constructor_type): Clear the expression ts
	so that the checking starts from the deepest level of array
	constructor.
	* primary.c (match_varspec): If an unknown type is changed to
	default character and the attempt to match a substring fails,
	change it back to unknown.

	PR fortran/34785
	* trans-array.c (gfc_add_loop_ss_code) : If ss->string_length is
	NULL for an array constructor, use the cl.length expression to
	build it.
	(gfc_conv_array_parameter): Change call to gfc_evaluate_now to
	a tree assignment.


2008-01-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34784
	* gfortran.dg/array_constructor_20.f90: New test.
	* gfortran.dg/mapping_2.f90: Correct ubound expression for h4.

	PR fortran/34785
	* gfortran.dg/array_constructor_21.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/array_constructor_20.f90
    trunk/gcc/testsuite/gfortran.dg/array_constructor_21.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/fortran/primary.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

Fixed on trunk

Paul

Subject: Bug 34784

Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131679
Log:
2008-01-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34861
	* resolve.c (resolve_entries): Do not do an array bounds check
	if the result symbols are the same.

	PR fortran/34854
	* module.c (read_module) : Hide the symtree of the previous
	version of the symbol if this symbol is renamed.

2008-01-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34784
	* gfortran.dg/mapping_2.f90: Correct ubound expression for h4.

	PR fortran/34861
	* gfortran.dg/entry_array_specs_3.f90: New test.

	PR fortran/34854
	* gfortran.dg/use_rename_1.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/entry_array_specs_3.f90
    trunk/gcc/testsuite/gfortran.dg/use_rename_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/mapping_2.f90

Subject: Re:  [4.2/4.3 Regression] implicit character(s) hides type of selected_int_kind intrinsic

I have another example of what might be the same problem, although the
symptoms are
a little different.  the error message is

C:gfortran v_ice.f
v_ice.f:21.72:

      END MODULE TESTS
                                                                       1
Internal Error at (1):
gfc_convert_constant(): Unexpected type

If I use either
      IMPLICIT CHARACTER (D)
      IMPLICIT CHARACTER (E)
things compile, although I'd have expected a problem with either
DIGITS or EPSILON.

A procedure question.  Is this the One True Way to add additional
comments or tests
about a bug report?  Or is there a better way?

Dick Hendrickson


      MODULE TESTS
      IMPLICIT CHARACTER (M)
      CONTAINS
      SUBROUTINE VF0010(IDA1,IDA2,RDA,QDA)
      INTEGER(4) IDA1(5)
      INTEGER(4) IDA2(5)
      REAL(4) RLA(5)
      REAL(4) RDA(5)
      REAL(8) QDA(5)
      REAL(8) DCA(5)
!  I N I T I A L I Z A T I O N  S E C T I O N
      INTEGER(KIND=4) :: TEST_ARRAY
     $(SUM((/DIGITS(1),DIGITS(RLA(2)),DIGITS(DCA),DIGITS(QDA)/))/10,
     $  MIN(6_4,
     $       INT((EPSILON(RLA)+EPSILON(ABS(QDA))+EPSILON(DCA))*1.E6)),
     $  INT(MIN(RDA(1),HUGE(RLA)/10)+MIN(QDA(1),HUGE(QDA)/10)
     $      +MIN(1,HUGE(IDA2))),
     $  MIN(6,MAXEXPONENT(1.0_8)+MAXEXPONENT(RLA)+
     $          MAXEXPONENT(QDA)))
      END SUBROUTINE
      END MODULE TESTS


On 20 Jan 2008 16:59:09 -0000, pault at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #7 from pault at gcc dot gnu dot org  2008-01-20 16:59 -------
> Subject: Bug 34784
>
> Author: pault
> Date: Sun Jan 20 16:58:15 2008
> New Revision: 131679
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131679
> Log:
> 2008-01-20  Paul Thomas  <pault@gcc.gnu.org>
>
>         PR fortran/34861
>         * resolve.c (resolve_entries): Do not do an array bounds check
>         if the result symbols are the same.
>
>         PR fortran/34854
>         * module.c (read_module) : Hide the symtree of the previous
>         version of the symbol if this symbol is renamed.
>
> 2008-01-20  Paul Thomas  <pault@gcc.gnu.org>
>
>         PR fortran/34784
>         * gfortran.dg/mapping_2.f90: Correct ubound expression for h4.
>
>         PR fortran/34861
>         * gfortran.dg/entry_array_specs_3.f90: New test.
>
>         PR fortran/34854
>         * gfortran.dg/use_rename_1.f90: New test.
>
> Added:
>     trunk/gcc/testsuite/gfortran.dg/entry_array_specs_3.f90
>     trunk/gcc/testsuite/gfortran.dg/use_rename_1.f90
> Modified:
>     trunk/gcc/fortran/ChangeLog
>     trunk/gcc/fortran/module.c
>     trunk/gcc/fortran/resolve.c
>     trunk/gcc/testsuite/ChangeLog
>     trunk/gcc/testsuite/gfortran.dg/mapping_2.f90
>
>
> --
>
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34784
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>

(reply to comment #8)
> I have another example of what might be the same problem, although the
> symptoms are a little different.

This test case seems to work meanwhile (both in gfortran 4.3.0 and 4.4.0, it fails in 4.2.2).