GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ludovic Courtès
Hi, In a build of GCC 4.7.0-RC-20120302 with --enable-languages=c,c++ [0], I’m seeing C++-mangled name for common functions, like: $ objdump -T cc1 | grep build1_stat_loc 00640a00 gDF .text 007a Base _Z20fold_build1_stat_locj9tree_codeP9tree_nodeS1_ Indeed,

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Andrew Pinski
2012/3/9 Ludovic Courtès : > I believe this is not intentional, right? No, this is intentional. We bootstrap the compiler using the C++ front-end now. We build stage1 with the C compiler and then build stages 2 and 3 with the C++ compiler. This is a documented change too. Thanks, Andrew Pinsk

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Jakub Jelinek
On Fri, Mar 09, 2012 at 01:53:52AM -0800, Andrew Pinski wrote: > 2012/3/9 Ludovic Courtès : > > > I believe this is not intentional, right? > > No, this is intentional. We bootstrap the compiler using the C++ > front-end now. We build stage1 with the C compiler and then build > stages 2 and 3 w

subreg:HI of PSI HW register issue

2012-03-09 Thread Aurelien Buhrig
Hi, It seems there is an issue around subreg:HI of PSI hardware register, which occurs either during expand or reload (GCC 4.6.1). For my big endian target, (subreg:HI (reg:PSI A0_REGNO) 0) is not representable but (subreg:HI (reg:PSI A0_REGNO) 2) is (reg:HI A0_REGNO). The issue occurs when stor

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ludovic Courtès
Hi, Andrew Pinski skribis: > 2012/3/9 Ludovic Courtès : > >> I believe this is not intentional, right? > > No, this is intentional. We bootstrap the compiler using the C++ > front-end now. We build stage1 with the C compiler and then build > stages 2 and 3 with the C++ compiler. OK. However,

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ludovic Courtès
Hi, ludovic.cour...@inria.fr (Ludovic Courtès) skribis: > Andrew Pinski skribis: > >> 2012/3/9 Ludovic Courtès : >> >>> I believe this is not intentional, right? >> >> No, this is intentional. We bootstrap the compiler using the C++ >> front-end now. We build stage1 with the C compiler and the

Question about -Wnonnull

2012-03-09 Thread Fredrik Hederstierna
Hi I'm testing __attribute__((nonnull)) and -Wnonnull. It seems like it does warn before constant/vrp propagations. Example code does not warn for first 2 calls to f(NULL), but warns for last 2 calls to f(NULL). Couldn't this checker be improved/extended to do checks also after some basic optim

Re: subreg:HI of PSI HW register issue

2012-03-09 Thread Bernd Schmidt
On 03/09/2012 11:20 AM, Aurelien Buhrig wrote: > Hi, > > It seems there is an issue around subreg:HI of PSI hardware register, > which occurs either during expand or reload (GCC 4.6.1). > > For my big endian target, > (subreg:HI (reg:PSI A0_REGNO) 0) is not representable but > (subreg:HI (reg:PSI

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Duncan Sands
Hi, I believe this is not intentional, right? No, this is intentional. We bootstrap the compiler using the C++ front-end now. We build stage1 with the C compiler and then build stages 2 and 3 with the C++ compiler. OK. However, this means that plug-ins must now be built with g++, except w

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ian Lance Taylor
ludovic.cour...@inria.fr (Ludovic Courtès) writes: > However, this means that plug-ins must now be built with g++, except > when GCC was configured with --disable-build-poststage1-with-cxx. This > seems difficult to deal with, for plug-in writers. This is an unfortunate truth during our transiti

Re: subreg:HI of PSI HW register issue

2012-03-09 Thread Aurelien Buhrig
09/03/2012 15:08, Bernd Schmidt : > On 03/09/2012 11:20 AM, Aurelien Buhrig wrote: >> Hi, >> >> It seems there is an issue around subreg:HI of PSI hardware register, >> which occurs either during expand or reload (GCC 4.6.1). >> >> For my big endian target, >> (subreg:HI (reg:PSI A0_REGNO) 0) is no

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ludovic Courtès
Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> However, this means that plug-ins must now be built with g++, except >> when GCC was configured with --disable-build-poststage1-with-cxx. This >> seems difficult to deal with, for plug-in writers. > > This is an

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ian Lance Taylor
ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> However, this means that plug-ins must now be built with g++, except >>> when GCC was configured with --disable-build-poststage1-with-cxx. This >>> seems

Re: subreg:HI of PSI HW register issue

2012-03-09 Thread Bernd Schmidt
On 03/09/2012 04:20 PM, Aurelien Buhrig wrote: > I'm not used to work at tree level for now and it is unclear for me what > part of the code should be tweaked. Can you tell me which part of the > code you are fixing/looking at, so that I can have a better > understanding of ptr_mode vs Pmode before

Re: subreg:HI of PSI HW register issue

2012-03-09 Thread Aurelien Buhrig
Le 09/03/2012 17:10, Bernd Schmidt a écrit : > On 03/09/2012 04:20 PM, Aurelien Buhrig wrote: >> I'm not used to work at tree level for now and it is unclear for me what >> part of the code should be tweaked. Can you tell me which part of the >> code you are fixing/looking at, so that I can have a

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ludovic Courtès
Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> However, this means that plug-ins must now be built with g++, except when GCC was configured with --disable-build-

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread Ian Lance Taylor
ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> Ian Lance Taylor skribis: >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: > However, this means that plug-ins must now be built with

Re: Building libstdc++ with current glibc, NULL and pthread.h

2012-03-09 Thread Joseph S. Myers
The answer from the Austin Group list was that the POSIX requirement *does* mean all symbols from time.h are to be defined by pthread.h and it's a bug in the change history that it refers to allowing rather than requiring the symbols to be made visible. Thus, I propose this patch to make pthread.h

Re: Building libstdc++ with current glibc, NULL and pthread.h

2012-03-09 Thread Roland McGrath
The change seems fine. But I think the log entry should have an explicit pointer to the POSIX interpretation citation by way of rationale. Thanks, Roland

Re: Building libstdc++ with current glibc, NULL and pthread.h

2012-03-09 Thread Joseph S. Myers
On Fri, 9 Mar 2012, Roland McGrath wrote: > The change seems fine. But I think the log entry should have an explicit > pointer to the POSIX interpretation citation by way of rationale. I've committed it with references in the log to https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index

gcc-4.6-20120309 is now available

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

Re: GCC 4.7.0RC: Mangled names in cc1

2012-03-09 Thread David Malcolm
On Fri, 2012-03-09 at 11:41 +0100, Ludovic Courtès wrote: > Hi, > > Andrew Pinski skribis: > > > 2012/3/9 Ludovic Courtès : > > > >> I believe this is not intentional, right? > > > > No, this is intentional. We bootstrap the compiler using the C++ > > front-end now. We build stage1 with the C