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

2021-10-26 Thread Tobias Burnus
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

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

2021-10-26 Thread Tobias Burnus
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

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

2021-10-26 Thread Tobias Burnus
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 2/7] Fortran: make some match* functions static

2021-10-26 Thread Tobias Burnus
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 4/7] Fortran: make some trans-array functions static

2021-10-26 Thread Tobias Burnus
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 5/7] Fortran: Delete unused decl in trans-stmt.h

2021-10-26 Thread Tobias Burnus
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 6/7] Fortran: Delete unused decl in trans-types.h

2021-10-26 Thread Tobias Burnus
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] PR fortran/102917 - PDT type parameters are not restricted to default integer

2021-10-26 Thread Tobias Burnus
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] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

2021-10-26 Thread Tobias Burnus
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: Replacing keyword in RISC-V Fortran

2021-10-26 Thread Amit Hmath via 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

2021-10-26 Thread Harald Anlauf via Fortran
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: [PATCH] PR fortran/102917 - PDT type parameters are not restricted to default integer

2021-10-26 Thread Harald Anlauf via Fortran
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

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

2021-10-26 Thread Harald Anlauf via Fortran
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/102956 - PDT KIND and LEN type parameters are mutually exclusive

2021-10-26 Thread Tobias Burnus
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, committed] PR fortran/86551 - ICE on invalid code with select type

2021-10-26 Thread Harald Anlauf via Fortran
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