Mark Mitchell <[EMAIL PROTECTED]> writes:
| Now that GCC 4.0 is out the door, I've spent some time looking at the
| status of the 3.4 branch. As stated previously, I'll be doing a 3.4.4
| release, and then turning the branch over to Gaby, to focus
| exclusively on 4.0/4.1.
I'm happy to help the
On Fri, Apr 29, 2005 at 08:54:00PM -0400, Ian Lance Taylor wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> > I think you need to talk to the binutils people. It should be possible
> > to make ar and ld more memory-efficient.
>
> And here I thought I had dug myself out of that swamp several yea
Joe Buck <[EMAIL PROTECTED]> writes:
> I think you need to talk to the binutils people. It should be possible
> to make ar and ld more memory-efficient.
And here I thought I had dug myself out of that swamp several years
ago. I once spent a month making the linker more memory efficient,
includi
Thanks for the sound advice. I am sure you are right,
2 Questions:
1. If I am ONLY interested in the compiler, and do NOT want to build
libraries, what would be the process ??
2. I looked at newlib, but wasn't sure of the process of including it as
a combined tree .. Which subdir should I move
Matt Thomas wrote:
I'd like to libjava be split into multiple shared libraries.
In C, we have libc, libm, libpthread, etc. In X11, there's X11, Xt, etc.
So why does java have everything in one shared library? Could
the swing stuff be moved to its own? Are there other logical
divisions?
Unlike ot
Snapshot gcc-3.4-20050429 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050429/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050429
You'll
Hi,
To see what kind of code GCC generates for FOR_EACH_EDGE, I wrote a
simple dummy function.
int
dummy (basic_block bb)
{
edge e;
edge_iterator ei;
FOR_EACH_EDGE (e, ei, bb->succs)
if (e->dest == NULL)
return 1;
return 0;
}
Vanilla mainline
The result is r
This is the beta release of binutils 2.16.90.0.2 for Linux, which is
based on binutils 2005 0429 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location
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 like to libjava be split into multiple
On Fri, 29 Apr 2005, Richard Henderson wrote:
For ld, at least, --no-keep-memory. Normally it makes things run
slower, but that may not actually be the case for libjava.
Another suggestion, even though my last one sank without trace :-)
There is a lot to read through to find out things like this,
On Fri, Apr 29, 2005 at 03:22:59PM -0700, 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.
For ld, at least, --no-keep-memory. Normally it makes things run
slower, but that may not actually be the case for libjava
On Fri, Apr 29, 2005 at 05:41:30PM -0400, Ian Lance Taylor wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > That's not the problem I have: the link is slow, but it's not the
> > dominant thing. Maybe it depends how much RAM you have? I have 1 Gbyte.
>
> Probably. I pay for my own machin
Andrew Haley <[EMAIL PROTECTED]> writes:
> That's not the problem I have: the link is slow, but it's not the
> dominant thing. Maybe it depends how much RAM you have? I have 1 Gbyte.
Probably. I pay for my own machines, and it's three years old, and I
have 256M.
Ian
On Apr 29, 2005, at 5:33 PM, Thorsten Glaser wrote:
Mark Mitchell dixit:
In general, GCC 3.4.3 is working for people
Does anyone have an idea where to look?
This is a bug in your config, you forgot to define NO_IMPLICIT_EXTERN_C.
-- Pinski
Joseph S. Myers wrote:
What's the position on closing 3.4 regression bugs which are fixed in 4.0
and where it doesn't seem worthwhile to attempt to backport a fix?
They should be closed as FIXED, with a note. It would be wrong to use
WONTFIX, since the bug is in fact FIXED in 4.0; it might make
What's the position on closing 3.4 regression bugs which are fixed in 4.0
and where it doesn't seem worthwhile to attempt to backport a fix? I'm
thinking in particular of issues relating to c-decl.c (1, 18799,
18935, 19694) since c-decl.c in 3.4 was part way through a rewrite and
that inte
Mark Mitchell dixit:
>In general, GCC 3.4.3 is working for people
I've been playing around a lot with the various 3.4.4 snapshots
lately, and got everything to work, except for libjava:
gmake[1]: Entering directory `/usr/obj/gcc/libjava'
/bin/ksh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CON
Joe Buck wrote:
On Wed, Apr 27, 2005 at 03:13:21PM -0700, Stan Shebs wrote:
No, there have been plenty of complaints, but the GCC mailing
lists have, shall we say, a "reputation", and a great many
users will not post to them, either for fear of being ridiculed,
or in the expection that they will no
Joe Buck wrote:
>>Thanks for your assessment of the problem: indeed, I can tell you for
>>sure that (b) it's true and, as reported by Kriang, the patches are
>>rather simple (but the details of this judgement are up to you, of
>>course). I'm not 100% sure about (a) but Michael can tell you better:
On Fri, Apr 29, 2005 at 10:12:46PM +0200, Paolo Carlini wrote:
> >> I know that, technically, we are not talking about regressions wrt
> >> 3.x, still, important packages that used to compile and, well,
> >> apparently at least, *work* well, now don't even compile (see
> >> c++/19403, c++/21235, ma
On Fri, Apr 29, 2005 at 04:10:57PM -0400, Jonathan Bastien-Filiatrault wrote:
>Me and Brian Richter are in the early development stage of the TI
> C54x DSP port of GCC. We have some technical/project management questions.
> I'll
> keep it short, so here it is:
>
> * How do we officially becom
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.
Incidentally, libtool does not com
Hi Mark,
>> I know that, technically, we are not talking about regressions wrt
>> 3.x, still, important packages that used to compile and, well,
>> apparently at least, *work* well, now don't even compile (see
>> c++/19403, c++/21235, many others linked from there). Would be a big
>> deal having m
Hello every one,
Me and Brian Richter are in the early development stage of the TI
C54x DSP port of GCC. We have some technical/project management questions. I'll
keep it short, so here it is:
* How do we officially become maintainers of this port ? We are presently in the
process of filling ou
Paolo Carlini wrote:
Hi Kriang and Mark,
[ friend PRs snipped ]
I know that, technically, we are not talking about regressions wrt 3.x, still, important packages that used to compile and, well, apparently at least, *work* well, now don't even compile (see c++/19403, c++/21235, many others linked fr
On Apr 29, 2005, at 3:40 PM, Paolo Carlini wrote:
Hi Kriang and Mark,
I know that, technically, we are not talking about regressions wrt
3.x, still, important packages that used to compile and, well,
apparently at least, *work* well, now don't even compile (see
c++/19403, c++/21235, many others
Hi Kriang and Mark,
as you know well, the most important linux distributions and software packages
are currently rebuilt with 4.0 and "weird" problems slowly surface. One of
those is the partial rework of friendship for 4_0, which misses these important
bits present in mainline:
2005-03-14 Kri
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-point functions.
Hans-Peter Nilsson wrote:
After synchronizing with Ian Lance Taylor on IRC, I'm in the
process of implementing the cc0 replacement machinery he
described here and found at
http://gcc.gnu.org/wiki/general%20backend%20cleanup> after
"Here is a possible approach in which macros are used in the MD
file
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > >> OK, I know nothing about libtool so this might not be possible, but
> > > >> IMO the easiest way of making a dramatic difference is to cease to
> > > >> compile every file twice, once with PIC and once without.
Now that GCC 4.0 is out the door, I've spent some time looking at the
status of the 3.4 branch. As stated previously, I'll be doing a 3.4.4
release, and then turning the branch over to Gaby, to focus
exclusively on 4.0/4.1.
The 3.4 branch is in pretty good shape, despite what Bugzilla might
lea
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.
>
> Incidentally, at least on my s
On Sun, Apr 24, 2005 at 07:35:43PM +0200, Andreas Jaeger wrote:
> I configure with:
>
> /cvs/gcc/configure --prefix=/opt/gcc/4.1-devel
> --enable-checking=misc,tree,gc,rtl,rtlflag,assert --enable-threads=posix
> --enable-clocale=gnu --enable-__cxa_atexit --enable-shared
> --enable-languages=c,
Andrew Haley <[EMAIL PROTECTED]> writes:
> > >> OK, I know nothing about libtool so this might not be possible, but
> > >> IMO the easiest way of making a dramatic difference is to cease to
> > >> compile every file twice, once with PIC and once without. There would
> > >> be a small performa
Hello,
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.
Specifically, the -funsafe-math-optimizations flag doesn't work
correctly on AMD64 because the default
Andreas Schwab writes:
> Ian Lance Taylor writes:
>
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> >> Ian Lance Taylor writes:
> >> >
> >> > And, yes, we clearly need to do something about the libjava build.
> >>
> >> OK, I know nothing about libtool so this might not be possible
On Thu, Apr 28, 2005 at 10:05:13PM -0700, Jason Thorpe 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 co
On Fri, Apr 29, 2005 at 12:05:03PM -0400, Ian Lance Taylor wrote:
> The way to help this process along is to report bugs at
> http://gcc.gnu.org/bugzilla.
>
> In particular, if you provide a set of preprocessed .i files,
> from, say, sys, libc, or libcrypto, whichever seems worst, and
> open a gc
Peter Barada wrote:
Unfortunately for some of the embedded targets(like the ColdFire V4e
work I'm doing), a bootstrap is impossible due to limited memory and
no usable mass-storage device on the hardware I have available, so
hopefully a successful crossbuild will suffice.
How about a successful cro
Jason Thorpe <[EMAIL PROTECTED]> writes:
> 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
Andreas Schwab <[EMAIL PROTECTED]> writes:
> > Try putting
> >
> > enable_shared=no
> >
> > in configure.ac somewhere before AC_PROG_LIBTOOL.
>
> I think you rather want AC_DISABLE_STATIC.
Even better. Thanks.
Ian
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
>> Ian Lance Taylor writes:
>> >
>> > And, yes, we clearly need to do something about the libjava build.
>>
>> OK, I know nothing about libtool so this might not be possible, but
>> IMO the easiest way of making a dramatic
Andrew Haley <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
> >
> > And, yes, we clearly need to do something about the libjava build.
>
> OK, I know nothing about libtool so this might not be possible, but
> IMO the easiest way of making a dramatic difference is to cease to
> compile
On Fri, Apr 29, 2005 at 12:49:37PM +0200, Lars Segerlund wrote:
> If we do a reasonable comparison of compile times against the intel compiler
> or
> the portland group or something similar we consistenly find that gcc is
> slower
> by a couple of times 1x - 3x, ( this is only my impression, n
Scott A Crosby writes:
> On Fri, 29 Apr 2005 10:43:57 +0100, Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > However, there is another major disparity here, in that on your box
> > jc1 uses much more cpu than bash. I don't know why that might be.
>
> I oprofiled a full bootstrap and you opr
On Fri, 29 Apr 2005 10:43:57 +0100, Andrew Haley <[EMAIL PROTECTED]> writes:
> Scott A Crosby writes:
> > On Thu, 28 Apr 2005 10:29:32 +0100, Andrew Haley <[EMAIL PROTECTED]>
> writes:
> >
> > > Having said that, I suspect that the single biggest improvement to the
> > > libgcj build time wo
Hello,
Some links are broken on this page:
http://gcc.gnu.org/install/specific.html
Specifically:
i?86-*-sco3.2v5*
i?86-*-solaris2.10
x86_64-*-*, amd64-*-*
all ELF targets
See also previous discussion on a similar issue:
http://gcc.gnu.org/ml/gcc/2005
Geoffrey Keating wrote:
> BIGGEST_ALIGNMENT is 128 for a number of reasons, but
> PREFERRED_STACK_BOUNDARY is 128 primarily so that code compiled with
> -meabi can also be used on Linux and other SVR4 targets, and for
> Altivec support.
I see. Both would deserve comments, IMHO.
Thanks for your
I think Zack summarises very well here, the general consensus is that gcc is
slow,
now if gcc was faster, it would perhaps not be so bad to build java ?
If we do a reasonable comparison of compile times against the intel compiler or
the portland group or something similar we consistenly find
On Thu, 28 Apr 2005, Richard Guenther wrote:
> Excess errors:
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.dg/c99-init-4.c:8:
> error: initializer element is not constant
So, in general you need to ensure that the new forms of trees are
TREE_CONSTANT and pass initializer_cons
On Fri, Apr 29, 2005 at 10:47:06AM +0100, Andrew Haley wrote:
> Ian Lance Taylor writes:
> >
> > And, yes, we clearly need to do something about the libjava build.
>
> OK, I know nothing about libtool so this might not be possible, but
> IMO the easiest way of making a dramatic difference is to
Hello,
> I cannot see how fold-const.c:try_move_mult_to_index ever
> successfully will do a transformation if the loop
>
> for (;; ref = TREE_OPERAND (ref, 0))
> {
> if (TREE_CODE (ref) == ARRAY_REF)
> {
> ...
> break;
> }
>
> if (!handled_component_p
Hi!
I cannot see how fold-const.c:try_move_mult_to_index ever
successfully will do a transformation if the loop
for (;; ref = TREE_OPERAND (ref, 0))
{
if (TREE_CODE (ref) == ARRAY_REF)
{
...
break;
}
if (!handled_component_p (ref))
return NULL_
Ian Lance Taylor writes:
>
> And, yes, we clearly need to do something about the libjava build.
OK, I know nothing about libtool so this might not be possible, but
IMO the easiest way of making a dramatic difference is to cease to
compile every file twice, once with PIC and once without. There
Scott A Crosby writes:
> On Thu, 28 Apr 2005 10:29:32 +0100, Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > -- and it wouldn't surprise me if the libjava build procedure were a
> > > major contributor there.
> >
> > Yes. This is a profile of the libgcj build. The single biggest user
>
srcdir/config.guess :
alphaev68-dec-osf5.1b
gcc -v :
Using built-in specs.
Target: alphaev68-dec-osf5.1b
Configured with: ../configure --enable-threads=posix --enable-languages=c,c++
--prefix=/Local
Thread model: posix
gcc version 4.0.0
OS:
Compaq Tru64 UNIX V5.1B (Rev. 2650); Wed Apr 27 21:14:5
56 matches
Mail list logo
