[Bug 1572613] Re: GCC stack access scheduled after stack deallocation
Bug Watch Updater
1572613 at bugs.launchpad.net
Thu Jul 2 13:48:30 UTC 2026
Launchpad has imported 7 comments from the remote bug at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers.
------------------------------------------------------------------------
On 2016-04-15T03:35:07+00:00 Krebbel wrote:
Created attachment 38276
Fix proposal
t.c:
void foo (void) { volatile int a = 5; (void) a; }
cc1 -O2 -fno-omit-frame-pointer -march=z10 -mtune=z196 t.c
The assignment to a is moved by the scheduler *after* the stack pointer
restore. While not being a problem in this example in other
circumstances this might cause data corruption if e.g. a signal handler
gets triggered in between.
foo:
ldgr %f2,%r11
ldgr %f0,%r15
lay %r15,-168(%r15)
lgr %r11,%r15
lgdr %r15,%f0 <----- stack pointer restore
mvhi 164(%r11),5 <----- stack write for variable a
l %r1,164(%r11)
lgdr %r11,%f2
br %r14
The variable access is done through the framepointer which does not
conflict with the restore of r15.
The problem was latent in the backend but was so far hidden by doing the
restore of r11 and r15 in the same instruction - a load multiple.
However, there always was the potential problem of doing the stack
access with a temporary register assigned by the compiler.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1572613/comments/0
------------------------------------------------------------------------
On 2016-04-15T07:16:59+00:00 Rguenth wrote:
please fill in known-to-work/fail fields. If it's present in 4.9 it can't be P1
(but it is P2). If it's only latent on branches and exposed on trunk then it
can be P1.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1572613/comments/1
------------------------------------------------------------------------
On 2016-04-20T07:10:04+00:00 Krebbel wrote:
Author: krebbel
Date: Wed Apr 20 07:09:32 2016
New Revision: 235233
URL: https://gcc.gnu.org/viewcvs?rev=235233&root=gcc&view=rev
Log:
PR70674: S/390: Add memory barrier to stack pointer restore from fpr.
This patches fixes a problem with stack variable accesses being
scheduled after the stack pointer restore instructions. In the
testcase this happened with the stack variable 'a' accessed through the
frame pointer.
The existing stack_tie we have in the backend is basically useless
when trying to block stack variable accesses from being scheduled
across an insn. The alias set of stack variables and the frame alias
set usually differ and hence aren't in conflict with each other. The
solution appears to be a magic MEM term with a scratch register which
is handled as a full memory barrier when analyzing scheduling
dependencies.
With the patch a (clobber (mem:BLK (scratch))) is being added to the
restore instruction in order to prevent any memory operations to be
scheduled across the insn. The patch does that only for the one case
where the stack pointer is restored from an FPR. Theoretically this
might happen also in the case where the stack pointer gets restored
using a load multiple. However, triggering that problem with
load-multiple appears to be much harder since the load-multiple will
restore the frame pointer as well. So in order to see the problem a
different call-clobbered register would need to be used as temporary
stack pointer.
Another case which needs to be handled some day is the stack pointer
allocation part. It needs to be a memory barrier as well.
Bootstrapped and regression tested with --with-arch z196 and z13 on
s390 and s390x.
gcc/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
Backport from mainline
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* config/s390/s390.c (s390_restore_gprs_from_fprs): Pick the new
stack_restore_from_fpr pattern when restoring r15.
(s390_optimize_prologue): Strip away the memory barrier in the
parallel when trying to get rid of restore insns.
* config/s390/s390.md ("stack_restore_from_fpr"): New insn
definition for loading the stack pointer from an FPR. Compared to
the normal move insn this pattern includes a full memory barrier.
gcc/testsuite/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
Backport from mainline
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* gcc.target/s390/pr70674.c: New test.
Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/s390/pr70674.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/s390/s390.c
branches/gcc-5-branch/gcc/config/s390/s390.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1572613/comments/2
------------------------------------------------------------------------
On 2016-04-20T07:13:55+00:00 Krebbel wrote:
Author: krebbel
Date: Wed Apr 20 07:13:23 2016
New Revision: 235234
URL: https://gcc.gnu.org/viewcvs?rev=235234&root=gcc&view=rev
Log:
PR70674: S/390: Add memory barrier to stack pointer restore from fpr.
This patches fixes a problem with stack variable accesses being
scheduled after the stack pointer restore instructions. In the
testcase this happened with the stack variable 'a' accessed through the
frame pointer.
The existing stack_tie we have in the backend is basically useless
when trying to block stack variable accesses from being scheduled
across an insn. The alias set of stack variables and the frame alias
set usually differ and hence aren't in conflict with each other. The
solution appears to be a magic MEM term with a scratch register which
is handled as a full memory barrier when analyzing scheduling
dependencies.
With the patch a (clobber (mem:BLK (scratch))) is being added to the
restore instruction in order to prevent any memory operations to be
scheduled across the insn. The patch does that only for the one case
where the stack pointer is restored from an FPR. Theoretically this
might happen also in the case where the stack pointer gets restored
using a load multiple. However, triggering that problem with
load-multiple appears to be much harder since the load-multiple will
restore the frame pointer as well. So in order to see the problem a
different call-clobbered register would need to be used as temporary
stack pointer.
Another case which needs to be handled some day is the stack pointer
allocation part. It needs to be a memory barrier as well.
Bootstrapped and regression tested with --with-arch z196 and z13 on
s390 and s390x.
-Andreas-
gcc/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* config/s390/s390.c (s390_restore_gprs_from_fprs): Pick the new
stack_restore_from_fpr pattern when restoring r15.
(s390_optimize_prologue): Strip away the memory barrier in the
parallel when trying to get rid of restore insns.
* config/s390/s390.md ("stack_restore_from_fpr"): New insn
definition for loading the stack pointer from an FPR. Compared to
the normal move insn this pattern includes a full memory barrier.
gcc/testsuite/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* gcc.target/s390/pr70674.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/s390/pr70674.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1572613/comments/3
------------------------------------------------------------------------
On 2016-04-20T07:16:36+00:00 Krebbel wrote:
Author: krebbel
Date: Wed Apr 20 07:16:03 2016
New Revision: 235235
URL: https://gcc.gnu.org/viewcvs?rev=235235&root=gcc&view=rev
Log:
PR70674: S/390: Add memory barrier to stack pointer restore from fpr.
This patches fixes a problem with stack variable accesses being
scheduled after the stack pointer restore instructions. In the
testcase this happened with the stack variable 'a' accessed through the
frame pointer.
The existing stack_tie we have in the backend is basically useless
when trying to block stack variable accesses from being scheduled
across an insn. The alias set of stack variables and the frame alias
set usually differ and hence aren't in conflict with each other. The
solution appears to be a magic MEM term with a scratch register which
is handled as a full memory barrier when analyzing scheduling
dependencies.
With the patch a (clobber (mem:BLK (scratch))) is being added to the
restore instruction in order to prevent any memory operations to be
scheduled across the insn. The patch does that only for the one case
where the stack pointer is restored from an FPR. Theoretically this
might happen also in the case where the stack pointer gets restored
using a load multiple. However, triggering that problem with
load-multiple appears to be much harder since the load-multiple will
restore the frame pointer as well. So in order to see the problem a
different call-clobbered register would need to be used as temporary
stack pointer.
Another case which needs to be handled some day is the stack pointer
allocation part. It needs to be a memory barrier as well.
Bootstrapped and regression tested with --with-arch z196 and z13 on
s390 and s390x.
gcc/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
Backport from mainline
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* config/s390/s390.c (s390_restore_gprs_from_fprs): Pick the new
stack_restore_from_fpr pattern when restoring r15.
(s390_optimize_prologue): Strip away the memory barrier in the
parallel when trying to get rid of restore insns.
* config/s390/s390.md ("stack_restore_from_fpr"): New insn
definition for loading the stack pointer from an FPR. Compared to
the normal move insn this pattern includes a full memory barrier.
gcc/testsuite/ChangeLog:
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
Backport from mainline
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* gcc.target/s390/pr70674.c: New test.
Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/s390/pr70674.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/s390/s390.c
branches/gcc-6-branch/gcc/config/s390/s390.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1572613/comments/4
------------------------------------------------------------------------
On 2016-04-21T11:50:53+00:00 Krebbel wrote:
Author: krebbel
Date: Thu Apr 21 11:50:22 2016
New Revision: 235334
URL: https://gcc.gnu.org/viewcvs?rev=235334&root=gcc&view=rev
Log:
PR70674: S/390: Add memory barrier to stack pointer restore
from fpr.
This patches fixes a problem with stack variable accesses being
scheduled after the stack pointer restore instructions. In the
testcase this happened with the stack variable 'a' accessed through the
frame pointer.
The existing stack_tie we have in the backend is basically useless
when trying to block stack variable accesses from being scheduled
across an insn. The alias set of stack variables and the frame alias
set usually differ and hence aren't in conflict with each other. The
solution appears to be a magic MEM term with a scratch register which
is handled as a full memory barrier when analyzing scheduling
dependencies.
With the patch a (clobber (mem:BLK (scratch))) is being added to the
restore instruction in order to prevent any memory operations to be
scheduled across the insn. The patch does that only for the one case
where the stack pointer is restored from an FPR. Theoretically this
might happen also in the case where the stack pointer gets restored
using a load multiple. However, triggering that problem with
load-multiple appears to be much harder since the load-multiple will
restore the frame pointer as well. So in order to see the problem a
different call-clobbered register would need to be used as temporary
stack pointer.
Another case which needs to be handled some day is the stack pointer
allocation part. It needs to be a memory barrier as well.
gcc/ChangeLog:
2016-04-21 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
Backport from mainline
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* config/s390/s390.c (s390_restore_gprs_from_fprs): Pick the new
stack_restore_from_fpr pattern when restoring r15.
(s390_optimize_prologue): Strip away the memory barrier in the
parallel when trying to get rid of restore insns.
* config/s390/s390.md ("stack_restore_from_fpr"): New insn
definition for loading the stack pointer from an FPR. Compared to
the normal move insn this pattern includes a full memory barrier.
gcc/testsuite/ChangeLog:
2016-04-21 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
Backport from mainline
2016-04-20 Andreas Krebbel <krebbel at linux.vnet.ibm.com>
PR target/70674
* gcc.target/s390/pr70674.c: New test.
Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/s390/pr70674.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/s390/s390.c
branches/gcc-4_9-branch/gcc/config/s390/s390.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1572613/comments/15
------------------------------------------------------------------------
On 2016-04-21T11:51:57+00:00 Krebbel wrote:
Fixed with the committed patch.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1572613/comments/16
** Changed in: gcc
Status: Unknown => Fix Released
** Changed in: gcc
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to ceph in Ubuntu.
https://bugs.launchpad.net/bugs/1572613
Title:
GCC stack access scheduled after stack deallocation
Status in gcc:
Fix Released
Status in Ubuntu on IBM z Systems:
Fix Released
Status in ceph package in Ubuntu:
Fix Released
Status in fpgatools package in Ubuntu:
Fix Released
Status in gambas3 package in Ubuntu:
Fix Released
Status in gcc-4.9 package in Ubuntu:
Fix Released
Status in gcc-5 package in Ubuntu:
Fix Released
Status in gcc-5-cross package in Ubuntu:
Fix Released
Status in gcc-arm-none-eabi package in Ubuntu:
Fix Released
Status in gcc-avr package in Ubuntu:
Fix Released
Status in gcc-mingw-w64 package in Ubuntu:
Fix Released
Status in higan package in Ubuntu:
Fix Released
Status in insighttoolkit4 package in Ubuntu:
Fix Released
Status in ivtools package in Ubuntu:
Fix Released
Status in juju-mongodb3.2 package in Ubuntu:
Fix Released
Status in libtsm package in Ubuntu:
Fix Released
Status in mariadb-10.0 package in Ubuntu:
Fix Released
Status in mysql-5.7 package in Ubuntu:
Fix Released
Status in nodejs package in Ubuntu:
Fix Released
Status in percona-server-5.6 package in Ubuntu:
Fix Released
Status in percona-xtrabackup package in Ubuntu:
Fix Released
Status in percona-xtradb-cluster-5.6 package in Ubuntu:
Fix Released
Status in valgrind package in Ubuntu:
Fix Released
Status in webkitgtk package in Ubuntu:
Fix Released
Status in ceph source package in Xenial:
Fix Released
Status in fpgatools source package in Xenial:
Fix Released
Status in gambas3 source package in Xenial:
Fix Released
Status in gcc-5 source package in Xenial:
Fix Released
Status in higan source package in Xenial:
Invalid
Status in insighttoolkit4 source package in Xenial:
Fix Released
Status in ivtools source package in Xenial:
Invalid
Status in juju-mongodb3.2 source package in Xenial:
Fix Released
Status in libtsm source package in Xenial:
Fix Released
Status in mariadb-10.0 source package in Xenial:
Fix Released
Status in mysql-5.7 source package in Xenial:
Fix Released
Status in nodejs source package in Xenial:
Fix Released
Status in percona-server-5.6 source package in Xenial:
Fix Released
Status in percona-xtrabackup source package in Xenial:
Fix Released
Status in percona-xtradb-cluster-5.6 source package in Xenial:
Fix Released
Status in valgrind source package in Xenial:
Fix Released
Status in webkitgtk source package in Xenial:
Fix Released
Status in ceph source package in Yakkety:
Fix Released
Status in fpgatools source package in Yakkety:
Fix Released
Status in gambas3 source package in Yakkety:
Fix Released
Status in gcc-5 source package in Yakkety:
Fix Released
Status in higan source package in Yakkety:
Fix Released
Status in insighttoolkit4 source package in Yakkety:
Fix Released
Status in ivtools source package in Yakkety:
Fix Released
Status in juju-mongodb3.2 source package in Yakkety:
Fix Released
Status in libtsm source package in Yakkety:
Fix Released
Status in mariadb-10.0 source package in Yakkety:
Fix Released
Status in mysql-5.7 source package in Yakkety:
Fix Released
Status in nodejs source package in Yakkety:
Fix Released
Status in percona-server-5.6 source package in Yakkety:
Fix Released
Status in percona-xtrabackup source package in Yakkety:
Fix Released
Status in percona-xtradb-cluster-5.6 source package in Yakkety:
Fix Released
Status in valgrind source package in Yakkety:
Fix Released
Status in webkitgtk source package in Yakkety:
Fix Released
Bug description:
= Validation =
For gcc-5, check that code generation is correct as per small C test case below.
== fpgatools ==
* compile autotest.c and strip chrpath
* change path in autotest_diff.sh from ./ to /usr/bin
* execute autotest and check error codes
== gambas3 ==
* execute gambas.test
== inisghttoolkit4 ==
$ apt install insighttoolkit4-python insighttoolkit4-examples
Run attached insightoolkit4.py script against an image file, e.g.
Circle.png from -examples package.
== libtsm ==
Nothing in the archive uses this... No idea why we have this package,
either release the update, or remove it from proposed.
== mariadb-10.0 ==
Run mariadb.sh
== percona-server-5.6 ==
Run percona.sh
== percona-xtrabackup ==
Execute $ xtrabackup --backup; xtracbackup --prepare; xtrabackup
--backup in a new directory
== percona-xtradb-cluster-5.6 ==
Deploy three node percona-cluster charm, upgrade to proposed, check
that updating tables on one node is reflected on the others.
== webkitgtk ==
Open start.ubuntu.com in midori
== Comment: #0 - Andreas Krebbel - 2016-04-19 05:22:12 ==
The following miscompilation was found in the Valgrind memcheck
preload library.
This compiler behavior can be reproduced with a small test case:
$ echo 'void foo (void) { volatile int a = 5; (void) a; }' | \
gcc -O2 -fno-omit-frame-pointer -o foo.o -c -x c - && objdump -d foo.o
foo.o: file format elf64-s390
Disassembly of section .text:
0000000000000000 <foo>:
0: b3 c1 00 2b ldgr %f2,%r11
4: b3 c1 00 0f ldgr %f0,%r15
8: e3 f0 ff 58 ff 71 lay %r15,-168(%r15)
e: b9 04 00 bf lgr %r11,%r15
12: b3 cd 00 f0 lgdr %r15,%f0
16: e5 4c b0 a4 00 05 mvhi 164(%r11),5 <---- stack variable access after stack pointer restore
1c: 58 10 b0 a4 l %r1,164(%r11) <----
20: b3 cd 00 b2 lgdr %r11,%f2
24: 07 fe br %r14
26: 07 07 nopr %r7
A patch for upstream GCC has been posted on the mailing list. Backports will go into 4.9/5/6 branches after the upstream patch is applied.
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00910.html
This patch needs to be included in the Ubuntu 16.04 GCC 5 packages.
We have scanned the entire xenial universe repo for suspicious
sequences. Unfortunately several packages need to be rebuild after
including the patch. We recommend rebuilding at least the following
packages:
ceph-test_10.1.1-0ubuntu1_s390x.deb
g++-mingw-w64-i686_5.3.1-8ubuntu3+17_s390x.deb
g++-mingw-w64-x86-64_5.3.1-8ubuntu3+17_s390x.deb
gambas3-gb-qt4_3.8.4-2ubuntu3_s390x.deb
gcc-arm-none-eabi_4.9.3+svn231177-1_s390x.deb
gcc-avr_4.9.2+Atmel3.5.0-1_s390x.deb
gcc-mingw-w64-i686_5.3.1-8ubuntu3+17_s390x.deb
gcc-mingw-w64-x86-64_5.3.1-8ubuntu3+17_s390x.deb
gcc-snapshot_20160320-1ubuntu1_s390x.deb
gfortran-mingw-w64-i686_5.3.1-8ubuntu3+17_s390x.deb
gfortran-mingw-w64-x86-64_5.3.1-8ubuntu3+17_s390x.deb
gnat-mingw-w64-i686_5.3.1-3ubuntu1+16_s390x.deb
gnat-mingw-w64-x86-64_5.3.1-3ubuntu1+16_s390x.deb
gobjc++-mingw-w64-i686_5.3.1-8ubuntu3+17_s390x.deb
gobjc++-mingw-w64-x86-64_5.3.1-8ubuntu3+17_s390x.deb
gobjc-mingw-w64-i686_5.3.1-8ubuntu3+17_s390x.deb
gobjc-mingw-w64-x86-64_5.3.1-8ubuntu3+17_s390x.deb
higan_094-6_s390x.deb
juju-mongodb3.2_3.2.4-0ubuntu1_s390x.deb
libfpga0_0.0+201212-1_s390x.deb
libgnatvsn5_5.3.1-14ubuntu2_s390x.deb
libgnatvsn5-s390x-cross_5.3.1-14ubuntu2cross1_all.deb
libinsighttoolkit4.9_4.9.0-4ubuntu1_s390x.deb
libiv-unidraw1_1.2.11a1-6_s390x.deb
libjavascriptcoregtk-1.0-0_2.4.10-0ubuntu1_s390x.deb
libjavascriptcoregtk-3.0-0_2.4.10-0ubuntu1_s390x.deb
libmariadbd18_10.0.24-7_s390x.deb
libtsm3_3-1_s390x.deb
libwebkit2gtk-3.0-25_2.4.10-0ubuntu1_s390x.deb
mariadb-client-core-10.0_10.0.24-7_s390x.deb
mariadb-plugin-oqgraph_10.0.24-7_s390x.deb
mariadb-plugin-spider_10.0.24-7_s390x.deb
mariadb-server-10.0_10.0.24-7_s390x.deb
mariadb-server-core-10.0_10.0.24-7_s390x.deb
mariadb-test_10.0.24-7_s390x.deb
mysql-client-5.6_5.6.28-1ubuntu3_s390x.deb
mysql-client-core-5.6_5.6.28-1ubuntu3_s390x.deb
mysql-server-5.6_5.6.28-1ubuntu3_s390x.deb
mysql-server-core-5.6_5.6.28-1ubuntu3_s390x.deb
mysql-testsuite-5.7_5.7.11-0ubuntu6_s390x.deb
nodejs_4.2.6~dfsg-1ubuntu4_s390x.deb
percona-server-server-5.6_5.6.22-rel71.0-0ubuntu2_s390x.deb
percona-xtrabackup_2.2.3-2.1build1_s390x.deb
percona-xtradb-cluster-server-5.6_5.6.21-25.8-0ubuntu2_s390x.deb
== Comment: #2 - Andreas Krebbel - 2016-04-20 03:22:27 ==
Patch is upstream committed to head, gcc-6, and gcc-5 branches.
To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/1572613/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list