* Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]
[not found] <c4d05663-57a2-40be-3fba-270239b52ee0@linux.ibm.com>
@ 2023-03-01 9:40 ` Tobias Burnus
2023-03-01 15:39 ` Steve Kargl
2023-03-02 0:00 ` Bernhard Reutner-Fischer
2023-03-02 2:27 ` Kewen.Lin
1 sibling, 2 replies; 6+ messages in thread
From: Tobias Burnus @ 2023-03-01 9:40 UTC (permalink / raw)
To: HAO CHEN GUI, gcc-patches, fortran
Cc: Segher Boessenkool, David, Kewen.Lin, Peter Bergner
Hi,
Please CC fortran@gcc for Fortran patches.
Fortraners: Please see my add-on suggestion/.diff for 'do_simply' below and
the original email at
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613019.html
On 01.03.23 08:09, HAO CHEN GUI via Gcc-patches wrote:
> The patch escalates the failure when Hollerith constant to real conversion
> fails in native_interpret_expr. It finally reports an "Unclassifiable
> statement" error.
I think we should do better than this (cf. below).
> The patch of pr95450 added a verification for decoding/encoding checking
> in native_interpret_expr. native_interpret_expr may fail on real type
> conversion and returns a NULL tree then. But upper layer calls don't handle
> the failure so that an ICE is reported when the verification fails.
>
> IBM long double is an example. It doesn't have a unique memory presentation
> for some real values. So it may not pass the verification. The new test
> case shows the problem.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
I think the patch OK except for two items:
> ChangeLog
> 2023-03-01 Haochen Gui <guihaoc@linux.ibm.com>
>
> gcc/
> PR target/103628
> * fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
> native_interpret_expr gets a NULL tree.
> * fortran/arith.cc (gfc_hollerith2real): Return NULL when
> gfc_interpret_float fails.
>
> gcc/testsuite/
> PR target/103628
> * gfortran.dg/pr103628.f90: New.
...
> --- a/gcc/fortran/target-memory.cc
> +++ b/gcc/fortran/target-memory.cc
> @@ -417,10 +417,13 @@ gfc_interpret_float (int kind, unsigned char *buffer, size_t buffer_size,
> {
> gfc_set_model_kind (kind);
> mpfr_init (real);
> - gfc_conv_tree_to_mpfr (real,
> - native_interpret_expr (gfc_get_real_type (kind),
> - buffer, buffer_size));
>
> + tree source = native_interpret_expr (gfc_get_real_type (kind), buffer,
> + buffer_size);
> + if (!source)
> + return 0;
> +
> + gfc_conv_tree_to_mpfr (real, source);
Can you move the mpfr_init before the 'gfc_conv...mfpr' to avoid
pointless allocation/leaks by mpfr_init.
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> @@ -0,0 +1,14 @@
> +! { dg-do compile { target powerpc*-*-* } }
> +! { dg-options "-O2 -mabi=ibmlongdouble" }
> +
> +! Test to ensure that it reports an "Unclassifiable statement" error
> +! instead of throwing an ICE when the memory represent of the HOLLERITH
> +! string is not unique with ibm long double encoding.
> ...
> + real(kind = k):: b = 4h1234
> ...
> +! { dg-warning "Conversion from HOLLERITH" "warning" { target powerpc*-*-* } 10 }
> +! { dg-error "Unclassifiable statement" "error" { target powerpc*-*-* } 10 }
I find a generic error pointing to the beginning of the line not that helpful.
I did wonder about something specific, but at the end for a rather special case,
a generic catch-all for 'do_simplify' seems to make sense. The callers of 'do_simplify'
clearly assume that this function will always (indirectly) generate an error message
if an error occurs. With my change, the result is:
10 | real(kind = k):: b = 4h1234
| 1
Error: Cannot simplify expression at (1)
That's with:
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 64821c84543..b60d92a0665 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -27,2 +27,3 @@ along with GCC; see the file COPYING3. If not see
#include "intrinsic.h"
+#include "diagnostic.h" /* For errorcount. */
@@ -4622,2 +4623,3 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)
gfc_actual_arglist *arg;
+ int old_errorcount = errorcount;
@@ -4710,3 +4712,7 @@ finish:
if (result == &gfc_bad_expr)
- return false;
+ {
+ if (errorcount == old_errorcount)
+ gfc_error ("Cannot simplify expression at %L", &e->where);
+ return false;
+ }
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]
[not found] <c4d05663-57a2-40be-3fba-270239b52ee0@linux.ibm.com>
2023-03-01 9:40 ` [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628] Tobias Burnus
@ 2023-03-02 2:27 ` Kewen.Lin
1 sibling, 0 replies; 6+ messages in thread
From: Kewen.Lin @ 2023-03-02 2:27 UTC (permalink / raw)
To: HAO CHEN GUI
Cc: Segher Boessenkool, David, Peter Bergner, gcc-patches, fortran
Hi Haochen,
on 2023/3/1 15:09, HAO CHEN GUI wrote:
> Hi,
> The patch escalates the failure when Hollerith constant to real conversion
> fails in native_interpret_expr. It finally reports an "Unclassifiable
> statement" error.
>
> The patch of pr95450 added a verification for decoding/encoding checking
> in native_interpret_expr. native_interpret_expr may fail on real type
> conversion and returns a NULL tree then. But upper layer calls don't handle
> the failure so that an ICE is reported when the verification fails.
>
> IBM long double is an example. It doesn't have a unique memory presentation
> for some real values. So it may not pass the verification. The new test
> case shows the problem.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
>
> Thanks
> Gui Haochen
>
> ChangeLog
> 2023-03-01 Haochen Gui <guihaoc@linux.ibm.com>
>
> gcc/
> PR target/103628
> * fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
> native_interpret_expr gets a NULL tree.
> * fortran/arith.cc (gfc_hollerith2real): Return NULL when
> gfc_interpret_float fails.
>
> gcc/testsuite/
> PR target/103628
> * gfortran.dg/pr103628.f90: New.
>
>
> patch.diff
> diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
> index c0d12cfad9d..d3d38c7eb6a 100644
> --- a/gcc/fortran/arith.cc
> +++ b/gcc/fortran/arith.cc
> @@ -2752,10 +2752,12 @@ gfc_hollerith2real (gfc_expr *src, int kind)
> result = gfc_get_constant_expr (BT_REAL, kind, &src->where);
>
> hollerith2representation (result, src);
> - gfc_interpret_float (kind, (unsigned char *) result->representation.string,
> - result->representation.length, result->value.real);
> -
> - return result;
> + if (gfc_interpret_float (kind,
> + (unsigned char *) result->representation.string,
> + result->representation.length, result->value.real))
> + return result;
> + else
> + return NULL;
> }
>
> /* Convert character to real. The constant will be padded or truncated. */
> diff --git a/gcc/fortran/target-memory.cc b/gcc/fortran/target-memory.cc
> index 7ce7d736629..04afc357e3c 100644
> --- a/gcc/fortran/target-memory.cc
> +++ b/gcc/fortran/target-memory.cc
> @@ -417,10 +417,13 @@ gfc_interpret_float (int kind, unsigned char *buffer, size_t buffer_size,
> {
> gfc_set_model_kind (kind);
> mpfr_init (real);
> - gfc_conv_tree_to_mpfr (real,
> - native_interpret_expr (gfc_get_real_type (kind),
> - buffer, buffer_size));
>
> + tree source = native_interpret_expr (gfc_get_real_type (kind), buffer,
> + buffer_size);
> + if (!source)
> + return 0;
> +
> + gfc_conv_tree_to_mpfr (real, source);
> return size_float (kind);
> }
>
> diff --git a/gcc/testsuite/gfortran.dg/pr103628.f90 b/gcc/testsuite/gfortran.dg/pr103628.f90
> new file mode 100644
> index 00000000000..e49aefc18fd
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> @@ -0,0 +1,14 @@
> +! { dg-do compile { target powerpc*-*-* } }
> +! { dg-options "-O2 -mabi=ibmlongdouble" }
Since this test case is powerpc only, I think it can be moved to gcc/testsuite/gcc.target/powerpc/ppc-fortran.
BR,
Kewen
^ permalink raw reply [flat|nested] 6+ messages in thread