Re: Three old entries from PROBLEMS

[Paolo Bonzini]

On 11/02/2009 08:49 AM, Joern Rennecke wrote:


This would only be valid if the comparison is in an equality context
(or for special input operand ranges).
So (unless the target is CC0) you'd either have to use dataflow analysis
to look at all the contexts the comparison result is used in, or you'd need
a target hook to classify CCmode modes to check if they are used only
for equality comparisons and can have their inputs altered.


Yes, that's why I suggested doing it on the tree level instead.


This is not implemented but IMHO obsolete, most of the targets will
just use an AND to implement zero extension.


If the target can actually write to partial registers and refer to the
entire register without undue delay, you won't need and zero_extend or
AND operation at all.  So this is obsolete only to the extent that such
targets have become fewer / more arcane.


Yes, that's what I meant.  The implementation effort is much less justified.

Paolo

RE: plugin hooks

[Joern Rennecke]

Quoting Grigori Fursin :
Also, I hope that we will start collaborating with Joern Rennecke in  
 a few weeks to update the ICI

and GSOC'09

developments based on the recent feedback to see if we can move it   
to the mainline ...


We still need a branch name for that.  Since GCC is currently in phase 3,
I suppose we should plan on re-baselining at least once - re-baselining
from 4.6 experimental mainline after 4.5 is branched - so instead of
a gcc version number a branch date seems more suitable.

I.e. if the branch were to be created today, I propose to use the name
branches/ici-20091102-branch for the branch.

Re: i370 port - constructing compile script

[Paul Edwards]

I've been having fantastic success building gcc.  I have got it
to iterate through the entire build (as far as I can tell) now.


Then finally I ran into an internal compiler error which I haven't seen
before.  One of the gcc options must have triggered something off.
Perhaps it was -Wwrite-strings, or maybe the -O2 (I normally use
-Os for a completely unrelated reason).  Either way, I need to find
out how to switch off those flags.  I'll also try to fix the compiler
internal error in i370.md.


This problem was due to the build being done with 64-bit
long long enabled - something i370.md can't cope with.

I forced it off with these two things:

configure:
 main ()
 {
! long long int i;
   ;
   return 0;
 }
--- 3196,3202 
 int
 main ()
 {
! zlong long int i;


hwint.h:
 #if !defined HAVE_LONG_LONG
! # if GCC_VERSION >= 3000 && !PUREISO && defined(WANT64)
 #  define HAVE_LONG_LONG 1
 #  define SIZEOF_LONG_LONG 8


Now at the end of the build, I can save the output, and do a
grep "^i370-mvspdp-gcc" to get all the source files that need to be
compiled.  I could attempt to use the .o files (that are really .s)
directly, but that's not something I really need.

The auto-host.h looks fine, plus I have the generated files.

I still need to clean up the scripts further (the below is a work in
progress), and I need to write the programs that will generate the
compile JCL and then try it out!

Part of the cleanup will hopefully get around the multiple make failures ...

+ make
+ cp gcc/config/i370/dummy_config.h gcc/config.h
+ make
+ cp gcc/config/i370/i370-mvspdp-gcc2 ../mvscross/bin/i370-mvspdp-gcc
+ make

:-)

BFN.  Paul.


Index: gccnew/gcc/configure
diff -c gccnew/gcc/configure:1.1.1.1 gccnew/gcc/configure:1.12
*** gccnew/gcc/configure:1.1.1.1 Thu Jul  9 10:25:05 2009
--- gccnew/gcc/configure Fri Oct 30 12:34:44 2009
***
*** 2463,2470 
--- 2463,2472 
 /* end confdefs.h.  */
 #include 
 #include 
+ #if !defined(__MVS__)
 #include 
 #include 
+ #endif
 /* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
 struct buf { int x; };
 FILE * (*rcsopen) (struct buf *, struct stat *, int);
***
*** 3194,3200 
 int
 main ()
 {
! long long int i;
   ;
   return 0;
 }
--- 3196,3202 
 int
 main ()
 {
! zlong long int i;
   ;
   return 0;
 }
***
*** 3377,3383 
--- 3379,3387 
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
 #include "confdefs.h"
+ #if !defined(__MVS__)
 #include 
+ #endif


 int
***
*** 3448,3454 
--- 3452,3460 
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
 #include "confdefs.h"
+ #if !defined(__MVS__)
 #include 
+ #endif


 int
***
*** 3519,3525 
--- 3525,3533 
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
 #include "confdefs.h"
+ #if !defined(__MVS__)
 #include 
+ #endif


 int
***
*** 3590,3596 
--- 3598,3606 
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
 #include "confdefs.h"
+ #if !defined(__MVS__)
 #include 
+ #endif


 int
***
*** 3662,3668 
--- 3672,3680 
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
 #include "confdefs.h"
+ #if !defined(__MVS__)
 #include 
+ #endif


 int
***
*** 3735,3741 
--- 3747,3755 
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
 #include "confdefs.h"
+ #if !defined(__MVS__)
 #include 
+ #endif


 int
***
*** 5656,5662 
--- 5670,5678 
 if test $ac_cv_header_time = yes; then

 cat >>confdefs.h <<\_ACEOF
+ #if !defined(__MVS__)
 #define TIME_WITH_SYS_TIME 1
+ #endif
 _ACEOF

 fi
***
*** 6150,6157 
--- 6166,6180 
 cat confdefs.h >>conftest.$ac_ext
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
+ #if !defined(__MVS__)
 #include 
 #include 
+ #endif
+ #if defined(__MVS__)
+ #define BIG_ENDIAN 1
+ #define LITTLE_ENDIAN 2
+ #define BYTE_ORDER 1
+ #endif
 int
 main ()
 {
***
*** 6192,6199 
--- 6215,6229 
 cat confdefs.h >>conftest.$ac_ext
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
+ #if !defined(__MVS__)
 #include 
 #include 
+ #endif
+ #if defined(__MVS__)
+ #define BIG_ENDIAN 1
+ #define LITTLE_ENDIAN 2
+ #define BYTE_ORDER 1
+ #endif
 int
 main ()
 {
***
*** 6731,6738 
--- 6761,6770 
 cat confdefs.h >>conftest.$ac_ext
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
+ #if !defined(__MVS__)
 #include 
 #include 
+ #endif
 int
 main ()
 {
***
*** 6851,6857 
--- 6883,6891 
 #endif
 /* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
 char $ac_func ();
+ #endif
 /* The GNU C library defines this for functions which it implements
 to always fail with ENOSYS.  Some functions are actually named
 something starting with __ and the normal name is an alias.  */
