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
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
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
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
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
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
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-
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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,
22 matches
Mail list logo