Zack Weinberg dixit:
>This could be made substantially easier if libgcc moved to the top
>level. You wanna help out with that?
What about crtstuff?
//mirabile
Some time ago, someone posted a patch which provided beginnings of a
general-purpose Ada test suite infrastructure (in addition to the
current ACATS tests, which cannot be used for regression tests). The
patch was not integrated, and I can't find it at the moment. 8-(
Does anybody know which patc
On Wed, 27 Apr 2005, Daniel Berlin wrote:
> If you want a faster compiler, it's hard work. It means not adding
> features because the design isn't a good one, *even if the user would
> still find it useful*. People aren't willing to do this. It means lots
> and lots of profiling, and taking care
> Some time ago, someone posted a patch which provided beginnings of a
> general-purpose Ada test suite infrastructure (in addition to the
> current ACATS tests, which cannot be used for regression tests). The
Note that this is technically incorrect: the ACATS infrastructure can
be used for regre
Paul Koning writes:
> > "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> >> However, I can always tell when a GCC build has hit the libjava
> >> build -- that's when the *whole system* suddenly slows to a crawl.
> >> Maybe it comes from doing some processing on 5000 foo.o file
Original Message
>From: Marcin Dalecki
>Sent: 28 April 2005 02:58
> On 2005-04-27, at 22:54, Karel Gardas wrote:
>>
>> Total Physical Source Lines of Code (SLOC)= 2,456,727
>> Development Effort Estimate, Person-Years (Person-Months) = 725.95
>> (8,711.36) (Basic COCOMO m
* Arnaud Charlet:
>> Some time ago, someone posted a patch which provided beginnings of a
>> general-purpose Ada test suite infrastructure (in addition to the
>> current ACATS tests, which cannot be used for regression tests). The
>
> Note that this is technically incorrect: the ACATS infrastruct
> I thought that there were some reservations about changing the ACATS
> test suite.
I do not remember anything like that. Also, we're not talking about changing
the ACATS test suite, but rather expanding it.
> So how we can make sure that this work is not lost? Who would be in a
> position to a
On 2005-04-28, at 12:03, Dave Korn wrote:
Original Message
From: Marcin Dalecki
Sent: 28 April 2005 02:58
On 2005-04-27, at 22:54, Karel Gardas wrote:
Total Physical Source Lines of Code (SLOC)= 2,456,727
Development Effort Estimate, Person-Years (Person-Months) = 725.95
(
On Thu, 2005-04-28 at 09:45 +0200, Florian Weimer wrote:
> Some time ago, someone posted a patch which provided beginnings of a
> general-purpose Ada test suite infrastructure (in addition to the
> current ACATS tests, which cannot be used for regression tests). The
> patch was not integrated, and
Hi all,
I have some preleminary benchmark results comparing 3.4(.3) with 4.0.0,
including some optimization option permuations.
http://exactcode.de/rene/hidden/gcc-article/2005-gcc-4.0/stat2-rt.png
http://exactcode.de/rene/hidden/gcc-article/2005-gcc-4.0/stat2-bt.png
rt = runtime
bt = buildti
On Wed, 2005-04-27 at 20:57, Steven Bosscher wrote:
> On Wednesday 27 April 2005 17:45, Matt Thomas wrote:
> > > The features under discussion are new, they didn't exist before.
> >
> > And because they never existed before, their cost for older platforms
> > may not have been correctly assessed.
>
On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote:
> > However, I can always tell when a GCC build has hit the libjava build
> > -- that's when the *whole system* suddenly slows to a crawl. Maybe
> > it comes from doing some processing on 5000 foo.o files all at
> > once... :-(
>
> But that is not
On Thu, Apr 28, 2005 at 07:31:06AM +, Thorsten Glaser wrote:
> Zack Weinberg dixit:
>
> >This could be made substantially easier if libgcc moved to the top
> >level. You wanna help out with that?
>
> What about crtstuff?
Yes, they should be moved at the same time; I consider them closer to
On Thu, 2005-04-28 at 02:40, Tom Tromey wrote:
> > "Paul" == Paul Koning <[EMAIL PROTECTED]> writes:
>
> Paul> Maybe. Then again, maybe there are real problems here. The ranlib
> Paul> one was already mentioned. And I wonder if libjava really needs to
> Paul> bring the host to its knees, as
Richard Earnshaw writes:
> On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote:
> > > However, I can always tell when a GCC build has hit the libjava build
> > > -- that's when the *whole system* suddenly slows to a crawl. Maybe
> > > it comes from doing some processing on 5000 foo.o files all at
On Thu, 2005-04-28 at 14:35, Andrew Haley wrote:
> Richard Earnshaw writes:
> > On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote:
> > > > However, I can always tell when a GCC build has hit the libjava build
> > > > -- that's when the *whole system* suddenly slows to a crawl. Maybe
> > > > it
Andrew Haley <[EMAIL PROTECTED]> writes:
> If ld can't accept a list of files from a stream but is instead
> limited by command line length, then that *is* the fault of ld.
You can always use a linker script.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Ma
James E Wilson wrote:
Amir Fuhrmann wrote:
../gcc-3.4.3/configure --exec-prefix=/usr/local --program-prefix=ppc-
--with-stabs -with-cpu=603 --target=powerpc-eabi --with-gnu-as=ppc-as
--with-gnu-ld=ppc-ld --enable-languages=c,c++
The suggestion to look at Dan Kegel's crosstool is a good one, but
A testcase to trigger the assert was:
typedef _Bool Tal16bool __attribute__ ((aligned (16)));
struct S49
{
Tal16bool a:1;
};
and it turns out that the underlying problem is actually in the
general-purpose
field layout code. Both known_align and actual_align are calculated as
BIGGEST_ALIGNMENT if
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 coming up, but every time there is a
speedup
it gets
This is sort of the "final" state I ended up trying to teach
the C frontend not to emit array-to-pointer decay as
ADDR_EXPR (element-type*, array)
but as
ADDR_EXPR (element-type*, ARRAY_REF (element-type, array, 0))
for both type correctness and for possible simplifications of
fold and the tre
On Wed, Apr 27, 2005 at 08:05:39AM -0700, Matt Thomas wrote:
> Am I the only person who has attempted to do a native bootstrap on a
> system as slow as a M68k?
I am using an Amiga with [EMAIL PROTECTED] myself. My last GCC bootstrap on
that machine was done in 1999 for GCC 2.95.2 and it took s
Peter Barada wrote:
Well, yes. 1 second/file is still slow! I want "make" to complete
instantaneously! Don't you?
Actually I want it to complete before I even start, but I don't want
to get too greedy. :)
What's really sad is that for cross-compilation of the toolchain, we
have to repeat a few
On Wed, Apr 27, 2005 at 04:40:29PM -0700, Zack Weinberg wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote:
> >> Steven Bosscher wrote:
> >> >If someone had cared about them, it would have been noticed
> >> >earlier. But since _nobody_ has
>> What's really sad is that for cross-compilation of the toolchain, we
>> have to repeat a few steps (build gcc twice, build glibc twice)
>> because glibc and gcc assume that a near-complete environment is
>> available(such as gcc needing headers, and glibc needing -lgcc-eh), so
>> even really fa
Andreas Schwab writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > If ld can't accept a list of files from a stream but is instead
> > limited by command line length, then that *is* the fault of ld.
>
> You can always use a linker script.
Yeah, good point. libtool seems to go to extr
> Andrew Haley writes:
Andrew> Yeah, good point. libtool seems to go to extraordinary lengths to
Andrew> avoid doing so, I presume because it isn't portable.
Current libtool does allow a list of files, but the version used
by GCC is not recent.
David
On Thu, 2005-04-28 at 11:58 -0400, Peter Barada wrote:
> This is for a m68k-linux build (with coldfire-linux config for glibc),
> and its only the C compiler, so adding C++ will obvioulsy make it take
> longer.
>
> >A 2.4 Ghz P4 isn't what I would consider an obsolete machine and it took
> >90 m
On 2005-04-27 14:30:01 -0700, Mike Stump wrote:
> On Apr 27, 2005, at 5:15 AM, Neil Booth wrote:
> >Even better, you can turn of the warning with a cast, making your
> >intent explicit to the compiler, so there's every reason to have
> >it on by default.
>
> And, if you don't like casts, you can (
Output from running srcdir/config.guess:
powerpc-ibm-aix5.2.0.0
I have not installed this version of gcc yet so here is the output from xgcc in
objdir/gcc/xgcc -v:
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local --enable-threads=ai
On Wed, 2005-04-27 at 16:40 -0700, Zack Weinberg wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote:
> >> Steven Bosscher wrote:
> >> >If someone had cared about them, it would have been noticed
> >> >earlier. But since _nobody_ has compla
On Thu, 28 Apr 2005, Richard Guenther wrote:
> The patch was bootstrapped and tested on i686-pc-linux-gnu for
> the C language with the only remaining regression being c99-init-4.c
> (I didn't manage to find the place to fix).
You don't say how it regresses. What diagnostic is it generating, wha
Andrew Haley <[EMAIL PROTECTED]> writes:
> If ld can't accept a list of files from a stream but is instead
> limited by command line length, then that *is* the fault of ld.
GNU ld won't currently read a list of files from stdin, but it will
read a list of files from a file.
For example, look at
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > If ld can't accept a list of files from a stream but is instead
> > limited by command line length, then that *is* the fault of ld.
>
> GNU ld won't currently read a list of files from stdin, but it will
> read a lis
> Martin Koegler wrote:
> I have redone the implementation of the eeprom attribute in my prototype.
> It is now a cleaner solution, but requires larger changes in the core,
> but the changes in the core should not affect any backend/frontend, if
> it does not uses them (except a missing case in tre
Hi,
PR21173 and its duplicates are a class of wrong-code and ICE bugs
in GCC 4.0.0.
In Bugzilla, PR21173 now has 3 duplicates, and there was another
example on this mailing list. That makes 5 users who have already
run into this rather serious bug. That is a lot, for a compiler
that has only just
On Wed, Apr 27, 2005 at 07:40:37PM -0600, Tom Tromey wrote:
> > "Paul" == Paul Koning <[EMAIL PROTECTED]> writes:
>
> Paul> Maybe. Then again, maybe there are real problems here. The ranlib
> Paul> one was already mentioned. And I wonder if libjava really needs to
> Paul> bring the host to
On Thu, Apr 28, 2005 at 12:09:35PM -0400, David Edelsohn wrote:
> > Andrew Haley writes:
>
> Andrew> Yeah, good point. libtool seems to go to extraordinary lengths to
> Andrew> avoid doing so, I presume because it isn't portable.
>
> Current libtool does allow a list of files, but the
Definitely helps!! but into the next problem, again, any help would be
appreciated.
Amir
Configuring in powerpc-eabi/libiberty
configure: creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo
checking for perl.
> Andrew Haley writes:
Andrew> Yes thanks, I've had that pointed out to me. Apparently the real
Andrew> issue here is that we have an older version of libtool in the gcc
Andrew> tree.
Any feature in libtool CVS is fair game to be backported to
libtool in GCC. I am planning to backpo
> Joe Buck writes:
Joe> Is there a reason why we aren't using a recent libtool?
Porting and testing effort to upgrade.
David
On Thu, Apr 28, 2005 at 06:45:10PM +0200, Steven Bosscher wrote:
> Hi,
>
> PR21173 and its duplicates are a class of wrong-code and ICE bugs
> in GCC 4.0.0.
>
> In Bugzilla, PR21173 now has 3 duplicates, and there was another
> example on this mailing list. That makes 5 users who have already
> r
Joe Buck writes:
> On Wed, Apr 27, 2005 at 07:40:37PM -0600, Tom Tromey wrote:
> > > "Paul" == Paul Koning <[EMAIL PROTECTED]> writes:
> >
> > Paul> Maybe. Then again, maybe there are real problems here. The ranlib
> > Paul> one was already mentioned. And I wonder if libjava really nee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I only build with --enable-languages=c,c++ - I can try a full build if
you want. Also I couldn't run the testsuite because of missing testtools.
Christian
- -
make bootstrap successful build info:
$ gcc-4.0.0/conf
On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote:
> > Martin Koegler wrote:
> > I have redone the implementation of the eeprom attribute in my prototype.
> > It is now a cleaner solution, but requires larger changes in the core,
> > but the changes in the core should not affect any backe
On 2005-04-28, at 16:26, Lars Segerlund wrote:
I have never done any 'memory profiling' but I think it might be time
to give it a
shot, does anybody have any hints on how to go about something like
this ?
The main performance problem for GCC as I see it is structural. GCC is
emulating
the conc
On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
yesterday.
2. Building XLC with (C,C++,Fortran) and a single backend takes
roughly
the same time as building GCC. And they aren't three staging, AFAIK.
"..ain't the same ballpark, it
t002.x has this code:
typedef unsigned short int Tal16ushort __attribute__ ((aligned (16)));
struct S460
{
unsigned long int __attribute__ ((packed)) a;
Tal16ushort __attribute__ ((aligned)) b:13) - 1) & 15) + 1);
unsigned short int c;
};
BIGGEST_ALIGNMENT is 64 for sh64-elf.
Does the ((align
On Apr 28, 2005 06:55 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 28, 2005 at 06:45:10PM +0200, Steven Bosscher wrote:
> > Hi,
> >
> > PR21173 and its duplicates are a class of wrong-code and ICE bugs
> > in GCC 4.0.0.
> >
> > In Bugzilla, PR21173 now has 3 duplicates, and there was an
On Thu, Apr 28, 2005 at 01:05:29PM +0200, Laurent GUERBY wrote:
> On Thu, 2005-04-28 at 09:45 +0200, Florian Weimer wrote:
> > Some time ago, someone posted a patch which provided beginnings of a
> > general-purpose Ada test suite infrastructure (in addition to the
> > current ACATS tests, which ca
On Wed, 27 Apr 2005 16:52:25 -0400, Paul Koning <[EMAIL PROTECTED]> said:
> However, I can always tell when a GCC build has hit the libjava build
> -- that's when the *whole system* suddenly slows to a crawl. Maybe
> it comes from doing some processing on 5000 foo.o files all at
> once... :-(
It
On Thu, 2005-04-28 at 19:31 +0200, Steven Bosscher wrote:
> On Apr 28, 2005 06:55 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Apr 28, 2005 at 06:45:10PM +0200, Steven Bosscher wrote:
> > > Hi,
> > >
> > > PR21173 and its duplicates are a class of wrong-code and ICE bugs
> > > in GCC 4.0
On Thu, Apr 28, 2005 at 07:31:32PM +0200, Steven Bosscher wrote:
> Yeah, but in this case the patch that introduced the bug was one of
> the last to go in before the release (it was the fix for PRs 20490
> and 20929, the patch for that went in on April 17). So it was more
> an unfortunate fix than
On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
> On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
>
> > 1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
> > yesterday.
> > 2. Building XLC with (C,C++,Fortran) and a single backend takes
> > roughly
> > the same time as buil
>Not that I'm really complaining: you can get quite a lot of mileage
>out of multiple CPUs as it is, more than enough (in my opinion) to
>justify purchasing some nice build servers by software shops that do a
>lot of GCC work. (I won't post the actual bootstrap times out of fear
>of being lynched
Someone complained I was unfair in my gcc bootstrap times since
some builds included libjava/gfortran and some did not.
So in the past day, I've done bootstrap with just c,c++,objc on
both 3.4 and gcc4.1. I've put the results in a web page at
http://3am-software.com/gcc-speed.html. The initial
On Apr 28, 2005, at 10:54 AM, Daniel Berlin wrote:
On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
yesterday.
2. Building XLC with (C,C++,Fortran) and a single backend takes
rough
On Thu, Apr 28, 2005 at 11:03:51AM -0700, Matt Thomas wrote:
>
> Someone complained I was unfair in my gcc bootstrap times since
> some builds included libjava/gfortran and some did not.
>
> So in the past day, I've done bootstrap with just c,c++,objc on
> both 3.4 and gcc4.1. I've put the resul
Matt Thomas <[EMAIL PROTECTED]> writes:
> When I see the native stage2 m68k compiler spend 30+ minutes compute bound
> with no paging activity compiling a single source file, I believe
> that is an accurate term. Compiling stage3 on a 50MHz 68060 took 18 hours.
> (That 30 minutes was for fold-con
On Thu, 2005-04-28 at 11:08 -0700, Devang Patel wrote:
> On Apr 28, 2005, at 10:54 AM, Daniel Berlin wrote:
>
> > On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
> >> On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
> >>
> >>> 1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
> Matt Thomas writes:
Matt> So in the past day, I've done bootstrap with just c,c++,objc on
Matt> both 3.4 and gcc4.1.
Matt> While taking out fortran and java reduced the disparity, there
Matt> is still a large increase in bootstrap times from 3.4 to 4.1.
libstdc++ contains a lot more
Note:
- I builded GMP 4.1.4 with MPFR 4.1 myself.
- I switched to GNU make and actualized some other tools as avalable
(http://gcc.gnu.org/install/prerequisites.html).
- Building fails if standard tools from Mac OS 10.3.9 are used! The
prerequisits changed!
- Other languages will come later.
/us
On Thu, 28 Apr 2005, Ian Lance Taylor wrote:
If you can include the preprocessed file and profiler output from cc1
running on your system, there is a chance that this can be addressed.
GCC comes with a test suite and a means for submitting results. May
I suggest that it might be useful to have a t
On Thu, 2005-04-28 at 10:39 -0700, Janis Johnson wrote:
> I'll look at the DejaGnu aspects of the patch and comment on them, but
> someone involved with Ada should maintain it.
Sounds fair, but then don't hesitate to add comments in the patch
so dejagnu illiterates don't feel lost :).
Thanks for
Joseph S. Myers wrote:
> On Thu, 28 Apr 2005, Richard Guenther wrote:
>
>
>>The patch was bootstrapped and tested on i686-pc-linux-gnu for
>>the C language with the only remaining regression being c99-init-4.c
>>(I didn't manage to find the place to fix).
>
>
> You don't say how it regresses.
Hello,
I would like just to know if string class of libstdc++ support UTF8 and
if not, is it possible to convert string to utf8 ?
Thanks a lot.
Regards,
Laurielle LEA
--
Laurielle LEA
Savoir-faire Linux inc.
http://www.savoirfairelinux.com
On Apr 28, 2005, at 3:08 PM, Laurielle Lea wrote:
Hello,
I would like just to know if string class of libstdc++ support UTF8
and if not, is it possible to convert string to utf8 ?
wstring supports wide strings via wchar_t. string supports just 8bit
chars so you figure
it out.
This question is n
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Apr 28, 2005, at 3:08 PM, Laurielle Lea wrote:
>
>> Hello,
>>
>> I would like just to know if string class of libstdc++ support UTF8
>> and if not, is it possible to convert string to utf8 ?
>
> wstring supports wide strings via wchar_t. string suppo
> From: Martin Koegler <[EMAIL PROTECTED]>
>> On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote:
>>> Martin Koegler wrote:
>>> I have redone the implementation of the eeprom attribute in my prototype.
>>> It is now a cleaner solution, but requires larger changes in the core,
>>> but the c
On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote:
> > For the MEM_AREA for the tree, I have eliminated many explicit set operation
> > of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly).
> >
> > For certain tree codes, the build{1,2,3,4} automatically generate the
Joe Buck wrote:
On Thu, Apr 28, 2005 at 07:31:32PM +0200, Steven Bosscher wrote:
Yeah, but in this case the patch that introduced the bug was one of
the last to go in before the release (it was the fix for PRs 20490
and 20929, the patch for that went in on April 17). So it was more
an unfortunate
On Thu, 2005-04-28 at 11:03 -0700, Matt Thomas wrote:
> Someone complained I was unfair in my gcc bootstrap times since
> some builds included libjava/gfortran and some did not.
>
> So in the past day, I've done bootstrap with just c,c++,objc on
> both 3.4 and gcc4.1. I've put the results in a we
On Thu, 28 Apr 2005, Daniel Berlin wrote:
On Thu, 2005-04-28 at 11:03 -0700, Matt Thomas wrote:
Someone complained I was unfair in my gcc bootstrap times since
some builds included libjava/gfortran and some did not.
So in the past day, I've done bootstrap with just c,c++,objc on
both 3.4 and gcc4.
Peter Barada wrote:
The alternative of course is to do only crossbuilds. Is it reasonable
to say that, for platforms where a bootstrap is no longer feasible, a
successful crossbuild is an acceptable test procedure to use instead?
A successful crossbuild is certainly the minimum concievable standa
> From: Martin Koegler <[EMAIL PROTECTED]>
>> On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote:
>>> For the MEM_AREA for the tree, I have eliminated many explicit set operation
>>> of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly).
>>>
>>> For certain tree codes, t
Dan Nicolaescu <[EMAIL PROTECTED]> writes:
> Matt Thomas <[EMAIL PROTECTED]> writes:
>
> > Richard Henderson wrote:
> > > On Tue, Apr 26, 2005 at 10:57:07PM -0400, Daniel Jacobowitz wrote:
> > >
> > >>I would expect it to be drastically faster. However this won't show
up
Amir Fuhrmann wrote:
checking whether byte ordering is bigendian... cross-compiling...
unknown
checking to probe for byte ordering... /usr/local/powerpc-eabi/bin/ld: warning:
cannot find entry symbol _start; defaulting to 01800074
Looking at libiberty configure, I see it first tries to get the
by
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
> of CPU is the libtool shell script, which
>> 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 crossbu
On Apr 27, 2005, at 12:57 PM, Steven Bosscher 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 continu
On Apr 27, 2005, at 7:41 AM, David Edelsohn wrote:
GCC now supports C++, Fortran 90 and Java. Those languages have
extensive, complicated runtimes. The GCC Java environment is becoming
much more complete and standards compliant, which means adding more
and
more features.
Except it's not jus
82 matches
Mail list logo
