[Bug c/109031] New: csmith: possible bad code with -O2 -fno-strict-aliasing

[Bug c/109031] New: csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

            Bug ID: 109031
           Summary: csmith: possible bad code with -O2
                    -fno-strict-aliasing
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54588&action=edit
C source code

For the attached C code:

$ for i in ~/gcc/results.2022*/bin/gcc
$ do 
$ echo $i
$ $i -O2 -fno-strict-aliasing -w bug892.c; ./a.out  1 2>&1 | fgrep g_50; 
$ done
/home/dcb36/gcc/results.20220306/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220403/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220501/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220605/bin/gcc
...checksum after hashing g_50 : C21BF3F9
/home/dcb36/gcc/results.20220703/bin/gcc
$

The git hash for 20220501 is g:75bbc3da3e5f75f683fa33e309045c582efd20eb
and for 20220605 is g:ad6919374beafac4ec1a2f8059620f261019b02f

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
I will try to bisect this one with snapshots. Trying 20220515 first.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #1)
> I will try to bisect this one with snapshots. Trying 20220515 first.

This one bad. Trying 20220508.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
20220508 is good, so the range is 20220508 to 20220515. 

In git hash terms, that's g:a1947c92f7cda5f6cf7b8d8a9a44f6dd45352c03
to g:18547874ee205d830acb31f1e3c1c89fc7725c14.

I will try to reduce the code further.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 54596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54596&action=edit
C source code

After 3 hours further reduction.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Both testcases I tested all exited with a non-zero value even at -O0 ...

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> Both testcases I tested all exited with a non-zero value even at -O0 ...

Ok, I missed you need to pass an argument to the program. Anyways I think this
might be an uninitialized variable causing the difference but I am not 100%
sure.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #4)
> Created attachment 54596 [details]
> C source code
> 
> After 3 hours further reduction.

I am struggling with further reduction. My bash knowledge is short.

My cvise script is:

/usr/bin/gcc -w -Werror=implicit bug892.c \
&& (./a.out 1 > 1) \
&& /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c 
\
&& (./a.out 1 > 2) \
&& diff 1 2; \

but then if diff returns 1, the script should return 0 and
if diff returns 0, then the script should return 1.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to David Binderman from comment #7)
> (In reply to David Binderman from comment #4)
> > Created attachment 54596 [details]
> > C source code
> > 
> > After 3 hours further reduction.
> 
> I am struggling with further reduction. My bash knowledge is short.
> 
> My cvise script is:
> 
> /usr/bin/gcc -w -Werror=implicit bug892.c \
> && (./a.out 1 > 1) \
> && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c 
> \
> && (./a.out 1 > 2) \
> && diff 1 2; \
> 
> but then if diff returns 1, the script should return 0 and
> if diff returns 0, then the script should return 1.

You can take an inspiration here:
https://github.com/marxin/gcc-util/blob/master/bisect/reduce.sh

and you can use multiple `if` statements.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #8)
> > but then if diff returns 1, the script should return 0 and
> > if diff returns 0, then the script should return 1.
> 
> You can take an inspiration here:
> https://github.com/marxin/gcc-util/blob/master/bisect/reduce.sh

Thanks for that. I am a bit further forward and I have this cvise
script:

/usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe
        && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) 
        && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c 
 -o two.exe
        && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) 
        && diff 1 2; 
        if test $? = 0; then 
                exit 1
        fi
                exit 0

It still doesn't work right and I can't fathom what's wrong.
It all works nicely when I do it line by line.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to David Binderman from comment #9)
> (In reply to Martin Liška from comment #8)
> > > but then if diff returns 1, the script should return 0 and
> > > if diff returns 0, then the script should return 1.
> > 
> > You can take an inspiration here:
> > https://github.com/marxin/gcc-util/blob/master/bisect/reduce.sh
> 
> Thanks for that. I am a bit further forward and I have this cvise
> script:
> 
> /usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe
> 	&& (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) 
> 	&& /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c 
>  -o two.exe

If the compilation fails for any reason, then the compound && expression is
false (non-zero) and thus you end up with 'exit 0'. That's not what you want I
guess.

What about:

/usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe
        && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) 
        && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c 
 -o two.exe
        && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) 

        if test $? != 0; then 
                exit 1

        diff 1 2; 
        if test $? = 0; then 
                exit 1
        fi
                exit 0