***
*** 7051,7057 
--- 7085,7093

RE: RFC PRE-ing REFERENCE expressions

[Rahul Kharche]

Hi Richard,

We would like to hang on to 4.4 for a little while. I was hoping I could
grab only the alias analysis improvements from the trunk. Do you suspect
this would be troublesome?

Cheers,
Rahul

-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com] 
Sent: 30 October 2009 14:50
To: Rahul Kharche
Cc: rgue...@gcc.gnu.org; gcc@gcc.gnu.org; sdkteam-gnu
Subject: Re: RFC PRE-ing REFERENCE expressions

On Fri, Oct 30, 2009 at 3:22 PM, Rahul Kharche  wrote:
> Hi Richi,
>
> Following up your suggestion on PR41488, I am continuing to test with
> loop header copy before FRE in GCC 4.4.1. One regression I am trying
> to tackle is from the test case below.
>
> typedef struct {
>  int degree;
>  int c[(256)];
> } swbcht_Polynomial;
>
>
> typedef struct {
>  int m;
>  int n;
>  const swbcht_Polynomial *primPoly;
>  unsigned short alpha[(1 << (13))];
> } swbcht_GF;
>
>
> typedef struct {
>  swbcht_GF gf;
> } swbcht_Handle;
>
>
> static const swbcht_Polynomial _primPoly13;
>
> void _ComputeGFLookupTables (swbcht_Handle *bchH, int m)
> {
>  int i, j;
>
>  swbcht_GF *gf = &bchH->gf;
>
>  gf->m = m;
>  gf->n = (1 << m) - 1;
>
>  gf->primPoly = &_primPoly13;
>
>  for (i = 0; i < gf->m; i++) {
>    gf->alpha[gf->m] ^= (gf->primPoly->c[i] * gf->alpha[i]);
>  }
> }
>
>
> The dump after CH - FRE looks like
>
> _ComputeGFLookupTables (struct swbcht_Handle * bchH, int m)
> {
>  int i;
>  short unsigned int D.1241;
>  short int D.1240;
>  short int D.1239;
>  short unsigned int D.1238;
>  short unsigned int D.1237;
>  short unsigned int D.1236;
>  const int D.1235;
>  const struct swbcht_Polynomial * D.1233;
>  short int D.1232;
>  short unsigned int D.1231;
>  int D.1230;
>  int D.1229;
>  int D.1228;
>
> :
>  bchH_2(D)->gf.m = m_4(D);
>  D.1228_5 = 1 << m_4(D);
>  D.1229_6 = D.1228_5 + -1;
>  bchH_2(D)->gf.n = D.1229_6;
>  bchH_2(D)->gf.primPoly = &_primPoly13;
>  if (m_4(D) > 0)
>    goto ;
>  else
>    goto ;
>
> :
>  goto ;
>
> :
>
> :
>  # i_35 = PHI <0(5), i_23(7)>
>  D.1230_10 = bchH_2(D)->gf.m;
>  D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
>  D.1232_12 = (short int) D.1231_11;
>  D.1233_13 = bchH_2(D)->gf.primPoly;
>  D.1235_15 = D.1233_13->c[i_35];
>  D.1236_16 = (short unsigned int) D.1235_15;
>  D.1237_18 = bchH_2(D)->gf.alpha[i_35];
>  D.1238_19 = D.1236_16 * D.1237_18;
>  D.1239_20 = (short int) D.1238_19;
>  D.1240_21 = D.1239_20 ^ D.1232_12;
>  D.1241_22 = (short unsigned int) D.1240_21;
>  bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
>  i_23 = i_35 + 1;
>  D.1230_8 = bchH_2(D)->gf.m;
>  if (i_23 < D.1230_8)
>    goto ;
>  else
>    goto ;
>
> :
>  goto ;
>
> :
>
> :
>  return;
>
> }
>
> 1. Why does FRE miss eliminating expression bchH_2(D)->gf.primPoly in
> bb 3 with &_primPoly13. This is normally the case if we ran FRE then
> CH.
>
> Further PRE identifies bchH_2(D)->gf.primPoly as a partially redundant
> expression and hoists it into predecessor bb 7 and we get
>
> :
>  # i_35 = PHI <0(5), i_23(7)>
>  # prephitmp.25_49 = PHI 
>  # prephitmp.27_51 = PHI <&_primPoly13(5), pretmp.26_50(7)>
>  D.1230_10 = prephitmp.25_49;
>  D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
>  D.1232_12 = (short int) D.1231_11;
>  D.1233_13 = prephitmp.27_51;
>  D.1235_15 = D.1233_13->c[i_35];
>  D.1236_16 = (short unsigned int) D.1235_15;
>  D.1237_18 = bchH_2(D)->gf.alpha[i_35];
>  D.1238_19 = D.1236_16 * D.1237_18;
>  D.1239_20 = (short int) D.1238_19;
>  D.1240_21 = D.1239_20 ^ D.1232_12;
>  D.1241_22 = (short unsigned int) D.1240_21;
>  bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
>  i_23 = i_35 + 1;
>  D.1230_8 = bchH_2(D)->gf.m;
>  if (D.1230_8 > i_23)
>    goto ;
>  else
>    goto ;
>
> :
>  pretmp.26_50 = bchH_2(D)->gf.primPoly;
>  goto ;
>
>
> Clearly prephitmp.27_51 will make a redundant induction variable.
> Stepping through the insert_into_preds_of_block in tree-ssa-pre.c
> I can see the value numbers for expression bchH_2(D)->gf.primPoly
> available through bb 3 and through bb 2 are different.
>
> 2. Is this because alias analysis cannot determine bchH_2(D)->gf
> has a unique target?

