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] | |
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] |