This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch,gfortran] ENUMERATIONS and ENUMERATORS
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: "Gaurav Gautam, Noida" <gauravga at noida dot hcltech dot com>
- Cc: fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org,Paul Brook <paul at codesourcery dot com>
- Date: Tue, 11 Oct 2005 22:43:08 +0200
- Subject: Re: [Patch,gfortran] ENUMERATIONS and ENUMERATORS
- References: <40CC5CC7CDACC048B1299C57025E330C010A031F@HSDLNTD1110010.noida.hcltech.com>
Gaurav Gautam, Noida wrote:
> I have modified the patch so that
>
> For an enumeration, the kind is selected such that an integer type with
> that kind is interoperable (15.2.1) with the corresponding C enumeration
> type.
>
>
> Also, an option -fshort-enums has been added, that ensures interoperability
> of enumerations when the corresponding C code has been compiled by gcc
> -fshort-enums.
>
>
> Same rules as that of gcc C front end have been used.
Your code supports the form
ENUM, BIND(C) etc.
of ENUM declarations. It doesn't support the form
ENUM (scalar-int-initialization-expr)
and it can't easily be extended to do so since the correct kind for the latter
can only be determined during resolution, and the same goes for the value
assignment and range checking.
I'd strongly prefer if you moved the checks and the kind determination to the
resolution stage, so that one can easily add the second form of the ENUM
statement (if you don't want to do so yourself) on top of what you did.
I also have a few remarks WRT the code which would also apply to a revised
version:
- there are a number of cases where you're not following the coding standards
(trailing whitespace, spaces around '->', maybe others)
- I think the function prototypes you added can safely be put into parse.h,
otherwise don't hesistate to put them in gfortran.h
- the logic here would be much easier if you moved the check for COMP_ENUM
before the other if
> if (d == DECL_NONE || d == DECL_COLON)
> ! {
> ! if (gfc_current_state () == COMP_ENUM)
> ! {
> ! t = gfc_add_flavor (¤t_attr, FL_PARAMETER, NULL, NULL);
> ! if (t == FAILURE)
> ! {
> ! m = MATCH_ERROR;
> ! goto cleanup;
> ! }
> ! current_attr.enumerator = 1;
> ! }
> ! break;
> ! }
> ! else if (gfc_current_state () == COMP_ENUM)
> ! {
> ! gfc_error ("Enumerator cannot have attributes %C");
> ! return MATCH_ERROR;
> ! }
the same goes for the change to variable_decl.
I'm wondering if using gfc_match_data_decl makes much sense given the very
restricted syntax that is allowed inside enumeration declarations.
Thanks,
- Tobi