Bug 58644 - [OOP] Missing .data ref in passing a CLASS array as actual argument to a TYPE.
Summary: [OOP] Missing .data ref in passing a CLASS array as actual argument to a TYPE.
Status: WAITING
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2013-10-06 19:21 UTC by Tobias Burnus
Modified: 2017-01-11 14:26 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-03-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2013-10-06 19:21:04 UTC
Found while looking at the dump. The code seems to work at run time on all targets.


Looking at gfortran.dg/class_to_type_2.f90, one has:

  function g () result(res)
    class(foo), allocatable :: res(:)
    allocate (res(3))
    res(:)%i = 55
  end function g

  subroutine subpr2_array (x)
    type(foo) :: x(:)
    if (any(x(:)%i /= 55)) call abort ()
  end subroutine

  call subpr2_array (g ())



For that one gets the dump:
          struct __class_mod_subpr_Foo_1_0a D.2108;
          D.2108 = g ();
          subpr2_array (&D.2108);

I believe that should be instead:
          subpr2_array (&D.2108.data);

As D.2108 is not a pointer and .data is the first field, it seems to work, though.
Comment 1 Dominique d'Humieres 2014-03-22 15:10:57 UTC
I don't understand this PR. The test succeeds even when compiled with -fsanitize=address.
Comment 2 Paul Thomas 2014-10-27 13:20:30 UTC
(In reply to Dominique d'Humieres from comment #1)
> I don't understand this PR. The test succeeds even when compiled with
> -fsanitize=address.

I think that the PR is justified. The actual argument should be as Tobias says. Both &D.2108 and &D.2108.data are valid address.  Not only this, they are the same address.  However, should we ever change the class ABI to put the vptr first, for example, then this will no longer work.

I believe that my imminent fix for PR63205 will correct this issue and so eliminate this PR.

Paul
Comment 3 Dominique d'Humieres 2015-09-29 17:22:48 UTC
> I believe that my imminent fix for PR63205 will correct this issue
> and so eliminate this PR.

Does it? If yes, this PR should be closed as FIXED. If no, what is missing?
Comment 4 Dominique d'Humieres 2017-01-11 14:26:29 UTC
> I believe that my imminent fix for PR63205 will correct this issue
> and so eliminate this PR.

With a clean trunk at r244231, I see

          subpr2_array (&atmp.39);

AFAIU this PR is not "eliminated".