[Bug fortran/52265] [OOP] TREE dump confusing with nested SELECT TYPE

["paul.richard.thomas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #1 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> 2012-02-16 06:58:10 UTC ---
Dear Tobias,

I have encountered this in the work on PR41600.  I thought to append a
numeric identifier that increments with each new temporary.  In fact,
I had wondered whether, once the SELECT TYPE is working properly, we
should not simplify the name to __tmp.###?  The present complexity
serves no purpose, since we can tell from the type what tehse things
are.

Cheers

Paul

PS PR41600 is fixed, barring some cleaning up.  Correct code is being
produced but the compiler segfaults at the due to attempted double
frees of array_specs.  I am pretty sure that I know where this is
happening - I'll let you know at lunchtime.

On Wed, Feb 15, 2012 at 9:51 PM, burnus at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52265
>
>             Bug #: 52265
>           Summary: [OOP] TREE dump confusing with nested SELECT TYPE
>    Classification: Unclassified
>           Product: gcc
>           Version: 4.7.0
>            Status: UNCONFIRMED
>          Keywords: diagnostic
>          Severity: normal
>          Priority: P3
>         Component: fortran
>        AssignedTo: unassigned@gcc.gnu.org
>        ReportedBy: burnus@gcc.gnu.org
>                CC: pault@gcc.gnu.org
>
>
> The following program seems to work as expected, however, the dump is very
> irritating:
>
>        switch (a._vptr->_hash)
>          {
>            case 6231989:;
>            __tmp_type_t = a._data;
>            {
>              struct t * __tmp_type_t;
>
>              switch (b._vptr->_hash)
>                {
>                  case 6231989:;
>                  __tmp_type_t = b._data;
>                  *__tmp_type_t = *__tmp_type_t;
>
> There are two variables called "__tmp_type_t", one pointing to a._data and the
> other to b._data. Most striking is the last line where both variables occur.
> That's very confusing and would be impossible to do in C, C++, or Fortran.
>
> Expected: Use different variable names, e.g. via
>  gfc_create_var (type, "__tmp_type_t")
>
>
> type t
>  integer :: i = 5
> end type t
>
> class(t), allocatable :: a, b
>
> allocate(a,b)
> b%i = 77
> select type (a)
>  type is (t)
>   select type (b)
>     type is (t)
>       a = b
>       b%i = 88
>   end select
> end select
> if (a%i /= 77) call abort ()
> if (a%i /= 88) call abort ()
> end
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.