?

> 	&& (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) 
> 	&& diff 1 2; 
> 	if test $? = 0; then 
> 		exit 1
> 	fi
> 		exit 0
> 
> It still doesn't work right and I can't fathom what's wrong.
> It all works nicely when I do it line by line.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #10)
> What about:
> 
> /usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe
> 	&& (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) 
> 	&& /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c 
>  -o two.exe
> 	&& (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) 
> 
> 	if test $? != 0; then 
> 		exit 1
> 
> 	diff 1 2; 
> 	if test $? = 0; then 
> 		exit 1
> 	fi
> 		exit 0
> 
> ?

Thanks for the idea, but no further forward ;-|. Getting to the diff
is easy. Getting the return code of 1 from the diff out to the calling
perl program converted to 0 is proving to be a challenge.

$ diff 1 2
1c1
< ...checksum after hashing g_50 : 646CF84D
---
> ...checksum after hashing g_50 : C21BF3F9
$ echo $?
1
$

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
> perl program converted to 0 is proving to be a challenge.

perl? Please provide a complete script reproducer.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #13 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #12)
> > perl program converted to 0 is proving to be a challenge.
> 
> perl? Please provide a complete script reproducer.

cvise is written in perl, isn't it ? You've got my cvise script.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to David Binderman from comment #13)
> (In reply to Martin Liška from comment #12)
> > > perl program converted to 0 is proving to be a challenge.
> > 
> > perl? Please provide a complete script reproducer.
> 
> cvise is written in perl, isn't it ? You've got my cvise script.

No, it's written in Python.

So show me how you run cvise then?

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #15 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #14)
> > cvise is written in perl, isn't it ? You've got my cvise script.
> 
> No, it's written in Python.

Of course. How stupid of me.

> So show me how you run cvise then?

$ cvise --n 8 qwe.sh bug892.c

where qwe.sh is the script shown above and bug892.c is the csmith
produced C source code I am trying to reduce.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to David Binderman from comment #15)
> (In reply to Martin Liška from comment #14)
> > > cvise is written in perl, isn't it ? You've got my cvise script.
> > 
> > No, it's written in Python.
> 
> Of course. How stupid of me.
> 
> > So show me how you run cvise then?
> 
> $ cvise --n 8 qwe.sh bug892.c
> 
> where qwe.sh is the script shown above and bug892.c is the csmith
> produced C source code I am trying to reduce.

and what error do you see?

Then please run:

bash -x qwe.sh bug892.c

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #17 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #16)
> bash -x qwe.sh bug892.c

That's a really useful tip. Thanks. I've debugged the script some more
and now have:

rm -f 1 2 one.exe two.exe
/usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe \
    && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1)
    if test $? != 0;
    then
        exit 1
    fi
    # So we have a checksum in file 1.
    /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c  -o
two.exe \
    && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2)
    if test $? != 0;
    then
         exit 1
    fi
    # And we have a checksum in file 2.
    diff 1 2
    if test $? = 0; then
        exit 1
    fi
    exit 0

This script appears to be running nicely now. I will report back
when it has finished or made significant progress.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

--- Comment #18 from David Binderman <dcb314 at hotmail dot com> ---
Part way through reduction, the C code seems to be

int crc32_tab_0;
int crc32_context = 0xFFFFFFFFUL;
void main(int , char []) {
  {
    int crc;
    int i;
    i = 0;
    for (; i < 256; i++)
      crc32_tab_0 = crc;
    {
      { crc32_context = 0 ^ crc32_tab_0; }
    }
    printf("...checksum after hashing %s : %lX\n", "g_50",
           crc32_context ^ 0xFFFFFFFFUL);
  }
}

This looks to me like reading rubbish off the local variable stack in main
and then hashing it.

AFAIK not a bug in gcc, but may be a bug in csmith.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[marxin at gcc dot gnu.org]

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

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

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

