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] PR54107: ICE on recursive interfaces and PR54195: symbol bogusly inserted twice in the interface.


Hi Mikael,

> The following patches fix both PR54107 and PR54195.

good stuff, thank you!


> - In PR54107(comment 26), the procedure result is a procedure pointer
> whose interface is the procedure itself, which leads to an infinite
> recursion during resolution.
> - In PR54195, a type's type bound procedures are resolved twice, leading
> to a symbol being added twice in an interface and rejected.

What about PR 54107 comment 4? This also still fails, right? You had
already posted a patch for this in this PR, which however was quite
different from the one you propose here. (I was assuming that the
problems of comment 4 and comment 26 were quite similar.)

Can your 'resolved' attribute also help to fix comment 4, or are you
going to post the other patch later?


> The fix, as discussed in PR54195, adds a flag to mark a symbol as
> resolved.

Why not add this flag directly to gfc_symbol instead of
symbol_attribute? It seems we do not need the attribute for components
(or do we?).


> This leads to two regressions.  For class_20, a check to skip
> result symbols had to be removed (which was there to avoid duplicated
> resolution).  For initialization_27 (among a few others) the code adding
> the default initialization code was guarded by a check against
> gfc_current_ns, which always ended triggering when there was more than
> one resolution but may not anymore.  The fix removes it; I checked that
> gfc_current_ns wasn't used in the following code.

Ok, this makes sense.


> The second fix makes the recursion through resolve_symbol, so that the
> flag just added triggers and PR54195 is fixed.
>
> Regression tested on x86_64-unknown-linux-gnu. OK for trunk?

Yes, I think it's basically ok, except for the points mentioned above.

Thanks,
Janus


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