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. So, we so
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 programs; however, keeping all
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 -fno-unit-at-a-time. Sometimes
> > we com
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
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
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
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 -
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:
> > 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.
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 <[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
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
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
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.
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
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
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
"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 reaches some
memory li
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
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, 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
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
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
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.
A user! Can you explain why?
The x86-64 2.4 linux kernel us
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.
>
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
> 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
27 matches
Mail list logo
