[PATCHv2,gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

  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.

  Compared to last version, this version moves the mpfr_init after NULL tree
test and fixes the format problem according to Tobias's advice. Thanks a lot.

Gui Haochen
Thanks

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
  

Hi,
  The patch passed regression test on Power linux platforms. Sorry for missing
the information.

Gui Haochen

在 2023/3/3 17:12, HAO CHEN GUI via Gcc-patches 写道:
> 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.
> 
>   Compared to last version, this version moves the mpfr_init after NULL tree
> test and fixes the format problem according to Tobias's advice. Thanks a lot.
> 
> Gui Haochen
> Thanks
> 
> 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..0c47aa6b842 100644
> --- a/gcc/fortran/target-memory.cc
> +++ b/gcc/fortran/target-memory.cc
> @@ -416,11 +416,14 @@ gfc_interpret_float (int kind, unsigned char *buffer, size_t buffer_size,
>  		     mpfr_t real)
>  {
>    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;
> +
> +  mpfr_init (real);
> +  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" }
> +
> +! 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.
> +
> +program main
> +  integer, parameter :: k = 16
> +  real(kind = k):: b = 4h1234
> +end program main
> +
> +! { dg-warning "Conversion from HOLLERITH" "warning" { target powerpc*-*-* } 10 }
> +! { dg-error "Unclassifiable statement" "error" { target powerpc*-*-* } 10 }
  

Hi Haochen,

thanks for fixing 'gcc/fortran/target-memory.cc'.

But could you also include the 'gcc/fortran/intrinsic.cc' change
proposed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613030.html (and
acknowledged by Steve)?

This will replace "Unclassifiable statement" by "Cannot simplify
expression" which is a bit more helpful.

(After doing so, at least the dg-error in your testcase needs to be
updated; I assume that it won't affect other testcases, but that needs
to be checked. – And you should update the comment in the testcase as
well - and in text you will put in the commit log, if applicable.)

Additionally, Kewen suggested:
> Since this test case is powerpc only, I think it can be moved to gcc/testsuite/gcc.target/powerpc/ppc-fortran.

Which sounds reasonable.


Otherwise it looks good to me.

On 03.03.23 10:12, 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.
>
>    Compared to last version, this version moves the mpfr_init after NULL tree
> test and fixes the format problem according to Tobias's advice. Thanks a lot.

(The format issue was actually spotted by Bernhard.)

Thanks for working on this!

Tobias

PS: One can also discuss Steve's suggestion about deprecating Holleriths / guarding
the support behind some flag. But I think that's unrelated to this bug fix patch and
should be discussed/done separately.


> 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..0c47aa6b842 100644
> --- a/gcc/fortran/target-memory.cc
> +++ b/gcc/fortran/target-memory.cc
> @@ -416,11 +416,14 @@ gfc_interpret_float (int kind, unsigned char *buffer, size_t buffer_size,
>                    mpfr_t real)
>   {
>     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;
> +
> +  mpfr_init (real);
> +  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" }
> +
> +! 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.
> +
> +program main
> +  integer, parameter :: k = 16
> +  real(kind = k):: b = 4h1234
> +end program main
> +
> +! { dg-warning "Conversion from HOLLERITH" "warning" { target powerpc*-*-* } 10 }
> +! { dg-error "Unclassifiable statement" "error" { target powerpc*-*-* } 10 }
-----------------
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
  

Hi Tobias,

在 2023/3/3 17:29, Tobias Burnus 写道:
> But could you also include the 'gcc/fortran/intrinsic.cc' change
> proposed in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613030.html (and
> acknowledged by Steve)? 

Sure, I will merge it into the patch and do the regression test.

Additionally, Kewen suggested:
>> Since this test case is powerpc only, I think it can be moved to gcc/testsuite/gcc.target/powerpc/ppc-fortran.
> 
> Which sounds reasonable.

Test cases under gcc.target are tested by check-gcc-c. It greps "warning"
and "error" (C style, lower case) from the output while check-gcc-fortran
greps "Warning" and "Error" (upper case). As the test case needs to check
the "Warning" and "Error" messages. I have to put it in gfortran.dg
directory. What's your opinion?

Gui Haochen
Thanks
  

Hi Haochen,

On 03.03.23 10:56, HAO CHEN GUI via Gcc-patches wrote:
> Sure, I will merge it into the patch and do the regression test.
Thanks :-)
> Additionally, Kewen suggested:
>>> Since this test case is powerpc only, I think it can be moved to gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.expgcc.target/powerpc/ppc-fortran.
>> Which sounds reasonable.
> Test cases under gcc.target are tested by check-gcc-c. It greps "warning"
> and "error" (C style, lower case) from the output while check-gcc-fortran
> greps "Warning" and "Error" (upper case). As the test case needs to check
> the "Warning" and "Error" messages. I have to put it in gfortran.dg
> directory. What's your opinion?

Thanks for digging and giving a reason.

Looks as if at some point, adapting
gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp to handle
this as well could make sense.

But placing it - as you did - under gcc/testsuite/gfortran.dg is fine
and surely the simpler solution. Thus, leave it as it.

Thanks,

Tobias


>
> Gui Haochen
> Thanks
-----------------
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
  

Hi Haochen,

on 2023/3/3 20:54, Tobias Burnus wrote:
> Hi Haochen,
> 
> On 03.03.23 10:56, HAO CHEN GUI via Gcc-patches wrote:
>> Sure, I will merge it into the patch and do the regression test.
> Thanks :-)
>> Additionally, Kewen suggested:
>>>> Since this test case is powerpc only, I think it can be moved to gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.expgcc.target/powerpc/ppc-fortran.
>>> Which sounds reasonable.
>> Test cases under gcc.target are tested by check-gcc-c. It greps "warning"
>> and "error" (C style, lower case) from the output while check-gcc-fortran
>> greps "Warning" and "Error" (upper case). As the test case needs to check
>> the "Warning" and "Error" messages. I have to put it in gfortran.dg
>> directory. What's your opinion?
> 
> Thanks for digging and giving a reason.

+1!

I just posted one patch[1] to make ppc-fortran.exp support the need of your
patch here, I verified it can work for this revision, could you double check
with your updated revision?

[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613442.html

> 
> Looks as if at some point, adapting
> gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp to handle
> this as well could make sense.
> 
> But placing it - as you did - under gcc/testsuite/gfortran.dg is fine
> and surely the simpler solution. Thus, leave it as it.

Yeah, either way works for me.

Thanks again!

BR,
Kewen