--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
Thus closing as invalid.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, cvise reduction of runtime testcases is always problematic, and trying to
ensure
the reduction doesn't introduce uninitialized var uses which weren't there
before (perhaps with checking for new -Wmaybe-uninitialized -Wuninitialized
warnings or even all -Wall -W warnings; or perhaps with
-ftrivial-var-init=something) as well as using some timeout on the execution
because the execution could very well loop forever is minimum what needs to be
done.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #20)
> Well, cvise reduction of runtime testcases is always problematic, and trying
> to ensure
> the reduction doesn't introduce uninitialized var uses which weren't there
> before (perhaps with checking for new -Wmaybe-uninitialized -Wuninitialized
> warnings or even all -Wall -W warnings; or perhaps with
> -ftrivial-var-init=something) as well as using some timeout on the execution
> because the execution could very well loop forever is minimum what needs to
> be done.

Yes, one can mitigate that with -fsanitize=undefined,address, I used that time
to time for csmith test-cases.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

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

--- Comment #22 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jakub Jelinek from comment #20)
> trying to ensure the reduction doesn't introduce uninitialized var uses
> which weren't there before 

I was also thinking this myself, so I went back to the original
test case I reported, before any reduction. This is what I found:

$ for i in ~/gcc/results.202205*/bin/gcc; do echo $i; $i -w
-ftrivial-auto-var-init=zero -O2 -fno-strict-aliasing bug892.c && (./a.out 1 |
fgrep g_50); done
/home/dcb36/gcc/results.20220501/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220508/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220515/bin/gcc
...checksum after hashing g_50 : C21BF3F9
$ 

So the original bug is still there and my reduction looks invalid ;-|

Snapshots don't exist between 20220508 and 20220515. Is anyone else
able to bisect that range ?

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sayle at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-03-09
           Keywords|needs-bisection             |
            Summary|csmith: possible bad code   |csmith: possible bad code
                   |with -O2                    |with -O2
                   |-fno-strict-aliasing        |-fno-strict-aliasing since
                   |                            |r13-254-gdd3c7873a61019e9
     Ever confirmed|0                           |1

--- Comment #23 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-254-gdd3c7873a61019e9.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[dcb314 at hotmail dot com]

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

--- Comment #24 from David Binderman <dcb314 at hotmail dot com> ---
I tried experimenting with the flags that change -O1 into -O2 and got this:

$ for i in ~/gcc/results.202205*/bin/gcc; do echo $i; $i -w
-ftrivial-auto-var-init=zero -O1 -fno-strict-aliasing bug892.c && (./a.out 1 |
fgrep g_50); done
/home/dcb36/gcc/results.20220501/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220508/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220515/bin/gcc
...checksum after hashing g_50 : 646CF84D

$ for i in ~/gcc/results.202205*/bin/gcc; do echo $i; $i -w
-ftrivial-auto-var-init=zero -O1 -fcode-hoisting -fno-strict-aliasing bug892.c
&& (./a.out 1 | fgrep g_50); done
/home/dcb36/gcc/results.20220501/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220508/bin/gcc
...checksum after hashing g_50 : 646CF84D
/home/dcb36/gcc/results.20220515/bin/gcc
...checksum after hashing g_50 : C21BF3F9

so the -fcode-hoisting looks to be part of the problem.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-reduction             |

--- Comment #25 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, using the following reduction script:
https://github.com/marxin/gcc-util/blob/master/bisect/reduce-csmith.sh

I was able to get to:

$ cat pr109031.c
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;

uint32_t crc32_context, g_50;
char transparent_crc_vname;
uint8_t g_44;

void crc32_byte(uint8_t b) { crc32_context = b; }

int main() {
  g_50 = 0;
  uint32_t *l_1155 = &g_50;
  uint8_t *l_1162 = &g_44;
lbl_1206:
  (*l_1155)++, (*l_1162)--;
  if (g_44)
    goto lbl_1206;
  crc32_byte(g_50 >> 8);
  uint32_t r = crc32_context ^ 5UL;
  __builtin_printf("...checksum after hashing %u\n", r);
  if (r != 4)
    __builtin_abort();
  return 0;
}

$ gcc -O2 pr109031.c && ./a.out
...checksum after hashing 5
Aborted (core dumped)
$ gcc-12 -O2 pr109031.c && ./a.out
...checksum after hashing 4
$ gcc pr109031.c && ./a.out
...checksum after hashing 4

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Priority|P3                          |P1

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška <marxin at gcc dot gnu.org> ---
Simplified to:

