This is the mail archive of the gcc-bugs@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]

[Bug fortran/41758] [Cleanup] Don't resolve expr in gfc_match_allocate



------- Comment #1 from kargl at gcc dot gnu dot org  2009-10-19 22:06 -------
(In reply to comment #0)
> In gfc_match_allocate one finds a call to gfc_resolve_expr, which resolves the
> optional SOURCE expression.
> 
> By definition, resolving should be done at resolution stage, and not already
> when matching the ALLOCATE statement. The canonical way to do it would be to
> add something like 'gfc_resolve_expr (code->expr3)' in resolve_code, where
> already code->expr1 and code->expr2 are being resolved (the SOURCE expr is
> being stored in code->expr3).
> 
> So, unless there are very good reasons for the resolution to happen in
> gfc_match_allocate, the call to gfc_resolve_expr should be moved to resolve.c
> (together with the various checks for the SOURCE expression that follow it).
> 
> I think the questionable code was committed as part of r151023 by Steve, when
> he implemented the SOURCE tag in ALLOCATE statements.

Yes, I added the call to gfc_resolve_expr.  Unfortnately, I can't remember
why :( other than tmp->ts.type is not properly set in some situation.  If
you move this to resolve.c, you'll need to move some or all of the error 
checking involving tmp->ts.type.  Perhaps, your changes to support CLASS
and allocatable scalars has removed the need for gfc_resolve_expr here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41758


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