Re: Patch pinging

[Gerald Pfeifer]

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 into upgrading that might be even preferrable.

Gerald

Re: Patch pinging

[Tobias Burnus]

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 details.

I concur an update would be very useful!

Tobias

Re: Patch pinging

[Manuel López-Ibáñez]

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://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 for more details.
>
> I concur an update would be very useful!

Bah! Someone already volunteered to do it in several occasions.
Myself, a long time ago. Someone else a few months ago, Frederic
Buclin volunteered to help and Nightstrike in that very same PR. The
answer was silence. It is not a matter of volunteers. The problem is
elsewhere, deeper in the (mal)functioning of GCC as a project.

Cheers,

Manuel.

Re: Patch pinging

[Richard Guenther]

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, looking into upgrading that might be even preferrable.
>>
>> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 for more details.
>>
>> I concur an update would be very useful!
>
> Bah! Someone already volunteered to do it in several occasions.
> Myself, a long time ago. Someone else a few months ago, Frederic
> Buclin volunteered to help and Nightstrike in that very same PR. The
> answer was silence. It is not a matter of volunteers. The problem is
> elsewhere, deeper in the (mal)functioning of GCC as a project.

GCC is not malefunctioning.  Please do not generalize this way.  Thanks.

The issue is that the only person familiar with the GCC bugzilla
deployment left and that access to the project hosting machines
is (obviously) restricted.  If you want to help with bugzilla it is best
to coordinate with overseers, not to rant about this on any gcc
specific list or in bugzilla.

Richard.

> Cheers,
>
> Manuel.
>

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Gerald Pfeifer]

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 that port is just doing some mechanical 
> changes a couple of times a year when the backend API changes, that port 
> should be kept even if there are ZERO known users.

Nothing in life is free, and certainly those "mechanical changes a 
couple of times a year" are not.  Plus we do have been using version
control systems for more than a decade, so indeed I'd say a port with
zero known users should actually be removed.  As should a port that
is not maintained, of course.

Gerald

Bootstrap failure on x86_64-unknown-linux-gnu