unsigned char zero;

int main() {
  unsigned g = 0;
  unsigned *p1 = &g;
  unsigned char *p2 = &zero;

  do {
    (*p1)++;
    (*p2)--;
  } while (zero);

  __builtin_printf ("g=%u\n", g);
  if (g != 256)
    __builtin_abort();
  return 0;
}

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[marxin at gcc dot gnu.org]

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

--- Comment #27 from Martin Liška <marxin at gcc dot gnu.org> ---
Polished a bit more into:

unsigned char f = 0;

int main() {
  unsigned g = 0;

  unsigned *p1 = &g;
  unsigned char *p2 = &f;

  do {
    (*p1)++;
    (*p2)--;
  } while (f);

  __builtin_printf ("g=%u\n", g);
  if (g != 256)
    __builtin_abort();
  return 0;
}

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |roger at nextmovesoftware dot com
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com
           Keywords|                            |patch

--- Comment #28 from Roger Sayle <roger at nextmovesoftware dot com> ---
Doh!  My apologies for this breakage.  I'm currently testing the following fix:

diff --git a/gcc/tree-chrec.cc b/gcc/tree-chrec.cc
index f93d8dc..2f67581 100644
--- a/gcc/tree-chrec.cc
+++ b/gcc/tree-chrec.cc
@@ -623,7 +623,9 @@ chrec_apply (unsigned var,
          else if (operand_equal_p (CHREC_LEFT (chrec), chrecr)
                   && TREE_CODE (x) == PLUS_EXPR
                   && integer_all_onesp (TREE_OPERAND (x, 1))
-                  && !POINTER_TYPE_P (type))
+                  && !POINTER_TYPE_P (type)
+                  && TYPE_PRECISION (TREE_TYPE (x))
+                     >= TYPE_PRECISION (type))
            {
              /* We know the number of iterations can't be negative.
                 So {a, +, a} (x-1) -> "a*x".  */

The integer_all_onesp test is only equivalent to -1 when the TREE_TYPE (x)
is the same width or wider than type.  In this case, TREE_TYPE (x) is unsigned
char and x is "zero+255", so performed in the wrong type (zero+255+1) becomes
zero instead of zero+256.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Roger Sayle from comment #28)
> The integer_all_onesp test is only equivalent to -1 when the TREE_TYPE (x)
> is the same width or wider than type

... or the narrower type is signed.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:eb1d8df792f990574cbb695b55c92ee2684fc96b

commit r13-6621-geb1d8df792f990574cbb695b55c92ee2684fc96b
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sun Mar 12 22:52:41 2023 +0000

    PR middle-end/109031: Fix final value replacement from narrower IVs.

    This patch fixes a P1 regression, a problem with my February 2022 patch
    to improve folding for final value replacement:
    https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590618.html

    The motivation for the original patch is that because we know the number
    of loop iterations can't be negative, final value expressions such as
    (int) ((unsigned int) x + 4294967295) + 1 can be simplified to x,
    as this is effectively ((x - 1) + 1) without overflow.

    The bug/oversight is that using integer_all_onesp to check for the
    implicit tree constant -1 it didn't consider that the inner (unsigned)
    type might be narrower than hthe outer result type.  For the case in the
    PR, (int)((unsigned char)x + 255) + 1 gets simplified to (int)x, but
    when x is originally zero, the correct result should be 256.

    The fix is to check that the inner type's precision (the width of the
    subtraction) is at least as wide as the result type (that of the addition).

    I've also added a test for signed types, but without -fwrapv this
    invokes undefined behaviour, and with -fwrapv it doesn't exhibit the
    problem in the PR.

    2023-03-12  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR middle-end/109031
            * tree-chrec.cc (chrec_apply): When folding "{a, +, a} (x-1)",
            ensure that the type of x is as wide or wider than the type of a.

    gcc/testsuite/ChangeLog
            PR middle-end/109031
            * gcc.dg/tree-ssa/pr109031-1.c: New test case.
            * gcc.dg/tree-ssa/pr109031-2.c: Likewise.

[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #31 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed on mainline.  Thanks for all your help.