[Bug fortran/113797] New: Deferred length character concatenation in openmp region has wrong length

[Bug fortran/113797] New: Deferred length character concatenation in openmp region has wrong length

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797

            Bug ID: 113797
           Summary: Deferred length character concatenation in openmp
                    region has wrong length
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mscfd at gmx dot net
  Target Milestone: ---

Created attachment 57349
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57349&action=edit
concat.f90

The code compiled with -fopenmp and run with at least 2 threads fails.

Usually "out" contains the expected string, but occasionally "out" is just "abc
                ", the leading concat_f(..) part is missing. I have added the
"// 'abc'" part to make this more visible. Without this additional
concatenation "out" would be empty. Looks like the length of the concat_f
result is wrong sometimes.

I do not see any errors with valgrind/helgrind or sanitizers.

The problem is already present in gfortran-13.

There are some related bugs, like bug 97977. But here all the involved
variables are local variables in subroutines or functions and thus on thread
private stack. So this feels different.

[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
  static integer(kind=8) slen.1;
inside 
void check (integer(kind=4) & restrict i)


    pstr.2 = 0B;
    slen.1 = 0;
    concat_f (&pstr.2, &slen.1, &"0123456 "[1]{lb: 1 sz: 1}, D.4331, 8);

That is it used for the return value of concat_f.
I don't know why it is static but that is almost likely the cause of the issue
there.

[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-02-08
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.


Maybe this:
```
apinski@xeond:~/src/upstream-gcc/gcc/gcc/fortran$ git diff trans-expr.cc
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 218fede6a82..8ab7efe5740 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7935,7 +7935,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
          tmp = len;
          if (!VAR_P (tmp))
            tmp = gfc_evaluate_now (len, &se->pre);
-         TREE_STATIC (tmp) = 1;
          gfc_add_modify (&se->pre, tmp,
                          build_int_cst (TREE_TYPE (tmp), 0));
          tmp = gfc_build_addr_expr (NULL_TREE, tmp);

```

But I don't know the fortran front-end that well.

[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length

[mscfd at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797

--- Comment #3 from martin <mscfd at gmx dot net> ---
Thanks for the patch, it does the job. But if I compile with 
"gfortran-14 -fopenmp -Wuninitialized"

then I obtain

   20 |       out = concat_f('0123456 ', some()) // ' abc'
      |                                                  ^
note: ‘slen.1’ declared here

So there still seems to be something amiss.

Here is the tree dump of the initial part of check(), where slen.1 is declared.
The problem might be the declaration of pstr.2?

__attribute__((fn spec (". r ")))
void check (integer(kind=4) & restrict i)
{
  character(kind=1) out[1:15];

  {
    struct string D.4330;
    struct string * D.4331;
    integer(kind=8) slen.1;
    character(kind=1)[1:slen.1] * pstr.2;
    character(kind=1)[1:] * pstr.3;
    void * restrict D.4336;
    integer(kind=8) D.4337;
    integer(kind=8) D.4338;
    void * D.4339;
    void * D.4340;

    D.4330 = some ();
    D.4331 = &D.4330;
        typedef character(kind=1) struct character(kind=1)[1:slen.1][1:slen.1];
    pstr.2 = 0B;
    slen.1 = 0;
    concat_f (&pstr.2, &slen.1, &"0123456 "[1]{lb: 1 sz: 1}, D.4331, 8);
    if (D.4331->chars != 0B)
      {
        __builtin_free ((void *) D.4331->chars);
        D.4331->chars = 0B;
      }
    D.4336 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
(slen.1 + 4), 1>);
    pstr.3 = (character(kind=1)[1:] *) D.4336;
    _gfortran_concat_string (slen.1 + 4, pstr.3, slen.1, pstr.2, 4, &"
abc"[1]{lb: 1 sz: 1});
    __builtin_free ((void *) pstr.2);
    D.4337 = slen.1 + 4;
    D.4338 = slen.1 + 4;
    D.4339 = (void *) &out;
    D.4340 = (void *) pstr.3;
    if (NON_LVALUE_EXPR <D.4338> <= 14)
      {
        __builtin_memmove (D.4339, D.4340, (unsigned long) NON_LVALUE_EXPR
<D.4338>);
        __builtin_memset (D.4339 + (sizetype) NON_LVALUE_EXPR <D.4338>, 32,
(unsigned long) (15 - NON_LVALUE_EXPR <D.4338>));
      }
    else
      {
        __builtin_memmove (D.4339, D.4340, 15);
      }
    __builtin_free ((void *) pstr.3);
  }
...

[Bug fortran/113797] Deferred length character concatenation in openmp region has wrong length

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to martin from comment #3)
>         typedef character(kind=1) struct
> character(kind=1)[1:slen.1][1:slen.1];
>     pstr.2 = 0B;
>     slen.1 = 0;

Maybe the order here. slen.1 should be set to 0 before the use inside the
typedef. That is kinda of the reason why static works (with not openmp).