diff options
| author | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
|---|---|---|
| committer | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
| commit | 554fd8c5195424bdbcabf5de30fdc183aba391bd (patch) | |
| tree | 976dc5ab7fddf506dadce60ae936f43f58787092 /gcc/testsuite/g++.old-deja/g++.mike/net4.C | |
| download | cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.bz2 cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.xz | |
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.
Diffstat (limited to 'gcc/testsuite/g++.old-deja/g++.mike/net4.C')
| -rw-r--r-- | gcc/testsuite/g++.old-deja/g++.mike/net4.C | 32 |
1 files changed, 32 insertions, 0 deletions
diff --git a/gcc/testsuite/g++.old-deja/g++.mike/net4.C b/gcc/testsuite/g++.old-deja/g++.mike/net4.C new file mode 100644 index 000000000..cc6712f0a --- /dev/null +++ b/gcc/testsuite/g++.old-deja/g++.mike/net4.C @@ -0,0 +1,32 @@ +// { dg-do assemble } +// Message-Id: <m0lLuUK-0000fRC@nix.appli.se> +// Date: Wed, 4 Mar 92 12:50 MET +// From: niklas@appli.se (Niklas Hallqvist) +// To: eichin@cygnus.com, tiemann@cygnus.com +// Cc: gcc2@cygnus.com +// Subject: nested type handling +// +// The last couple of days I've been struggling with nested types in the +// C++ compiler. Frankly, it's a mess! Was it impossible to put the stuff +// into the parser instead of the lexer? Well, anyway, to get the following +// code to compile: +// +// struct O { +// struct M { +// struct I +// {}; +// }; +// }; +// O::M::I s; +// +// a patch enclosed below is needed. I'm not sure if it causes any +// unanticipated side-effects, but it seem to work well for me. + + +struct O { + struct M { + struct I + {}; + }; +}; +O::M::I s; |