This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[gfortran,patch] Correctly handle "empty" derived types


Hi all,

This patch makes the front-end correctly handle "empty" derived types,
ie derived types without a component. This is allowed by F2003 and was
enabled by Tobias, but all examples of declaring variables of such
types are were rejected.

The problem is that when a symbol->components field is NULL, the
front-end takes this to mean that the symbol for the derived type
isn't fully resolved (ie we don't know yet what the components are,
and we'll have to look into scoping units other than the current one).
Now that derived types can be empty, this is wrong, because these
empty derived types also have symbol->components == NULL. I thought
about two different ways of handling this:
  -- either we initially set symbol->components to a static constant
gfc_component * components_are_not_known_yet, and check for
(symbol->components == components_are_not_known_yet) instead of
(symbol->components == NULL)
  -- or we add a zero_comp attribute to mark empty derived types, and
check for (symbol->components == NULL && !symbol->attr.zero_comp)

I've chosen the second approach, because it seemed easier (there are,
AFAICT, more than one place where derived types symbols are
allocated), but if you think that one attribute is too high a price, I
can work on the second idea.

Regtested on x86_64-linux, manually tested on a few examples, will
come with testcases. OK to commit?

FX



:ADDPATCH fortran:

Attachment: empty_derived_type.ChangeLog
Description: Binary data

Attachment: empty_derived_type.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]