[Bug c/96326] New: Incorrect loop optimization at -O3

[Bug c/96326] New: Incorrect loop optimization at -O3

[pterjan at gmail dot com]

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

            Bug ID: 96326
           Summary: Incorrect loop optimization at -O3
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pterjan at gmail dot com
  Target Milestone: ---

Found in https://github.com/Sereal/Sereal/issues/229

#include <string.h>
#include <stdio.h>

int main() {
        char buf[128];
        char *src = buf;
        char *op = buf + 3;
        int len = 64;
        strcpy(buf, "abc");
        while (op - src < 8) {
                *(unsigned long*)op = *(const unsigned long*)src;
                len -= op - src;
                op += op - src;
        }
        while (len > 0) {
                *(unsigned long*)op = *(const unsigned long*)src;
                src += 8;
                op += 8;
                len -= 8;
        }
        printf("%ld\n", strlen(buf));
}

$ gcc -O2 -Wall t.c; ./a.out 
68

$ gcc -O3 -Wall t.c; ./a.out 
24

Adding a printf in the second loop also fixes it.

[Bug middle-end/96326] Incorrect loop optimization at -O3

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
           Keywords|                            |wrong-code

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does adding -fno-strict-aliasing helps?

[Bug middle-end/96326] Incorrect loop optimization at -O3

[pterjan at gmail dot com]

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

--- Comment #2 from Pascal Terjan <pterjan at gmail dot com> ---
No:

$ gcc -O3 -Wall -fno-strict-aliasing  t.c; ./a.out 
24

However -fno-tree-loop-vectorize fixes it:

$ gcc -O3 -Wall -fno-tree-loop-vectorize t.c; ./a.out 
68

[Bug middle-end/96326] [10/11 Regression] Incorrect loop optimization at -O3 since r10-4803-g8489e1f45b50600c

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org
   Last reconfirmed|                            |2020-07-27
            Summary|Incorrect loop optimization |[10/11 Regression]
                   |at -O3                      |Incorrect loop optimization
                   |                            |at -O3 since
                   |                            |r10-4803-g8489e1f45b50600c
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r10-4803-g8489e1f45b50600c. I see:

$ gcc pr96326.c -fsanitize=undefined && ./a.out 
pr96326.c:11:23: runtime error: store to misaligned address 0x7fffffffe263 for
type 'long unsigned int', which requires 8 byte alignment
0x7fffffffe263: note: pointer points here
 00  61 62 63 00 00 00 00 00  e0 69 61 f7 ff 7f 00 00  29 00 00 00 00 00 00 00 
88 ff ff ff ff ff ff
              ^ 
pr96326.c:16:23: runtime error: store to misaligned address 0x7fffffffe26c for
type 'long unsigned int', which requires 8 byte alignment
0x7fffffffe26c: note: pointer points here
  63 61 62 63 00 00 00 00  29 00 00 00 00 00 00 00  88 ff ff ff ff ff ff ff  40
6a 61 f7 ff 7f 00 00
              ^ 
68


and ASAN returns a different value:

$ gcc pr96326.c -fsanitize=address && ./a.out 
70

Same for clang:

$ clang pr96326.c -fsanitize=address && ./a.out 
70

So I bet the test-case must be invalid?

[Bug middle-end/96326] [10/11 Regression] Incorrect loop optimization at -O3 since r10-4803-g8489e1f45b50600c

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |10.3

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The following works - your unsigned long objects are not aligned according
to the type which makes the accesses undefined (actually C even specifies
forming the pointer itself is undefined).

#include <string.h>
#include <stdio.h>

typedef unsigned long mylong __attribute__((aligned(1)));
int main() {
        char buf[128];
        char *src = buf;
        char *op = buf + 3;
        int len = 64;
        strcpy(buf, "abc");
        while (op - src < 8) {
                *(mylong*)op = *(const mylong*)src;
                len -= op - src;
                op += op - src;
        }
        while (len > 0) {
                *(mylong*)op = *(const mylong*)src;
                src += 8;
                op += 8;
                len -= 8;
        }
        printf("%ld\n", strlen(buf));
}