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

François-Xavier Coudert fxcoudert@gmail.com
Tue Sep 18 13:09:00 GMT 2007

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?


:ADDPATCH fortran:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty_derived_type.ChangeLog
Type: application/octet-stream
Size: 506 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070918/b3a73e9a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty_derived_type.diff
Type: application/octet-stream
Size: 4792 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070918/b3a73e9a/attachment-0001.obj>

More information about the Gcc-patches mailing list