[Bug fortran/57305] New: ICE with warnings and unlimited polymorphic (incorrect code)

[Bug fortran/57305] New: ICE with warnings and unlimited polymorphic (incorrect code)

[vladimir.fuka at gmail dot com]

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

            Bug ID: 57305
           Summary: ICE with warnings and unlimited polymorphic (incorrect
                    code)
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vladimir.fuka at gmail dot com

Created attachment 30135
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30135&action=edit
source

The attached code produces ICE with recent build of 4.8:
 gfortran ice6.f90  -fopenmp -Wall

f951: internal compiler error: NeoprĂĄvnÄĂ˝ pĹĂ­stup do pamÄi (SIGSEGV)
0x8ba79f crash_signal
        ../../gcc-4.8-20130509/gcc/toplev.c:332
0x5d6021 __gmpz_get_ui
        /usr/include/gmp.h:1744
0x5d6021 gfc_target_expr_size(gfc_expr*)
        ../../gcc-4.8-20130509/gcc/fortran/target-memory.c:143
0x5445cd gfc_calculate_transfer_sizes(gfc_expr*, gfc_expr*, gfc_expr*, unsigned
long*, unsigned long*, unsigned long*)
        ../../gcc-4.8-20130509/gcc/fortran/check.c:4028
0x544788 gfc_check_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
        ../../gcc-4.8-20130509/gcc/fortran/check.c:4093
0x56dffa check_specific
        ../../gcc-4.8-20130509/gcc/fortran/intrinsic.c:3928
0x57ad1e gfc_intrinsic_func_interface(gfc_expr*, int)
        ../../gcc-4.8-20130509/gcc/fortran/intrinsic.c:4144
0x5b690f resolve_unknown_f
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:2602
0x5b690f resolve_function
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:3204
0x5b690f gfc_resolve_expr(gfc_expr*)
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:6544
0x5bc0a9 resolve_code
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:10135
0x5bbe8b gfc_resolve_blocks(gfc_code*, gfc_namespace*)
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:9449
0x5bc0ea resolve_code
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:10121
0x5bec4e resolve_codes
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:14975
0x5afb22 gfc_resolve
        ../../gcc-4.8-20130509/gcc/fortran/resolve.c:15003
0x5a4662 resolve_all_program_units
        ../../gcc-4.8-20130509/gcc/fortran/parse.c:4406
0x5a4662 gfc_parse_file()
        ../../gcc-4.8-20130509/gcc/fortran/parse.c:4673
0x5dfd15 gfc_be_parse_file
        ../../gcc-4.8-20130509/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-422466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu May 16 18:45:50 2013
Return-Path: <gcc-bugs-return-422466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17093 invoked by alias); 16 May 2013 18:45:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17051 invoked by uid 48); 16 May 2013 18:45:46 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57303] [4.7/4.8/4.9 Regression] struct miscompiled at -O1 and above
Date: Thu, 16 May 2013 18:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57303-4-fjYZDgY0wd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57303-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57303-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg01139.txt.bz2
Content-length: 529

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW303

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
statement_sink_location in

          /* A killing definition is not a use.  */
          if (gimple_assign_single_p (use_stmt)
              && gimple_vdef (use_stmt)
              && operand_equal_p (gimple_assign_lhs (stmt),
                                  gimple_assign_lhs (use_stmt), 0))
            continue;

doesn't check:

(gdb) call debug_gimple_stmt (use_stmt)
# .MEM_11 = VDEF <.MEM_10>
y.f0 = y.f0;

[Bug fortran/57305] ICE with warnings and unlimited polymorphic (incorrect code)

[vladimir.fuka at gmail dot com]

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

--- Comment #1 from Vladimir Fuka <vladimir.fuka at gmail dot com> ---
Created attachment 30136
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30136&action=edit
ice7.f90 (second source)

[Bug fortran/57305] ICE with warnings and unlimited polymorphic (incorrect code)

[vladimir.fuka at gmail dot com]

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

--- Comment #2 from Vladimir Fuka <vladimir.fuka at gmail dot com> ---
Connected error:

 gfortran -Wall -c ice7.f90
ice7.f90: In function âadd_element_polyâ:
ice7.f90:25:0: internal compiler error: in lhd_incomplete_type_error, at
langhooks.c:203
         dummy = memcpy(loc(a(size(tmp)+1)),loc(e),sizeof(e))
 ^
0x7d3bbc lhd_incomplete_type_error(tree_node const*, tree_node const*)
        ../../gcc-4.8-20130509/gcc/langhooks.c:203
0xa200db size_in_bytes(tree_node const*)
        ../../gcc-4.8-20130509/gcc/tree.c:2379
0x61748f gfc_conv_intrinsic_sizeof
        ../../gcc-4.8-20130509/gcc/fortran/trans-intrinsic.c:5209
0x61df6d gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
        ../../gcc-4.8-20130509/gcc/fortran/trans-intrinsic.c:6824
