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]

Re: [PATCH, fortran] Equivalence constraints and private types -redux


Tobi,

First, many thanks for reviewing this lot. I hope you realise that there are at least two more batches waiting in the wings. I have decided to try to clear as many of the PRs from Joost VandeVondele as I possibly can. Most are relatively trivial but, in total, they comprise one third of the outstanding fortran PRs. It's funny, I was initially inclined to view them as unimportant and trivial but a fortran compiler worth its salt had better recognise the standard, hadn't it?

Paul Thomas wrote:


OK for mainline and 4.03, when open?



Almost ok, except ...




--- 2638,2656 ----
goto cleanup;
}
! sym = set->expr->symtree->n.sym;
! ! if (gfc_add_in_equivalence (&sym->attr, sym->name, NULL)
! == FAILURE)
! goto cleanup;
! ! if (sym->attr.in_common)
{
common_flag = TRUE;
! common_head = sym->common_head;
}
! sym->attr.in_equivalence = 1;



the last line is redundant.


True - match_common takes a similarly belt-and-braces approach to ensuring that the attribute is set. I'll remove it.



+ /* Returns the type of a symbol or sequence. BT_INTEGER for numeric,
+ BT_CHARACTER for characters and BT_UNKNOWN for mixed sequences. */
+ + static bt
+ sequence_type (gfc_typespec ts)






! if (previous_equiv_type == BT_INTEGER)
! {
! if (equiv_type != BT_INTEGER)
! {
! if (gfc_notify_std (GFC_STD_GNU,
! "Non-numeric object '%s' in numeric "
! "EQUIVALENCE statement at %L",
! sym->name, &e->where) == FAILURE)
! continue;
! }
! }



This doesn't catch all incorrect cases:
equivalence (i,x) ! <- allowed
integer*8 j
equivalence (j,y) ! <- not allowed


Yes, that was the reason for the comments in the message. I could do it but is it worth it?....

I'm also not too fond of overloading the meaning of the BT_*. A new enum can
be used to solve both these issues at the same time.


.... I guess with a different enum, it can be done quite conveniently. OK, will do.

Many thanks

Paul


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