public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/95868] New: Derived-type deferred-length character component handling broken
@ 2020-06-24 12:48 burnus at gcc dot gnu.org
2020-07-08 10:44 ` [Bug fortran/95868] " dominiq at lps dot ens.fr
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: burnus at gcc dot gnu.org @ 2020-06-24 12:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868
Bug ID: 95868
Summary: Derived-type deferred-length character component
handling broken
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following program fails with an ICE or a segfault.
Issues I observed:
* For the ICE, the issue seems to be:
gfc_conv_loop_setup() calls
gfc_add_loop_ss_code (loop, loop->ss, false, where)
expr = ss_info->expr;
case GFC_SS_SCALAR:
gfc_conv_expr (&se, expr);
→ The ICE occur because expr == NULL and expr is dereferenced.
I am not sure whether it is the following code, but it sets
ss-info->expr and I bet ss.end == NULL in my testcase, but I
have not check it:
gfc_walk_array_ref()
if (ref->type == REF_SUBSTRING)
{
ss = gfc_get_scalar_ss (ss, ref->u.ss.start);
ss = gfc_get_scalar_ss (ss, ref->u.ss.end);
}
and the second argument is the 'expr'.
* For derived-type deferred strings, one often has the intcst "0" in the tree.
for gfc_conv_expr_descriptor, for the simple case, that's handled
(search: deferred_array_component).
However, for the complicated case, one might end up with
"0 = 0;"
which the gimplifier does not like.
I am not sure whether the patch is correct, but it fixes one testcase
for me (not shown, OpenMP one) and looks more sensible. I am not sure
whether VAR_P(se->string_length) makes sense and when it gets set or
defined.
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 54e1107c711..6da8c6d5595 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7551,15 +7551,14 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
/* Set the string_length for a character array. */
if (expr->ts.type == BT_CHARACTER)
{
- se->string_length = gfc_get_expr_charlen (expr);
- if (VAR_P (se->string_length)
- && expr->ts.u.cl->backend_decl == se->string_length)
- tmp = ss_info->string_length;
- else
- tmp = se->string_length;
-
- if (expr->ts.deferred)
- gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl, tmp);
+ tmp = gfc_get_expr_charlen (expr);
+ if (!VAR_P (expr->ts.u.cl->backend_decl))
+ se->string_length = (expr->ts.deferred ? ss_info->string_length
+ : tmp);
+ else if (expr->ts.deferred
+ && se->string_length != expr->ts.u.cl->backend_decl)
+ gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl,
+ ss_info->string_length);
}
/* If we have an array section, are assigning or passing an array
--------------
implicit none
type t
character(len=:), allocatable :: str(:)
end type t
type (t) :: var
character(len=:), allocatable :: str(:)
integer :: i
allocate(character(len=3) :: str(3))
str(:) = ["abc", "def", "ghi"]
!call dummy(str) ! OK
!call dummy(str(2:)) ! OK
!call dummy(str(:)(2:)) ! (1) ICE
!call sub1(str) ! OK
!call sub2(str(2:)) ! (2) Segfault at runtime
!call sub3(str(:)(2:)) ! (3) ICE
var%str = ["abc", "def", "ghi"]
!call sub1(var%str) ! (4) Fails at runtime ('stop 1')
!call sub2(var%str(2:)) ! (5) Fails at runtime ('stop 1')
!call sub3(var%str(:)(2:)) ! ICE
deallocate(str,var%str)
contains
subroutine dummy(x)
character(len=1), dimension(*) :: x
end
subroutine sub1(x)
character(len=*), dimension(*) :: x
if (len(x) /= 3) stop 1
if (any (x(1:3) /= ["abc", "def", "ghi"])) stop 2
end
subroutine sub2(x)
character(len=*), dimension(*) :: x
if (len(x) /= 3) stop 3
if (any (x(1:2) /= ["def", "ghi"])) stop 4
end
subroutine sub3(x)
character(len=*), dimension(*) :: x
if (len(x) /= 2) stop 5
if (any (x(1:3) /= ["bc", "ef", "hi"])) stop 6
end
end
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/95868] Derived-type deferred-length character component handling broken
2020-06-24 12:48 [Bug fortran/95868] New: Derived-type deferred-length character component handling broken burnus at gcc dot gnu.org
@ 2020-07-08 10:44 ` dominiq at lps dot ens.fr
2020-07-15 10:09 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-07-08 10:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-07-08
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed. Quite complex test case!
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/95868] Derived-type deferred-length character component handling broken
2020-06-24 12:48 [Bug fortran/95868] New: Derived-type deferred-length character component handling broken burnus at gcc dot gnu.org
2020-07-08 10:44 ` [Bug fortran/95868] " dominiq at lps dot ens.fr
@ 2020-07-15 10:09 ` burnus at gcc dot gnu.org
2021-02-24 16:33 ` burnus at gcc dot gnu.org
2022-02-28 10:14 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: burnus at gcc dot gnu.org @ 2020-07-15 10:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed. Quite complex test case!
Came up when trying to write a patch for OpenMP structure/derived-type element
mapping (r11-2079). Hence:
Additional testcase:
libgomp/testsuite/libgomp.fortran/struct-elem-map-1.f90
look for the var%str4 and var%uni4 lines – and uncomment them.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/95868] Derived-type deferred-length character component handling broken
2020-06-24 12:48 [Bug fortran/95868] New: Derived-type deferred-length character component handling broken burnus at gcc dot gnu.org
2020-07-08 10:44 ` [Bug fortran/95868] " dominiq at lps dot ens.fr
2020-07-15 10:09 ` burnus at gcc dot gnu.org
@ 2021-02-24 16:33 ` burnus at gcc dot gnu.org
2022-02-28 10:14 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: burnus at gcc dot gnu.org @ 2021-02-24 16:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The patch of comment 0 re-appeared in slightly different flavor for PR99125
(https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565768.html); thus,
that part is now fixed.
Still, the tests in the testcase still fail as before.
(Except: sub2 fails with '4' not '1' (typo) and '(2)' does not segfault at run
time (at the moment) but just fails with 'stop 4'.)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/95868] Derived-type deferred-length character component handling broken
2020-06-24 12:48 [Bug fortran/95868] New: Derived-type deferred-length character component handling broken burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2021-02-24 16:33 ` burnus at gcc dot gnu.org
@ 2022-02-28 10:14 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-02-28 10:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I additionally observe the following:
<component_ref 0x7ffff71c2150
type <pointer_type 0x7ffff71bb2a0
type <array_type 0x7ffff71bb1f8 type <integer_type 0x7ffff6fe1348
character(kind=1)>
string-flag BLK
size <integer_cst 0x7ffff6fc9c78 constant 0>
That makes it difficult to check the length later on during ME processing. In
my case, for lang hooks in trans-openmp.c for mapping
omp target map(var)
where var is allocatable and var%string is a deferred-length allocatable.
EXPECTED:
* the field's GFC_DECL_STRING_LEN points for 'var%string' to the
_string_length component.
* TODO: Check whether the debug info is correctly set for those.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-02-28 10:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-24 12:48 [Bug fortran/95868] New: Derived-type deferred-length character component handling broken burnus at gcc dot gnu.org
2020-07-08 10:44 ` [Bug fortran/95868] " dominiq at lps dot ens.fr
2020-07-15 10:09 ` burnus at gcc dot gnu.org
2021-02-24 16:33 ` burnus at gcc dot gnu.org
2022-02-28 10:14 ` burnus at gcc dot gnu.org
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).