Re: g++ doesn't unroll a loop it should unroll
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 time, none of it remains visible in the binary, so > > it shouldn't make the binary slower. > > You're confusing theory and practice... We're getting offtopic here, the example program I sent in my first mail didn't have any templates, so the gcc bug we're talking about has nothing to do with templates. The same bug would appear in any C or C++ program having nested loops and expecting them to get completely unrolled. Benoit pgpI1YexNOPbn.pgp Description: PGP signature
Re: g++ doesn't unroll a loop it should unroll
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 each iteration. This is another compiler bug. Note however, that if I want to use oldskool tricks to remove ?:, I would instead do -(i == j) & factor. The compiler should be able to transform the ?: expression to the faster form (and to transform the latter into ?: on architectures where it's better) but it does this quite late in the compilation. It can happen that things are screwed up by the time we reach that part of the optimization pipeline, and the ?: idiom is not recognized anymore. We are currently discussing including ?: in the compiler's intermediate representation, instead of representing it as an "if" statement; this might be a case where it helps. Paolo
configuration options policy (at toplevel or only inside gcc/)?
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.
When adding a new option, should I always add it at the toplevel or not?
Some options (like --enable-mapped-location or --with-gc=zone) seems to be
only usable with the gcc/configure script which seems usually to be run by
the build procedure (ie by the make at build).
Actually, I don't fully understand what might go inside the toplevel. I
believed that once perhaps even gdb or binutils could go there but I might
be wrong...
In other words, should I make all my configurable flag visible by the
toplevel configure and propagated (thru Makefile.tpl) to gcc/ or not?
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
[infrastructure] what about gmp and mpfr on multilibbed builds?
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 this: Do I need to have libgmp and libmpfr available as both 32 and 64 bit variants? If so, how would you recommend to build and install gmp and mpfr "multilibbed" also? -- Cheers, /ChJ
Re: [infrastructure] what about gmp and mpfr on multilibbed builds?
> 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
libjvm.la and problems with libtool relink mode
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 installation" directory is performed by invoking a command of the form "make prefix=/path/to/working/dir/install install". Unfortunately it seems that, when using current mainline and building for native x86_64, there is an awkward problem involving the building of libjvm.la. This libtool file is built from two others: one .lo file and one .la file. The difficulty arises at the libtool "install" step for libjvm.la. It seems that since the "link" command that constructed libjvm.la built that library using another .la file (libgcj.la) then libtool writes a relink command into the libjvm.la file. Then, when installing libjvm.la using libtool, it attempts to execute that relink command. This however fails because the installation location is not a subdirectory of the configured prefix -- it is somewhere completely different. This piece of libtool code causes the error: # Don't allow the user to place us outside of our expected # location b/c this prevents finding dependent libraries that # are installed to the same prefix. # At present, this check doesn't affect windows .dll's that # are installed into $libdir/../bin (currently, that works fine) # but it's something to keep an eye on. if test "$inst_prefix_dir" = "$destdir"; then $echo "$modename: error: cannot install \`$file' to a directory not ending in $libdir" 1>&2 exit 1 fi This problem does not arise with various other .la files created during the build process of gcc (such as libstdc++.la for example) because those are directly created from a bunch of .lo files; none of them were built from another .la as libjvm.la is. The writing of the relink command into libjvm.la comes as a result of "need_relink=yes" on line 2095 of the ltmain.sh in the toplevel directory of mainline gcc. I wonder if this assignment ought to be guarded by a test involving $hardcode_into_libs, which is currently set to "yes" in my generated /x86_64-unknown-linux-gnu/libjava/libtool. Perhaps I should be having $hardcode_into_libs set to "no" in addition to changing the libtool code so that need_relink is only set to "yes" if $hardcode_into_libs is set to "yes" also? The exact behaviour of the two modes of $hardcode_into_libs isn't clear to me, however, so I'm not very sure. With that "solution" I'm also assuming that libtool is doing the right thing in forcing a relink in this situation (if $hardcode_into_libs is "yes"); perhaps even that isn't the case. If anyone could offer any advice as to how to proceed here, I'd be most grateful. I've copied this to Alexandre since a colleague suggested he might know the answer :-) Mark
Re: libjvm.la and problems with libtool relink mode
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 scratch space). The installation step into this "working installation" directory is performed by invoking a command of the form "make prefix=/path/to/working/dir/install install". I think you should use DESTDIR instead of prefix here. Richard.
Re: configuration options policy (at toplevel or only inside gcc/)?
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 CodeSourcery
Re: configuration options policy (at toplevel or only inside gcc/)?
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 (thru Makefile.tpl) to gcc/ or not?
> No, you shouldn't. Only add them to subdirs that need them.
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?
What should be the user installation & configuration procedure replacing the
# from http://gcc.gnu.org/install/configure.html
mkdir objdir
cd objdir
srcdir/configure [options] [target]
in that case?
Should it become
mkdir objdir
cd objdir
srcdir/configure [options-to-toplevel] [target]
cd ../objdir/gcc # or simply gcc, but in the build tree
srcdir/gcc/configure [options-to-gcc] [target]
At last I do not understand why the MPFR & GMP stuff which has been
discussed a lot is not already under the above scheme? Why is it cheched at
toplevel and not only in gcc/ ? AFAIK the #include appears only in
gcc/real.h
BTW, I am working on add stuff (heavy global static analysis) which
should be disablable at configure time and at runtime, and uses several
third parties (GPL or LGPL) libraries
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: configuration options policy (at toplevel or only inside gcc/)?
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? 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 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. But then configure --help is kind of useless anyhow since it has so much boilerplate, so this is not a significant problem. > At last I do not understand why the MPFR & GMP stuff which has been > discussed a lot is not already under the above scheme? Why is it cheched at > toplevel and not only in gcc/ ? AFAIK the #include appears only in > gcc/real.h It's at the top level because the original implementation envisioned support for putting MPFR and GMP in the tree, alongside of the directories gcc, libcpp, etc. That may still happen. Ian
Re: configuration options policy (at toplevel or only inside gcc/)?
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
> > instructions on http://gcc.gnu.org/install/configure.html are no more valid
> > for that case?
>
> 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 wrong) that there is
no generic machinery which passes the --with & --enable of the
top-level configure to the configure in gcc subdirectory. There is
some code in Makefile.tpl for this, but each such option has to be
explicitly & individually processed.
In other words for adding new configure options to gcc/ subdirectory,
we have to hack the gcc/configure.ac file, the toplevel configure.in
and the toplevel Makefile.tpl and this should be done for every
user-visible options. Otherwise, it is an option which is not visible
to the user. If I hack only gcc/configure.ac, I am adding an option
which the user do not see. Is this correct?
> 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. But then configure --help is kind of useless anyhow
> since it has so much boilerplate, so this is not a significant
> problem.
Still, what is the build procedure then? Do we expect users to type
two configure commands?
>
> > At last I do not understand why the MPFR & GMP stuff which has been
> > discussed a lot is not already under the above scheme? Why is it cheched at
> > toplevel and not only in gcc/ ? AFAIK the #include appears only in
> > gcc/real.h
>
> It's at the top level because the original implementation envisioned
> support for putting MPFR and GMP in the tree, alongside of the
> directories gcc, libcpp, etc. That may still happen.
Thanks for the explanation. But I thought it has been firmly decided
to keep GMP & MPFR outside!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: configuration options policy (at toplevel or only inside gcc/)?
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 wrong) that there is no generic machinery which passes the --with & --enable of the top-level configure to the configure in gcc subdirectory. There is some code in Makefile.tpl for this, but each such option has to be explicitly & individually processed. No, see how host_configure_args is set in Makefile.in. In other words for adding new configure options to gcc/ subdirectory, we have to hack the gcc/configure.ac file, the toplevel configure.in and the toplevel Makefile.tpl and this should be done for every user-visible options. Otherwise, it is an option which is not visible to the user. If I hack only gcc/configure.ac, I am adding an option which the user do not see. Is this correct? No, you are adding an option that will not be listed in ./configure --help. So you document that option in install.texi. 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. But then configure --help is kind of useless anyhow since it has so much boilerplate, so this is not a significant problem. Still, what is the build procedure then? Do we expect users to type two configure commands? No. Options are passed down automatically from the toplevel configure to the ones below. This is true of any configure script, even though the gcc/binutils/gdb/cygwin/newlib/... toplevel configure script has some extra involutions. At last I do not understand why the MPFR & GMP stuff which has been discussed a lot is not already under the above scheme? Why is it cheched at toplevel and not only in gcc/ ? AFAIK the #include appears only in gcc/real.h It's at the top level because the original implementation envisioned support for putting MPFR and GMP in the tree, alongside of the directories gcc, libcpp, etc. That may still happen. Thanks for the explanation. But I thought it has been firmly decided to keep GMP & MPFR outside! We might still allow other people to put gmp and mpfr in the same source tree as gcc, even though it was decided to keep them out of the gcc tarball.
Re: configuration options policy (at toplevel or only inside gcc/)?
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 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 wrong) that there is > no generic machinery which passes the --with & --enable of the > top-level configure to the configure in gcc subdirectory. There is > some code in Makefile.tpl for this, but each such option has to be > explicitly & individually processed. I just ran the top level configure script with --with-foobar, and then did "make configure-gcc". When I look in gcc/config.status I do see --with-foobar in there. So I think it does work as I expected. I haven't bothered to dig into exactly how it works. > > 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. But then configure --help is kind of useless anyhow > > since it has so much boilerplate, so this is not a significant > > problem. > > Still, what is the build procedure then? Do we expect users to type > two configure commands? No, definitely not. That would not be acceptable. > > > At last I do not understand why the MPFR & GMP stuff which has been > > > discussed a lot is not already under the above scheme? Why is it cheched > > > at > > > toplevel and not only in gcc/ ? AFAIK the #include appears only in > > > gcc/real.h > > > > It's at the top level because the original implementation envisioned > > support for putting MPFR and GMP in the tree, alongside of the > > directories gcc, libcpp, etc. That may still happen. > > Thanks for the explanation. But I thought it has been firmly decided > to keep GMP & MPFR outside! I don't think it has been firmly decided to not permit the user to unpack MPFR and GMP next to gcc, and have that work--the traditional one-tree build. Ian
Re: configuration options policy (at toplevel or only inside gcc/)?
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 configure --help is kind of useless anyhow since it has so > much boilerplate, so this is not a significant problem. If I want to find something in a long list, I can pipe it to less and search for it. That's trivial, but it's a good enough reason to have something listed. You may find this discussion currently on the Autoconf list helpful: http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/8755 Cheers, Ralf
MULTILIB_MATCHES question
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 = mfp?hard=mhard-float
When I specify -mfp=hard, the correct lib ("hard")is selected.
When I specify -mhard-float, the default is selected.
How should I write the MULTILIB_MATCHES spec to do this?
(The docs are less than clear about the MULTILIB_MATCHES
option and don't mention using '?'.)
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: configuration options policy (at toplevel or only inside gcc/)?
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 partly updated the Wiki. It is sad that nobody corrected the page
http://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
(I hope I corrected some stuff there, and I wrote most of it).
I really think that such information should go into GCC internal
documentation, where I was not able to find it out. Do you believe
that some of the descriptions in this thread and in the Wiki page just
cited should go into the documentation? Is the documentation expected
to help new GCC contributors, or is it only for users? In particular,
IMHO the commands to re-generate the configure scripts should be
documented if the documentation also targets potential GCC
contributors.
I could write (by copying phrases from the wiki page) a few sentences
into the documentation (gcc/doc/sourcebuild.texi)? Is it worthwhile;
in other words for whom is this documentation written: for users of
GCC (including the few people compiling GCC to use it) or for
potential contributors (GCC hackers)?
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Compile Farm : one year uptime, call for projects
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 days == gcc06 == 21:08:28 up 365 days == gcc07 == 21:08:28 up 365 days == gcc08 == 21:08:28 up 365 days == gcc09 == 21:08:28 up 242 days There are currently 17 users with access to the farm, new users and projects are as welcomed as before :). http://gcc.gnu.org/wiki/CompileFarm << GCC Compile Farm Project The GCC CompileFarm Project is seeking volunteers to maintain script machinery to help with GCC development on nine bi pentium 3 machines as well as GCC developers that are lacking x86 machine access. How to Get Involved ? If you are a GCC developer and want access to the compileFarm for GCC development and testing, or if you are a free software developer wishing to set up automated testing of a piece of free software with the current GCC development version (preferably with a test suite), please send 1. your ssh public key (HOME/.ssh/authorized_keys format) *in attachment* and not inline in the email and 2. your prefered UNIX login to laurent at guerby dot net. [...] >> Many thanks to the http://jexiste.org/ staff for providing reliable and free hosting to this project. Laurent http://guerby.org/blog/
Re: Compile Farm : one year uptime, call for projects
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 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 days == gcc06 == 21:08:28 up 365 days == gcc07 == 21:08:28 up 365 days == gcc08 == 21:08:28 up 365 days == gcc09 == 21:08:28 up 242 days There are currently 17 users with access to the farm, new users and projects are as welcomed as before :). http://gcc.gnu.org/wiki/CompileFarm << GCC Compile Farm Project The GCC CompileFarm Project is seeking volunteers to maintain script machinery to help with GCC development on nine bi pentium 3 machines as well as GCC developers that are lacking x86 machine access. How to Get Involved ? If you are a GCC developer and want access to the compileFarm for GCC development and testing, or if you are a free software developer wishing to set up automated testing of a piece of free software with the current GCC development version (preferably with a test suite), please send 1. your ssh public key (HOME/.ssh/authorized_keys format) *in attachment* and not inline in the email and 2. your prefered UNIX login to laurent at guerby dot net. [...] >> Many thanks to the http://jexiste.org/ staff for providing reliable and free hosting to this project. Laurent http://guerby.org/blog/
gcc-4.0-20061214 is now available
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/gcc-4_0-branch revision 119869 You'll find: gcc-4.0-20061214.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20061214.tar.bz2 C front end and core compiler gcc-ada-4.0-20061214.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20061214.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20061214.tar.bz2 C++ front end and runtime gcc-java-4.0-20061214.tar.bz2 Java front end and runtime gcc-objc-4.0-20061214.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20061214.tar.bz2The GCC testsuite Diffs from 4.0-20061207 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: MULTILIB_MATCHES question
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
MULTILIB_MATCHES = mfp?hard=mhard-float
When I specify -mfp=hard, the correct lib ("hard")is selected.
When I specify -mhard-float, the default is selected.
How should I write the MULTILIB_MATCHES spec to do this?
(The docs are less than clear about the MULTILIB_MATCHES
option and don't mention using '?'.)
Ah, never mind. I found a typo in my specification.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
[RFC] centralizing vector support info in the testsuite
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 convenient way, so I'd like some advice. The following .exp files currently check whether various targets can generate and run vector instructions and provide command line options for specific targets: gcc.dg/vmx/vmx.exp gcc.dg/vect/vect.exp g++.dg/vect/vect.exp gfortran.dg/vect/vect.exp lib/fortran-torture.exp The following procedures are used only by other procedures: check_effective_target_mpaired_single (for mips) check_alpha_max_hw_available check_vmx_hw_available The following effective targets are used in individual tests as well as within .exp files: powerpc_altivec_ok vect_cmdline_needed (checks i?86, x86_64, ia64) I'd like to pull all of the logic into a single procedure I'll call check_vector_support that will return a list where the first element is 0 no vector support 1 can generate but not run vector instructions 2 can generate and run vector instructions The second element returned is the command line options needed to generate vector instructions for the current effective target. This information can be used in the .exp files that currently do all these checks themselves, and can be used for new target-independent effective targets to replace vmx_hw and powerpc_altivec_ok: vect_gen (ok to generate vector instructions) vect_run (ok to generate and run vector instructions) The existing proc for vect_cmdline_needed would also use the results of check_vector_support and would support all targets. Current handling of i?86, x86_64, and ia64 is confusing. Some places use "-msse2" for all of these, but the procedure check_effective_target_vect_cmdline_needed says no options are needed for ia64 or for LP64 x86_64 and i?86. I seem to recall from long ago that some processors support generating, and possibly running, multiple kinds of vector instructions. If that is the case then check_vector_support could return a list of two (possibly empty) lists of options: options that the target compiler can use to generate vector instructions options for vector instructions that the test system can run In either case, "" is not the same as an empty list, and means that vector instructions are generated by default. The lists could be used in torture lists for testing vector code generation for multiple kinds of vector instructions. Comments? Janis
Question on BOOT_CFLAGS vs. CFLAGS
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 using BOOT_CFLAGS="-g -O0", but that seems a bit inconsistent. My question is: Is this behaving as designed or would it be reasonable to file a bug and/or supply a patch to change the behavior so that CFLAGS are respected whether bootstrapping is enabled or not? Thanks - Josh
Re: Question on BOOT_CFLAGS vs. CFLAGS
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 > are not used to build the final compiler. I can get past this by using > BOOT_CFLAGS="-g -O0", but that seems a bit inconsistent. > > My question is: Is this behaving as designed or would it be reasonable > to file a bug and/or supply a patch to change the behavior so that > CFLAGS are respected whether bootstrapping is enabled or not? It is working as documented: http://gcc.gnu.org/onlinedocs/gccint/Makefile.html http://gcc.gnu.org/install/build.html Paul
Re: Question on BOOT_CFLAGS vs. CFLAGS
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 same CFLAGS, these options >> are not used to build the final compiler. I can get past this by using >> BOOT_CFLAGS="-g -O0", but that seems a bit inconsistent. >> >> My question is: Is this behaving as designed or would it be reasonable >> to file a bug and/or supply a patch to change the behavior so that >> CFLAGS are respected whether bootstrapping is enabled or not? > > It is working as documented: > > http://gcc.gnu.org/onlinedocs/gccint/Makefile.html > http://gcc.gnu.org/install/build.html OK - it seemed a bit strange to me, but I'm glad to hear it is behaving as intended. - Josh
Re: Question on BOOT_CFLAGS vs. CFLAGS
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 with the same CFLAGS, these options are not used to build the final compiler. I can get past this by using BOOT_CFLAGS="-g -O0", but that seems a bit inconsistent. My question is: Is this behaving as designed or would it be reasonable to file a bug and/or supply a patch to change the behavior so that CFLAGS are respected whether bootstrapping is enabled or not? It is working as documented: http://gcc.gnu.org/onlinedocs/gccint/Makefile.html http://gcc.gnu.org/install/build.html I read that, could you please quote the part that documents the current behavior. Let me offer a counter quote: If you want to save additional space during the bootstrap and in the final installation as well, you can build the compiler binaries without debugging information as in the following example. This will save roughly 40% of disk space both for the bootstrap and the final installation. (Libraries will still contain debugging information.) make CFLAGS='-O' LIBCFLAGS='-g -O2' \ LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap I think that is pretty clear. I think this is a bug that was unintentionally introduced by someone that didn't realize all the nuances of this. If you examine the patch submission where this was changed, I don't recall they called out or discussed the changed behavior. Do you have a pointer that shows otherwise? Now, why do we do this, kinda simple, because this is a standard that trancends gcc and dates back a long, long time, see http:// www.gnu.org/prep/standards/standards.html for example. The fix is simple, we just change BOOT_CFLAGS = -O2 -g to instead be $ (CFLAGS). This way, if someone builds as documented in the manual, they get the results documented in the manual.
