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).