Bug 34784 - [4.2/4.3 Regression] implicit character(s) hides type of selected_int_kind intrinsic
Summary: [4.2/4.3 Regression] implicit character(s) hides type of selected_int_kind in...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.2.3
Assignee: Paul Thomas
URL:
Keywords: rejects-valid
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-01-14 21:34 UTC by Dick Hendrickson
Modified: 2008-03-30 21:37 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-01-17 21:34:19


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-01-14 21:34:58 UTC
When I have an IMPLICIT CHARACTER(S) statement above a declaration,
the SELECTED_INT_KIND( ) function is diagnosed as a character function
with the message


u_dimension.f:3.50:

      INTEGER, DIMENSION(0:20) ::  IP_ARRAY1_3_S =
                                                 1
Error: Can't convert CHARACTER(1) to INTEGER(4) at (1)

      MODULE U_TESTS
      implicit character(s)
      INTEGER, DIMENSION(0:20) ::  IP_ARRAY1_3_S =
     $     (/ (SELECTED_INT_KIND(J1),J1=0,20) /)
      END MODULE U_TESTS


Note, I've gotten the same error message in other contexts.  This might
be a broader problem that just the selected_int_kind function in a
unusual use.  If it isn't obvious to you that there is a more general
problem than this isolated example, I'll try to track down some more
examples.

Dick Hendrickson
Comment 1 Dick Hendrickson 2008-01-15 20:49:33 UTC
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
Comment 2 Paul Thomas 2008-01-16 17:33:44 UTC
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
Comment 3 Paul Thomas 2008-01-17 21:34:19 UTC
I have a one line fix for this, which will be applied as obvious tomorrow morning.

Paul
Comment 4 Paul Thomas 2008-01-18 09:25:37 UTC
Dang it!  I posted the fix for this one on PR34785.

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

Paul
Comment 5 Paul Thomas 2008-01-20 08:23:43 UTC
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

Comment 6 Paul Thomas 2008-01-20 08:43:58 UTC
Fixed on trunk

Paul
Comment 7 Paul Thomas 2008-01-20 16:59:08 UTC
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

Comment 8 Dick Hendrickson 2008-01-23 18:31:20 UTC
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.
>
Comment 9 Tobias Burnus 2008-03-30 21:37:46 UTC
(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).