Re: [PATCH] Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865]
On 6/3/24 1:12 PM, Harald Anlauf wrote: Dear all, the attached simple patch fixes an ICE for ALLOCATE with SOURCE= of a deferred-length character array with source-expression being an array of character with length zero. The reason was that the array descriptor of the source-expression was discarded in the special case of length 0. Solution: restrict special case to rank 0. Regtested on x86_64-pc-linux-gnu. OK for mainline? The offending code was introduced during 7-development, so it is technically a regression. I would therefore like to backport after waiting for a week or two. Thanks, Harald OK and thanks for patch. Jerry
[PATCH] Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865]
Dear all,
the attached simple patch fixes an ICE for ALLOCATE with SOURCE=
of a deferred-length character array with source-expression
being an array of character with length zero. The reason was
that the array descriptor of the source-expression was discarded
in the special case of length 0.
Solution: restrict special case to rank 0.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
The offending code was introduced during 7-development,
so it is technically a regression. I would therefore
like to backport after waiting for a week or two.
Thanks,
Harald
From ae5e3654d30d17584cfcfc3bbcc48cf75cb7453c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 3 Jun 2024 22:02:06 +0200
Subject: [PATCH] Fortran: fix ALLOCATE with SOURCE=, zero-length character
[PR83865]
gcc/fortran/ChangeLog:
PR fortran/83865
* trans-stmt.cc (gfc_trans_allocate): Restrict special case for
source-expression with zero-length character to rank 0, so that
the array shape is not discarded.
gcc/testsuite/ChangeLog:
PR fortran/83865
* gfortran.dg/allocate_with_source_32.f90: New test.
---
gcc/fortran/trans-stmt.cc | 3 +-
.../gfortran.dg/allocate_with_source_32.f90 | 33 +++
2 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/allocate_with_source_32.f90
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 9b497d6bdc6..93b633e212e 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6449,8 +6449,9 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist *omp_allocate)
else
gfc_add_block_to_block (, );
- /* Special case when string in expr3 is zero. */
+ /* Special case when string in expr3 is scalar and has length zero. */
if (code->expr3->ts.type == BT_CHARACTER
+ && code->expr3->rank == 0
&& integer_zerop (se.string_length))
{
gfc_init_se (, NULL);
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_32.f90 b/gcc/testsuite/gfortran.dg/allocate_with_source_32.f90
new file mode 100644
index 000..4a9bd46da4d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_32.f90
@@ -0,0 +1,33 @@
+! { dg-do run }
+!
+! PR fortran/83865
+!
+! Test ALLOCATE with SOURCE= of deferred length character, where
+! the source-expression is an array of character with length 0.
+
+program p
+ implicit none
+ character(:), allocatable :: z(:)
+ character(1) :: cc(4) = ""
+ allocate (z, source=[''])
+ if (len (z) /= 0 .or. size (z) /= 1) stop 1
+ deallocate (z)
+ allocate (z, source=['',''])
+ if (len (z) /= 0 .or. size (z) /= 2) stop 2
+ deallocate (z)
+ allocate (z, source=[ character(0) :: 'a','b','c'])
+ if (len (z) /= 0 .or. size (z) /= 3) stop 3
+ deallocate (z)
+ allocate (z, source=[ character(0) :: cc ])
+ if (len (z) /= 0 .or. size (z) /= 4) stop 4
+ deallocate (z)
+ associate (x => f())
+if (len (x) /= 0 .or. size (x) /= 1) stop 5
+if (x(1) /= '') stop 6
+ end associate
+contains
+ function f() result(z)
+character(:), allocatable :: z(:)
+allocate (z, source=[''])
+ end function f
+end
--
2.35.3
Re: [PATCH 03/52] fortran: Replace uses of {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE
Hi,
Am 03.06.24 um 05:00 schrieb Kewen Lin:
Joseph pointed out "floating types should have their mode,
not a poorly defined precision value" in the discussion[1],
as he and Richi suggested, the existing macros
{FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
hook mode_for_floating_type. To be prepared for that, this
patch is to replace use of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
in fortran with TYPE_PRECISION of
{float,{,long_}double}_type_node.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (build_round_expr): Use TYPE_PRECISION of
long_double_type_node to replace LONG_DOUBLE_TYPE_SIZE.
* trans-types.cc (gfc_build_real_type): Use TYPE_PRECISION of
{float,double,long_double}_type_node to replace
{FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE.
---
gcc/fortran/trans-intrinsic.cc | 3 ++-
gcc/fortran/trans-types.cc | 10 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 912c1000e18..96839705112 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -395,7 +395,8 @@ build_round_expr (tree arg, tree restype)
don't have an appropriate function that converts directly to the integer
type (such as kind == 16), just use ROUND, and then convert the result to
an integer. We might also need to convert the result afterwards. */
- if (resprec <= INT_TYPE_SIZE && argprec <= LONG_DOUBLE_TYPE_SIZE)
+ if (resprec <= INT_TYPE_SIZE
+ && argprec <= TYPE_PRECISION (long_double_type_node))
fn = builtin_decl_for_precision (BUILT_IN_IROUND, argprec);
else if (resprec <= LONG_TYPE_SIZE)
fn = builtin_decl_for_precision (BUILT_IN_LROUND, argprec);
diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
index 8466c595e06..0ef67723fcd 100644
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
@@ -873,13 +873,15 @@ gfc_build_real_type (gfc_real_info *info)
int mode_precision = info->mode_precision;
tree new_type;
- if (mode_precision == FLOAT_TYPE_SIZE)
+ if (mode_precision == TYPE_PRECISION (float_type_node))
info->c_float = 1;
- if (mode_precision == DOUBLE_TYPE_SIZE)
+ if (mode_precision == TYPE_PRECISION (double_type_node))
info->c_double = 1;
- if (mode_precision == LONG_DOUBLE_TYPE_SIZE && !info->c_float128)
+ if (mode_precision == TYPE_PRECISION (long_double_type_node)
+ && !info->c_float128)
info->c_long_double = 1;
- if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128)
+ if (mode_precision != TYPE_PRECISION (long_double_type_node)
+ && mode_precision == 128)
{
/* TODO: see PR101835. */
info->c_float128 = 1;
the Fortran part looks good to me.
Thanks,
Harald
[GOMP, Fortran] RFC: Issues with gomp-fortran tests
Hi gfortraneers and gomp-specialists,
during regression testing I lately experience all OpenMP fortran tests to be
failing. I do:
make check-fortran
My configure is:
../gcc/configure --disable-multilib --enable-stage1-languages=c,fortran,c++
--enable-checking=yes --enable-offload-defaulted --prefix=`realpath ../gfortran`
It does not matter, if I just do a stage1 build or a full bootstrap,
fortran-gomp tests always fail. I haven't tried running the full testsuite,
because that takes a lng time. Trying to run only the target
make check-target-libgomp-fortran
(which is included in check-fortran), also results in the fortran-gomp tests not
being run, or more specifically not being able to be compiled. In fact the
gfortran compiler is not found. The expect scripts resolve the gfortran
compiler for fortran-gomp-testing to be three levels up the directory tree,
where a "gfortran" filesystem node is present, but is a directory. I.e. testing
if something called gfortran is present there, will pass. Later on the tests
then complain about "gfortran: Permission denied", because a directory - of
course - can not be executed. I have spent two days now to figure how to resolve
this, but all I came up with is this patch:
diff --git a/libgomp/testsuite/libgomp.fortran/fortran.exp
b/libgomp/testsuite/libgomp.fortran/fortran.exp index 32e4bb2af4e..dd18aa98a91
100644 --- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -20,9 +20,14 @@ if { $blddir != "" } {
} else {
set libquadmath_library_path ""
}
-} elseif { ![info exists GFORTRAN_UNDER_TEST] } {
+}
+if { ![info exists GFORTRAN_UNDER_TEST]
+|| ![file exists "$GFORTRAN_UNDER_TEST"] } {
verbose -log "GFORTRAN_UNDER_TEST not defined, will not execute fortran
tests"
-return
+set GFORTRAN_UNDER_TEST "${blddir}/../../gcc/gfortran -B$blddir/../../gcc"
+if { ![file exists "$GFORTRAN_UNDER_TEST"] } {
+ return
+}
}
if { $blddir != "" } {
set lang_source_re {^.*\.[fF](|90|95|03|08)$}
This is just a first shot. With the patch the test compile and run ok. But now
my question: What am I doing wrong? I am working on gcc-master with only a few
commits behind. Is testing libgomp-fortran fine for everyone else?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
