Re: [Fortran] half-cycle trig functions and atan[d] fixes
Hi, > Hopefully, FX sees this as my emails to gmail bounce. I am seeing this email. > Now, if > the OS adds cospi() to libm and it's in libm's symbol map, then the > cospi() used by gfortran depends on the search order of the loaded > libraries. We only include the fallback math functions in libgfortran when they are not available on the system. configure detects what is present in the libc being targeted, and conditionally compiles the necessary fallback functions (and only them). FX
Re: [Fortran] half-cycle trig functions and atan[d] fixes
On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: > > Now, if > > the OS adds cospi() to libm and it's in libm's symbol map, then the > > cospi() used by gfortran depends on the search order of the loaded > > libraries. > > We only include the fallback math functions in libgfortran when they are not > available on the system. configure detects what is present in the libc being > targeted, and conditionally compiles the necessary fallback functions (and > only them). Exactly. However, there is the (corner?) case when libgfortran has been compiled, and cospi() not found and thus the fallback implementation is included, and then later libc is updated to a version that does provide cospi(). I believe in that case which version gets used is down to the library search order (i.e. the order that "ldd /path/to/binary" prints the libs), it will use the first symbol it finds. Also, it's not necessary to do some ifdef tricks with gfortran.map, if a symbol listed there isn't found in the library it's just ignored. So the *pi() trig functions can be unconditionally added there, and then depending on whether the target libm includes those or not they are then included in the exported symbol list. It's possible to override this to look for specific symbol versions etc., but that probably goes deep into the weeds of target-specific stuff (e.g. are we looking for cospi@FBSD_1.7, cospi@GLIBC_X.Y.Z, or something else?). I'm sure you don't wanna go there. -- Janne Blomqvist
Re: [Fortran] half-cycle trig functions and atan[d] fixes
Am 24.01.24 um 10:13 schrieb Janne Blomqvist: On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: Now, if the OS adds cospi() to libm and it's in libm's symbol map, then the cospi() used by gfortran depends on the search order of the loaded libraries. We only include the fallback math functions in libgfortran when they are not available on the system. configure detects what is present in the libc being targeted, and conditionally compiles the necessary fallback functions (and only them). Exactly. However, there is the (corner?) case when libgfortran has been compiled, and cospi() not found and thus the fallback implementation is included, and then later libc is updated to a version that does provide cospi(). I believe in that case which version gets used is down to the library search order (i.e. the order that "ldd /path/to/binary" prints the libs), it will use the first symbol it finds. Also, it's not necessary to do some ifdef tricks with gfortran.map, if a symbol listed there isn't found in the library it's just ignored. So the *pi() trig functions can be unconditionally added there, and then depending on whether the target libm includes those or not they are then included in the exported symbol list. It's possible to override this to look for specific symbol versions etc., but that probably goes deep into the weeds of target-specific stuff (e.g. are we looking for cospi@FBSD_1.7, cospi@GLIBC_X.Y.Z, or something else?). I'm sure you don't wanna go there. Isn't this something that could be addressed by __attribute__(__weakref__)?
Re: [PATCH] Fortran: passing of optional dummies to elemental procedures [PR113377]
Le 23/01/2024 à 21:36, Harald Anlauf a écrit :
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elemental. Adjustments
were necessary when the missing dummy has the VALUE attribute.
I factored the code for the treatment of VALUE, hoping that the
monster loop in gfc_conv_procedure_call will become slightly
easier to overlook.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good, but...
Thanks,
Harald
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 128add47516..0fac0523670 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6392,12 +6479,23 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
}
}
+ /* Scalar dummy arguments of intrinsic type with VALUE attribute. */
+ if (fsym
+ && fsym->attr.value
+ && !fsym->attr.dimension
+ // && (fsym->ts.type != BT_CHARACTER
+ // || gfc_length_one_character_type_p (&fsym->ts))
... please remove the commented code here. OK with that change.
The !fsym->attr.dimension condition could be removed as well as we are
in the case of an elemental procedure at this point, but it doesn't harm
if you prefer keeping it.
Thanks for the patch.
Mikael
+ && fsym->ts.type != BT_DERIVED
+ && fsym->ts.type != BT_CLASS)
+ conv_dummy_value (&parmse, e, fsym, optionalargs);
+
/* If we are passing an absent array as optional dummy to an
elemental procedure, make sure that we pass NULL when the data
pointer is NULL. We need this extra conditional because of
scalarization which passes arrays elements to the procedure,
ignoring the fact that the array can be absent/unallocated/... */
- if (ss->info->can_be_null_ref && ss->info->type != GFC_SS_REFERENCE)
+ else if (ss->info->can_be_null_ref
+ && ss->info->type != GFC_SS_REFERENCE)
{
tree descriptor_data;
Re: [Fortran] half-cycle trig functions and atan[d] fixes
On Wed, Jan 24, 2024 at 11:13:05AM +0200, Janne Blomqvist wrote: > On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: > > > Now, if > > > the OS adds cospi() to libm and it's in libm's symbol map, then the > > > cospi() used by gfortran depends on the search order of the loaded > > > libraries. > > > > We only include the fallback math functions in libgfortran when they are > > not available on the system. configure detects what is present in the libc > > being targeted, and conditionally compiles the necessary fallback functions > > (and only them). > > Exactly. However, there is the (corner?) case when libgfortran has > been compiled, and cospi() not found and thus the fallback > implementation is included, and then later libc is updated to a > version that does provide cospi(). I believe in that case which > version gets used is down to the library search order (i.e. the order > that "ldd /path/to/binary" prints the libs), it will use the first > symbol it finds. Also, it's not necessary to do some ifdef tricks > with gfortran.map, if a symbol listed there isn't found in the library > it's just ignored. So the *pi() trig functions can be unconditionally > added there, and then depending on whether the target libm includes > those or not they are then included in the exported symbol list. > > It's possible to override this to look for specific symbol versions > etc., but that probably goes deep into the weeds of target-specific > stuff (e.g. are we looking for cospi@FBSD_1.7, cospi@GLIBC_X.Y.Z, or > something else?). I'm sure you don't wanna go there. > Ah, so that's the part I was missing. I was under the impression that if a symbol appears in a libraries symbol map, then the library had to contain a function by that name. If the loader ignores symbols for a missing function, then yes, I think I can get rid of the indirection via _gfortran_cospi_r4(). It will take a few days for me to redesign this, which shouldn't be too problematic in that GCC is in stage 4 and this is neither a regression or doc fix. Janne, FX, Harald, thanks for taking a peek. -- Steve
Re: [PATCH] Fortran: passing of optional dummies to elemental procedures [PR113377]
Hi Mikael,
Am 24.01.24 um 19:46 schrieb Mikael Morin:
Le 23/01/2024 à 21:36, Harald Anlauf a écrit :
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elemental. Adjustments
were necessary when the missing dummy has the VALUE attribute.
I factored the code for the treatment of VALUE, hoping that the
monster loop in gfc_conv_procedure_call will become slightly
easier to overlook.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good, but...
Thanks,
Harald
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 128add47516..0fac0523670 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6392,12 +6479,23 @@ gfc_conv_procedure_call (gfc_se * se,
gfc_symbol * sym,
}
}
+ /* Scalar dummy arguments of intrinsic type with VALUE
attribute. */
+ if (fsym
+ && fsym->attr.value
+ && !fsym->attr.dimension
+ // && (fsym->ts.type != BT_CHARACTER
+ // || gfc_length_one_character_type_p (&fsym->ts))
... please remove the commented code here. OK with that change.
Duh! I completely missed that during cleanup.
The !fsym->attr.dimension condition could be removed as well as we are
in the case of an elemental procedure at this point, but it doesn't harm
if you prefer keeping it.
You're absolutely right. I've removed it.
Thanks for the patch.
Thanks for the review!
Harald
Mikael
+ && fsym->ts.type != BT_DERIVED
+ && fsym->ts.type != BT_CLASS)
+ conv_dummy_value (&parmse, e, fsym, optionalargs);
+
/* If we are passing an absent array as optional dummy to an
elemental procedure, make sure that we pass NULL when the data
pointer is NULL. We need this extra conditional because of
scalarization which passes arrays elements to the procedure,
ignoring the fact that the array can be
absent/unallocated/... */
- if (ss->info->can_be_null_ref && ss->info->type !=
GFC_SS_REFERENCE)
+ else if (ss->info->can_be_null_ref
+ && ss->info->type != GFC_SS_REFERENCE)
{
tree descriptor_data;
[PATCH] Fortran: use name of array component in runtime error message [PR30802]
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code. Without the proper
part ref, not only a user may get confused: I was, too...
The testcase is compile-only, as it is only important to check the
strings used in the error messages.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 43c0185764ec878576ef2255d9df24fbb1961af4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 24 Jan 2024 22:28:31 +0100
Subject: [PATCH] Fortran: use name of array component in runtime error message
[PR30802]
gcc/fortran/ChangeLog:
PR fortran/30802
* trans-array.cc (trans_array_bound_check): Derive name of component
for use in runtime error message.
gcc/testsuite/ChangeLog:
PR fortran/30802
* gfortran.dg/bounds_check_fail_8.f90: New test.
---
gcc/fortran/trans-array.cc| 34 ++
.../gfortran.dg/bounds_check_fail_8.f90 | 35 +++
2 files changed, 69 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/bounds_check_fail_8.f90
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 878a92aff18..f6ddce2d023 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3497,6 +3497,10 @@ trans_array_bound_check (gfc_se * se, gfc_ss *ss, tree index, int n,
tree descriptor;
char *msg;
const char * name = NULL;
+ char *var_name = NULL;
+ gfc_expr *expr;
+ gfc_ref *ref;
+ size_t len;
if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS))
return index;
@@ -3509,6 +3513,36 @@ trans_array_bound_check (gfc_se * se, gfc_ss *ss, tree index, int n,
name = ss->info->expr->symtree->n.sym->name;
gcc_assert (name != NULL);
+ /* When we have a component ref, compile name for the array section.
+ Note that there can only be one part ref. */
+ expr = ss->info->expr;
+ if (expr->ref && !compname)
+{
+ len = strlen (name) + 1;
+
+ /* Find a safe length. */
+ for (ref = expr->ref; ref; ref = ref->next)
+ if (ref->type == REF_COMPONENT)
+ len += 2 + strlen (ref->u.c.component->name);
+
+ var_name = XALLOCAVEC (char, len);
+ strcpy (var_name, name);
+
+ for (ref = expr->ref; ref; ref = ref->next)
+ {
+ /* Append component name. */
+ if (ref->type == REF_COMPONENT)
+ {
+ strcat (var_name, "%%");
+ strcat (var_name, ref->u.c.component->name);
+ continue;
+ }
+ if (ref->type == REF_ARRAY && ref->u.ar.type == AR_SECTION)
+ break;
+ }
+ name = var_name;
+}
+
if (VAR_P (descriptor))
name = IDENTIFIER_POINTER (DECL_NAME (descriptor));
diff --git a/gcc/testsuite/gfortran.dg/bounds_check_fail_8.f90 b/gcc/testsuite/gfortran.dg/bounds_check_fail_8.f90
new file mode 100644
index 000..3397e953ba6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/bounds_check_fail_8.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! { dg-additional-options "-fcheck=bounds -g -fdump-tree-original" }
+! { dg-output "At line 22 .*" }
+! { dg-shouldfail "dimension 3 of array 'uu%z' outside of expected range" }
+!
+! PR fortran/30802 - improve bounds-checking for array references
+!
+! Checking the proper component references is the most important part here.
+
+program test
+ implicit none
+ integer :: k = 0
+ type t
+ real, dimension(10,20,30) :: z = 23
+ end type t
+ type u
+ type(t) :: vv(4,5)
+ end type u
+ type(t) :: uu, ww(1)
+ type(u) :: x1, x2, y1(1), y2(1)
+
+ print *, uu % z(1,k,:) ! runtime check only for dimension 2 of z
+ print *, ww(1)% z(1,:,k) ! runtime check only for dimension 3 of z
+ print *, x1 % vv(2,3)% z(1,:,k) ! runtime check only for dimension 3 of z
+ print *, x2 % vv(k,:)% z(1,2,3) ! runtime check only for dimension 1 of vv
+ print *, y1(1)% vv(2,3)% z(1,:,k) ! runtime check only for dimension 3 of z
+ print *, y2(1)% vv(:,k)% z(1,2,3) ! runtime check only for dimension 2 of vv
+end program test
+
+! { dg-final { scan-tree-dump-times "'uu%%z.' outside of expected range" 2 "original" } }
+! { dg-final { scan-tree-dump-times "'ww%%z.' outside of expected range" 2 "original" } }
+! { dg-final { scan-tree-dump-times "'x1%%vv%%z.' outside of expected range" 2 "original" } }
+! { dg-final { scan-tree-dump-times "'x2%%vv.' outside of expected range" 2 "original" } }
+! { dg-final { scan-tree-dump-times "'y1%%vv%%z.' outside of expected range" 2 "original" } }
+! { dg-final { scan-tree-dump-times "'y2%%vv.' outside of expected range" 2 "original" } }
--
2.35.3
GSoc Topics
Hello, I'm Gaurang Aswal, an undergraduate student from India. I'm interested in working on Fortran projects, but I'm a bit confused and need some guidance on getting started and selecting a suitable project. I've already built, installed, and tested GCC, and I have a good understanding of intermediate representation concepts. Could you help me with where to start exactly?