[Steven Bosscher]

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/home/stevenb/devel/build-test/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-W -Wall
-Wmissing-declarations -Wwrite-strings -Wmissing-prototypes
-Wno-long-long  -I/opt/cfarm/gmp-4.2.4/include  -g -O2 -module
-version-info 0:0:0 -no-undefined -L/opt/cfarm/gmp-4.2.4/lib -lgmp
-avoid-version  -o libjavamath.la -rpath
/usr/local/lib/../lib64/gcj-4.6.0-12 gnu_java_math_GMP.lo
../../../native/jni/classpath/jcl.lo
libtool: link: /home/stevenb/devel/build-test/./gcc/xgcc
-B/home/stevenb/devel/build-test/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-shared
.libs/gnu_java_math_GMP.o ../../../native/jni/classpath/.libs/jcl.o
-L/opt/cfarm/gmp-4.2.4/lib /opt/cfarm/gmp-4.2.4/lib/libgmp.a
-Wl,-soname -Wl,libjavamath.so -o .libs/libjavamath.so
/usr/bin/ld: /opt/cfarm/gmp-4.2.4/lib/libgmp.a(mp_set_fns.o):
relocation R_X86_64_32 against `__gmp_default_allocate' can not be
used when making a shared object; recompile with -fPIC
/opt/cfarm/gmp-4.2.4/lib/libgmp.a: could not read symbols: Bad value


Any ideas what might be wrong here?

Ciao!
Steven

Re: Patch pinging

[David Edelsohn]

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, looking into upgrading that might be even preferrable.
>>
>> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 for more details.
>>
>> I concur an update would be very useful!
>
> Bah! Someone already volunteered to do it in several occasions.
> Myself, a long time ago. Someone else a few months ago, Frederic
> Buclin volunteered to help and Nightstrike in that very same PR. The
> answer was silence. It is not a matter of volunteers. The problem is
> elsewhere, deeper in the (mal)functioning of GCC as a project.

Manuel,

The GNU Toolchain projects currently are hampered by a lack of
volunteers or sponsors to maintain the support infrastructure around
the core projects.  The GNU Toolchain projects have not retained a
diverse community to work on infrastructure like Bugzilla, Issue /
Patch Tracking, Repository, and Wiki, which usually are
under-appreciated.  No companies have stepped up to pay for such work,
unlike other projects (other than "let us take it over").

However, characterizing the GCC project as malfunctioning is not
correct.  Acting like a victim because the project does not do what
you want speaks for itself.  And repeatedly complaining about the
project certainly does not help GCC attract and inspire new
volunteers.  Practical suggestions and contributions of resources
would be helpful.

Thanks, David

Re: Massive performance regression from switching to gcc 4.5

[Jan Hubicka]

> 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
> > abstraction penalty go away. GCC -Os implementation is generally tuned for
> > CSiBE and it is somewhat C centric (that makes sense for embedded world). 
> > As a
> > result we might get quite noticeable slowdowns on C++ apps compiled with -Os
> > (and code size growth too since abstraction is never eliminated). It can be
> > seen also at tramp3d (Pooma testcase) where -Os produces a lot bigger and a 
> > lot
> > slower code.
> 
> One would think that in most of the abstraction-penalty cases, the inlined
> code (often the direct reading or setting of a class data member) should
> be both smaller and faster than the call, so -Os should inline.  Perhaps

Yes at -Os inliner should inline to produce smallest binary.  Problem is to
figure out at inline time what the results of the inlining decisions will be.
Inliner has no idea how the code will optimize if it does inlining or if it
does not and often the code quality depends on multiple inline decisions (i.e.
one needs to inline all methods of the object to make it to be scalar replaced
and optimized away).

Current herusitcs makes some simple guesses. Some of them are turned off for -Os
to avoid regressions on C benchmarks in CSiBE.  So I would really need to see 
individual
examples to work out what can be done about them.

Honza
> there are cases where the inlined version is, say, one or two instructions 
> larger
> than the version with a call, and this causes the degradation?  If so,
> maybe some heuristic could be produced that would inline anyway for
> a small function?

Re: Massive performance regression from switching to gcc 4.5

[Jan Hubicka]

> 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 please also try gcc4.4, so that it is clear if the slowdowns
> > are between 4.3 and 4.4 or 4.4 and 4.5?  Would be nice to narrow the changes
> > a little bit.
> 
> 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 differences between 4.3 and 4.4.

FP intensive code could be also affected by:

On x86 targets, code containing floating-point calculations may run 
significantly slower when compiled with GCC 4.5 in strict C99 conformance mode 
than they did with earlier GCC versions. This is due to stricter standard 
conformance of the compiler and can be avoided by using the option 
-fexcess-precision=fast; also see below.

(see http://gcc.gnu.org/gcc-4.5/changes.html)
If not, I would be interested to take a look.  C++ code in general tends to
challenge inliner heruistic.  We assembled a benchmark suite that we use for
tunning the interprocedural optimizers pretty much every release. So perhaps
GiNaC can be used as one of the tests.

Honza

> 
>   -richy.
> -- 
> Richard B. Kreckel
> 

Re: Patch pinging

[Manuel López-Ibáñez]

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 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 details.
>>>
>>> I concur an update would be very useful!
>>
>> Bah! Someone already volunteered to do it in several occasions.
>> Myself, a long time ago. Someone else a few months ago, Frederic
>> Buclin volunteered to help and Nightstrike in that very same PR. The
>> answer was silence. It is not a matter of volunteers. The problem is
>> elsewhere, deeper in the (mal)functioning of GCC as a project.
>
> Manuel,
>
> The GNU Toolchain projects currently are hampered by a lack of
> volunteers or sponsors to maintain the support infrastructure around
> the core projects.  The GNU Toolchain projects have not retained a
> diverse community to work on infrastructure like Bugzilla, Issue /
> Patch Tracking, Repository, and Wiki, which usually are
> under-appreciated.  No companies have stepped up to pay for such work,
> unlike other projects (other than "let us take it over").

In this case, as I point out above, there were volunteers. They didn't
get any answer.

I didn't know this was a problem affecting the whole GNU Toolchain. It
is clear that I don't have the whole picture.

> However, characterizing the GCC project as malfunctioning is not
> correct.  Acting like a victim because the project does not do what

"Malfunctioning" is perhaps the incorrect term. And I should have said
"a malfunctioning" not "the malfunctioning". I am referring strictly
to this particular issue and to GCC as a free-software
volunteer-community-based project, not as the quality of the software,
not as a corporate project, not to anything else. And of course, this
is a personal, debatable opinion, that certainly some people do not
share (although I feel some do).

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, is still using a bugzilla version that
reached end-of-life more than 2 years ago.

> you want speaks for itself.  And repeatedly complaining about the
> project certainly does not help GCC attract and inspire new
> volunteers.  Practical suggestions and contributions of resources
> would be helpful.

I didn't feel that was right to ask for volunteers again to do
something, when there have been volunteers and they have been ignored.
It is true that frustration does not justify an outburst, specially
since I am not volunteering anymore.

Your last two sentences are definitely right. I don't have anything
else new to propose. It is a difficult situation. Good luck. Sorry for
the noise.

Manuel.

Re: Bootstrap failure on x86_64-unknown-linux-gnu

[Eric Botcazou]

> Any ideas what might be wrong here?

Probably PR libgcj/44415.

-- 
Eric Botcazou

Re: Massive performance regression from switching to gcc 4.5

[Richard B. Kreckel]

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 differences between 4.3 and 4.4.


FP intensive code could be also affected by:


This code isn't using floating-point.

  -richy.
--
Richard B. Kreckel

Re: Massive performance regression from switching to gcc 4.5

[Jan Hubicka]

> 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 differences between 4.3 and 4.4.
>>
>> FP intensive code could be also affected by:
>
> This code isn't using floating-point.

Hmm, building ginac with current 4.5 branch I get:
/bin/sh ../libtool --tag=CXX   --mode=compile 
/abuild/jh/gcc-4.5-nopatch/bin/g++ -DHAVE_CONFIG_H -I. -I../../ginac 
-I../config   -I/usr/local/include-g -O2 -MT function.lo -MD -MP -MF 
.deps/function.Tpo -c -o function.lo ../../ginac/function.cpp
libtool: compile:  /abuild/jh/gcc-4.5-nopatch/bin/g++ -DHAVE_CONFIG_H -I. 
-I../../ginac -I../config -I/usr/local/include -g -O2 -MT function.lo -MD -MP 
-MF .deps/function.Tpo -c ../../ginac/function.cpp  -fPIC -DPIC -o 
.libs/function.o
../../ginac/function.cpp: In member function ‘GiNaC::ex 
GiNaC::function::power(const GiNaC::ex&) const’:
../../ginac/function.cpp:1800:15: error: expected type-specifier
../../ginac/function.cpp:1800:15: error: expected ‘)’
../../ginac/function.cpp:1801:72: error: conversion from ‘int*’ to 
‘GiNaC::ex’ is ambiguous
../../ginac/ex.h:279:1: note: candidates are: GiNaC::ex::ex(long unsigned int) 

../../ginac/ex.h:273:1: note: GiNaC::ex::ex(long int) 
../../ginac/ex.h:267:1: note: GiNaC::ex::ex(unsigned int) 
../../ginac/ex.h:261:1: note: GiNaC::ex::ex(int) 

Honza
>
>   -richy.
> -- 
> Richard B. Kreckel
> 

Re: Massive performance regression from switching to gcc 4.5

[Jan Hubicka]

> > 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 differences between 4.3 and 4.4.
> >>
> >> FP intensive code could be also affected by:
> >
> > This code isn't using floating-point.
> 
> Hmm, building ginac with current 4.5 branch I get:
> /bin/sh ../libtool --tag=CXX   --mode=compile 
> /abuild/jh/gcc-4.5-nopatch/bin/g++ -DHAVE_CONFIG_H -I. -I../../ginac 
> -I../config   -I/usr/local/include-g -O2 -MT function.lo -MD -MP -MF 
> .deps/function.Tpo -c -o function.lo ../../ginac/function.cpp
> libtool: compile:  /abuild/jh/gcc-4.5-nopatch/bin/g++ -DHAVE_CONFIG_H -I. 
> -I../../ginac -I../config -I/usr/local/include -g -O2 -MT function.lo -MD -MP 
> -MF .deps/function.Tpo -c ../../ginac/function.cpp  -fPIC -DPIC -o 
> .libs/function.o
> ../../ginac/function.cpp: In member function ‘GiNaC::ex 
> GiNaC::function::power(const GiNaC::ex&) const’:
> ../../ginac/function.cpp:1800:15: error: expected type-specifier
> ../../ginac/function.cpp:1800:15: error: expected ‘)’
> ../../ginac/function.cpp:1801:72: error: conversion from ‘int*’ to 
> ‘GiNaC::ex’ is ambiguous
> ../../ginac/ex.h:279:1: note: candidates are: GiNaC::ex::ex(long unsigned 
> int) 
> ../../ginac/ex.h:273:1: note: GiNaC::ex::ex(long int)  match>
> ../../ginac/ex.h:267:1: note: GiNaC::ex::ex(unsigned int) 
> 
> ../../ginac/ex.h:261:1: note: GiNaC::ex::ex(int) 

Hi,
I got arround by just replacing the offending line by abort() that seems to get 
me far enough
to build the testsuite.  One thing I noticed is that compile time prolonged 
excessively to about
10 minutes.  It seems to be var tracking

3960911.3093  cc1plus  canonicalize_values_star
33469 9.5562  cc1plus  loc_cmp
22206 6.3403  cc1plus  set_slot_part
15798 4.5107  cc1plus  rtx_equal_p
14479 4.1341  cc1plus  htab_find_with_hash
10461 2.9869  cc1plus  htab_find_slot_with_hash
7268  2.0752  cc1plus  find_loc_in_1pdv
6718  1.9181  cc1plus  cselib_expand_value_rtx_1
6619  1.8899  libc-2.11.1.so   strcmp
6193  1.7682  cc1plus  htab_expand
6020  1.7188  cc1plus  check_changed_vars_0
5797  1.6552  cc1plus  htab_traverse_noresize
5615  1.6032  cc1plus  htab_find_with_hash
4757  1.3582  cc1plus  vt_expand_loc_callback
4529  1.2931  libginac-1.5.so.0.1.2GiNaC::basic::compare(GiNaC::basic 
const&) const
4497  1.2840  libc-2.11.1.so   _int_malloc
3879  1.1075  as   /usr/bin/as
3703  1.0573  cc1plus  variable_htab_eq
3698  1.0559  cc1plus  insert_into_intersection
3287  0.9385  cc1plus  emit_note_insn_var_location

Honza

Re: Massive performance regression from switching to gcc 4.5

[Jan Hubicka]

> > > 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 differences between 4.3 and 4.4.
> > >>
> > >> FP intensive code could be also affected by:
> > >
> > > This code isn't using floating-point.
> > 
> > Hmm, building ginac with current 4.5 branch I get:
> > /bin/sh ../libtool --tag=CXX   --mode=compile 
> > /abuild/jh/gcc-4.5-nopatch/bin/g++ -DHAVE_CONFIG_H -I. -I../../ginac 
> > -I../config   -I/usr/local/include-g -O2 -MT function.lo -MD -MP -MF 
> > .deps/function.Tpo -c -o function.lo ../../ginac/function.cpp
> > libtool: compile:  /abuild/jh/gcc-4.5-nopatch/bin/g++ -DHAVE_CONFIG_H -I. 
> > -I../../ginac -I../config -I/usr/local/include -g -O2 -MT function.lo -MD 
> > -MP -MF .deps/function.Tpo -c ../../ginac/function.cpp  -fPIC -DPIC -o 
> > .libs/function.o
> > ../../ginac/function.cpp: In member function ‘GiNaC::ex 
> > GiNaC::function::power(const GiNaC::ex&) const’:
> > ../../ginac/function.cpp:1800:15: error: expected type-specifier
> > ../../ginac/function.cpp:1800:15: error: expected ‘)’
> > ../../ginac/function.cpp:1801:72: error: conversion from ‘int*’ to 
> > ‘GiNaC::ex’ is ambiguous
> > ../../ginac/ex.h:279:1: note: candidates are: GiNaC::ex::ex(long unsigned 
> > int) 
> > ../../ginac/ex.h:273:1: note: GiNaC::ex::ex(long int)  > match>
> > ../../ginac/ex.h:267:1: note: GiNaC::ex::ex(unsigned int) 
> > 
> > ../../ginac/ex.h:261:1: note: GiNaC::ex::ex(int)  > match>
> 
> Hi,
> I got arround by just replacing the offending line by abort() that seems to 
> get me far enough
> to build the testsuite.  One thing I noticed is that compile time prolonged 
> excessively to about
> 10 minutes.  It seems to be var tracking
> 
> 3960911.3093  cc1plus  canonicalize_values_star
> 33469 9.5562  cc1plus  loc_cmp
> 22206 6.3403  cc1plus  set_slot_part
> 15798 4.5107  cc1plus  rtx_equal_p
> 14479 4.1341  cc1plus  htab_find_with_hash
> 10461 2.9869  cc1plus  htab_find_slot_with_hash
> 7268  2.0752  cc1plus  find_loc_in_1pdv
> 6718  1.9181  cc1plus  cselib_expand_value_rtx_1
> 6619  1.8899  libc-2.11.1.so   strcmp
> 6193  1.7682  cc1plus  htab_expand
> 6020  1.7188  cc1plus  check_changed_vars_0
> 5797  1.6552  cc1plus  htab_traverse_noresize
> 5615  1.6032  cc1plus  htab_find_with_hash
> 4757  1.3582  cc1plus  vt_expand_loc_callback
> 4529  1.2931  libginac-1.5.so.0.1.2GiNaC::basic::compare(GiNaC::basic 
> const&) const
> 4497  1.2840  libc-2.11.1.so   _int_malloc
> 3879  1.1075  as   /usr/bin/as
> 3703  1.0573  cc1plus  variable_htab_eq
> 3698  1.0559  cc1plus  insert_into_intersection
> 3287  0.9385  cc1plus  emit_note_insn_var_location

(it is regression at 4.5 branch, forgot to mention)

Honza
> 
> Honza

gcc-4.3-20100627 is now available

[gccadmin]

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/gcc-4_3-branch 
revision 161474

You'll find:

gcc-4.3-20100627.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20100627.tar.bz2 C front end and core compiler

gcc-ada-4.3-20100627.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20100627.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20100627.tar.bz2  C++ front end and runtime

gcc-java-4.3-20100627.tar.bz2 Java front end and runtime

gcc-objc-4.3-20100627.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20100627.tar.bz2The GCC testsuite

Diffs from 4.3-20100620 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Massive performance regression from switching to gcc 4.5

[Jan Hubicka]

> 
> (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 commutative expansion and substitution
size:   100 200 400 800
time/s: 0.080   0.361.6 7.4
and for 4.6
timing commutative expansion and substitution
size:   100 200 400 800
time/s: 0.076   0.371.7 8.2

I assume that the numbers are times in second, so it is indeed not good.  Can I
easilly run the individual tests by hand?  Do you have any idea what is going
wrong here?

Honza

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Martin Guy]

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.
>
>  I'd say a port with
>  zero known users should actually be removed.

FPA is very widely used. From day 0 until 2006 it was the only FP
model emulated by the Linux kernel and so in required by all operating
systems created up to that date.
  Actively-maintained software distributions and recent ports of Linux
tend to use a different ABI ("EABI") whose default FP model is
user-space softfloat and does not require FPA code generation
(thankfully!), however there are many exiting software distributions
in current use that only support emulated hard FPA instructions. 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.

 M

Re: Deprecating ARM FPA support

[Mark Mitchell]

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 are the chances that GCC 4.7 (the first release in which FPA
would actually be removed, and probably not released until about two
years from now) is actually useful on this system?  It's very unlikely
that GCC 4.7 will successfully compile the 2.6.16 kernel, or, I would
expect, a lot of userspace applications.

My feeling is that it makes sense to deprecate this now, which allows us
in the 4.7 cycle to decide whether or not to remove the functionality.
If we decide then that it's still needed, we can always keep it.  But,
if we don't deprecate it now, then our policy is that we can't remove it.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Patch pinging

[David Edelsohn]

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, is still using a bugzilla version that
> reached end-of-life more than 2 years ago.
>
> I didn't feel that was right to ask for volunteers again to do
> something, when there have been volunteers and they have been ignored.
> It is true that frustration does not justify an outburst, specially
> since I am not volunteering anymore.
>
> Your last two sentences are definitely right. I don't have anything
> else new to propose. It is a difficult situation. Good luck. Sorry for
> the noise.

Manuel,

As you mention, GCC is one of the most important Free Software
projects.  We rely on the infrastructure, like Bugzilla and
Subversion.  While we appreciate someone volunteering to upgrade the
infrastructure, that someone needs to be experienced and
knowledgeable.  It would not help the project to have a failed
conversion or partial conversion or a lack of future support.  The
current infrastructure may be old, but it works and the system
administrators are able to keep it running.

I do not know what happened in the past with your previous offer.  I
am sorry that you are unable to help now.  Not only do we need a
volunteer, but we need a volunteer with realistic goals that the
leaders of the project have confidence in and one who shows
perseverance.

Thanks, David

Re: Patch pinging

[NightStrike]

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 comparable and often superior to
>> the closed-source counterparts, is still using a bugzilla version that
>> reached end-of-life more than 2 years ago.
>>
>> I didn't feel that was right to ask for volunteers again to do
>> something, when there have been volunteers and they have been ignored.
>> It is true that frustration does not justify an outburst, specially
>> since I am not volunteering anymore.
>>
>> Your last two sentences are definitely right. I don't have anything
>> else new to propose. It is a difficult situation. Good luck. Sorry for
>> the noise.
>
> Manuel,
>
> As you mention, GCC is one of the most important Free Software
> projects.  We rely on the infrastructure, like Bugzilla and
> Subversion.  While we appreciate someone volunteering to upgrade the
> infrastructure, that someone needs to be experienced and
> knowledgeable.  It would not help the project to have a failed
> conversion or partial conversion or a lack of future support.  The
> current infrastructure may be old, but it works and the system
> administrators are able to keep it running.
>
> I do not know what happened in the past with your previous offer.  I
> am sorry that you are unable to help now.  Not only do we need a
> volunteer, but we need a volunteer with realistic goals that the
> leaders of the project have confidence in and one who shows
> perseverance.
>
> Thanks, David
>

Ian had confidence in me.  He also liked the proposal I set for how to
go about it.