Bug 47680 - [OOP] ICE with polymorphic array elements as dummy
Summary: [OOP] ICE with polymorphic array elements as dummy
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.8.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2011-02-10 14:53 UTC by Tobias Burnus
Modified: 2016-11-16 14:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.8.0
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2011-02-10 14:53:25 UTC 
Follow up to PR 47569.

The following program is invalid (Cf. F2008 12.5.2.4) - but my diagnostic in interface.c (cf. patch for PR 47569) is not reached due to an earlier ICE.

The problem is:

1898          else if (ref->type == REF_ARRAY && ref->u.ar.type == AR_FULL
1899                   && ref->u.ar.as->lower && ref->u.ar.as->upper)
1900            for (i = 0; i < ref->u.ar.as->rank; i++)

(gdb) p ref->u.ar
$4 = {type = AR_FULL, dimen = 0, codimen = 0, in_allocate = 0 '\000', where = {nextc = 0x148e95c, lb = 0x148e900}, as = 0x0, c_where = {{nextc = 0x0,
      lb = 0x0}, {nextc = 0x0, lb = 0x0}, {nextc = 0x0, lb = 0x0}, {nextc = 0x0, lb = 0x0}, {nextc = 0x0, lb = 0x0}, {nextc = 0x0, lb = 0x0}, {
      nextc = 0x0, lb = 0x0}}, start = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, end = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, stride = {0x0, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x0}, dimen_type = {0, 0, 0, 0, 0, 0, 0}, offset = 0x0}
(gdb) p ref->u.ar->as
$5 = (gfc_array_spec *) 0x0


I assume that that is a side effect of the extra BT_CLASS wrapper, but I might be wrong.

module m
type t
 integer :: i
end type t
contains
subroutine classtest(x)
  class(t) :: x(4)
  call foo(x(1)) ! <<<<< ICE
contains
  subroutine foo(a,b)
    class(t) :: a(*)
  end subroutine
end subroutine
end module m
Comment 1 janus 2011-02-10 21:09:40 UTC 
Actually I think it would be best to reject polymorphic arrays altogether for the 4.6 release, i.e. throw an error as soon as we encounter something like

>   class(t) :: x(4)

and tell the user that this feature is not yet supported.

This would convey a much cleaner message than the various ICEs one runs into at present. For 4.7 we can then take out the error message again, and start implementing polymorphic arrays.
Comment 2 Dominique d'Humieres 2011-02-10 21:16:27 UTC 
> Actually I think it would be best to reject polymorphic arrays altogether for
> the 4.6 release, i.e. throw an error as soon as we encounter something like
>
> >   class(t) :: x(4)
>
> and tell the user that this feature is not yet supported.
>
> This would convey a much cleaner message than the various ICEs one runs into at
> present. For 4.7 we can then take out the error message again, and start
> implementing polymorphic arrays.

I fully agree that it would be more user friendly (and prevent duplicates;-).
Comment 3 Mikael Morin 2013-01-15 21:43:32 UTC 
The ICE is gone in 4.8.0:

:11.20:

    class(t) :: a(*)
                    1
Error: Assumed size polymorphic objects or components, such as that at (1), have not yet been implemented
:8.11:

  call foo(x(1)) ! <<<<< ICE
           1
Error: Type mismatch in argument 'a' at (1); passed CLASS(t) to REAL(4)
Comment 4 Dominique d'Humieres 2013-06-10 16:31:46 UTC 
Per comment #3, this PR should probably be closed.
Comment 5 Mikael Morin 2013-06-10 17:24:13 UTC 
(In reply to Dominique d'Humieres from comment #4)
> Per comment #3, this PR should probably be closed.

Let's do it then.