You should move to GCC 4.5 - the alias-oracle in GCC 4.4 is too weak
to discover all this and virtual operands are not helpful because these
are all indirect accesses through pointers without points-to information.

Richard.

>
> Many Thanks,
> Rahul
>
>

RE: RFC PRE-ing REFERENCE expressions

[Richard Guenther]

On Mon, 2 Nov 2009, Rahul Kharche wrote:

> Hi Richard,
> 
> We would like to hang on to 4.4 for a little while. I was hoping I could
> grab only the alias analysis improvements from the trunk. Do you suspect
> this would be troublesome?

Uh, definitely - it's not easy to grab them in isolation.

Richard.

> Cheers,
> Rahul
> 
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com] 
> Sent: 30 October 2009 14:50
> To: Rahul Kharche
> Cc: rgue...@gcc.gnu.org; gcc@gcc.gnu.org; sdkteam-gnu
> Subject: Re: RFC PRE-ing REFERENCE expressions
> 
> On Fri, Oct 30, 2009 at 3:22 PM, Rahul Kharche  wrote:
> > Hi Richi,
> >
> > Following up your suggestion on PR41488, I am continuing to test with
> > loop header copy before FRE in GCC 4.4.1. One regression I am trying
> > to tackle is from the test case below.
> >
> > typedef struct {
> >  int degree;
> >  int c[(256)];
> > } swbcht_Polynomial;
> >
> >
> > typedef struct {
> >  int m;
> >  int n;
> >  const swbcht_Polynomial *primPoly;
> >  unsigned short alpha[(1 << (13))];
> > } swbcht_GF;
> >
> >
> > typedef struct {
> >  swbcht_GF gf;
> > } swbcht_Handle;
> >
> >
> > static const swbcht_Polynomial _primPoly13;
> >
> > void _ComputeGFLookupTables (swbcht_Handle *bchH, int m)
> > {
> >  int i, j;
> >
> >  swbcht_GF *gf = &bchH->gf;
> >
> >  gf->m = m;
> >  gf->n = (1 << m) - 1;
> >
> >  gf->primPoly = &_primPoly13;
> >
> >  for (i = 0; i < gf->m; i++) {
> >    gf->alpha[gf->m] ^= (gf->primPoly->c[i] * gf->alpha[i]);
> >  }
> > }
> >
> >
> > The dump after CH - FRE looks like
> >
> > _ComputeGFLookupTables (struct swbcht_Handle * bchH, int m)
> > {
> >  int i;
> >  short unsigned int D.1241;
> >  short int D.1240;
> >  short int D.1239;
> >  short unsigned int D.1238;
> >  short unsigned int D.1237;
> >  short unsigned int D.1236;
> >  const int D.1235;
> >  const struct swbcht_Polynomial * D.1233;
> >  short int D.1232;
> >  short unsigned int D.1231;
> >  int D.1230;
> >  int D.1229;
> >  int D.1228;
> >
> > :
> >  bchH_2(D)->gf.m = m_4(D);
> >  D.1228_5 = 1 << m_4(D);
> >  D.1229_6 = D.1228_5 + -1;
> >  bchH_2(D)->gf.n = D.1229_6;
> >  bchH_2(D)->gf.primPoly = &_primPoly13;
> >  if (m_4(D) > 0)
> >    goto ;
> >  else
> >    goto ;
> >
> > :
> >  goto ;
> >
> > :
> >
> > :
> >  # i_35 = PHI <0(5), i_23(7)>
> >  D.1230_10 = bchH_2(D)->gf.m;
> >  D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
> >  D.1232_12 = (short int) D.1231_11;
> >  D.1233_13 = bchH_2(D)->gf.primPoly;
> >  D.1235_15 = D.1233_13->c[i_35];
> >  D.1236_16 = (short unsigned int) D.1235_15;
> >  D.1237_18 = bchH_2(D)->gf.alpha[i_35];
> >  D.1238_19 = D.1236_16 * D.1237_18;
> >  D.1239_20 = (short int) D.1238_19;
> >  D.1240_21 = D.1239_20 ^ D.1232_12;
> >  D.1241_22 = (short unsigned int) D.1240_21;
> >  bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
> >  i_23 = i_35 + 1;
> >  D.1230_8 = bchH_2(D)->gf.m;
> >  if (i_23 < D.1230_8)
> >    goto ;
> >  else
> >    goto ;
> >
> > :
> >  goto ;
> >
> > :
> >
> > :
> >  return;
> >
> > }
> >
> > 1. Why does FRE miss eliminating expression bchH_2(D)->gf.primPoly in
> > bb 3 with &_primPoly13. This is normally the case if we ran FRE then
> > CH.
> >
> > Further PRE identifies bchH_2(D)->gf.primPoly as a partially redundant
> > expression and hoists it into predecessor bb 7 and we get
> >
> > :
> >  # i_35 = PHI <0(5), i_23(7)>
> >  # prephitmp.25_49 = PHI 
> >  # prephitmp.27_51 = PHI <&_primPoly13(5), pretmp.26_50(7)>
> >  D.1230_10 = prephitmp.25_49;
> >  D.1231_11 = bchH_2(D)->gf.alpha[D.1230_10];
> >  D.1232_12 = (short int) D.1231_11;
> >  D.1233_13 = prephitmp.27_51;
> >  D.1235_15 = D.1233_13->c[i_35];
> >  D.1236_16 = (short unsigned int) D.1235_15;
> >  D.1237_18 = bchH_2(D)->gf.alpha[i_35];
> >  D.1238_19 = D.1236_16 * D.1237_18;
> >  D.1239_20 = (short int) D.1238_19;
> >  D.1240_21 = D.1239_20 ^ D.1232_12;
> >  D.1241_22 = (short unsigned int) D.1240_21;
> >  bchH_2(D)->gf.alpha[D.1230_10] = D.1241_22;
> >  i_23 = i_35 + 1;
> >  D.1230_8 = bchH_2(D)->gf.m;
> >  if (D.1230_8 > i_23)
> >    goto ;
> >  else
> >    goto ;
> >
> > :
> >  pretmp.26_50 = bchH_2(D)->gf.primPoly;
> >  goto ;
> >
> >
> > Clearly prephitmp.27_51 will make a redundant induction variable.
> > Stepping through the insert_into_preds_of_block in tree-ssa-pre.c
> > I can see the value numbers for expression bchH_2(D)->gf.primPoly
> > available through bb 3 and through bb 2 are different.
> >
> > 2. Is this because alias analysis cannot determine bchH_2(D)->gf
> > has a unique target?
> 
> You should move to GCC 4.5 - the alias-oracle in GCC 4.4 is too weak
> to discover all this and virtual operands are not helpful because these
> are all indirect accesses through pointers without points-to information.
> 
> Richard.
> 
> >
> > Many Thanks,
> > Rahul
> >
> >
> 
> 

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: Three old entries from PROBLEMS

