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 <guih...@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