Re: [PATCH] Fortran: fix treatment of character, value, optional dummy arguments [PR107444]
On Nov 10 2022, Harald Anlauf via Gcc-patches wrote: > Dear Fortranners, > > the attached patch is a follow-up to the fix for PR107441, > as it finally fixes the treatment of character dummy arguments > that have the value,optional attribute, and allows for checking > of the presence of such arguments. > > This entails a small ABI clarification, as the previous text > was not really clear on the argument passing conventions, > and the previously generated code was inconsistent at best, > or rather wrong, for this kind of procedure arguments. > (E.g. the number of passed arguments was varying...) > > Testcase cross-checked with NAG 7.1. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? This breaks aarch64: $ /opt/gcc/gcc-20221113/Build/./gcc/xgcc -B/opt/gcc/gcc-20221113/Build/./gcc/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include -fchecking=1 ../../../../libgomp/testsuite/libgomp.fortran/is_device_ptr-2.f90 -mabi=lp64 -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/ -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/.libs -I/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp -I../../../../libgomp/testsuite/../../include -I../../../../libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O -fdump-tree-original -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp -L/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/.libs -L/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./is_device_ptr-2.exe during GIMPLE pass: omplower ../../../../libgomp/testsuite/libgomp.fortran/is_device_ptr-2.f90:66:77: internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137 0x8acb63 gfc_omp_check_optional_argument(tree_node*, bool) ../../gcc/fortran/trans-openmp.cc:137 0xd29fc3 lower_omp_target ../../gcc/omp-low.cc:13632 0xd314b3 lower_omp_1 ../../gcc/omp-low.cc:14523 0xd314b3 lower_omp ../../gcc/omp-low.cc:14662 0xd31283 lower_omp_1 ../../gcc/omp-low.cc:14436 0xd31283 lower_omp ../../gcc/omp-low.cc:14662 0xd318a3 lower_omp_1 ../../gcc/omp-low.cc:14452 0xd318a3 lower_omp ../../gcc/omp-low.cc:14662 0xd377fb execute_lower_omp ../../gcc/omp-low.cc:14701 0xd377fb execute ../../gcc/omp-low.cc:14755 Please submit a full bug report, with preprocessed source (by using -freport-bug). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Proxy ping [PATCH] Fortran: diagnostics for actual arguments to pointer dummy arguments [PR94104]
Le 09/11/2022 à 21:50, Harald Anlauf via Fortran a écrit : Dear all, Jose posted a patch here that was never reviewed: https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html I think the diagnostics improvement is helpful, as it adjusts to the changes from F2003 to F2008. The patch suffered a little from bitrot, but was otherwise straightforward to apply. I slightly edited the commit message, as I found the original one difficult to parse. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK, thanks.
Re: [PATCH 3/5] Fortran: Narrow return types [PR78798]
On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
wrote:
> --- a/gcc/fortran/arith.cc
> +++ b/gcc/fortran/arith.cc
> @@ -1135,7 +1135,7 @@ compare_complex (gfc_expr *op1, gfc_expr *op2)
> strings. We return -1 for a < b, 0 for a == b and 1 for a > b.
> We use the processor's default collating sequence. */
>
> -int
> +signed char
> gfc_compare_string (gfc_expr *a, gfc_expr *b)
> {
>size_t len, alen, blen, i;
> @@ -1162,7 +1162,7 @@ gfc_compare_string (gfc_expr *a, gfc_expr *b)
> }
Hmm, really? PR 78798 mentions changing int to bool, where
appropriate, which I think is uncontroversial, but this?
--
Janne Blomqvist
Re: [PATCH 3/5] Fortran: Narrow return types [PR78798]
On Sun, 13 Nov 2022 12:13:26 +0200
Janne Blomqvist wrote:
> On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
> wrote:
> > --- a/gcc/fortran/arith.cc
> > +++ b/gcc/fortran/arith.cc
> > @@ -1135,7 +1135,7 @@ compare_complex (gfc_expr *op1, gfc_expr *op2)
> > strings. We return -1 for a < b, 0 for a == b and 1 for a > b.
> > We use the processor's default collating sequence. */
> >
> > -int
> > +signed char
> > gfc_compare_string (gfc_expr *a, gfc_expr *b)
> > {
> >size_t len, alen, blen, i;
> > @@ -1162,7 +1162,7 @@ gfc_compare_string (gfc_expr *a, gfc_expr *b)
> > }
>
> Hmm, really? PR 78798 mentions changing int to bool, where
> appropriate, which I think is uncontroversial, but this?
Well we could leave this or all spots alone where a bool is
insufficient, if you prefer.
In the case of gfc_compare_string, the only user is simplify which only
looks at ge/gt/le/lt 0
Re: [PATCH 3/5] Fortran: Narrow return types [PR78798]
Am 13.11.22 um 11:39 schrieb Bernhard Reutner-Fischer via Gcc-patches:
On Sun, 13 Nov 2022 12:13:26 +0200
Janne Blomqvist wrote:
On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
wrote:
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1135,7 +1135,7 @@ compare_complex (gfc_expr *op1, gfc_expr *op2)
strings. We return -1 for a < b, 0 for a == b and 1 for a > b.
We use the processor's default collating sequence. */
-int
+signed char
gfc_compare_string (gfc_expr *a, gfc_expr *b)
{
size_t len, alen, blen, i;
@@ -1162,7 +1162,7 @@ gfc_compare_string (gfc_expr *a, gfc_expr *b)
}
Hmm, really? PR 78798 mentions changing int to bool, where
appropriate, which I think is uncontroversial, but this?
Well we could leave this or all spots alone where a bool is
insufficient, if you prefer.
In the case of gfc_compare_string, the only user is simplify which only
looks at ge/gt/le/lt 0
My reading of the mentioned PR is that there is a fundamental
disagreement with the subject:
Bug 78798 - [cleanup] some int-valued functions should be bool
I see that as an issue of (a minor lack of) conciseness;
it is *not* about narrowing.
Replacing "int" by "signed char" adds confusion and makes code
less understandable, so I would oppose it, as we don't solve a
real problem and rather add confusion.
Re: [PATCH] Fortran: fix treatment of character, value, optional dummy arguments [PR107444]
Am 13.11.22 um 09:51 schrieb Andreas Schwab: This breaks aarch64: $ /opt/gcc/gcc-20221113/Build/./gcc/xgcc -B/opt/gcc/gcc-20221113/Build/./gcc/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include -fchecking=1 ../../../../libgomp/testsuite/libgomp.fortran/is_device_ptr-2.f90 -mabi=lp64 -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/ -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/.libs -I/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp -I../../../../libgomp/testsuite/../../include -I../../../../libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -O -fdump-tree-original -B/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp -L/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/.libs -L/opt/gcc/gcc-20221113/Build/aarch64-suse-linux/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./is_device_ptr-2.exe during GIMPLE pass: omplower ../../../../libgomp/testsuite/libgomp.fortran/is_device_ptr-2.f90:66:77: internal compiler error: in gfc_omp_check_optional_argument, at fortran/trans-openmp.cc:137 0x8acb63 gfc_omp_check_optional_argument(tree_node*, bool) ../../gcc/fortran/trans-openmp.cc:137 0xd29fc3 lower_omp_target ../../gcc/omp-low.cc:13632 0xd314b3 lower_omp_1 ../../gcc/omp-low.cc:14523 0xd314b3 lower_omp ../../gcc/omp-low.cc:14662 0xd31283 lower_omp_1 ../../gcc/omp-low.cc:14436 0xd31283 lower_omp ../../gcc/omp-low.cc:14662 0xd318a3 lower_omp_1 ../../gcc/omp-low.cc:14452 0xd318a3 lower_omp ../../gcc/omp-low.cc:14662 0xd377fb execute_lower_omp ../../gcc/omp-low.cc:14701 0xd377fb execute ../../gcc/omp-low.cc:14755 Please submit a full bug report, with preprocessed source (by using -freport-bug). I apologize for forgetting to add the attached change, which does the adjustment of the name of the generated internal symbol. Can you please confirm that it fixes your issues? Thanks, Harald From 872ed50812d3ca13554411e107317161777ecf5d Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Sun, 13 Nov 2022 21:53:58 +0100 Subject: [PATCH] Fortran: fix treatment of character, value, optional dummy arguments [PR107444] gcc/fortran/ChangeLog: PR fortran/107444 * trans-openmp.cc (gfc_omp_check_optional_argument): Adjust to change of prefix of internal symbol for presence status to '.'. --- gcc/fortran/trans-openmp.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc index 4bfdf85cd9b..9070c03353d 100644 --- a/gcc/fortran/trans-openmp.cc +++ b/gcc/fortran/trans-openmp.cc @@ -123,7 +123,7 @@ gfc_omp_check_optional_argument (tree decl, bool for_present_check) char name[GFC_MAX_SYMBOL_LEN + 2]; tree tree_name; - name[0] = '_'; + name[0] = '.'; strcpy (&name[1], IDENTIFIER_POINTER (DECL_NAME (decl))); tree_name = get_identifier (name); -- 2.35.3
Re: [PATCH 3/5] Fortran: Narrow return types [PR78798]
On 13 November 2022 21:29:50 CET, Harald Anlauf wrote: >Replacing "int" by "signed char" adds confusion and makes code >less understandable, so I would oppose it, as we don't solve a >real problem and rather add confusion. Ok so consider the non-bool hunks dropped, they just fell out of my helper and I thought I'd ask. I can send an updated patch during the weekend. thanks,