[Richard Henderson]

On 11/01/2009 04:03 PM, Paolo Bonzini wrote:



An andl
#1 after a seq is 1 to 1, but how should compiler know that?


I don't understand the last sentence.


I think it's talking about something like

int f(int x, int y)
{
  int r;
  r = x == y;
  r &= 1;
  return r;
}

cmpl%esi, %edi
sete%al
andl$1, %eax

Not the most ideal way to zero-extend the return value, from a partial 
register stall point of view.  Note that with char values, we do 
eliminate the AND operation, so this is not (any longer) about some pass 
not understanding STORE_FLAG_VALUE.



r~

Re: Three old entries from PROBLEMS

[Richard Henderson]

On 11/02/2009 09:37 AM, Richard Henderson wrote:

Note that with char values, we do
eliminate the AND operation, so this is not (any longer) about some pass
not understanding STORE_FLAG_VALUE.


... or maybe it is.  We probably should have eliminated the AND at the 
gimple level.



r~

RE; BAD WEATHER IS COMING... How will you reach your people?

[info]

If you can not view this email CLICK HERE

.

 1. Unlimited call.blast

- Record a single message and reach a few or thousands of people in
minutes! 

 2. Flash Website

- Your website will resemble a TV commercial rather than a billboard.
Look at ours!

 3. Streaming TV Station-

 Effectively become your own TV station. Your content live and on
demand.

 4. Streaming Radio Station

- Full functioning 24/7 Radio Station. Why stay local? Go global!

 5. WebPaper

-Flip thru pages of a newspaper, book or magazine online like you
have it in your hands!

 

 Built and Powered by
http://callblastcom.com/maillist/lt.php?id=ZkQFUwoEAB5RSAYAAAs%3D



--
If you do not want to receive any more newsletters, 
http://callblastcom.com/maillist/lt.php?id=ZkQFUwoEDx5RSAYAAAs%3D

To update your preferences and to unsubscribe visit
http://callblastcom.com/maillist/lt.php?id=ZkQFUwoEDh5RSAYAAAs%3D
Forward a Message to Someone
http://callblastcom.com/maillist/lt.php?id=ZkQFUwoLBx5RSAYAAAs%3D



--
Powered by PHPlist, www.phplist.com --

incorrect place for LTO options description

[Denis Onischenko]

description of the LTO specific options (--enable-lto, --with-libelf
and --enable gold) should be placed in "Options specification" section
instead of "Java-Specific Options" section on
http://gcc.gnu.org/install/configure.html

RE: plugin hooks

[Grigori Fursin]

Hi Joern,

I think, that's very reasonable.

Just as we agreed, wait a few days until you are covered by the INRIA agreement
to transfer copyright to FSF ... I should be able to tell you more within a few
days ...

Also, I added Yuanjie, Liang (they did GSOC developments) and Yuri in CC since
they will help with testing and extending the ICI and GSOC developments...

Cheers,
Grigori

> -Original Message-
> From: Joern Rennecke [mailto:amyl...@spamcop.net]
> Sent: Monday, November 02, 2009 1:50 PM
> To: Grigori Fursin
> Cc: 'Zbigniew Chamski'; 'Richard Guenther'; 'Basile STARYNKEVITCH'; 'Ian 
> Lance Taylor'; 'GCC
> Mailing List'; 'Albert Cohen'; ctuning-discussi...@googlegroups.com; Yuri 
> Kashnikoff
> Subject: RE: plugin hooks
> 
> Quoting Grigori Fursin :
> > Also, I hope that we will start collaborating with Joern Rennecke in
> >  a few weeks to update the ICI
> > and GSOC'09
> >
> > developments based on the recent feedback to see if we can move it
> > to the mainline ...
> 
> We still need a branch name for that.  Since GCC is currently in phase 3,
> I suppose we should plan on re-baselining at least once - re-baselining
> from 4.6 experimental mainline after 4.5 is branched - so instead of
> a gcc version number a branch date seems more suitable.
> 
> I.e. if the branch were to be created today, I propose to use the name
> branches/ici-20091102-branch for the branch.

