On Sat, Apr 30, 2005 at 10:33:43AM +0100, Andrew Haley wrote:
> OK, so the low-hanging fruit that remains is the libtools script and
> the linker. In the latter case, it seems that the big link causes
> severe problems with small memory systems.
I did some experiments today just to see what kind
On Apr 30, 2005, at 10:51 PM, Bill Northcott wrote:
Basically my logic is fairly simple. If I use Apple's OS, I feel
happier using their compiler. While that creates some problems, it
avoids others like the restFP,savFP issue.
The restFP/saveFP issue has been resolved since
2004-03-31 Andrew P
On 01/05/2005, at 1:11 AM, Andrew Pinski wrote:
Even if the libraries build, will libffi or libobjc work on 64 bit
PPC Since I don't have access to a 64 bit PPC machine I cannot
test this.
There was some talk about this earlier this year and then the support
for building the 64bit libraries on
On Apr 30, 2005, at 12:33 PM, Giovanni Bajo wrote:
I would also like to note that I *myself* requested preprocessed
source code to
NetBSD developers at least 6 times in the past 2 years. I am sure
Andrew Pinski
did too, a comparable amound of times. These requests, as far as I can
understand, w
Snapshot gcc-4.0-20050430 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050430/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050430
You'll
Vladimir A. Merzliakov wrote:
> At FreeBSD 5.3 this testcase failed with gcc version 4.1.0 20050429
> (extracted log attached)
Ah! Thanks a lot Vladimir: now it's also obvious why I'm not seeing it:
often, while working hard on the library, I don't update the compiler
proper every day.
I'm not s
it looks like in mainline this test recently started failing at compile
time on some machines. I'm puzzled, unfortunately cannot reproduce the
problem and would be grateful is someone could send me (either privately
or in public) more information (e.g., an extract from libstdc++.log, at
least)
Hi,
it looks like in mainline this test recently started failing at compile time on
some machines. I'm puzzled, unfortunately cannot reproduce the problem and
would be grateful is someone could send me (either privately or in public) more
information (e.g., an extract from libstdc++.log, at le
On 30 Apr 2005, Giovanni Bajo uttered the following:
> There is no outcome, because it is just the Nth legend. Like people say "I
> believe GCC is slow because of pointer indirection" or stuff like that.
Don't we have actual *evidence* that it's slow because of cache
thrashing?
--
`End users are
Hi,
The prerelease tarballs for GCC-3.3.6 are avaliable at
ftp://gcc.gnu.org/pub/gcc/prerelease-3.3.6-20050430/
for testing. Please download test, and fill bugzilla PRs (putting
me in the CC: field).
This branch has been stable for long time. GCC-3.3.6 will be the
last of the 3.3.x
_bfd_strip_section_from_output is known to be very slow:
http://sourceware.org/ml/binutils/2005-03/msg00826.html
It scans every section in all input files to find a match. We do
have link_order_head/link_order_tail. But they aren't available
when _bfd_strip_section_from_output is called. Can we b
The default BFD hash table size is too small for ELF section merge.
This patch speeds up sec_merge_hash_lookup by 50% in average.
H.J.
---
2005-04-30 H.J. Lu <[EMAIL PROTECTED]>
* hash.c (hash_size_primes): Add 65537.
* merge.c (sec_merge_init): Call bfd_hash_set_default_size
We are calling _bfd_elf_get_sec_type_attr on sections from input files.
It is not necessary at all. This patch should speed up AR for ELF.
H.J.
---
2005-04-30 H.J. Lu <[EMAIL PROTECTED]>
* elf.c (_bfd_elf_new_section_hook): Don't call
_bfd_elf_get_sec_type_attr on sections from
Ian Lance Taylor wrote:
>> Except it's not just bootstrapping GCC. It's everything. When the
>> NetBSD Project switched from 2.95.3 to 3.3, we had a noticeably
>> increase in time to do the "daily" builds because the 3.3 compiler
>> was so much slower at compiling the same OS source code. And
> I configured/made/installed gcc 4.0.0 partially on a Solaris host. I
> could not build with C++ support, because ld (GNU ld, that is) choked
> (dumped core, signal 11, segmentation violation) on abi_check (see
> below).
> When using the Sun-supplied as and ld, ld chokes on alignment errors
> dur
Richard Earnshaw <[EMAIL PROTECTED]> wrote:
>> The GCC build times are not unreasonable compared to other,
>> commercial compilers with similar functionality. And the GCC
>> developers
>> ave plans to address inefficiencies -- GCC 4.0 often is faster than
>> GCC
>> 3.4.
>
> If you are going to ma
Jason Thorpe <[EMAIL PROTECTED]> wrote:
>> Maybe the older platform should stick to the older compiler then,
>> if it is too slow to support the kind of compiler that modern
>> systems need.
>
> This is an unreasonable request. Consider NetBSD, which runs on new
> and old hardware. The OS contin
Lars Segerlund <[EMAIL PROTECTED]> wrote:
> I have to agree with Richard's assessment, gcc is currently on the
> verge of being unusable in many instances.
> If you have a lot of software to build and have to do complete
> rebuilds it's painful, the binutils guys have a 3x speedup patch
> com
> 1) Using Sun's as/ld. I build gcc this way:
> cd /tmp
> gtar xjf ~/gcc-4.0.0.tar.bz2
> mkdir gcc
> cd gcc
> setenv CONFIG_SHELL /bin/ksh
> /tmp/gcc-4.0.0/configure \
> --prefix=/usr/local/gcc-4.0.0
> gmake bootstrap
>
> The build fails with
On 30 Apr 2005, Gabriel Dos Reis wrote:
> There were 36 PRs open against it (as of this morning, 6am, GMT-05).
> I wnet through all of them and the appeared to be very minor or
> impossible bugs to fix in 3.3.6 major restructuring (typically, they
> were bugs fixed in 3.4.x or 4.0.x). Two of them
Hi,
GCC-3.3.6 appears in pretty good shape.
There were 36 PRs open against it (as of this morning, 6am, GMT-05).
I wnet through all of them and the appeared to be very minor or
impossible bugs to fix in 3.3.6 major restructuring (typically, they
were bugs fixed in 3.4.x or 4.0.x). Two of th
On Fri, 29 Apr 2005, Scott Robert Ladd wrote:
> I've been down (due to illness) for a couple of months, so I don't know
> if folk here are aware of something I discovered about GCC 4.0 on AMD64:
> -ffast-math is "broken" on AMD64/x86_64.
Hi Scott,
I was wondering if you could do some investigati
On Apr 30, 2005, at 9:46 AM, Andreas Schwab wrote:
Bill Northcott <[EMAIL PROTECTED]> writes:
Even if the libraries build, will libffi or libobjc work on 64 bit
PPC Since I don't have access to a 64 bit PPC machine I cannot
test this.
They appear to work fine on powerpc64-linux.
He is talking
Bill Northcott <[EMAIL PROTECTED]> writes:
> Even if the libraries build, will libffi or libobjc work on 64 bit
> PPC Since I don't have access to a 64 bit PPC machine I cannot
> test this.
They appear to work fine on powerpc64-linux.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROT
Joe Buck wrote:
>I don't quite understand your answer. It seems that (a) is the important
>issue; if the programs are valid, they compiled before, and they worked
>before, then it seems there really is a regression, even if we can argue
>that we were "right by accident" in the past.
>
This is a
Andrew Pinski dixit:
>> Does anyone have an idea where to look?
>
> This is a bug in your config, you forgot to define NO_IMPLICIT_EXTERN_C.
Thanks a lot, I will try that after I updated to 20050429.
bye,
//mirabile
For what are probably misguided reasons I am trying to build Apple
style compilers which include gfortran, libffi and libobjc.
This was not a particular problem with the latest apple-ppc-branch
sources (apple-ppc-5013) until I got MacOS X 10.4 Tiger yesterday.
On Darwin8/MacOS X 10.4 the Appl
On 4/29/05, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello Scott!
Hello Scott & Uros,
> > Specifically, the -funsafe-math-optimizations flag doesn't work
> > correctly on AMD64 because the default on that platform is
> > -mfpmath=sse. Without specifying -mfpmath=387,
> > -funsafe-math-optimizatio
Uros Bizjak wrote:
Hello Scott!
Specifically, the -funsafe-math-optimizations flag doesn't work
correctly on AMD64 because the default on that platform is
-mfpmath=sse. Without specifying -mfpmath=387,
-funsafe-math-optimizations does not generate inline processor
instructions for most floating
Matt Thomas writes:
> Joe Buck wrote:
> > I think you need to talk to the binutils people. It should be possible
> > to make ar and ld more memory-efficient.
>
> Even though systems maybe demand paged, having super large
> libraries that consume lots of address space can be a problem.
>
Richard Henderson writes:
> On Fri, Apr 29, 2005 at 01:30:13PM -0400, Ian Lance Taylor wrote:
> > I don't know of a way to tell libtool to not do duplicate compiles.
> > You can use -prefer-pic, but at least from looking at the script it
> > will still compile twice, albeit with -fPIC both time
31 matches
Mail list logo
