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 times.
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.
I'd
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-optimizations does not
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
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
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
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
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
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 investigating
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
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
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 the
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 continues to
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 make sweeping
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
during
Ian Lance Taylor ian@airs.com 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.
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
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
_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
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
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,
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
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
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
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 find
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,
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 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
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 of
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-30
06:54 ---
Subject: Bug 21286
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-30 06:54:08
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk
2005-04-30 07:37 ---
I may have a discovered a related bug with a large program using
STL (hash_set). I've tried to simplify somewhat, and I have some
comments arising from some hacking with gdb (ddd). As a previous
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-04-30 07:54 ---
Subject: Re: [PR tree-optimization/21029, RFC] harmful chrec type conversions
Hello,
Alexandre Oliva wrote:
This is not a final patch; if the idea is considered sound, I'd
--- Additional Comments From uros at kss-loka dot si 2005-04-30 07:59
---
I think that the best way to fix problems with missing floorf(), floorl(),
ceilf() and ceill() builtins is to completely disable all (int)floor() and
(int)ceil() optimizations for !TARGET_C99_FUNCTIONS.
I'll make
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286
When building gcc, it is not clear in the documentation (at least to me) how to
configure the C++ standard library so that it accepts locales other than C and
POSIX. The versions before g++-3.4 did accept them by default, but it is not the
case for g++-3.4 and gcc-4 apparently.
--
--- Additional Comments From uros at kss-loka dot si 2005-04-30 08:25
---
Could this be related to PR19398: secondary reloads don't consider m
alternatives?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-04-30 09:08 ---
Oops, I reduced the code in comment #1 too much. This shows the problem.
//dllimport_array.C
// This causes 'initializer element is not constant' error in C,
//
--- Additional Comments From pluto at pld-linux dot org 2005-04-30 09:35
---
(In reply to comment #5)
(In reply to comment #3)
I can't build the Objective Caml compiler with this gcc error :/
(...)
Also using -fomit-frame-pointer works around the problem by adding
another
-Wall warns about most statements with no effect. However, it doesn't warn
about
volatile int v;
void foo(void)
{
v;
}
--
Summary: Missed warning
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:03
---
No maintainer is interested in fixing this.
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:08
---
will not fix in 3.3.x
--
What|Removed |Added
Target Milestone|3.3.6
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:09
---
-
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:10
---
Not critical.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:12
---
work for 3.4.x, won't fix in 3.3.x
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:13
---
As per target maintainer comments.
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:15
---
Won't fix for 3.3.6. Suggest upgrade to 3.4.x
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:16
---
Not critical for 3.3.6
--
What|Removed |Added
Target Milestone|3.3.6
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:18
---
Not critical for 3.3.6
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:19
---
won't fix for 3.3.6. Fixed in 3.4.x
--
What|Removed |Added
Target Milestone|3.3.6
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:23
---
fixed on 3.4.x
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:25
---
not critical for 3.3.6
--
What|Removed |Added
Resolution|WORKSFORME
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:26
---
fixed for 3.4.x
--
What|Removed |Added
Status|ASSIGNED
--
Bug 18327 depends on bug 18384, which changed state.
Bug 18384 Summary: [3.3 Regression] ICE on zero-length array with empty
initializer...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
What|Old Value |New Value
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:30
---
Not critical. Fixed in 3.4.x
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:34
---
Won't fix for 3.3.6
--
What|Removed |Added
Status|WAITING
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:37
---
As per comment #10, there is no proposed patch for 3.3.6. Closing as
won't fix..
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:40
---
won't fix for 3.3.6. Works for 3.4.0 and higher
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:40
---
won't fix for 3.3.6. Works in 3.4.0 and higher.
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:44
---
Chnages to fix this bug would happen in the middle=end which is risky at
this point. Therefore it won't be fixed for 3.3.6. It fixed in 3.4.0 though.
--
What|Removed
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:46
---
removing target milestone
--
What|Removed |Added
Target Milestone|3.3.6
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:47
---
won't fix for 3.3.6. Works in 3.4.0 and higher
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:48
---
Access control has been reworked on 3.4.x and is known to be bogus in several
respect in 3.3.x and previous. Won't fix in 3.3.6. Suggest upgrade to 3.4.x
or higher.
--
What|Removed
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:51
---
won't fix for 3.3.6. The root of the bug has been cured in 3.4.x with
the new parser.
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:51
---
Not critical for 3.3.6. Fixed in 3.4.0 and higher.
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:53
---
won't fix for 3.3.5. Fixed in 3.4.x
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:54
---
As per comment #6
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:55
---
Not ciritcal for 3.3.6. Fixed in 3.4.1
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 13:57
---
won't fix in 3.3.6. Works with 3.4.0 and higher.
--
What|Removed |Added
Status|NEW
--- Additional Comments From ralfixx at gmx dot de 2005-04-30 14:16 ---
Paolo Carlini wrote:
I'd like to know your opinion, as a user: are you
noticing worthwhile performance improvements?
Would you consider very annoying trying to read again
(calling clear()), when pipes are used?
--- Additional Comments From berndtrog at yahoo dot com 2005-04-30 14:29
---
Arnaud Charlet wrote:
Should be fixed now.
Can you please describe how you tested the patch?
I still get the errors in 4_0-branch and head!
Why does the '--disable-libada' switch disable gnattools-cross?
--
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:31
---
(In reply to comment #12)
Fixed also in 3.4.3, Gaby is this okay to apply to the 3.3 branch when it
opens up again?
This patch does not seem to apply cleanly to 3.3.6 which as a different logic.
will close as
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:32
---
closing as fixed for 3.4.x
--
What|Removed |Added
Target Milestone|3.4.0
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:36
---
Patch does not apply to 3.3.6 source. closing as fixed in 3.4.x
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:38
---
fixed in 3.4.0. won't fix for 3.3.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14766
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:41
---
access control is known broken in 3.3.x and previous.
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:42
---
won't fix for 3.3.6. Works in 3.4.0 and higher.
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:46
---
fixed in 3.4.4. Won't fix for 3.3.6
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:47
---
won't fix for 3.3.6. Works in 3.4.4 and higher.
--
What|Removed |Added
Status|NEW
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 14:48
---
won't fix in 3.3.6. Known workaround.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
14:56 ---
What option are you taking about?
The standard way of changing the locale is either by the LC_*/LANG environment
variable or using the
locale class.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
15:02 ---
Hmm, this is only a regression with 3.3, there might be another bug related to
this then.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
15:08 ---
Fixed so closing as such.
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Target Milestone|3.3.3 |3.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21296
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
15:15 ---
Fixed in 3.4.0 and above, This is only a diagnostic problem which is why I am
closing it.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
15:35 ---
I think this is a dup of bug 21081.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From ncm-nospam at cantrip dot org 2005-04-30
15:48 ---
A note for Ralf: It is incorrect to use cin.eof() to watch for the end
of a stream. The correct flag to check is fail(). eof() is really
meant for seeing if that's why op failed.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
15:54 ---
Fixed in 4.0.0 and above.
--
What|Removed |Added
Status|NEW
gcc 4.0.0 optimization seems to have a problem.
In the f function in following source, buf[i+i] = '\0' stores '\0' to buf[2].
But it should store to buf[4].
% cat t.c
extern int printf (__const char *__restrict __format, ...);
void
f(char *buf)
{
int i;
for (i = 0; i 2; i++) ;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
16:00 ---
This is another expand issue:
;; *((char *) (unsigned int) (i + i) + buf) = 0
(insn 27 25 0 (set (mem:QI (plus:SI (mult:SI (reg/v:SI 60 [ i ])
(const_int 1 [0x1]))
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-30
16:01 ---
Subject: Bug 18004
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2005-04-30 16:01:38
Modified files:
gcc:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
16:03 ---
Hmm, maybe this should be closed as will not fix as the new verify fixes almost
if not all the problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15735
--
What|Removed |Added
CC||lerdsuwa at gcc dot gnu dot
||org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
16:12 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
16:12 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 16:19
---
Patch applied to 3.3.6.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
16:20 ---
*** This bug has been marked as a duplicate of 16104 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-30
16:20 ---
*** Bug 18238 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 16:31
---
Fixed in 3.4.x. Thr formating machinery is different in 3.3.6 and
this is not critical for 3.3.6. So closing.
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-04-30 16:33
---
Fixed in 3.4.3. Won't fix for 3.3.6.
--
What|Removed |Added
Target Milestone|3.4.4
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-30
17:10 ---
Fixing.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou
1 - 100 of 210 matches
Mail list logo
