Bug 52265 - [OOP] TREE dump confusing with nested SELECT TYPE
Summary: [OOP] TREE dump confusing with nested SELECT TYPE
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2012-02-15 20:51 UTC by Tobias Burnus
Modified: 2015-10-13 13:29 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-10-13 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2012-02-15 20:51:12 UTC
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
Comment 1 paul.richard.thomas@gmail.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.
Comment 2 janus 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?
Comment 3 Thomas Koenig 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.
Comment 4 Dominique d'Humieres 2015-10-13 13:29:31 UTC
Still present at r228753.