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/41242] [4.5 Regression] PPC call rejected (related to user-defined assignment?)



------- Comment #10 from domob at gcc dot gnu dot org  2009-09-10 16:25 -------
(In reply to comment #8)
> Index: gcc/fortran/resolve.c
> ===================================================================
> --- gcc/fortran/resolve.c       (revision 151596)
> +++ gcc/fortran/resolve.c       (working copy)
> @@ -6958,7 +6958,6 @@ resolve_ordinary_assign (gfc_code *code,
>             && (lhs->symtree->n.sym == (*rhsptr)->symtree->n.sym))
>         *rhsptr = gfc_get_parentheses (*rhsptr);
> 
> -      resolve_code (code, ns);
>        return true;
>      }
> 
> Daniel, do you think this patch is ok, or is there a better way to fix this?

I think this is ok from the point of view of my patch.  I did introduce it
mainly because I thought it is "cleaner" to resolve every piece of code, even
though it was not "needed" at that place.  It seems it hurts there, though.

But I also think that maybe fixing the code so that the double resolve is no
harm in this case is the better way to go; something like adding a flag that
code is from PPCs and shouldn't be resolved and returning early, if there's no
other solution...  What do you think?

But otherwise, your patch should also be ok.


-- 


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


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