Hi all,
attached patches fix a 12-regression, when a caf token is requested from an
abstract class-typed dummy. The token was not looked up in the correct spot.
Due the class typed object getting an artificial variable for direct derived
type access, the get_caf_decl was looking at the wrong decl.
Hi Paul,
thanks for the review. Committed as gcc-15-7789-g43c11931acc.
The regression is tagged as 15-regression only and was caused by PR
fortran/90068. At least the change in trans-array.cc:2000-.. is one of
major causes for that regression.
Thanks again,
Andre
On Sat, 1 Mar 2025 08:0
Hi Paul,
what do want us to do with it?
Let me give an early review:
In gfc_resolve_reduce, I think you duplicate the test for the function having
optional formal arguments. Ones in this block:
+ if (formal->sym->attr.allocatable || formal->sym->attr.allocatable
+ || formal->sym->attr.po
Hi Harald,
in +++ b/gcc/fortran/symbol.cc
@@ -4624,12 +4624,28 @@ verify_bind_c_derived_type (gfc_symbol *derived_sym)
there is
+ else if (!pedantic)
+ gfc_warning (0, "Derive ...
To me the "not pedantic" is counter-intuitive. In pedantic mode I would have
expected this to be at leas
On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote:
>
> attached patches fix a 12-regression, when a caf token is requested from an
> abstract class-typed dummy. The token was not looked up in the correct spot.
> Due the class typed object getting an artificial variable for direct d
Hello world,
this patch is a bit more complicated than originally envisioned.
The problem was that we were not handling external dummy arguments
with -fc-prototypes-external. In looking at this, I found that we
were not warning about external procedures with different argument
lists. This can a
Hi Andre,
Am 03.03.25 um 10:08 schrieb Andre Vehreschild:
Hi Harald,
in +++ b/gcc/fortran/symbol.cc
@@ -4624,12 +4624,28 @@ verify_bind_c_derived_type (gfc_symbol *derived_sym)
there is
+ else if (!pedantic)
+ gfc_warning (0, "Derive ...
To me the "not pedantic" is counter-intuiti
