[Bug target/95276] New: Amusing stringpop-overflow message building libgfortran on power9

[Bug target/95276] New: Amusing stringpop-overflow message building libgfortran on power9

[tkoenig at gcc dot gnu.org]

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

            Bug ID: 95276
           Summary: Amusing stringpop-overflow message building
                    libgfortran on power9
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Just noted this building libgfortran on powerpc64le-unknown-linux-gnu:

../../../trunk/libgfortran/io/write.c: In Funktion »write_z«:
../../../trunk/libgfortran/io/write.c:1181:6: Warnung: Schreiben von
140735240075856 Byte in eine Region der Größe 1 [-Wstringop-overflow=]
 1181 |   *q = '\0';
      |   ~~~^~~~~~

I never thought a single byte could be _that_ big.

The hex number is 0x7fff79fdfa50, which I don't recognize.

This is with trunk dc50686d78d4679b727548c3edc1cb6b0d3b658e.

[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Amusing stringpop-overflow  |[11 Regression] Amusing
                   |message building            |stringpop-overflow message
                   |libgfortran on power9       |building libgfortran
          Component|target                      |middle-end

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Also found on x86_64. Not sure where this belongs, but it looks like
a regression.

[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-05-22
             Status|UNCONFIRMED                 |WAITING
                 CC|                            |msebor at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Can you please reduce that to a test case or a translation unit?

[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Created attachment 48586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48586&action=edit
(somewhat reduced) test case

Here's a somewhat reduced test case; I did not spend too much time
throwing out unnecessary functions or declarations.

The warning I now see is

In function 'ztoa_big',
    inlined from 'write_z' at w2.i:6499:11:
w2.i:6484:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
 6484 |   *q = '\0';
      |   ~~~^~~~~~
w2.i: In function 'write_z':
w2.i:6495:8: note: at offset 0 to object 'itoa_buf' with size 33 declared here
 6495 |   char itoa_buf[((sizeof (GFC_REAL_16)) * 2 + 1)];
      |        ^~~~~~~~

so the really big number is gone.

[Bug middle-end/95276] [11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
The error is locale-dependent, at least somewhat. With the test case
I posted:

$ LANG="" gcc -S -O2 w-posted.i 
In function 'ztoa_big',
    inlined from 'write_z' at w-posted.i:6499:11:
w-posted.i:6484:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
 6484 |   *q = '\0';
      |   ~~~^~~~~~
w-posted.i: In function 'write_z':
w-posted.i:6495:8: note: at offset 0 to object 'itoa_buf' with size 33 declared
here
 6495 |   char itoa_buf[((sizeof (GFC_REAL_16)) * 2 + 1)];
      |        ^~~~~~~~
$ LANG="de_DE.UTF-8" gcc -S -O2 w-posted.i 
w-posted.i: In Funktion »write_z«:
w-posted.i:6484:6: Warnung: Schreiben von 140096374336960 Byte in eine Region
der Größe 1 [-Wstringop-overflow=]
 6484 |   *q = '\0';
      |   ~~~^~~~~~
w-posted.i:6495:8: Anmerkung: bei Offset 0 zum Objekt »itoa_buf« mit Größe 33
wurde hier deklariert
 6495 |   char itoa_buf[((sizeof (GFC_REAL_16)) * 2 + 1)];

So, probably reading from uninitialized memory somewhere.

I think this should be enough to confirm this.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |10.2
            Summary|[11 Regression] Amusing     |[10/11 Regression] Amusing
                   |stringpop-overflow message  |stringpop-overflow message
                   |building libgfortran        |building libgfortran

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
gcc 10 also fails, gcc 9 is OK:

$ LANG="de_DE.UTF-8" ~/lib/gcc/x86_64-pc-linux-gnu/10.0.1/cc1 -quiet -O2
w-posted.i 
w-posted.i: In Funktion »write_z«:
w-posted.i:6484:6: Warnung: Schreiben von 139708431197600 Byte in eine Region
der Größe 1 [-Wstringop-overflow=]
 6484 |   *q = '\0';
      |   ~~~^~~~~~
w-posted.i:6495:8: Anmerkung: bei Offset 0 zum Objekt »itoa_buf« mit Größe 33
wurde hier deklariert
 6495 |   char itoa_buf[((sizeof (GFC_REAL_16)) * 2 + 1)];
      |        ^~~~~~~~
$ LANG="de_DE.UTF-8" ~/lib/gcc/x86_64-pc-linux-gnu/9.3.1/cc1 -quiet -O2
w-posted.i 
$

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Created attachment 48588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48588&action=edit
shortened test case

Here's the test case as shortened by multidelta.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
There are some uninitialized local variables in the reduced test case but with
those made extern I was able to reproduce the warning.  But unless the test
case was reduced too far or the reduction introduced bugs (or I unless missed
something) I think the warning justified.  ztoa_big() is being called with len
> 16 and a buffer of size 33.  The loop in the function iterates 2 * len times,
storing into successive elements of the 33-byte itoa_buf, and then appending
'\0'.  So with len == 17 it writes 35 bytes into the 33-bute itoa_buf.

Here's a much smaller test case that I ultimately reduced it to that shows the
bug (I shrank the buffer while still keeping the size ratios).  The offset of
zero doesn't seem right but that's a side issue.

$ cat pr95276.c && gcc -O2 -S  pr95276.c 
char a[4];

void f (char *s, int n)
{
  if (n <= 2)
    return;

  char *d = a;

  for (int i = 0; i < n; i++)
    {
      extern volatile unsigned char h, l;

      *d++ = s[h];
      *d++ = s[l];
    }

  *d = '\0';
}
pr95276.c: In function ‘f’:
pr95276.c:18:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   18 |   *d = '\0';
      |   ~~~^~~~~~
pr95276.c:1:6: note: at offset 0 to object ‘a’ with size 4 declared here
    1 | char a[4];
      |      ^

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Looks like a faithful reduction that you made, it also still shows
the locale dependency from comment #4:

$ LANG="" gcc -O2 -S a.c
a.c: In function 'f':
a.c:18:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   18 |   *d = '\0';
      |   ~~~^~~~~~
a.c:1:6: note: at offset 0 to object 'a' with size 4 declared here
    1 | char a[4];
      |      ^
$ LANG=de_DE.UTF-8  gcc -O2 -S a.c
a.c: In Funktion »f«:
a.c:18:6: Warnung: Schreiben von 140075679154576 Byte in eine Region der Größe
1 [-Wstringop-overflow=]
   18 |   *d = '\0';
      |   ~~~^~~~~~
a.c:1:6: Anmerkung: bei Offset 0 zum Objekt »a« mit Größe 4 wurde hier
deklariert
    1 | char a[4];
      |      ^

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
So, two bugs, as far as I can see: One in libgfortran, which was warned about.
I will check if this is actually valid, maybe the automated test case reduction
went too far.

The second one about the apparent use of uninitialized memory for the warning.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
The libgfortran bug is now PR 95313 .

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #10)
> The libgfortran bug is now PR 95313 .

Actually, the warning is a false positive, for our code.

We never call write_z with an excessive length.

So, what's left is to tell -Wstringop-overflow to shut up in a way
that does not incur a run-time penalty.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.2                        |10.3

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.2 is released, adjusting target milestone.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |10.1.0
           Priority|P3                          |P2

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #13 from Martin Sebor <msebor at gcc dot gnu.org> ---
The latest trunk outputs the same warning with a better note (the offset is
correct).  As discussed in comment #7 the warning for the small test case is
correct: the loop overflows the small buffer.  It iterates at least three
times, writing two bytes into the four byte destination in each iteration, for
a total of six bytes.  I don't see a bug here so I'm resolving it as invalid. 
If the test case below isn't representative of the fortran code please submit
one that is.

$ cat pr95276.c && gcc -O2 -S -Wall pr95276.c
char a[4];

void f (char *s, int n)
{
  if (n <= 2)
    return;

  char *d = a;

  for (int i = 0; i < n; i++)
    {
      extern volatile unsigned char h, l;

      *d++ = s[h];
      *d++ = s[l];
    }

  *d = '\0';
}
pr95276.c: In function ‘f’:
pr95276.c:18:6: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   18 |   *d = '\0';
      |   ~~~^~~~~~
pr95276.c:1:6: note: at offset 6 into destination object ‘a’ of size 4
    1 | char a[4];
      |      ^

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #8)
> a.c:18:6: warning: writing 1 byte into a region of size 0
> $ LANG=de_DE.UTF-8  gcc -O2 -S a.c
> a.c:18:6: Warnung: Schreiben von 140075679154576 Byte in eine Region der

That's due to the missing %G in some translation such as at:
 msgid "%Gwriting between %wu and %wu bytes into a region of size %wu"
 msgstr "Schreiben von %wu bis %wu Bytes in eine Region der Größe %wu"

I reported it to the translators of the de.po file.