[Bug fortran/52227] New: TARGET attribute mishandled in polymorphic types

[Bug fortran/52227] New: TARGET attribute mishandled in polymorphic types

[burnus at gcc dot gnu.org]

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

             Bug #: 52227
           Summary: TARGET attribute mishandled in polymorphic types
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: missed-optimization, rejects-valid, wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: pault@gcc.gnu.org


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

[Bug fortran/52227] [OOP] TARGET attribute mishandled in polymorphic types

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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"

[Bug fortran/52227] [OOP] TARGET attribute mishandled in polymorphic types

[burnus at gcc dot gnu.org]

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!

[Bug fortran/52227] [OOP] TARGET attribute mishandled in polymorphic types

[paul.richard.thomas at gmail dot com]

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

--- Comment #3 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot 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.

[Bug fortran/52227] [OOP] TARGET attribute mishandled in polymorphic types

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-11
     Ever confirmed|0                           |1

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

[Bug fortran/52227] [OOP] TARGET attribute mishandled in polymorphic types

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
The testcases in comment#0 and comment#1 are duplicates and work now.

I haven't checked the other remarks about handling of other attributes
extensively.  Duplicate volatile or asynchronous are detected,
although with a misleading error text, which is not class-specific.

Resolving as duplicate.

*** This bug has been marked as a duplicate of bug 106856 ***