From: Harald Anlauf <anlauf@gmx.de>
To: Mikael Morin <mikael@gcc.gnu.org>,
gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org
Subject: Re: [PATCH 2/2] libgfortran: Remove empty array descriptor first dimension overwrite [PR112371]
Date: Mon, 6 Nov 2023 19:20:32 +0100 [thread overview]
Message-ID: <5562f6b7-1b0d-4ff7-9797-8f1f58edc1f5@gmx.de> (raw)
In-Reply-To: <20231106114325.828968-3-mikael@gcc.gnu.org>
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
> Remove the forced overwrite of the first dimension of the result array
> descriptor to set it to zero extent, in the function templates for
> transformational functions doing an array reduction along a dimension. This
> overwrite, which happened before early returning in case the result array
> was empty, was wrong because an array may have a non-zero extent in the
> first dimension and still be empty if it has a zero extent in a higher
> dimension. Overwriting the dimension was resulting in wrong array result
> upper bound for the first dimension in that case.
>
> The offending piece of code was present in several places, and this removes
> them all. More precisely, there is only one case to fix for logical
> reduction functions, and there are three cases for other reduction
> functions, corresponding to non-masked reduction, reduction with array mask,
> and reduction with scalar mask. The impacted m4 files are
> ifunction_logical.m4 for logical reduction functions, ifunction.m4 for
> regular functions and types, ifunction-s.m4 for character minloc and maxloc,
> ifunction-s2.m4 for character minval and maxval, and ifindloc1.m4 for
> findloc.
while your fix seems mechanical and correct, I wonder if you looked
at the following pre-existing irregularity which can be seen in
this snippet:
> diff --git a/libgfortran/m4/ifunction.m4 b/libgfortran/m4/ifunction.m4
> index 480649cf691..abc15b430ab 100644
> --- a/libgfortran/m4/ifunction.m4
> +++ b/libgfortran/m4/ifunction.m4
> @@ -96,12 +96,7 @@ name`'rtype_qual`_'atype_code` ('rtype` * const restrict retarray,
>
> retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
> if (alloc_size == 0)
> - {
> - /* Make sure we have a zero-sized array. */
> - GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
> - return;
> -
> - }
> + return;
> }
> else
> {
This is all enclosed in a block which has
if (retarray->base_addr == NULL)
but allocates and sets retarray->base_addr, while
> @@ -290,11 +285,7 @@ m'name`'rtype_qual`_'atype_code` ('rtype` * const restrict retarray,
> retarray->dtype.rank = rank;
>
> if (alloc_size == 0)
> - {
> - /* Make sure we have a zero-sized array. */
> - GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
> - return;
> - }
> + return;
> else
> retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
>
and
> @@ -454,11 +445,7 @@ void
> alloc_size = GFC_DESCRIPTOR_STRIDE(retarray,rank-1) * extent[rank-1];
>
> if (alloc_size == 0)
> - {
> - /* Make sure we have a zero-sized array. */
> - GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
> - return;
> - }
> + return;
> else
> retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
> }
do not set retarray->base_addr to non-NULL for alloc_size == 0.
Do you know if the first snippet can be safely rewritten to avoid
the (hopefully pointless) xmallocarray for alloc_size == 0?
Thanks,
Harald
WARNING: multiple messages have this Message-ID
From: Harald Anlauf <anlauf@gmx.de>
To: gcc-patches@gcc.gnu.org
Cc: fortran@gcc.gnu.org
Subject: Re: [PATCH 2/2] libgfortran: Remove empty array descriptor first dimension overwrite [PR112371]
Date: Mon, 6 Nov 2023 19:20:32 +0100 [thread overview]
Message-ID: <5562f6b7-1b0d-4ff7-9797-8f1f58edc1f5@gmx.de> (raw)
Message-ID: <20231106182032.gOvwtcLnkm62-NnDytrZVU0iLoK_Y-QiOe-fhcNNS4s@z> (raw)
In-Reply-To: <20231106114325.828968-3-mikael@gcc.gnu.org>
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
> Remove the forced overwrite of the first dimension of the result array
> descriptor to set it to zero extent, in the function templates for
> transformational functions doing an array reduction along a dimension. This
> overwrite, which happened before early returning in case the result array
> was empty, was wrong because an array may have a non-zero extent in the
> first dimension and still be empty if it has a zero extent in a higher
> dimension. Overwriting the dimension was resulting in wrong array result
> upper bound for the first dimension in that case.
>
> The offending piece of code was present in several places, and this removes
> them all. More precisely, there is only one case to fix for logical
> reduction functions, and there are three cases for other reduction
> functions, corresponding to non-masked reduction, reduction with array mask,
> and reduction with scalar mask. The impacted m4 files are
> ifunction_logical.m4 for logical reduction functions, ifunction.m4 for
> regular functions and types, ifunction-s.m4 for character minloc and maxloc,
> ifunction-s2.m4 for character minval and maxval, and ifindloc1.m4 for
> findloc.
while your fix seems mechanical and correct, I wonder if you looked
at the following pre-existing irregularity which can be seen in
this snippet:
> diff --git a/libgfortran/m4/ifunction.m4 b/libgfortran/m4/ifunction.m4
> index 480649cf691..abc15b430ab 100644
> --- a/libgfortran/m4/ifunction.m4
> +++ b/libgfortran/m4/ifunction.m4
> @@ -96,12 +96,7 @@ name`'rtype_qual`_'atype_code` ('rtype` * const restrict retarray,
>
> retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
> if (alloc_size == 0)
> - {
> - /* Make sure we have a zero-sized array. */
> - GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
> - return;
> -
> - }
> + return;
> }
> else
> {
This is all enclosed in a block which has
if (retarray->base_addr == NULL)
but allocates and sets retarray->base_addr, while
> @@ -290,11 +285,7 @@ m'name`'rtype_qual`_'atype_code` ('rtype` * const restrict retarray,
> retarray->dtype.rank = rank;
>
> if (alloc_size == 0)
> - {
> - /* Make sure we have a zero-sized array. */
> - GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
> - return;
> - }
> + return;
> else
> retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
>
and
> @@ -454,11 +445,7 @@ void
> alloc_size = GFC_DESCRIPTOR_STRIDE(retarray,rank-1) * extent[rank-1];
>
> if (alloc_size == 0)
> - {
> - /* Make sure we have a zero-sized array. */
> - GFC_DIMENSION_SET(retarray->dim[0], 0, -1, 1);
> - return;
> - }
> + return;
> else
> retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
> }
do not set retarray->base_addr to non-NULL for alloc_size == 0.
Do you know if the first snippet can be safely rewritten to avoid
the (hopefully pointless) xmallocarray for alloc_size == 0?
Thanks,
Harald
next prev parent reply other threads:[~2023-11-06 18:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 11:43 [PATCH 0/2] libgfortran: empty array fixes [PR112371] Mikael Morin
2023-11-06 11:43 ` [PATCH 1/2] libgfortran: Remove early return if extent is zero [PR112371] Mikael Morin
2023-11-06 18:12 ` Harald Anlauf
2023-11-06 18:12 ` Harald Anlauf
2023-11-06 18:57 ` Mikael Morin
2023-11-06 11:43 ` [PATCH 2/2] libgfortran: Remove empty array descriptor first dimension overwrite [PR112371] Mikael Morin
2023-11-06 18:20 ` Harald Anlauf [this message]
2023-11-06 18:20 ` Harald Anlauf
2023-11-06 19:19 ` Mikael Morin
2023-11-06 20:03 ` Harald Anlauf
2023-11-06 20:03 ` Harald Anlauf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5562f6b7-1b0d-4ff7-9797-8f1f58edc1f5@gmx.de \
--to=anlauf@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=mikael@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).