0x6098e2 gfc_conv_function_expr
        ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:5547
0x609dca gfc_conv_expr(gfc_se*, gfc_expr*)
        ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6258
0x6058da gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
        ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:4230
0x60992a gfc_conv_function_expr
        ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:5566
0x609dca gfc_conv_expr(gfc_se*, gfc_expr*)
        ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:6258
0x60f3a6 gfc_trans_assignment_1
        ../../gcc-4.8-20130509/gcc/fortran/trans-expr.c:7739
0x5e3975 trans_code
        ../../gcc-4.8-20130509/gcc/fortran/trans.c:1422
0x6274c8 gfc_trans_if_1
        ../../gcc-4.8-20130509/gcc/fortran/trans-stmt.c:965
0x627454 gfc_trans_if_1
        ../../gcc-4.8-20130509/gcc/fortran/trans-stmt.c:988
0x62cb7a gfc_trans_if(gfc_code*)
        ../../gcc-4.8-20130509/gcc/fortran/trans-stmt.c:1015
0x5e37d7 trans_code
        ../../gcc-4.8-20130509/gcc/fortran/trans.c:1519
0x600c92 gfc_generate_function_code(gfc_namespace*)
        ../../gcc-4.8-20130509/gcc/fortran/trans-decl.c:5397
0x5a49d0 translate_all_program_units
        ../../gcc-4.8-20130509/gcc/fortran/parse.c:4474
0x5a49d0 gfc_parse_file()
        ../../gcc-4.8-20130509/gcc/fortran/parse.c:4688
0x5dfd15 gfc_be_parse_file
        ../../gcc-4.8-20130509/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-422470-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu May 16 19:10:33 2013
Return-Path: <gcc-bugs-return-422470-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6777 invoked by alias); 16 May 2013 19:10:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6724 invoked by uid 48); 16 May 2013 19:10:26 -0000
From: "vladimir.fuka at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57305] ICE with warnings and unlimited polymorphic
Date: Thu, 16 May 2013 19:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vladimir.fuka at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57305-4-zlodbesGny@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57305-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57305-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg01143.txt.bz2
Content-length: 196

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW305

--- Comment #3 from Vladimir Fuka <vladimir.fuka at gmail dot com> ---
The first one is incorrect code, the other one compiles with ifort 13.1.

[Bug fortran/57305] ICE with warnings and unlimited polymorphic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-11
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
For the first test I get

pr57305.f90:13.8:

        a(1:size(tmp)) = transfer(tmp,a)
        1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator
pr57305.f90:14.8:

        a(size(tmp)+1) = transfer(e,a)
        1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator

for 4.8.1 and trunk. I get the ICE for the second test at revision 199959.

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
                 CC|                            |janus at gcc dot gnu.org
            Summary|ICE with warnings and       |[OOP] ICE when calling
                   |unlimited polymorphic       |SIZEOF on an unlimited
                   |                            |polymorphic variable

--- Comment #5 from janus at gcc dot gnu.org ---
The ICE on comment 1 seems to be due to the SIZEOF call. Reduced test case:


subroutine add_element_poly(e)
  class(*) :: e
  print *, sizeof(e)
end subroutine


Fails with 4.8 and current trunk.

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> The ICE on comment 1 seems to be due to the SIZEOF call.

... which is basically because SIZEOF is supposed to return the size of the
declared type, and a CLASS(*) doesn't really have a declared type, cf. also

http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html

Of course SIZEOF is a GNU extension, so we are free to define its behavior in
any way we please. I don't remember why it was chosen to take the size of the
declared type back in the day. When it was implemented for polymorphics,
CLASS(*) was not yet available in gfortran.

One way out: You could use STORAGE_SIZE, which is standard F08 and returns the
size of the *dynamic* type. Also it seems to work well with CLASS(*).

In any case the ICE should be fixed by one of the following approaches:
1) reject SIZEOF on CLASS(*)
2) make it return 0 for CLASS(*)
3) make it return the size of the dynamic type

Option #3 is probably what you were expecting, right? I don't see any reason
for not going this route, except that changing behavior is bad in general. But
if it fixes an ICE, I guess it's not that bad after all ...

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Created attachment 30682
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30682&action=edit
patch

Here is a preliminary patch to make SIZEOF return the size of the dynamic type
for polymorphic variables, which at the same time fixes the ICE on CLASS(*)
variables.

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #7)
> Here is a preliminary patch to make SIZEOF return the size of the dynamic
> type for polymorphic variables, which at the same time fixes the ICE on
> CLASS(*) variables.

Of course this fails on storage_size_1, which expects the old behavior for
CLASS variables, but otherwise it regtests cleany.

