From 554fd8c5195424bdbcabf5de30fdc183aba391bd Mon Sep 17 00:00:00 2001 From: upstream source tree Date: Sun, 15 Mar 2015 20:14:05 -0400 Subject: obtained gcc-4.6.4.tar.bz2 from upstream website; verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository. --- gcc/testsuite/g++.old-deja/g++.brendan/crash24.C | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 gcc/testsuite/g++.old-deja/g++.brendan/crash24.C (limited to 'gcc/testsuite/g++.old-deja/g++.brendan/crash24.C') diff --git a/gcc/testsuite/g++.old-deja/g++.brendan/crash24.C b/gcc/testsuite/g++.old-deja/g++.brendan/crash24.C new file mode 100644 index 000000000..42d0fabc2 --- /dev/null +++ b/gcc/testsuite/g++.old-deja/g++.brendan/crash24.C @@ -0,0 +1,19 @@ +// { dg-do assemble } +// { dg-options "-O" } +// GROUPS passed old-abort +// gcc puts the array into a register, and then the store_bit_field () code +// in expmed.c gets confused when it tries to store zero past the end of the +// register (because the index is past the array bounds). It ends up calling +// store_split_bit_field, which then aborts, because we don't have a split bit +// field. +// +// Seems easiest to detect this case in the front end, i.e. access outside the +// array bounds, and then force the array to be allocated on the stack instead +// of a register. + +main() +{ + char i[1]; + + i[1] = 0; +} -- cgit v1.2.3