Le jeudi 14 décembre 2006 08:58, Steven Bosscher a écrit :
> On 12/14/06, Benoît Jacob <[EMAIL PROTECTED]> wrote:
> > I don't understand why you say that. At the language specification level,
> > templates come with no inherent speed overhead. All of the template stuff
> > is unfolded at compile ti
loop anyway... you C++ people tend to overtax compiler with
optimizations. Is it really necessary to do (i == j) * factor
when (i == j) ? factor : 0 is easier for compiler to grok?
Of course I tried it. It's even slower. Doesn't help the compiler unroll the
loop, and now there's a branch at e
Hello,
Most options of GCC (like --enable-werror --with-gmp ...) are configure-able
at its toplevel source directory while others ( --enable-mapped-location
) are configure-able with the configure script inside its gcc/ source
subdirectory
Of course, some options are for the whole toplevel.
I just built and locally installed gcc's (infrastructure) tarballs of
gmp-4.2.1 and mpfr-2.2.1 to try to build gcc trunk (as my build
system's versions are too old).
But, I am on a UltraSPARC system so I test build gcc multilibbed
enabled to have both 32 and 64 bit capability.
So, my question is
> So, my question is this: Do I need to have libgmp and libmpfr
> available as both 32 and 64 bit variants?
No if you use only one compiler (i.e. the multilibbed 32-bit compiler).
--
Eric Botcazou
I am currently involved in building GCC toolchains by configuring them with
the prefix that is to be used on the target system (somewhere in /opt)
and then installing them in a separate "working installation" directory
(say somewhere in my scratch space). The installation step into this
"working
On 12/14/06, Mark Shinwell <[EMAIL PROTECTED]> wrote:
I am currently involved in building GCC toolchains by configuring them with
the prefix that is to be used on the target system (somewhere in /opt)
and then installing them in a separate "working installation" directory
(say somewhere in my scr
On Thu, Dec 14, 2006 at 10:19:12AM +0100, Basile STARYNKEVITCH wrote:
> In other words, should I make all my configurable flag visible by the
> toplevel configure and propagated (thru Makefile.tpl) to gcc/ or not?
No, you shouldn't. Only add them to subdirs that need them.
--
Daniel Jacobowitz
Le Thu, Dec 14, 2006 at 08:56:27AM -0500, Daniel Jacobowitz écrivait/wrote:
Thanks to Daniel for his reply!
> On Thu, Dec 14, 2006 at 10:19:12AM +0100, Basile STARYNKEVITCH wrote:
> > In other words, should I make all my configurable flag visible by the
> > toplevel configure and propagated (thr
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> This makes life much simpler to me, but then I do not understand how end-
> users compiling GCC are expected to configure it. Does this mean that the
> instructions on http://gcc.gnu.org/install/configure.html are no more valid
> for that case?
N
Le Thu, Dec 14, 2006 at 07:29:19AM -0800, Ian Lance Taylor écrivait/wrote:
> Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
>
> > This makes life much simpler to me, but then I do not understand how end-
> > users compiling GCC are expected to configure it. Does this mean that the
> > instructio
Note that configure options beginning with --with and --enable are
passed from the top level configure script to the subdirectory
configure scripts. So the user just uses all the options at the top
level, and the subdirectories will see them.
I did notice this, but it seems to me (maybe I am
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> Le Thu, Dec 14, 2006 at 07:29:19AM -0800, Ian Lance Taylor écrivait/wrote:
>
> > Note that configure options beginning with --with and --enable are
> > passed from the top level configure script to the subdirectory
> > configure scripts. So the
Hello,
* Ian Lance Taylor wrote on Thu, Dec 14, 2006 at 04:29:19PM CET:
>
> I agree that new options should only be added at the appropriate
> level, but there is one disadvantage: top level configure --help will
> not display them.
Autoconf 2.5x implements --help=recursive.
> But then configur
I'm having some trouble understanding how to write
a MULTILIB_MATCHES specification.
I need to treat a simple option like "-mhard-float" the
same as an option with a value "-mfp=hard". Here's what
I came up with:
MULTILIB_OPTIONS = mfp=hard
MULTILIB_DIRNAMES = hard
MULTILIB_MATCHES = mf
On Thu, Dec 14, 2006 at 06:32:41PM +0100, Ralf Wildenhues wrote:
>
> You may find this discussion currently on the Autoconf list helpful:
> http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/8755
Thanks to all (Daniel Jacobowitz, Ian Lance Taylor, Paolo Bonzini,
Ralf Wildenhues).
I pa
Excepted two machines I opened to change their disk, the nine GCC
Compile Farm bi-pentium III machines are reaching one year uptime today:
== gcc01 == 21:08:26 up 242 days
== gcc02 == 21:08:26 up 365 days
== gcc03 == 21:08:26 up 365 days
== gcc04 == 9:08PM up 365 days
== gcc05 == 21:08:27 up 365
Congratulations and thanks for your work. I could not do any GCC
development without it.
Thanks,
Manuel.
On 14/12/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
Excepted two machines I opened to change their disk, the nine GCC
Compile Farm bi-pentium III machines are reaching one year uptime t
Snapshot gcc-4.0-20061214 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061214/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Michael Eager wrote:
I'm having some trouble understanding how to write
a MULTILIB_MATCHES specification.
I need to treat a simple option like "-mhard-float" the
same as an option with a value "-mfp=hard". Here's what
I came up with:
MULTILIB_OPTIONS = mfp=hard
MULTILIB_DIRNAMES = hard
Checks for vector instruction support are spreading throughout the
testsuite. I'd like to pull the basic logic into a single place that
can be referenced wherever it's needed. What's there now isn't always
consistent and there might be new things we can do if the information
is presented in a con
All -
When I configure with --disable-bootstrap and build with:
CFLAGS="-g -O0"
The resultant compiler is built with the specified options. However, if
I --enable-bootstrap, when I build with the same CFLAGS, these options
are not used to build the final compiler. I can get past this by usin
On Friday 15 December 2006 01:37, Josh Conner wrote:
> All -
>
> When I configure with --disable-bootstrap and build with:
>
> CFLAGS="-g -O0"
>
> The resultant compiler is built with the specified options. However, if
> I --enable-bootstrap, when I build with the same CFLAGS, these options
> ar
Paul Brook wrote:
> On Friday 15 December 2006 01:37, Josh Conner wrote:
>> All -
>>
>> When I configure with --disable-bootstrap and build with:
>>
>> CFLAGS="-g -O0"
>>
>> The resultant compiler is built with the specified options. However, if
>> I --enable-bootstrap, when I build with the sam
On Dec 14, 2006, at 5:59 PM, Paul Brook wrote:
On Friday 15 December 2006 01:37, Josh Conner wrote:
All -
When I configure with --disable-bootstrap and build with:
CFLAGS="-g -O0"
The resultant compiler is built with the specified options.
However, if
I --enable-bootstrap, when I build w
25 matches
Mail list logo
