[Bug c/106843] New: gcc with -O2 corrupt data on stack

[Bug c/106843] New: gcc with -O2 corrupt data on stack

[gcc at linuxmotors dot com]

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

            Bug ID: 106843
           Summary: gcc with -O2 corrupt data on stack
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at linuxmotors dot com
  Target Milestone: ---

Compile the following file named t.c with
gcc -O2 t.c -o t
Then run with ./t
it will print out
0 0 401060 0
or some other unexpected data. Without -O2 it prints out the correct
1 2 3 4
gcc 7.5.0 also handles this code fine with or without -O2

#include <stdio.h>
struct rect {
        int x,y,w,h;
};
void test(struct rect *r) {
        if(!r) r=&(struct rect){1,2,3,4};
        printf("%x %x %x %x\n", r->x, r->y, r->w, r->h);
}
int main(int argc, char **argv) {
        test(0);
}


I don't know if this is useful but an objdump of the code produced is this:
0000000000401140 <test>:
  401140:       48 8d 44 24 e8          lea    -0x18(%rsp),%rax
  401145:       48 85 ff                test   %rdi,%rdi
  401148:       48 0f 44 f8             cmove  %rax,%rdi
  40114c:       31 c0                   xor    %eax,%eax
  40114e:       8b 4f 08                mov    0x8(%rdi),%ecx
  401151:       8b 57 04                mov    0x4(%rdi),%edx
  401154:       44 8b 47 0c             mov    0xc(%rdi),%r8d
  401158:       8b 37                   mov    (%rdi),%esi
  40115a:       bf 04 20 40 00          mov    $0x402004,%edi
  40115f:       e9 cc fe ff ff          jmp    401030 <printf@plt>
  401164:       66 2e 0f 1f 84 00 00    cs nopw 0x0(%rax,%rax,1)
  40116b:       00 00 00 
  40116e:       66 90                   xchg   %ax,%ax

It looks like the structure is being referenced on the stack but the optimizer
removed the initialization or something.

It's a linux box.
/proc/cpuinfo starts with this:
processor       : 6
vendor_id       : GenuineIntel
cpu family      : 6
model           : 94
model name      : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
stepping        : 3

/etc/os-release is this:
NAME=Slackware
VERSION="15.0"
ID=slackware
VERSION_ID=15.0
PRETTY_NAME="Slackware 15.0 x86_64"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:slackware:slackware_linux:15.0"
HOME_URL="http://slackware.com/"
SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
VERSION_CODENAME=stable

[Bug c/106843] gcc with -O2 corrupt data on stack

[gcc at linuxmotors dot com]

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

--- Comment #1 from Dave A <gcc at linuxmotors dot com> ---
gcc -dumpmachine
x86_64-slackware-linux

gcc -v
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/11.2.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/11.2.0/lto-wrapper
Target: x86_64-slackware-linux
Configured with: ../configure --prefix=/usr --libdir=/usr/lib64
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,brig,c,c++,d,fortran,go,lto,objc,obj-c++
--enable-threads=posix --enable-checking=release --enable-objc-gc
--with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new
--disable-libstdcxx-pch --disable-libunwind-exceptions --enable-__cxa_atexit
--disable-libssp --enable-gnu-unique-object --enable-plugin --enable-lto
--disable-install-libiberty --disable-werror --with-gnu-ld --with-isl --verbose
--with-arch-directory=amd64 --disable-gtktest --enable-clocale=gnu
--disable-multilib --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)

[Bug c/106843] gcc with -O2 corrupt data on stack

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The temporary that stores the Designated initializer goes out of scope at the
end of the statement that is inside the if statement.

[Bug c/106843] gcc with -O2 corrupt data on stack

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I mean compound literal not Designated initializers.

[Bug c/106843] gcc with -O2 corrupt data on stack

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
6.8.4 Selection statements

3 A selection statement is a block whose scope is a strict subset of the scope
of its enclosing block. Each associated substatement is also a block whose
scope is a strict subset of the scope of the selection statement.

[Bug c/106843] gcc with -O2 corrupt data on stack

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
6.5.2.5 Compound literals

5 The value of the compound literal is that of an unnamed object initialized by
the initializer list. If the compound literal occurs outside the body of a
function, the object has static storage duration; otherwise, it has automatic
storage duration associated with the enclosing block.

[Bug c/106843] gcc with -O2 corrupt data on stack

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-fsanitize=address would have told you you used the address after it went out
of scope.

[Bug c/106843] gcc with -O2 corrupt data on stack

[gcc at linuxmotors dot com]

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

--- Comment #7 from Dave A <gcc at linuxmotors dot com> ---
-fsanitize=address balked on the executable even without the -O2, even though
it printed out the correct values. The stack must have been initialzed and the
values persisted after the variable went out of scope.

In retrospect I'm surprised this ever worked. I have a vague memory of copying
this "trick" from libSDL source. Thanks for investigating.