Index: gcc/testsuite/gfortran.dg/storage_size_1.f08
===================================================================
--- gcc/testsuite/gfortran.dg/storage_size_1.f08    (revision 201896)
+++ gcc/testsuite/gfortran.dg/storage_size_1.f08    (working copy)
@@ -25,7 +25,7 @@ if (storage_size(a)  /= 64) call abort()
 if (sizeof(b)        /= 24) call abort()
 if (storage_size(b)  /= 64) call abort()

-if (sizeof(cp)       /=  8) call abort()
+if (sizeof(cp)       /= 12) call abort()
 if (storage_size(cp) /= 96) call abort()

 end

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

--- Comment #9 from janus at gcc dot gnu.org ---
And of course the changed behavior should be reflected in the documentation:


Index: gcc/fortran/intrinsic.texi
===================================================================
--- gcc/fortran/intrinsic.texi    (revision 201896)
+++ gcc/fortran/intrinsic.texi    (working copy)
@@ -11546,7 +11546,7 @@ number of bytes occupied by the argument.  If the
 to is returned.  If the argument is of a derived type with @code{POINTER}
 or @code{ALLOCATABLE} components, the return value does not account for
 the sizes of the data pointed to by these components. If the argument is
-polymorphic, the size according to the declared type is returned. The argument
+polymorphic, the size according to the dynamic type is returned. The argument
 may not be a procedure or procedure pointer.

 @item @emph{Example}:

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Any reason why the patch in comment 7 has not been applied? I have it in my
working tree since a while without any associated problem.

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #10)
> Any reason why the patch in comment 7 has not been applied?

It was posted at http://gcc.gnu.org/ml/fortran/2013-08/msg00068.html some time
ago, but did not directly get an ok and was apparently forgotten about again.

TODO: A proper treatment of array arguments seems to be missing for both SIZEOF
and STORAGE_SIZE.

Question is whether the patch should be applied now and the array treatment
added later, or if it should happen in one go.

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> TODO: A proper treatment of array arguments seems to be missing for both SIZEOF 
> and STORAGE_SIZE.

??? besides

if (sizeof(b)        /= 24) call abort()
if (storage_size(b)  /= 64) call abort()

> Question is whether the patch should be applied now and the array treatment 
> added later, or if it should happen in one go.

Unless the patch remove the ICE by silent wrong codes, I'ld say incremental fix
is not bad.

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

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

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
AFAICT this PR has been fixed by r213079.

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305

--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #13)
> AFAICT this PR has been fixed by r213079.

Yes. I have implemented it to return - as in comment 6's option (c): It returns
the size of the dynamic type.

However, I missed to do what comment 9 mentioned: Updating the documentation. I
will do this as follow-up patch.


(In reply to janus from comment #11)
> TODO: A proper treatment of array arguments seems to be missing for both
> SIZEOF and STORAGE_SIZE.

Seems to work okay: It returns the element-size times array size. For a
noncontiguous array, SIZEOF is not really defined – and for STORAGE_SIZE should
simply return the size in bytes, which should be fine as well.

Does anyone see a problem with the current implementation?
>From gcc-bugs-return-457150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 26 17:57:16 2014
Return-Path: <gcc-bugs-return-457150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16154 invoked by alias); 26 Jul 2014 17:57:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16093 invoked by uid 55); 26 Jul 2014 17:57:12 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61888] Wrong results with SIZEOF and assumed-rank arrays
Date: Sat, 26 Jul 2014 17:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: rejects-valid, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61888-4-CcoNNWJPYC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61888-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61888-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg01741.txt.bz2
Content-length: 606

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida888

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Sat Jul 26 17:56:39 2014
New Revision: 213085

URL: https://gcc.gnu.org/viewcvs?rev!3085&root=gcc&view=rev
Log:
Follow up to r213079.

2014-07-26  Tobias Burnus  <burnus@net-b.de>

        PR fortran/61881
        PR fortran/61888
        PR fortran/57305
        * intrinsic.texi (SIZEOF): Document changed behavior
        for polymorphic arrays.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/intrinsic.texi
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305

--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Sat Jul 26 17:56:39 2014
New Revision: 213085

URL: https://gcc.gnu.org/viewcvs?rev=213085&root=gcc&view=rev
Log:
Follow up to r213079.

2014-07-26  Tobias Burnus  <burnus@net-b.de>

        PR fortran/61881
        PR fortran/61888
        PR fortran/57305
        * intrinsic.texi (SIZEOF): Document changed behavior
        for polymorphic arrays.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/intrinsic.texi
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Close as FIXED in the GCC 5 trunk (alias 4.10).

[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Wed Sep  3 06:41:37 2014
New Revision: 214843

URL: https://gcc.gnu.org/viewcvs?rev=214843&root=gcc&view=rev
Log:
Missed that file in r213079 of 2014-07-26

2014-09-03  Tobias Burnus  <burnus@net-b.de>

        PR fortran/61881
        PR fortran/61888
        PR fortran/57305
        * gfortran.dg/sizeof_4.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/sizeof_4.f90
Modified:
    trunk/gcc/testsuite/ChangeLog