[PATCH, committed] PR fortran/86551 - ICE on invalid code with select type

Dear Fortranners, as has been validated by others before and checked again, the underlying issue of this PR has been fixed before by an unknown commit. To ensure that it doesn't pop up again, and as suggested in the PR, I've packaged the testcase and committed as obvious. Thanks, Harald commit

Re: [PATCH] PR fortran/102956 - PDT KIND and LEN type parameters are mutually exclusive

On 26.10.21 21:40, Harald Anlauf via Fortran wrote: we were missing a conflict check for PDT KIND and LEN type parameters: F2018: 7.5.3.1 Type parameter definition statement R732 type-param-def-stmt is integer-type-spec, type-param-attr-spec :: type-param-decl-list R734 type-param-

[PATCH] PR fortran/102956 - PDT KIND and LEN type parameters are mutually exclusive

Dear Fortranners, we were missing a conflict check for PDT KIND and LEN type parameters: F2018: 7.5.3.1 Type parameter definition statement R732 type-param-def-stmt is integer-type-spec, type-param-attr-spec :: type-param-decl-list R734 type-param-attr-spec is KIND or LEN (3) The ty

Re: [PATCH] PR fortran/102917 - PDT type parameters are not restricted to default integer

Hi Tobias, > OK. I wonder whether a valid len/kind example should be added which uses > such a PDT with non-default-kind integer. the testcase pdt_4.f03 did actually check for the error message that gets removed and had to be adjusted. Removing just the dg-error does that job :-) Thanks, Harald

Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

Hi Tobias, > In other cases, it requires some careful weighting whether error should > have the error location "use m" or where the symbol is used. (Here, it > cannot occur as the module won't get generated and an error is already > printed at the proper location.) I had though about this but cou

Re: Replacing keyword in RISC-V Fortran

Thanks Arjen. Let me work on your comments. On Mon, Oct 25, 2021 at 12:53 PM Arjen Markus wrote: > I am not sure I understand your question correctly, but Fortran uses the > KIND mechanism to declare the precise characteristics of floating-point > variables and constants. Typically, these are

Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

Dear Harald, hi all, On 22.10.21 21:36, Harald Anlauf via Fortran wrote: the recently introduced shape validation for array components in DT constructors did not properly deal with invalid code created by ingenious testers. Obvious solution: replace the gcc_assert by a suitable error message.

Re: [PATCH] PR fortran/102917 - PDT type parameters are not restricted to default integer

Dear Harald, dear all, On 24.10.21 21:00, Harald Anlauf via Fortran wrote: I've created PR 102917 for tracking this issue and packaged the attached patch. Regtested on x86_64-pc-linux-gnu. OK mainline? OK. I wonder whether a valid len/kind example should be added which uses such a PDT with n

Re: [PATCH,Fortran 6/7] Fortran: Delete unused decl in trans-types.h

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote: From: Bernhard Reutner-Fischer gcc/fortran/ChangeLog: * trans-types.h (gfc_convert_function_code): Delete. OK. Tobias --- gcc/fortran/trans-types.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/gcc/fortran/tran

Re: [PATCH,Fortran 5/7] Fortran: Delete unused decl in trans-stmt.h

On 25.10.21 00:30, Bernhard Reutner-Fischer via Gcc-patches wrote: From: Bernhard Reutner-Fischer gcc/fortran/ChangeLog: * trans-stmt.h (gfc_trans_deallocate_array): Delete. OK. Thanks! Tobias --- gcc/fortran/trans-stmt.h | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/for

Re: [PATCH,Fortran 4/7] Fortran: make some trans-array functions static

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote: From: Bernhard Reutner-Fischer gcc/fortran/ChangeLog: * trans-array.c (gfc_trans_scalarized_loop_end): Make static. * trans-array.h (gfc_trans_scalarized_loop_end, gfc_conv_tmp_ref, gfc_conv_array_transpose): Dele

Re: [PATCH,Fortran 2/7] Fortran: make some match* functions static

On 25.10.21 00:30, Bernhard Reutner-Fischer via Gcc-patches wrote: From: Bernhard Reutner-Fischer gfc_match_small_int_expr was unused, delete it. gfc_match_gcc_unroll should use gfc_match_small_literal_int and then (but wasn't in this patch) gfc_match_small_int can be deleted since it will b

Re: [PATCH,Fortran 1/7] Fortran: make some trans* functions static

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote: From: Bernhard Reutner-Fischer This makes some trans* functions static and deletes declarations of functions that either do not exist anymore like gfc_get_function_decl or that are unused like gfc_check_any_c_kind. gcc/fortran/Cha

Re: [PATCH,Fortran 3/7] Fortran: make some constructor* functions static

On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote: From: Bernhard Reutner-Fischer gfc_constructor_expr_foreach and gfc_constructor_swap were just stubs. gcc/fortran/ChangeLog: * constructor.c (gfc_constructor_get_base): Make static. (gfc_constructor_expr_foreach, (gfc_co

[committed] Fortran: Fix character(len=cst) dummies with bind(C) [PR102885] (erratum: should be: 'len=noncst')

I forgot to handle len= correctly. This patch does the same as for non-BIND(C). In the latter case, the call is: gfc_generate_function_code → gfc_trans_deferred_vars → gfc_trans_deferred_array and that function has if (sym->ts.type == BT_CHARACTER && !INTEGER_CST_P (sym->ts.u.cl->bac