Re: 4.0.2 bootstrap comparison failure on AIX 5.3

> Albert Chin writes: Albert> I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a Albert> bootstrap comparison failure: Albert> $ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \ Albert> I don't see anything on Albert> http://gcc.gnu.org/install/specific.html#x-ibm-aix specific t

4.0.2 bootstrap comparison failure on AIX 5.3

I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a bootstrap comparison failure: $ cd /opt/build $ bzip2 -dc gcc-4.0.2.tar.bz2 | tar xf - $ mkdir gcc $ cd gcc $ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \ /opt/fsw/bin/bash /opt/build/gcc-4.0.2/configure \ --with-inc

RFC: weakref GCC attribute and .weakref assembly directive

I'll probably post a patch for the assembler, that implements this, tonight. The compiler still needs a bit more work in the testsuite (or in the implementation, to make it independent from assembler support) so it might take longer. Comments are welcome. Using weakrefs to avoid weakeni

Re: Running ranlib after installation - okay or not?

On Sep 29, 2005, "Peter O'Gorman" <[EMAIL PROTECTED]> wrote: > I posted a patch that nobody has had time to look at for this, even if > it is not acceptable (it would probably be better if it reset the > permissions after calling ranlib) I'd appreciate some feedback :) >

Re: Update on GCC moving to svn

On Tue, 2005-10-11 at 02:02 +0200, Giovanni Bajo wrote: > Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > Thus, i'm going to put an updated repo on gcc.gnu.org on Monday (i was > > converting it, but it looks like they shutdown the machines at watson) > > and do a few test branch merges to make sur

Re: Update on GCC moving to svn

Daniel Berlin <[EMAIL PROTECTED]> wrote: > Thus, i'm going to put an updated repo on gcc.gnu.org on Monday (i was > converting it, but it looks like they shutdown the machines at watson) > and do a few test branch merges to make sur eall the commit mails come > out okay for very large cases. Will

Re: RFC: IPO optimization framework for GCC

> > Second question is - When to put info on the disk? Few alternatives, > > 1) Before gimplfication > > 2) Before optimizing tree-ssa > > 3) After tree-ssa optimization is complete > > 4) Immediately after generating RTL > > 5) Halfway throuh RTL passes > > etc.. And answer to this question largel

Re: warning on i686-pc-cygwin

Brian Dessent wrote: bobby mcnulty wrote: This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005 You're running into PR21766. So its been reported already. OK. Bobby

Re: RFC: IPO optimization framework for GCC

Thanks to everyone who replied to my mail, I am currently waiting for some follow-ups to replies I got off-list. In the mean time I wonder if we could talk about Devang's questions on what this might look like to a user. > From: Devang Patel <[EMAIL PROTECTED]> > > It is useful to get clear under

Thanks [was Re: Speed impact of virtual inheritance]

On Monday 10 October 2005 15:21, Frans Englich wrote: > Hello all, > > In a large project I'm participating in, a design dilemma have arrived. > Adding virtual inheritance would solve it beautifully on the source code > level, but a potential drawback is the speed penalty it brings. Measurement > i

Re: warning on i686-pc-cygwin

bobby mcnulty wrote: > > This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005 You're running into PR21766.

warning on i686-pc-cygwin

This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005 CONFIG_FILES= CONFIG_HEADERS=config.h:../../../gcc/libiberty/config.in /bin/sh . /config.status config.status: creating config.h config.status: config.h is unchanged config.status: executing default commands if [ x"" != x ]; t

Re: Speed impact of virtual inheritance

Frans Englich wrote: > On Monday 10 October 2005 22:29, Mark Mitchell wrote: > >>Frans Englich wrote: >> >>>Followup question: what is the increased cost of calling a non-virtual, >>>inlined function('inline' keyword) on a virtual base? >> >>None, if the function is inlined -- and whether it is in

Re: Speed impact of virtual inheritance

On Monday 10 October 2005 22:29, Mark Mitchell wrote: > Frans Englich wrote: > > Followup question: what is the increased cost of calling a non-virtual, > > inlined function('inline' keyword) on a virtual base? > > None, if the function is inlined -- and whether it is inlined or not > should not be

Re: Speed impact of virtual inheritance

Frans Englich wrote: > Followup question: what is the increased cost of calling a non-virtual, > inlined function('inline' keyword) on a virtual base? None, if the function is inlined -- and whether it is inlined or not should not be affected by whether or not it is in a virtual base. > What m

Re: [gomp]

On Mon, Oct 10, 2005 at 10:49:52PM +0200, Christian Joensson wrote: > ../gcc.gomp/configure --enable-__cxa_atexit --enable-shared --with-cpu=v7 -- > enable-languages=c,ada,c++,fortran,java,objc,treelang Only C and Fortran are expected to build at the moment. What you're seeing is C++ pragmas be

Explicit NOPs for a VLIW Machine

