obtained gcc-4.6.4.tar.bz2 from upstream website;upstream

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.

1 files changed, 19 insertions, 0 deletions

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;
+}