[Bug c/111904] New: Miscompilation with -O3 -fharden-control-flow-redundancy?

[Bug c/111904] New: Miscompilation with -O3 -fharden-control-flow-redundancy?

[sjames at gcc dot gnu.org]

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

            Bug ID: 111904
           Summary: Miscompilation with -O3
                    -fharden-control-flow-redundancy?
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
                CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56161&action=edit
memset_explicit-gone-wrong.tar.xz

Needs a trunk build from today or newer for -fharden-control-flow-redundancy.

1. git clone https://git.savannah.gnu.org/git/gnulib.git
2. ./gnulib-tool --single-configure --conditional-dependencies --create-testdir
--dir=uhoh memset_explicit
3. cd uhoh
4. ./configure CFLAGS="-O3 -fharden-control-flow-redundancy" # passes with -O2
5. make TESTS=test-memset_explicit check -j$(nproc)

```
$ ./test-memset_explicit
test_heap: address range is still mapped after free().
test_stack: count = 1000
test-memset_explicit.c:191: assertion 'count < 50' failed
Aborted (core dumped)
```

I'm not sure where it goes wrong yet. Attached
memset_explicit-gone-wrong.tar.xz has uhoh-O2 (good) and uhoh-O3 (bad) for
x86_64, but I reproduced this on arm64 too.

[Bug c/111904] Miscompilation with -O3 -fharden-control-flow-redundancy?

[sjames at gcc dot gnu.org]

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

--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
gllib/memset_explicit.o is apparently the same between the two directories

[Bug middle-end/111904] Miscompilation with -O3 -fharden-control-flow-redundancy?

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

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

--- Comment #2 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
AFAICT the test expects stackbuf to remain unchanged across do_secret_stuff
calls, even though it's free stack space, but calling the hardcfr checker may
scribble over it.  But the real kicker is that, at -O3, do_secret_stuff gets
two different versions for each of the pass numbers, and in the specialization
for odd passes the stackbuf is optimized away entirely, and the visited bitmap
ends up assigned at stack space that overlaps with the stackbuf allocated
during the previous even pass, and that's what gets memcmp to fail at every
execution.  Adding attributes noclone and noipa to do_secret_stuff avoids the
specializations, and then the test passes even at -O3.

[Bug middle-end/111904] Miscompilation with -O3 -fharden-control-flow-redundancy?

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruno at clisp dot org

--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
Thank you Alexandre!

[Bug middle-end/111904] Miscompilation with -O3 -fharden-control-flow-redundancy?

[bruno at clisp dot org]

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

--- Comment #4 from Bruno Haible <bruno at clisp dot org> ---
I've added your fix to gnulib:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=f8ce7e779de156cb6d0fa51dbaef49cd255b7171

Thank you, Alexandre!