Bonjour,
pour l'achat ou la vente de votre propriété (maison, chalet, condo, terrain, ou
commerce),
pour du prêt hypothécaire ou une reprise de finance, visitez:
http://www.voscomplicesimmobilier.com
Un service complet, rapide et professionnel.
Merci.
Vos complices immobiliers.
Jean-Pierre et R
Hi,
On Mon, May 17, 2010 at 15:15, Sandeep Soni wrote:
> Hi,
>
> As part of GSoC 2010, I am developing a front end for GIMPLE.
> You can find the basic theme of the project at:
> http://gcc.gnu.org/wiki/GimpleFrontEnd
>
> One of the most important components in this GIMPLE Front End is to
> conve
Snapshot gcc-4.5-20100603 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100603/
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
On 3 June 2010 20:35, Steinar Bang wrote:
>> Mark Mitchell :
>
>> I think virtual functions are on the edge; quite useful, but do result
>> in the compiler adding a pointer to data objects and in uninlinable
>> indirect calls at run-time. Therefore, I would avoid them in the
>> initial subset
Okay, I guess we 'll just disable the __wur's by default then -- as introducing
an unnecessary hard-to-avoid noise. I recon many other people do the same.
Thanks nevertheless. It's still a useful feature, just not flexible enough to
use it for *everyday* compilation.
Denis
Steinar Bang wrote:
Mark Mitchell :
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset of C++ used in GCC.
Umm...? Virtual
Andrew Haley wrote:
Right, but I didn't think there was any plan to convert en masse to
C++ -- just to allow people to use it where appropriate. Apart from
anything else, there's always a nonzero probablility of breaking
something.
It's the "where appropriate" that is the sneaky detail here :
> On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther
> wrote:
>
> > Indeed ;) I'd like us to switch to the C / C++ common soon (thus,
> > use C for stage1 and C++ for stage2 and stage3). That will help
> > us sort out problems on the various host/target combinations that
> > will surely exist.
>
Steinar Bang writes:
>> Mark Mitchell :
>
>> I think virtual functions are on the edge; quite useful, but do result
>> in the compiler adding a pointer to data objects and in uninlinable
>> indirect calls at run-time. Therefore, I would avoid them in the
>> initial subset of C++ used in GCC.
On Thu, 2010-06-03 at 14:24 +0200, Uros Bizjak wrote:
> I'm looking into i386.md, where we have a bunch of instances of
> following comment:
>
> ; Current assemblers are broken and do not allow @GOTOFF in
> ; ought but a memory context.
>
> Code, following this comment di
> Larry Evans :
> claims that switch statements are faster than virtual function calls.
That's not really interesting, is it? The overhead and downsides of
virtual functions are well known.
The upside is the possibility to use polymorphism to make frameworks.
All kinds of pluggable framewor
> Mark Mitchell :
> I think virtual functions are on the edge; quite useful, but do result
> in the compiler adding a pointer to data objects and in uninlinable
> indirect calls at run-time. Therefore, I would avoid them in the
> initial subset of C++ used in GCC.
Umm...? Virtual functions
On Thu, 2010-06-03 at 13:05 -0500, Gabriel Dos Reis wrote:
> On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther
> wrote:
>
> > Indeed ;) I'd like us to switch to the C / C++ common soon (thus,
> > use C for stage1 and C++ for stage2 and stage3). That will help
> > us sort out problems on the vari
On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther
wrote:
> Indeed ;) I'd like us to switch to the C / C++ common soon (thus,
> use C for stage1 and C++ for stage2 and stage3). That will help
> us sort out problems on the various host/target combinations that
> will surely exist.
Here is a concr
On 06/03/2010 12:09 PM, Richard Guenther wrote:
> On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar wrote:
>> Steven Bosscher wrote:
>>
>>> Indeed. It is, well, perhaps not surprising, but quite annoying (to me
>>> at least) that a possible move to C++ as implementation language of
>>> GCC is so much
On 06/03/2010 12:51 PM, Robert Dewar wrote:
Steven Bosscher wrote:
Indeed. It is, well, perhaps not surprising, but quite annoying (to me
at least) that a possible move to C++ as implementation language of
GCC is so much bigger news than all the amazing amounts of work done
in the last few yea
On Thu, Jun 03, 2010 at 03:31:30PM +0200, Gerald Pfeifer wrote:
> On Thu, 3 Jun 2010, Richard Guenther wrote:
> >> As I was about to check in the -mrecip changes for powerpc on GCC 4.6,
> >> I figured to get a start on documentation, and I was going to edit the
> >> gcc-4.6/changes.html file. I
On Thu, 3 Jun 2010, Richard Guenther wrote:
>> As I was about to check in the -mrecip changes for powerpc on GCC 4.6,
>> I figured to get a start on documentation, and I was going to edit the
>> gcc-4.6/changes.html file. I realize this is early in the cycle, but
>> did we want to create the gc
2010/6/3 Uros Bizjak :
> Hello!
>
> I'm looking into i386.md, where we have a bunch of instances of
> following comment:
>
> ; Current assemblers are broken and do not allow @GOTOFF in
> ; ought but a memory context.
>
> Code, following this comment disables or special-cases
Hello!
I'm looking into i386.md, where we have a bunch of instances of
following comment:
; Current assemblers are broken and do not allow @GOTOFF in
; ought but a memory context.
Code, following this comment disables or special-cases "pic_symbolic_operands".
I'm investi
On Thu, Jun 3, 2010 at 1:14 PM, Ira Rosen wrote:
>
>
> Richard Guenther wrote on 03/06/2010 02:00:00
> PM:
>
>> >> tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST
>> >> tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST
>> >> tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST
>> >> tree
Richard Guenther wrote on 03/06/2010 02:00:00
PM:
> >> tree-vectorizer.h:#ifndef TARG_COND_TAKEN_BRANCH_COST
> >> tree-vectorizer.h:#ifndef TARG_COND_NOT_TAKEN_BRANCH_COST
> >> tree-vectorizer.h:#ifndef TARG_SCALAR_STMT_COST
> >> tree-vectorizer.h:#ifndef TARG_SCALAR_LOAD_COST
> >> tree-vectori
On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar wrote:
> Steven Bosscher wrote:
>
>> Indeed. It is, well, perhaps not surprising, but quite annoying (to me
>> at least) that a possible move to C++ as implementation language of
>> GCC is so much bigger news than all the amazing amounts of work done
>
On Thu, Jun 3, 2010 at 9:01 AM, Ira Rosen wrote:
>
>
> Steven Bosscher wrote on 02/06/2010 06:13:36 PM:
>
>>
>> On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell
> wrote:
>> > Ulrich Weigand wrote:
>> >
>> >>> So the question is: The goal is to have hooks, not macros, right? If
>> >>> so, can revie
Steven Bosscher wrote:
Indeed. It is, well, perhaps not surprising, but quite annoying (to me
at least) that a possible move to C++ as implementation language of
GCC is so much bigger news than all the amazing amounts of work done
in the last few years on things like LTO, the vectorizer, IRA, et
On Thu, Jun 3, 2010 at 1:49 AM, Michael Meissner
wrote:
> As I was about to check in the -mrecip changes for powerpc on GCC 4.6, I
> figured to get a start on documentation, and I was going to edit the
> gcc-4.6/changes.html file. I realize this is early in the cycle, but did we
> want to create
On Thu, Jun 3, 2010 at 10:24 AM, Andrew Haley wrote:
> On 06/02/2010 09:19 PM, DJ Delorie wrote:
>>
>> Robert Dewar writes:
>>> I would create a specific committee to reccommend a C++ coding
>>> standard (preferably based on one of the standard ones available, such
>>> as Google).
>>
>> Doing thi
On 06/01/2010 08:10 AM, Ian Lance Taylor wrote:
Mark Mitchell writes:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. Of course, there's no reason for
us to use C++ features just because we can. The goal is a better
compiler for
On 06/02/2010 09:19 PM, DJ Delorie wrote:
>
> Robert Dewar writes:
>> I would create a specific committee to reccommend a C++ coding
>> standard (preferably based on one of the standard ones available, such
>> as Google).
>
> Doing things in secret like that is not the Open Source Way.
No, havi
Steven Bosscher wrote on 02/06/2010 06:13:36 PM:
>
> On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell
wrote:
> > Ulrich Weigand wrote:
> >
> >>> So the question is: The goal is to have hooks, not macros, right? If
> >>> so, can reviewers please take care to reject patches that introduce
> >>> ne
30 matches
Mail list logo
