From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 84B5C385843F; Fri, 8 Oct 2021 13:38:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 84B5C385843F From: "davidhaufegcc at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/102649] New: GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed Date: Fri, 08 Oct 2021 13:38:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 9.3.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: davidhaufegcc at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 13:38:03 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102649 Bug ID: 102649 Summary: GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: davidhaufegcc at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hello, We witnessed incorrect application behavior in a large binary built using L= TO. Doing an assembly instruction stepping of the binary, the issue was identif= ied. We have a function with 21 parameters. The function is called from many call-sites. In the instance that is not working properly, the C++ function caller passes a hard-coded integer '0' to a variable which is passed on the stack (ie not register passed). GCC ends up generating two versions of the called function under LTO. A version of the function that takes this integer parameter, and one that optimizes out the need for this integer to be passe= d at all, as it is a hardcoded 0.=20 The issue is that the caller is still pushing an integer 0 function paramet= er onto the stack. The callee does not expect the caller to have done this and then is incorrectly popping stack function arguments that have been offset = by this extra stack arg.=20 This issue was complicated to track down because some time later in our codebase, unrelated classes/files in the same static library as the caller = were touched. The bug has since stopped. Rolling back GIT we can reproduce the b= ug over about 10 checkins of unrelated code, and then unrelated code causes the bug to stop. GCC generates the proper variable passing stack for the optimi= zed function.=20 Compile flag investigation: All builds were done with -O3 -flto -fno-fat-lto-objects -ffast-math -funroll-loops Disabling LTO -- bug does not present itself With LTO on, we decomposed -ffast-math into its individual flags. If we lea= ve all -ffast-math flags on but disable -freciprocal-math, the bug does not present itself. The code in question doesn't have any division anywhere aro= und it. We speculate that disabling -freciprocal-math or the codebase generally changing fixed the bug because it simply changes the global state of the compile. This made us very nervous as there was no way to anticipate this b= ug going forward.=20 We are using the devtoolset-9 (GCC 9.3.1) centos7/rh7 package. Moving to the devtoolset-10 (GCC 10.2.1) package "fixes" the issue with the same code and build flags. devtoolset-8 (GCC 8.3.1) does not present the bug either. Our concern is that the bug is not actually fixed though, and that moving versions of GCC is like changing our codebase by 10 unrelated check-ins or disabling -freciprocal-math. It is simply changing the state of the compile. The bug may or may not be fixed. I would like to help in any way I can. This build generates a binary that is 200MB w/o debug symbols. It is a lot of code. I do not think we can create a smaller test case showing this behavior. I thought about doing a bisect of = the GCC repo, but even that might just be changing the state of GCC and not actually showing the bug is fixed.=20 It is a concerning bug. I can try to provide any further information that w= ould be useful.=20 Thanks, Dave Haufe $ ./gcc -v Using built-in specs. COLLECT_GCC=3D./gcc COLLECT_LTO_WRAPPER=3D/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redh= at-linux/9/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=3Dc,c++,fortran,lto --prefix=3D/opt/rh/devtoolset-9/root= /usr --mandir=3D/opt/rh/devtoolset-9/root/usr/share/man --infodir=3D/opt/rh/devtoolset-9/root/usr/share/info --with-bugurl=3Dhttp://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=3Dposix --enable-checking=3Drelease --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=3Dgnu --with-default-libstdcxx-abi=3Dgcc4-compatible --enable-plugin --enable-initfini-array --with-isl=3D/builddir/build/BUILD/gcc-9.3.1-20200408/obj-x86_64-redhat-lin= ux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=3Dgeneric --with-arch_32=3Dx86-64 --build=3Dx86_64-redhat-linux Thread model: posix gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) $ cat /etc/*release* CentOS Linux release 7.9.2009 (Core) Derived from Red Hat Enterprise Linux 7.9 (Source) cat: /etc/lsb-release.d: Is a directory NAME=3D"CentOS Linux" VERSION=3D"7 (Core)" ID=3D"centos" ID_LIKE=3D"rhel fedora" VERSION_ID=3D"7" PRETTY_NAME=3D"CentOS Linux 7 (Core)" ANSI_COLOR=3D"0;31" CPE_NAME=3D"cpe:/o:centos:centos:7" HOME_URL=3D"https://www.centos.org/" BUG_REPORT_URL=3D"https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT=3D"CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION=3D"7" REDHAT_SUPPORT_PRODUCT=3D"centos" REDHAT_SUPPORT_PRODUCT_VERSION=3D"7" CentOS Linux release 7.9.2009 (Core) CentOS Linux release 7.9.2009 (Core) cpe:/o:centos:centos:7 Example of .cpp file compile with args g++ -m64 -std=3Dc++17 -Wsuggest-override -Wduplicated-cond -Wduplicated-branches -Wcast-qual -Wmissing-include-dirs -Wall -Werror -Wextra -fno-strict-aliasing -ggdb -frecord-gcc-switches -I. -I...... -O3 -flto -fno-fat-lto-objects -ffast-math -funroll-loops -c ServiceThread.cpp = -o release/gcc/ServiceThread.o Example of final link g++ -Werror -Wl,--fatal-warnings release/gcc/main.o ...many *.a libs ...=20= =20=20 -lcap -lnuma -lpthread -lrt -ldl -lutil -lstdc++ -lstdc++fs -lm -lcrypto -lz -flto=3D4 -O3 -ffast-math -funroll-loops -o ./release/gcc/app=