On 28/09/2010 13:28, Andrew Haley wrote:
> On 09/28/2010 12:35 PM, Dave Korn wrote:
>> On 28/09/2010 11:44, Andrew Haley wrote:
>>> On 09/28/2010 01:51 AM, Dave Korn wrote:
>>>
Huh, am I doing something seriously wrong? It takes me four hours to
boostrap GCC at with all languages enabl
On 09/28/2010 12:35 PM, Dave Korn wrote:
> On 28/09/2010 11:44, Andrew Haley wrote:
>> On 09/28/2010 01:51 AM, Dave Korn wrote:
>>
>>> Huh, am I doing something seriously wrong? It takes me four hours to
>>> boostrap GCC at with all languages enabled at -j8 on an AMD2x64
>>
>> You must be. I ju
On 28/09/2010 11:44, Andrew Haley wrote:
> On 09/28/2010 01:51 AM, Dave Korn wrote:
>
>> Huh, am I doing something seriously wrong? It takes me four hours to
>> boostrap GCC at with all languages enabled at -j8 on an AMD2x64
>
> You must be. I just bootstrapped with c, c++, and java, and it w
On 09/28/2010 01:51 AM, Dave Korn wrote:
>
> Huh, am I doing something seriously wrong? It takes me four hours to
> boostrap GCC at with all languages enabled at -j8 on an AMD2x64
You must be. I just bootstrapped with c, c++, and java, and it was
real40m36.704s
user164m5.664s
sys
> Well, the other thing is: why not just build them once and install them to
> your $prefix? There's no need to build them in-tree every time if you have
> sufficiently up-to-date versions installed.
>
> cheers,
> DaveK
I have a CVS tree, used by others, that builds a frontend.
"Others" are
On 28/09/2010 02:01, Jay K wrote:
> I only do one language, no driver, one stage, no libraries (none of libgcc,
> libstdc++, libjava, libada, etc.), no fixincludes (the headers are probably
> fine, and aren't used by this frontend anyway), the bootstrap compiler is
> always pretty decent, thus one
+0100
> From: dave.korn.cyg...@gmail.com
> To: jay.kr...@cornell.edu
> CC: a...@redhat.com; gcc@gcc.gnu.org
> Subject: Re: eliminating mpc/mpfr and reducing gmp
>
> On 27/09/2010 12:39, Jay K wrote:
>
> > gmp
> > time sh -c "CC=gcc-4.2 ./configure n
On 27/09/2010 12:39, Jay K wrote:
> gmp
> time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared
> -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\""
> real2m2.594s
>
> mpfr
> time sh -c "./configure -disable-shared -enable-static && make && ssh
> r...@loc
gcc and gmp
> gets messy.
> i.e. as gmp changes.
No, we don't want that. It'll exlode the testing matrix and we'd get
weird bugreports for missed optimizations.
Richard.
>
> - Jay
>
>
>> Date: Mon, 27 Se
lots others, but then the linkage between gcc and gmp
gets messy.
i.e. as gmp changes.
- Jay
----------------
> Date: Mon, 27 Sep 2010 11:37:04 +0100
> From: a...@redhat.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: eliminating mpc
On 09/27/2010 01:23 AM, Jay K wrote:
>
> Hi. You know, gmp/mpfr/mpc are a significant
> portion of building any frontend/backend.
I disagree. Most of the time I don't notice them.
> The result is a lot faster to build, if you are just doing a just
> a single stage build of a compiler.
Sure, bu
Hi. You know, gmp/mpfr/mpc are a significant
portion of building any frontend/backend.
So I looked at it.
mpc of course is only for complex numbers.
Our frontend doesn't use them.
Maybe only for "builtins" as well.
#define do_mpc_arg1(a, b, c) NULL_TREE
and such.
mpfr appears to be used fo
12 matches
Mail list logo