RE; BAD WEATHER IS COMING... How will you reach your people?

[info]

If you can not view this email CLICK HERE

.

 1. Unlimited call.blast

- Record a single message and reach a few or thousands of people in
minutes! 

 2. Flash Website

- Your website will resemble a TV commercial rather than a billboard.
Look at ours!

 3. Streaming TV Station-

 Effectively become your own TV station. Your content live and on
demand.

 4. Streaming Radio Station

- Full functioning 24/7 Radio Station. Why stay local? Go global!

 5. WebPaper

-Flip thru pages of a newspaper, book or magazine online like you
have it in your hands!

 

 Built and Powered by
http://callblastcom.com/maillist/lt.php?id=ZkQFUwoKAB5RSAYAAA0%3D



--
If you do not want to receive any more newsletters, 
http://callblastcom.com/maillist/lt.php?id=ZkQFUwoKDx5RSAYAAA0%3D

To update your preferences and to unsubscribe visit
http://callblastcom.com/maillist/lt.php?id=ZkQFUwoKDh5RSAYAAA0%3D
Forward a Message to Someone
http://callblastcom.com/maillist/lt.php?id=ZkQFUwsDBx5RSAYAAA0%3D



--
Powered by PHPlist, www.phplist.com --

Process for proposing new C/C++ language extensions.

[johnchristian]

Can someone explain to me what the process is for adding extensions to the GNU 
implementation of the C/C++ preprocessor?

cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Justin Mattock]

Hello,
I'm not sure how to handle this,
while compiling firefox-3.6b1.source
I get this with the default compiling options,
as well as custom:


[  532.942324] cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
[  532.942330] Pid: 16002, comm: cc1plus Tainted: P
2.6.32-rc5-00083-g04ea458 #2
[  532.942333] Call Trace:
[  532.942342]  [] T.417+0x7c/0x245
[  532.942347]  [] __out_of_memory+0x142/0x159
[  532.942352]  [] out_of_memory+0x6e/0x9d
[  532.942357]  [] __alloc_pages_nodemask+0x47e/0x5cc
[  532.942363]  [] handle_mm_fault+0x25d/0x68e
[  532.942369]  [] do_page_fault+0x2bb/0x2d3
[  532.942373]  [] page_fault+0x25/0x30
[  532.942376] Mem-Info:
[  532.942378] DMA per-cpu:
[  532.942380] CPU0: hi:0, btch:   1 usd:   0
[  532.942383] CPU1: hi:0, btch:   1 usd:   0
[  532.942385] DMA32 per-cpu:
[  532.942388] CPU0: hi:  186, btch:  31 usd:  94
[  532.942391] CPU1: hi:  186, btch:  31 usd:  23
[  532.942393] Normal per-cpu:
[  532.942395] CPU0: hi:  186, btch:  31 usd: 150
[  532.942398] CPU1: hi:  186, btch:  31 usd: 155
[  532.942404] active_anon:707575 inactive_anon:264673 isolated_anon:0
[  532.942406]  active_file:58 inactive_file:33 isolated_file:0
[  532.942407]  unevictable:0 dirty:0 writeback:0 unstable:0 buffer:71
[  532.942408]  free:6998 slab_reclaimable:2697 slab_unreclaimable:16267
[  532.942409]  mapped:136 shmem:64 pagetables:2761 bounce:0
[  532.942418] DMA free:15944kB min:28kB low:32kB high:40kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15360kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? yes
[  532.942425] lowmem_reserve[]: 0 2976 3986 3986
[  532.942436] DMA32 free:10020kB min:6020kB low:7524kB high:9028kB
active_anon:2360492kB inactive_anon:590196kB active_file:84kB
inactive_file:68kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:3047792kB mlocked:0kB dirty:0kB
writeback:0kB mapped:136kB shmem:80kB slab_reclaimable:0kB
slab_unreclaimable:88kB kernel_stack:0kB pagetables:6100kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:448
all_unreclaimable? yes
[  532.942443] lowmem_reserve[]: 0 0 1010 1010
[  532.942454] Normal free:2028kB min:2040kB low:2548kB high:3060kB
active_anon:469808kB inactive_anon:468496kB active_file:148kB
inactive_file:64kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:1034240kB mlocked:0kB dirty:0kB
writeback:0kB mapped:408kB shmem:176kB slab_reclaimable:10788kB
slab_unreclaimable:64972kB kernel_stack:800kB pagetables:4944kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:413
all_unreclaimable? yes
[  532.942461] lowmem_reserve[]: 0 0 0 0
[  532.942465] DMA: 2*4kB 2*8kB 3*16kB 2*32kB 3*64kB 2*128kB 2*256kB
1*512kB 2*1024kB 2*2048kB 2*4096kB = 15944kB
[  532.942478] DMA32: 7*4kB 7*8kB 5*16kB 4*32kB 2*64kB 1*128kB 1*256kB
4*512kB 3*1024kB 0*2048kB 1*4096kB = 10020kB
[  532.942490] Normal: 507*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2028kB
[  532.942501] 7974 total pagecache pages
[  532.942503] 7778 pages in swap cache
[  532.942506] Swap cache stats: add 112290, delete 104512, find 3595/4051
[  532.942508] Free swap  = 0kB
[  532.942510] Total swap = 431632kB
[  532.957941] 1048576 pages RAM
[  532.957943] 40518 pages reserved
[  532.957945] 312 pages shared
[  532.957947] 1000176 pages non-shared
[  532.957951] Out of memory: kill process 16001 (c++) score 543727 or a child
[  532.957955] Killed process 16002 (cc1plus)

