On Sun, Jun 27, 2010 at 11:35 PM, David Edelsohn wrote:
> On Sun, Jun 27, 2010 at 3:45 PM, Manuel López-Ibáñez
> wrote:
>
>> I do believe that it is odd that one of the most important
>> free-software projects in terms of widespread use, a free-software
>> project that has a technical quality com
On Sun, Jun 27, 2010 at 3:45 PM, Manuel López-Ibáñez
wrote:
> I do believe that it is odd that one of the most important
> free-software projects in terms of widespread use, a free-software
> project that has a technical quality comparable and often superior to
> the closed-source counterparts, i
Martin Guy wrote:
> For
> ARM boards without mainline Linux support whose manufacturers' kernel
> ports predates 2.6.16, it is mandatory, as is also is for users who
> just want to compile code for a given existing system that happens not
> to be running a recent kernel and userspace.
But what ar
On 6/27/10, Gerald Pfeifer wrote:
> On Mon, 24 May 2010, Richard Kenner wrote:
> > I think that's a critical distinction. I can't see removing a port just
> > because it's not used much (or at all) because it might be valuable for
> > historical reason or to show examples for how to do things.
>
> (it is regression at 4.5 branch, forgot to mention)
PR44694
GiNaC indeed shows interesting behaviour. Just the first test on 4.3 is:
timing commutative expansion and substitution
size: 100 200 400 800
time/s: 0.064 0.301.4 6.2
for 4.5
timing commu
Snapshot gcc-4.3-20100627 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100627/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> > > Jan Hubicka wrote:
> > >>> On Fri, 25 Jun 2010, it was written:
> > >>> There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
> > >>> (a computer algebra library) benchmark suite after switching from 4.4 to
> > >>> 4.5 on x86_64 when compiling with -O2. And there hasn't been
> > Jan Hubicka wrote:
> >>> On Fri, 25 Jun 2010, it was written:
> >>> There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
> >>> (a computer algebra library) benchmark suite after switching from 4.4 to
> >>> 4.5 on x86_64 when compiling with -O2. And there hasn't been a measura
> Jan Hubicka wrote:
>>> On Fri, 25 Jun 2010, it was written:
>>> There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
>>> (a computer algebra library) benchmark suite after switching from 4.4 to
>>> 4.5 on x86_64 when compiling with -O2. And there hasn't been a measurable
>>> pe
Jan Hubicka wrote:
On Fri, 25 Jun 2010, it was written:
There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
(a computer algebra library) benchmark suite after switching from 4.4 to
4.5 on x86_64 when compiling with -O2. And there hasn't been a measurable
performance difference
> Any ideas what might be wrong here?
Probably PR libgcj/44415.
--
Eric Botcazou
On 27 June 2010 20:45, David Edelsohn wrote:
> On Sun, Jun 27, 2010 at 5:43 AM, Manuel López-Ibáñez
> wrote:
>> On 27 June 2010 11:32, Tobias Burnus wrote:
>>> Gerald Pfeifer wrote:
We actually do have an issue with the Bugzilla instance on gcc.gnu.org
being rather old, so if anyone wi
> On Fri, 25 Jun 2010, it was written:
> > On Thu, Jun 24, 2010 at 11:50:52AM -0700, Taras Glek wrote:
> > > We switched gcc4.3 for gcc4.5 and our automated benchmarking
> > > infrastructure reported 4-19% slowdown on most of our performance
> > > metrics on 32 and 64bit Linux.
> >
> > Could you p
> On Fri, Jun 25, 2010 at 06:10:56AM -0700, Jan Hubicka wrote:
> > When you compile with -Os, the inlining happens only when code size reduces.
> > Thus we pretty much care about the code size metrics only. I suspect the
> > problem here might be that normal C++ code needs some inlining to make
>
On Sun, Jun 27, 2010 at 5:43 AM, Manuel López-Ibáñez
wrote:
> On 27 June 2010 11:32, Tobias Burnus wrote:
>> Gerald Pfeifer wrote:
>>> We actually do have an issue with the Bugzilla instance on gcc.gnu.org
>>> being rather old, so if anyone with Bugzilla foo wants to donate time
>>> and effort, l
Hello,
On a clean trunk r161470 with java enabled, I get a bootstrap failure:
make[6]: Entering directory
`/home/stevenb/devel/build-test/x86_64-unknown-linux-gnu/libjava/classpath/native/jni/java-math'
/bin/sh ../../../libtool --tag=CC --mode=link
/home/stevenb/devel/build-test/./gcc/xgcc
-B/h
On Mon, 24 May 2010, Richard Kenner wrote:
> I think that's a critical distinction. I can't see removing a port just
> because it's not used much (or at all) because it might be valuable for
> historical reason or to show examples for how to do things. If the
> maintenance burden of keeping tha
On Sun, Jun 27, 2010 at 11:43 AM, Manuel López-Ibáñez
wrote:
> On 27 June 2010 11:32, Tobias Burnus wrote:
>> Gerald Pfeifer wrote:
>>> We actually do have an issue with the Bugzilla instance on gcc.gnu.org
>>> being rather old, so if anyone with Bugzilla foo wants to donate time
>>> and effort,
On 27 June 2010 11:32, Tobias Burnus wrote:
> Gerald Pfeifer wrote:
>> We actually do have an issue with the Bugzilla instance on gcc.gnu.org
>> being rather old, so if anyone with Bugzilla foo wants to donate time
>> and effort, looking into upgrading that might be even preferrable.
>
> See http:
Gerald Pfeifer wrote:
> We actually do have an issue with the Bugzilla instance on gcc.gnu.org
> being rather old, so if anyone with Bugzilla foo wants to donate time
> and effort, looking into upgrading that might be even preferrable.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 for more
On Mon, 7 Jun 2010, Ben White wrote:
> Would a modestly modified copy of Bugzilla be workable for that
> something? I.E. Patchzilla?
We actually do have an issue with the Bugzilla instance on gcc.gnu.org
being rather old, so if anyone with Bugzilla foo wants to donate time
and effort, looking int
21 matches
Mail list logo
