Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

[Harald Anlauf]

Hi Andre,

Am 17.03.25 um 09:56 schrieb Andre Vehreschild:

The issue is that the tbp (the typebound proc info structure) is not resolved
completely when the associate tries to do an early resolve to determine the
rank of the associate variable. When the expression to be resolved for that
contains a compcall, the resolve branches into the incorrect case and emits the
error. My current fix is to wait with generating the error message until the
type has been resolved completely (aka. symbol's resolve_symbol_called is set).
I am not sure, if this is correct, therefore CC'ing Paul, who, to my
knowledge, has more experience in the associate area. But everyone please feel
free to step in!


your solution looks basically correct to me, but I wonder why to
return early w/o error.  Would the following logic be wrong?

@@ -7349,7 +7357,8 @@ resolve_compcall (gfc_expr* e, const char **name)
   gfc_symtree* target;

   /* Check that's really a FUNCTION.  */
-  if (!e->value.compcall.tbp->function)
+  if (!e->value.compcall.tbp->function
+  && e->symtree && e->symtree->n.sym->resolve_symbol_called)
 {
   gfc_error ("%qs at %L should be a FUNCTION",
 e->value.compcall.name, &e->where);

Sorry if this is a stupid question.  And not regtested, although
it also fixes the original report.


Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?


If neither Paul steps in nor anybody else, go ahead and commit.
Even if your patch were a band-aid, it does not look wrong, and
if it is later found to be it can be improved...

Thanks,
Harald


Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: [PATCH] Fortran: check type-spec in ALLOCATE of dummy with assumed length [PR119338]

[Harald Anlauf]

Am 18.03.25 um 00:20 schrieb Jerry D:

On 3/17/25 2:47 PM, Harald Anlauf wrote:

Dear all,

F2003:C626 was only partly implemented: we missed the case of ALLOCATE
of character dummy arguments with assumed length, where the type-spec
must use asterisk, i.e. (*).

Regtesting found one testcase that had a previously undetected error
and needed adjustment, which I chose such that the original error
was kept.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald



Yes, OK and thanks for the fix.


Thanks for the review, Jerry!

Pushed as r15-8271-g6cbeab134f048d.

Cheers,
Harald


Jerry