I just compiled the latest gcc snapshot a few days
ago.


-- 
Justin P. Mattock

Re: Process for proposing new C/C++ language extensions.

[Basile STARYNKEVITCH]

johnchrist...@smtp.brenneise.com wrote:

Can someone explain to me what the process is for adding extensions to the GNU 
implementation of the C/C++ preprocessor?


I am guessing that you really mean to extend the C++ language, perhaps 
thru additional preprocessor constructs.


I am not sure to understand the details of the question.

Honestly, I would guess that few people care about extending C or C++. 
It seems even that the GCC community has become quite conservative w.r.t 
new language extensions.


I would imagine that the only way to convince people is to make a 
tentative implementation. So perhaps the standard answer would be to 
create your own branch of GCC. Maybe the coming soon (ie in gcc 4.5) 
plugin machinery should help (but I am not sure it is supporting plugin 
extension of the preprocessor yet).


So perhaps you might push - this takes time & effort - the necessary 
hooks for plugin extensions of libcpp [the preprocessor part of GCC] and 
illustrate them by your own plugin which would provide your extensions.


And very probably, discussing language extensions should not be done on 
any @gcc.gnu.org mailing list (but somewhere else). Once you have a 
specification, implementing it is another issue.


Maybe you should first try to make a detailed specification [not here, 
but on your own site] and discuss it elsewhere of the extensions you are 
dreaming of, and start asking here how to implement it.


Very probably, few people care inside the GCC community about language 
extensions (unless they are already discussed in formal language 
standard committees).


I personnally would be delighted if someone (perhaps you) made the 
effort to push into GCC the plugin hooks for preprocessing, and perhaps 
this sub-goal  could help your own goal of new preprocessor based 
language extensions.
But discussing language extensions [which have no specification yet] is 
probably outside the scope of any @gcc.gnu.org list.


Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Jiri Slaby]

On 11/02/2009 10:29 PM, Justin Mattock wrote:
> [  532.942324] cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, 
> oom_adj=0
> [  532.942330] Pid: 16002, comm: cc1plus Tainted: P
> 2.6.32-rc5-00083-g04ea458 #2
> [  532.942333] Call Trace:
> [  532.942342]  [] T.417+0x7c/0x245
> [  532.942347]  [] __out_of_memory+0x142/0x159
> [  532.942352]  [] out_of_memory+0x6e/0x9d
> [  532.942357]  [] __alloc_pages_nodemask+0x47e/0x5cc
> [  532.942363]  [] handle_mm_fault+0x25d/0x68e
> [  532.942369]  [] do_page_fault+0x2bb/0x2d3
> [  532.942373]  [] page_fault+0x25/0x30
...
> [  532.957951] Out of memory: kill process 16001 (c++) score 543727 or a child
> [  532.957955] Killed process 16002 (cc1plus)
> 
> I just compiled the latest gcc snapshot a few days
> ago.

How many jobs did you run in parallel? Was there anything else memory
consuming running on that machine? Do you run the same jobs count every
time you compile such big c++ projects?

Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Justin Mattock]

On Mon, Nov 2, 2009 at 1:49 PM, Jiri Slaby  wrote:
> On 11/02/2009 10:29 PM, Justin Mattock wrote:
>> [  532.942324] cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, 
>> oom_adj=0
>> [  532.942330] Pid: 16002, comm: cc1plus Tainted: P
>> 2.6.32-rc5-00083-g04ea458 #2
>> [  532.942333] Call Trace:
>> [  532.942342]  [] T.417+0x7c/0x245
>> [  532.942347]  [] __out_of_memory+0x142/0x159
>> [  532.942352]  [] out_of_memory+0x6e/0x9d
>> [  532.942357]  [] __alloc_pages_nodemask+0x47e/0x5cc
>> [  532.942363]  [] handle_mm_fault+0x25d/0x68e
>> [  532.942369]  [] do_page_fault+0x2bb/0x2d3
>> [  532.942373]  [] page_fault+0x25/0x30
> ...
>> [  532.957951] Out of memory: kill process 16001 (c++) score 543727 or a 
>> child
>> [  532.957955] Killed process 16002 (cc1plus)
>>
>> I just compiled the latest gcc snapshot a few days
>> ago.
>
> How many jobs did you run in parallel? Was there anything else memory
> consuming running on that machine? Do you run the same jobs count every
> time you compile such big c++ projects?
>

This would be the only job running.

as for other types of jobs under ps aux there's only
udev,dbus,acpid,sshd,wicd running.

Now with this oom-killer I'm
hitting this on an imac9,1 with
gcc (GCC) 4.5.0 20091029 (experimental)
2.6.32-rc5-00083-g04ea458

On my other machine macbook pro ati chipset
(same system pure64)firefox seems to be going a lot farther
than on the imac(doing this in the past I think this takes a good
45min to compile).

the macbook has:
gcc (GCC) Cross-LFS 4.4.1.20090722) 4.4.1
2.6.32-rc4-00039-ga3f6f2e



-- 
Justin P. Mattock

Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Jiri Slaby]

On 11/02/2009 11:02 PM, Justin Mattock wrote:
> Now with this oom-killer I'm
> hitting this on an imac9,1 with
> gcc (GCC) 4.5.0 20091029 (experimental)

So there is probably a leak in the gcc chain. Does this happen with a
stable gcc version?

PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[H.J. Lu]

Hi,

This patch adds --enable-gold=both --with-linker=[bfd|gold] so that we
can build both ld and gold. This patch will

1. Install ld as ld.bfd
2. Install gold as ld.gold
3. Install one of them as ld, selected by --with-linker.

If needed, gcc install invoke gold as ld.gold and ld as ld.bfd.  Any
comments?

Thanks.


H.J.
--
2009-11-03  Roland McGrath  

* configure.ac (--enable-gold): Accept --enable-gold=both to
add gold to configdirs without removing ld.
* configure: Regenerated.

gold/

2009-11-03  H.J. Lu  

* Makefile.am (install-exec-local): Install as ld.gold.  Install
as ld if "@linker@" == "ld.gold".
* Makefile.in: Regenerated.

* configure.ac (linker): New substituted variable.  Set by
--enable-gold and --with-linker.
* configure: Regenerated.

ld/

2009-11-03  H.J. Lu  

* Makefile.am (transform): Install as ld.bfd
(install-exec-local): Depend on install-binPROGRAMS.  Install
as ld.gold.  Install as ld if "@linker@" == "ld.bfd".
* Makefile.in: Regenerated.

* configure.ac (linker): New substituted variable.  Set by
--enable-gold and --with-linker.
* configure: Regenerated.

diff --git a/configure b/configure
index 1ece75c..7e7076a 100755
--- a/configure
+++ b/configure
@@ -3076,7 +3076,8 @@ else
   ENABLE_GOLD=no
 fi
 
-if test "${ENABLE_GOLD}" = "yes"; then
+case "${ENABLE_GOLD}" in
+yes|both)
   # Check for ELF target.
   is_elf=no
   case "${target}" in
@@ -3096,11 +3097,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
 # Check for target supported by gold.
 case "${target}" in
   i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
-configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+if test "${ENABLE_GOLD}" = both; then
+  configdirs="$configdirs gold"
+   else
+  configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+   fi
 ;;
 esac
   fi
-fi
+  ENABLE_GOLD=yes
+  ;;
+esac
 
 # Configure extra directories which are host specific
 
diff --git a/configure.ac b/configure.ac
index 407ab59..b07ad23 100644
--- a/configure.ac
+++ b/configure.ac
@@ -314,7 +314,8 @@ AC_ARG_ENABLE(gold,
 [  --enable-gold   use gold instead of ld],
 ENABLE_GOLD=$enableval,
 ENABLE_GOLD=no)
-if test "${ENABLE_GOLD}" = "yes"; then
+case "${ENABLE_GOLD}" in 
+yes|both)
   # Check for ELF target.
   is_elf=no
   case "${target}" in
@@ -334,11 +335,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
 # Check for target supported by gold.
 case "${target}" in
   i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
-configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+if test "${ENABLE_GOLD}" = both; then
+  configdirs="$configdirs gold"
+   else
+  configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+   fi
 ;;
 esac
   fi
-fi
+  ENABLE_GOLD=yes
+  ;;
+esac
 
 # Configure extra directories which are host specific
 
diff --git a/gold/Makefile.am b/gold/Makefile.am
index 8d8b617..1747a92 100644
--- a/gold/Makefile.am
+++ b/gold/Makefile.am
@@ -163,12 +163,18 @@ check: libgold.a
 
 install-exec-local: ld-new$(EXEEXT)
