> Thanks. I was under the impression that 2.4 doesn't build with GCC
> HEAD, anyway - I saw some patches pile up and not get applied.
AFAIK some gcc 4.0 patches went in. I assume it will build eventually
at least once 4.0 is released.
> Does 2.6 still use the option?
No.
However the change nee
Daniel Jacobowitz wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
or so... I still lean on that crutch.
A user! Can you explain why?
The x86-64 2.4 linux kernel uses it too, because some code relies on
the ordering between asm and several functions.
Other Linux por
On Tue, Apr 12, 2005 at 06:34:29PM +0200, Andi Kleen wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> >> or so... I still lean on that crutch.
>
o-unit-at-a-time. Maybe Jakub can comment on
the timetable for getting rid of -fno-unit-at-a-time.
(And even if glibc-2.4.0 no longer needs -fno-unit-at-a-time,
there will still be people who want to build
oldish glibc's with new gcc's. I tend to sympathize
with them, and explicitly sup
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
>> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
>> or so... I still lean on that crutch.
>
> A user! Can you explain why?
The x86-64 2.4 linux kernel uses it
On Apr 12, 2005, at 3:14 AM, Thorsten Glaser wrote:
Daniel Jacobowitz dixit:
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least
gcc-4.1.1
or so... I still lean on that crutch.
A user! Can you explain why?
If you're "just" l
Daniel Jacobowitz dixit:
>On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
>> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
>> or so... I still lean on that crutch.
>
>A user! Can you explain why?
If you're "just" looking for users:
I need -fno-unit-at-a-
On Apr 11, 2005, at 4:58 AM, Nathan Sidwell wrote:
> Might I refer you to Mike Stump's answer regarding swap :)
I haven't seen it.
It was basically 'get more memory'.
Actually, an expanded version of it would be:
If gcc swaps, you're in serious trouble, gcc won't perform very well
well when it s
On Mon, 2005-04-11 at 13:03 -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> > BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> > or so... I still lean on that crutch.
>
> A user! Can you explain why?
Actually, I still use
Daniel Jacobowitz wrote:
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
or so... I still lean on that crutch.
A user! Can you explain why?
Hmm. I just looked, and it seems the only thing I still
use it for is
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> or so... I still lean on that crutch.
A user! Can you explain why?
--
Daniel Jacobowitz
CodeSourcery, LLC
"Rupert Wood" <[EMAIL PROTECTED]> wrote:
I have a problem with getting rid of -fno-unit-at-a-time. Sometimes
we compile huge Java programs; however, keeping all the method bodies
consumes vast amouts of memory.
AFAICT, MSVC solves this by generating some of the code when it rea
Marcin Dalecki writes:
>
> On 2005-04-11, at 14:01, Andrew Haley wrote:
>
> > Nathan Sidwell writes:
> >> Andrew Haley wrote:
> >>> Nathan Sidwell writes:
> Andrew Haley wrote:
>
> > Might it still be possible for a front end to force all pending
> > code
> > to
On 2005-04-11, at 14:01, Andrew Haley wrote:
Nathan Sidwell writes:
Andrew Haley wrote:
Nathan Sidwell writes:
Andrew Haley wrote:
Might it still be possible for a front end to force all pending
code
to be generated, even with -fno-unit-at-a-time gone?
I think this is a bad idea. You're essential
On Apr 11, 2005 2:01 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Nathan Sidwell writes:
> > Andrew Haley wrote:
> > > Nathan Sidwell writes:
> > > > Andrew Haley wrote:
> > > >
> > > > > Might it still be possible for a front end to force all pending code
> > > > > to be generated, even
Nathan Sidwell writes:
> Andrew Haley wrote:
> > Nathan Sidwell writes:
>
> > > 1) The C++ programs are smaller than the java programs
> >
> > That's my guess. Usually, C++ users compile one source file at a
> > time, whereas Java users find it convenient to compile a whole
> > archive.
Andrew Haley <[EMAIL PROTECTED]> writes:
> That's my guess. Usually, C++ users compile one source file at a
> time,
Unless you use --enable-final in KDE.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint
Andrew Haley wrote:
Nathan Sidwell writes:
> 1) The C++ programs are smaller than the java programs
That's my guess. Usually, C++ users compile one source file at a
time, whereas Java users find it convenient to compile a whole
archive.
ok, thanks. This sounds like you're really in an IMA mode
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Andrew Haley wrote:
| > Nathan Sidwell writes:
| > > Andrew Haley wrote:
| > > > > Might it still be possible for a front end to force all
| > pending code
| > > > to be generated, even with -fno-unit-at-a-time gone?
| > > > I think this is a bad
Just as another idea -
Steven Bosscher wrote:
> (The proper solution is of course to have an IR that we can stream
> to disk, *sigh* ;-)
AFAICT, MSVC solves this by generating some of the code when it reaches some
memory limit. So when GCC is under some memory pressure it could identify
functio
Nathan Sidwell writes:
> Andrew Haley wrote:
> > Nathan Sidwell writes:
> > > Andrew Haley wrote:
> > >
> > > > Might it still be possible for a front end to force all pending code
> > > > to be generated, even with -fno-unit-at-a-time gone?
> > >
> > > I think this is a bad idea.
Andrew Haley wrote:
Nathan Sidwell writes:
> Andrew Haley wrote:
>
> > Might it still be possible for a front end to force all pending code
> > to be generated, even with -fno-unit-at-a-time gone?
>
> I think this is a bad idea. You're essentially asking for the backend
> to retain all th
Nathan Sidwell writes:
> Andrew Haley wrote:
>
> > Might it still be possible for a front end to force all pending code
> > to be generated, even with -fno-unit-at-a-time gone?
>
> I think this is a bad idea. You're essentially asking for the backend
> to retain all the functionality of -
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Andrew Haley wrote:
|
| > Might it still be possible for a front end to force all pending code
| > to be generated, even with -fno-unit-at-a-time gone?
|
| I think this is a bad idea. You're essentially asking for the backend
| to retain all the func
Andrew Haley wrote on 11/04/2005 13:31:52:
> Steven Bosscher writes:
> >
> > This is what C++ does now too. Why would this be a problem
> > for Java but not for C++?
>
> I don't know why it's not a problem for C++; I do know why it's a
> problem for Java. Perhaps the files we're compiling
Andrew Haley wrote:
Might it still be possible for a front end to force all pending code
to be generated, even with -fno-unit-at-a-time gone?
I think this is a bad idea. You're essentially asking for the backend
to retain all the functionality of -fno-unit-at-a-time.
Might I refer you to Mike Stum
Steven Bosscher writes:
> On Monday 11 April 2005 12:18, Andrew Haley wrote:
> > Mark Mitchell writes:
> > > Your primary objective (get rid of -fno-unit-at-a-time) is one that I
> > > strongly support.
> >
> > I have a problem with getting rid of
On Monday 11 April 2005 12:18, Andrew Haley wrote:
> Mark Mitchell writes:
> > Your primary objective (get rid of -fno-unit-at-a-time) is one that I
> > strongly support.
>
> I have a problem with getting rid of -fno-unit-at-a-time. Sometimes
> we compile huge Java pr
Mark Mitchell writes:
> Your primary objective (get rid of -fno-unit-at-a-time) is one that I
> strongly support.
I have a problem with getting rid of -fno-unit-at-a-time. Sometimes
we compile huge Java programs; however, keeping all the method bodies
consumes vast amouts of memory.
29 matches
Mail list logo
