Re: __function_size builtin

2011-06-23 Thread Paulo J. Matos
On 22/06/11 23:25, Ian Lance Taylor wrote: "Paulo J. Matos" writes: On 22/06/11 17:34, Paulo J. Matos wrote: I thought this was the same as using __attribute__((used)) on a function declaration (which works). DECL_PRESERVE_P(node) = 1; seems to be what I wanted. :) I always wondered wha

Re: [GCC steering committee] I'd like to be maintainer for Linux/x86 platform

2011-06-23 Thread Jan Hubicka
> On Wed, Jun 22, 2011 at 3:25 PM, Ian Lance Taylor wrote: > > "H.J. Lu" writes: > > > >> Apparently, there is no GCC maintainer for Linux/x86 platform.  I have > >> been working on GCC, as well as binutils and C libraries, for Linux/x86 > >> over 20 years.  I ported GCC, binutils and the C libra

Re: Middle end warnings cascading after C++ parsing errors

2011-06-23 Thread Diego Novillo
On Mon, Jun 20, 2011 at 10:50, Diego Novillo wrote: > On Mon, Jun 20, 2011 at 10:47, Richard Guenther > wrote: >> On Fri, Jun 17, 2011 at 5:39 PM, Jason Merrill wrote: >>> >>> That seems reasonable to me. >> >> Yes.  I think Steven proposed this as well at some point. > > Alright, thanks. > > Un

gcc-4.5-20110623 is now available

2011-06-23 Thread gccadmin
Snapshot gcc-4.5-20110623 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110623/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Middle end warnings cascading after C++ parsing errors

2011-06-23 Thread Ian Lance Taylor
Diego Novillo writes: > So, I think we need to re-think where to check for seen_errors(). > Bailing out too early is disabling some valid diagnostics. For > instance, > > gcc/testsuite/gcc.dg/asm-7.c: > $ cat -n > /home/dnovillo/g1/fix-4487457/Patch-752f00bd28e325efdfa0ac7abed22feb_branches-goo

Re: Middle end warnings cascading after C++ parsing errors

2011-06-23 Thread Jason Merrill
On 06/23/2011 06:48 PM, Ian Lance Taylor wrote: Well, so what? This test case does not represent actual or even likely user code. I don't think we need to contort ourselves to generate all possible errors for erroneous input. As many errors as reasonable, yes. All possible errors, no. I agree