User account creation filtered due to spam.

Bug 52227 - [OOP] TARGET attribute mishandled in polymorphic types
Summary: [OOP] TARGET attribute mishandled in polymorphic types
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: missed-optimization, rejects-valid, wrong-code
Depends on:
Blocks:
 
Reported: 2012-02-13 09:39 UTC by Tobias Burnus
Modified: 2013-06-11 19:07 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-11 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-13 09:39:04 UTC
Seemingly, the TARGET attribute is mishandled. The following program gives:

  target :: a,b
              1
  Error: Duplicate TARGET attribute specified at (1)


Thus, there is a rejects valid issue. However, depending which variable is declared first, there is also a potential wrong-code issue as a TARGET variable might still get the "restrict" qualifier in the gimple representation. Or a nontarget might get no "restricted", which is a missed optimization.


The other attributes have to be checked as well. That includes VOLATILE and ASYNCHRONOUS. It might be enough that the variable has the proper attribute and that such the attribute is properly propagated; at least volatile seems to be handled correctly, but it should be re-checked. (Asynchronous is currently not used on gimple level, cf. PR49733/PR25829; nevertheless, it should be propagated correctly.)

I think the other attributes are either related to dimension/allocatable/pointer and already taken care of - or are dummy-related attributes such as optional, value (cf. PR51284), intent etc.



type t
end type t

class(t), allocatable :: a(:), b(:)
target :: a,b
select type (a)
  type is (t)
   select type (b)
     type is (t)
       a(1) = b(1)
   end select
end select
end
Comment 1 Tobias Burnus 2012-02-15 20:59:06 UTC
A related issue, for
 class(t), target, allocatable :: a(:)
 target :: a
no error is printed - but it should!

The problem seems to be that already for the first line, the class symbol is created - and the attr.target does not seem to get stored properly.

The same problem occurs for ALLOCATABLE or POINTER - but only if the variable is a dummy, otherwise class_ok is false and the creation is deferred. Example:

  type t
  end type t
contains
  subroutine foo(a,b)
    class(t) :: a, b
    allocatable :: a, b
    allocate(a,b)
  end subroutine
end

which fails with "ALLOCATABLE attribute conflicts with POINTER" while using "pointer" fails with "Duplicate POINTER attribute specified"
Comment 2 Tobias Burnus 2012-07-13 13:17:23 UTC
I think we need so change class.c's gfc_build_class_symbol. It currently only handles pointer/allocatable plus a (co)rank.

It seems to definitely lacks support for TARGET, judging by this PR, PR51610 and PR53951. At least I fear that some wrong-code bug is lurking there if TARGET is not properly set.

As written in comment 0, there might be other attributes which have to be taken into account, e.g. VOLATILE or ASYNCHRONUOUS.

Recall that when adding letters to the type name, either the number of allowed characters has to change or the length part in the hashing, otherwise, names might get cropped.

We should try to fix this issue soonish, as it is a nasty wrong-code issue (depending on the optimization and timing) and it affects the ABI!
Comment 3 paul.richard.thomas@gmail.com 2012-07-13 15:10:52 UTC
Hmmm!  OK - I guess that we need
class_pointer/class_target/class_allocatable attributes that are
retained by the symbol, rather than the container.

Cheers

Paul

PS I have to recover the steps between the last unlimited polymorphic
patch that I sent you and the present on, which does the job for
unlimited OOP but breaks something such that regressions run into the
hundreds.  I have stared at it for a couple of evenings but cannot see
what generates the problem.  If I do not see it by Sunday, I'll let
you take a look.

On 13 July 2012 15:17, burnus at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52227
>
> Tobias Burnus <burnus at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |janus at gcc dot gnu.org
>
> --- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-13 13:17:23 UTC ---
> I think we need so change class.c's gfc_build_class_symbol. It currently only
> handles pointer/allocatable plus a (co)rank.
>
> It seems to definitely lacks support for TARGET, judging by this PR, PR51610
> and PR53951. At least I fear that some wrong-code bug is lurking there if
> TARGET is not properly set.
>
> As written in comment 0, there might be other attributes which have to be taken
> into account, e.g. VOLATILE or ASYNCHRONUOUS.
>
> Recall that when adding letters to the type name, either the number of allowed
> characters has to change or the length part in the hashing, otherwise, names
> might get cropped.
>
> We should try to fix this issue soonish, as it is a nasty wrong-code issue
> (depending on the optimization and timing) and it affects the ABI!
>
> --
> 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 4 Dominique d'Humieres 2013-06-11 19:07:00 UTC
Still present at revision 199959.