$(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(tooldir)/bin
-   n=`echo ld | sed '$(transform)'`; \
+   n=`echo ld.gold | sed '$(transform)'`; \
$(INSTALL_PROGRAM) ld-new$(EXEEXT) $(DESTDIR)$(bindir)/$${n}$(EXEEXT); \
-   if test "$(bindir)" != "$(tooldir)/bin"; then \
- rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
- ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
$(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
+   if test "@linker@" = "ld.gold"; then \
+ ld=`echo ld | sed '$(transform)'`; \
+ rm -f $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
+ ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
$(DESTDIR)$(bindir)/$${ld}$(EXEEXT) >/dev/null 2>/dev/null \
+ || $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
$(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
+ if test "$(bindir)" != "$(tooldir)/bin"; then \
+   rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
+   ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
$(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
|| $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
$(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
+ fi; \
fi
 
 # We want install to imply install-info as per GNU standards, despite
diff --git a/gold/Makefile.in b/gold/Makefile.in
index d4c689b..fce401c 100644
--- a/gold/Makefile.in
+++ b/gold/Makefile.in
@@ -305,6 +305,7 @@ infodir = @infodir@
 install_sh = @install_sh@
 libdir = @libdir@
 libexecdir = @libexecdir@
+linker = @linker@
 localedir = @localedir@
 localstatedir = @localstatedir@
 mandir = @mandir@
@@ -1200,12 +1201,18 @@ check: libgold.a
 
 install-exec-local: ld-new$(EXEEXT)
$(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(tooldir)/bin
-   n=`

Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Justin P. Mattock]

Jiri Slaby wrote:

On 11/02/2009 11:02 PM, Justin Mattock wrote:
   

Now with this oom-killer I'm
hitting this on an imac9,1 with
gcc (GCC) 4.5.0 20091029 (experimental)
 


So there is probably a leak in the gcc chain. Does this happen with a
stable gcc version?

   
well right now I'(on the macbook), seems to be going for a good ten 
minutes before

I hit an error with a header file(nss)

I'll see if I can get this thing to compile all the way through.
(knock on wood) then go from there.

Justin P. Mattock

Re: undefined reference to `gt_pch_nx_tree_code'

[Aravinda]

Hi,

Thanks a lot for your time and replies.. It worked. Im sorry it was a
silly mistake that I dint notice.

Aravinda

On Sun, Nov 1, 2009 at 5:45 PM, Laurynas Biveinis
 wrote:
>> static GTY(( is_param(union tree_code) )) htab_t boud_ins = NULL;
>
> Ah, now it's clear. You probably wanted "union tree_node" with n, not c, here.
>
> --
> Laurynas
>

Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0

[Justin P. Mattock]

Jiri Slaby wrote:

On 11/02/2009 11:02 PM, Justin Mattock wrote:
   

Now with this oom-killer I'm
hitting this on an imac9,1 with
gcc (GCC) 4.5.0 20091029 (experimental)
 


So there is probably a leak in the gcc chain. Does this happen with a
stable gcc version?

   

o.k. I think it's something with the latest gcc(snapshot)
right now she's been compiling firefox for 45min
(then crapped out because I compiled nss without sqlite)
without no omm-killer.

Justin P. Mattock

[c++]pt.c:most_specialized_class appears to substitute outer args for inner params

[Larry Evans]

The following code around trunk/gcc/cp/pt.c:15514:

15513   partial_spec_args = INNERMOST_TEMPLATE_ARGS (partial_spec_args);
15514   partial_spec_args = tsubst_template_args
15515 (partial_spec_args, outer_args, tf_none, NULL_TREE);

as shown here:

http://gcc.gnu.org/viewcvs/trunk/gcc/cp/pt.c?view=markup&pathrev=153822

appears to substitute outer_args in the place where inner parameters
are located.  Am I reading the code wrong?  I ask because gdb seems to
show this happening with the following code:

--{-- test code --
  struct
outer_arg0
;
  struct
inner_arg0
;
  struct
inner_arg1
;

//#define CLASS_SCOPE_SPECIALIZATION
  template
  < class OuterArg0
  >
  struct
outer_tmpl
{
  template
  < typename InnerArg0
  , typename InnerArg1
  >
  struct
inner_tmpl
  #ifndef CLASS_SCOPE_SPECIALIZATION
;
  #else
{};
  template
  < typename InnerArg0
  >
  struct
inner_tmpl
  < InnerArg0
  , inner_arg1
  >
{
typedef
  InnerArg0
inner_typdef
;
};
  #endif
};

#ifndef CLASS_SCOPE_SPECIALIZATION
  template
  < //class OuterArg0
  >
  template
  < typename InnerArg0
  >
  struct
outer_tmpl
  < outer_arg0
  >::
inner_tmpl
  < InnerArg0
  , inner_arg1
  >
{
typedef
  InnerArg0
inner_typdef
;
};
#endif

typedef
  outer_tmpl
  ::inner_tmpl
  < inner_arg0
  , inner_arg1
  >
  ::inner_typdef //error here.
outer_inner_type
;
--}-- test code --

To be more specific, the following is part of a gdb session:

--{-- gdb session --

Breakpoint 5, tsubst_template_args (t=0x7f89a3765d80, 
args=0x7f89a3788750, complain=0, in_decl=0x0) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/pt.c:8136

[@@]tsubst_template_args:.TREE_VEC_LENGTH(t)[@@]
[***]len=
$6 = 2
[***]inp t=
 >

elt 1 >>
[***]inp args=
 >>
[***]bt:
#0  tsubst_template_args (t=0x7f89a3765d80, args=0x7f89a3788750, 
complain=0, in_decl=0x0) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/pt.c:8136
#1  0x00586ed4 in most_specialized_class (type=0x7f89a3789e40, 
tmpl=0x7f89a37869c0) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/pt.c:15439
#2  0x0053fa43 in instantiate_class_template 
(type=0x7f89a3789e40) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/pt.c:7324
#3  0x00644002 in complete_type (type=0x7f89a3789e40) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/typeck.c:130
#4  0x0061507d in cp_parser_nested_name_specifier_opt 
(parser=0x7f89a42cca50, typename_keyword_p=0 '\0', check_dependency_p=1 
'\001', type_p=0 '\0', is_declaration=0 '\0') at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:4255
#5  0x00621ba0 in cp_parser_simple_type_specifier 
(parser=0x7f89a42cca50, decl_specs=0x7fffac4025b0, flags=1) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:11947
#6  0x00621795 in cp_parser_type_specifier 
(parser=0x7f89a42cca50, flags=1, decl_specs=0x7fffac4025b0, 
is_declaration=1 '\001', declares_class_or_enum=0x7fffac402534, 
is_cv_qualifier=0x7fffac402533 "") at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:11749
#7  0x0061d3ff in cp_parser_decl_specifier_seq 
(parser=0x7f89a42cca50, flags=1, decl_specs=0x7fffac4025b0, 
declares_class_or_enum=0x7fffac4025ac) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:9130
#8  0x0061ce17 in cp_parser_simple_declaration 
(parser=0x7f89a42cca50, function_definition_allowed_p=1 '\001') at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:8792
#9  0x0061cdcb in cp_parser_block_declaration 
(parser=0x7f89a42cca50, statement_p=0 '\0') at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:8753
#10 0x0061cbb5 in cp_parser_declaration (parser=0x7f89a42cca50) 
at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:8658
#11 0x0061c827 in cp_parser_declaration_seq_opt 
(parser=0x7f89a42cca50) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:8549
#12 0x00612cd7 in cp_parser_translation_unit 
(parser=0x7f89a42cca50) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:3058
#13 0x00639680 in c_parse_file () at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp/parser.c:22960
#14 0x007a4773 in c_common_parse_file (set_yydebug=0) at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/c-opts.c:1302
#15 0x00bc2112 in compile_file () at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/toplev.c:1049
#16 0x00bc434f in do_compile () at 
/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/toplev.c:2408
#17 0x00bc4425 in toplev_main (argc=2, a