public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/55765] New: Remaining issues with unlimited polymorphic (CLASS(*))
@ 2012-12-20 17:27 burnus at gcc dot gnu.org
2012-12-21 10:53 ` [Bug fortran/55765] " burnus at gcc dot gnu.org
2013-06-20 18:39 ` dominiq at lps dot ens.fr
0 siblings, 2 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-12-20 17:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55765
Bug #: 55765
Summary: Remaining issues with unlimited polymorphic (CLASS(*))
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: burnus@gcc.gnu.org
CC: pault@gcc.gnu.org
Depends on: 55763
Issues related to CLASS(*)
- Smaller bugs, cf. PR 55763
- As mentioned in the submittal email,
http://gcc.gnu.org/ml/fortran/2012-12/msg00090.html
> Some parts of the code, relating to the handling of intrinsic
> expressions, are near duplicates of exiting code for derived types;
> for example class.c( gfc_find_intrinsic_vtab). I did this in order to
> maximise the separation of the treatment of unlimited polymorphism
> from existing code in the compiler in order that the risk of
> regression be minimised. This new code can be absorbed later on; eg.
> gfc_find_intrinsic_vtab into gfc_find_derived_vtab.
- CLASS(*) currently doesn't handle nonconstant strings. Currently, for each
string a new __vtab is generated which encodes the string length. The proper
way is to store the information in the variable itself. There are two
possibilities: (a) Either extend the class container to store this information
(b) Use an array descriptor or similar to store this information
(b) requires the new array descriptor and is in line of TR 29113:2012, where at
least for strings the full array descriptor is passed (with BIND(C)), cf.
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf See 8.7, (6) (b) and (c) and
8.3 - in particular "size_t elem_len" which together with the type (char(kind=1
or 4)) can be used to determine the length.
(a) requires an additional field in the class container. In principle, it could
come last, but that will prevent the extension of the rank. Currently, one has
{ _data, _vtpr } and for assumed-rank, one passes a max-rank (rank-7) array to
make sure the offset to _vptr is correct. With {_vptr, _data}, the last item
could remain the actual size; but with {_vptr, _data, int string_len } that
won't work. Cf. PR 53971.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/55765] Remaining issues with unlimited polymorphic (CLASS(*))
2012-12-20 17:27 [Bug fortran/55765] New: Remaining issues with unlimited polymorphic (CLASS(*)) burnus at gcc dot gnu.org
@ 2012-12-21 10:53 ` burnus at gcc dot gnu.org
2013-06-20 18:39 ` dominiq at lps dot ens.fr
1 sibling, 0 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-12-21 10:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55765
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-21 10:52:51 UTC ---
One probably should audit all calls to gfc_find_derived_vtab whether also
CLASS(*) could occur in that context; e.g. TRANSFER comes into my mind.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/55765] Remaining issues with unlimited polymorphic (CLASS(*))
2012-12-20 17:27 [Bug fortran/55765] New: Remaining issues with unlimited polymorphic (CLASS(*)) burnus at gcc dot gnu.org
2012-12-21 10:53 ` [Bug fortran/55765] " burnus at gcc dot gnu.org
@ 2013-06-20 18:39 ` dominiq at lps dot ens.fr
1 sibling, 0 replies; 3+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-06-20 18:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55765
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2013-06-20
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Marked as ASSIGNED.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-06-20 18:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-20 17:27 [Bug fortran/55765] New: Remaining issues with unlimited polymorphic (CLASS(*)) burnus at gcc dot gnu.org
2012-12-21 10:53 ` [Bug fortran/55765] " burnus at gcc dot gnu.org
2013-06-20 18:39 ` dominiq at lps dot ens.fr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).