Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

On 8/9/23 7:58 AM, Paul Richard Thomas via Fortran wrote: I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: Committed to trunk as

[PATCH 2/3] fortran: Fix length one character dummy arg type [PR110419]

Revision r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa changed the argument passing convention for length 1 value dummy arguments to pass just the single character by value. However, the procedure declarations weren't updated to reflect the change in the argument types. This change does the

[PATCH 1/3] fortran: New predicate gfc_length_one_character_type_p

Introduce a new predicate to simplify conditionals checking for a character type whose length is the constant one. gcc/fortran/ChangeLog: * gfortran.h (gfc_length_one_character_type_p): New inline function. * check.cc (is_c_interoperable): Use

[PATCH 0/3] fortran: fix length one character dummy args [PR110419]

Hello, I propose with this patchset a fix for the test value_9.f90 which has been failing on 32 bits powerpc since it was added a few weeks back (see PR110360 and PR110419). The problem is an argument type mismatch between a procedure declaration, and the argument value for a call of that same

[PATCH 3/3] testsuite: Use distinct explicit error codes in value_9.f90

Use distinct error codes, so that we can spot directly from the testsuite log which case is failing. gcc/testsuite/ChangeLog: * gfortran.dg/value_9.f90 (val, val4, sub, sub4): Take the error codes from the arguments. (p): Update calls: pass explicit distinct error codes.

Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: > > Committed to trunk as 'obvious' in >

[Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

Committed to trunk as 'obvious' in r14-3098-gb8ec3c952324f866f191883473922e250be81341 13-branch to follow in a few days. Paul