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

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

[burnus at gcc dot gnu.org]

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

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

[paul.richard.thomas at gmail dot com]

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.

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

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #2 from janus at gcc dot gnu.org 2012-06-08 18:21:36 UTC ---
(In reply to comment #0)
> Expected: Use different variable names, e.g. via
>   gfc_create_var (type, "__tmp_type_t")

I guess the technical problem here is that the temporaries are created already
at resolution stage (in resolve_select_type) on a gfc_symtree level, while
gfc_create_var operates on tree-level (at translation stage).

Do we have any other mechanism for creating temporaries, which could be
employed here? Or do we need to generate a numerically-decorated (or
'randomized') name by hand?

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

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

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-06-10 08:42:44 UTC ---

> Do we have any other mechanism for creating temporaries, which could be
> employed here? Or do we need to generate a numerically-decorated (or
> 'randomized') name by hand?

There is create_var in frontend-passes.c.  It probably does most
of what you would want for another frontend-created variable.

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

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-10-13
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Still present at r228753.