Hi Everyone, I am porting GCC 4.0.0 to a proprietary VLIW machine, and I want to insert NOPs explicitly wherever there is an Output/Flow/Anti dependencies. I am currently doing this insertion in the machine dependent reorganization phase. Is there a way to do this in machine description file (o

Re: Speed impact of virtual inheritance

On Mon, Oct 10, 2005 at 09:25:15PM +, Frans Englich wrote: > Followup question: what is the increased cost of calling a non-virtual, > inlined function('inline' keyword) on a virtual base? If the function is successfully inlined, then the question really refers to the cost of the code inside

Re: Speed impact of virtual inheritance

On Monday 10 October 2005 18:53, Mark Mitchell wrote: > Frans Englich wrote: > > Hello all, > > > > In a large project I'm participating in, a design dilemma have arrived. > > Adding virtual inheritance would solve it beautifully on the source code > > level, but a potential drawback is the speed p

Re: [gomp] libgcj.so: undefined reference to `hidden alias for java::lang::Class::isArray()' and more...

On Monday 10 October 2005 16:51, Christian Joensson wrote: > > Is gomp not doing java yet? > > It's due to changes in pragma processing in the C++ FE. For now just disable java when configuring the compiler.

Re: [gomp] libgcj.so: undefined reference to `hidden alias for java::lang::Class::isArray()' and more...

Sorry, I forgot the subject... On 10/10/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > well, trying to build the gomp branch, LAST_UPDATED: Mon Oct 10 > 16:34:17 UTC 2005, on this system: > > Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: > > (auroralinux corona +

[gomp]

well, trying to build the gomp branch, LAST_UPDATED: Mon Oct 10 16:34:17 UTC 2005, on this system: Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: (auroralinux corona + rathann's and rzm's FC3 updates) binutils-2.16.91.0.2-4.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.n

Re: Speed impact of virtual inheritance

Frans Englich wrote: > Hello all, > > In a large project I'm participating in, a design dilemma have arrived. > Adding > virtual inheritance would solve it beautifully on the source code level, but > a potential drawback is the speed penalty it brings. Measurement is always > the way of approa

Re: RFC: IPO optimization framework for GCC

On 10/7/05, Steve Ellcey <[EMAIL PROTECTED]> wrote: [snip] > In the meantime I would be interested in any opinions people have on > what level we should be writing things out at. Generic? Gimple? RTL? > (Just kidding on that last one.) Also any opinions on what format to > write things out in

Re: Mainline now closed to all changes which do not fix regressions

Steven Bosscher wrote: > On Monday 10 October 2005 19:35, Mark Mitchell wrote: > >>As previously announced, here: >> >>http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html >> >>the mainline is now subject to the usual release-branch rules: only >>fixes for regressions. > > > How does this affect gfor

Re: Mainline now closed to all changes which do not fix regressions

On Monday 10 October 2005 19:35, Mark Mitchell wrote: > As previously announced, here: > > http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html > > the mainline is now subject to the usual release-branch rules: only > fixes for regressions. How does this affect gfortran, and what about already posted b

Mainline now closed to all changes which do not fix regressions

As previously announced, here: http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html the mainline is now subject to the usual release-branch rules: only fixes for regressions. The goal is to quickly reduce the current 219 oustanding regressions against 4.1 to approximately 100 -- in part by me retarge

Re: Speed impact of virtual inheritance

On Monday 10 October 2005 16:12, Jonathan Wakely wrote: > Frans Englich wrote: > > In a large project I'm participating in, a design dilemma have arrived. > > Adding virtual inheritance would solve it beautifully on the source code > > level, but a potential drawback is the speed penalty it brings.

Successful gcc 4.0.2 build on alphaev68-dec-osf5.1bTru64(c,c++,f95,objc,java,treelang)

Dear list, [EMAIL PROTECTED]:~/GNU/gcc-4.0.2/SRC#gcc -v Using built-in specs. Target: alphaev68-dec-osf5.1b Configured with: ../configure --host=alphaev68-dec-osf5.1b --enable-threads=posix --enable-languages=c,c++,f95,objc,java,treelang --prefix=/usr/local --enable-version-specific-runtime-libs

Re: Speed impact of virtual inheritance

Frans Englich wrote: > In a large project I'm participating in, a design dilemma have arrived. > Adding > virtual inheritance would solve it beautifully on the source code level, but > a potential drawback is the speed penalty it brings. Measurement is always > the way of approaching performan

Speed impact of virtual inheritance

Hello all, In a large project I'm participating in, a design dilemma have arrived. Adding virtual inheritance would solve it beautifully on the source code level, but a potential drawback is the speed penalty it brings. Measurement is always the way of approaching performance questions, but si

Re: New branch opened: dataflow-branch

On Thursday 06 October 2005 16:17, Daniel Berlin wrote: > This branch contains the work Ken Zadeck and I have been doing > replacing the backend dataflow (such as live register analysis) with > df.c based dataflow. Very cool! :-) Gr. Steven