On Wed, 2 Jun 2004, Richard Hadsell wrote:
>> http://www.lam-mpi.org/~jsquyres/lam/beta/lam-7.0.7b1.tar.bz2
>> ...
>> Can you test this tarball and let me know if it works without problems?
>
> It got rid of the -MP flag but not the -fexceptions option:
Ok, so one test fixed but another not fixed. #$%@#$%
I'm guessing that Automake has updated to recognize this behavior but
Autoconf has not (AC v2.59 has been out for quite a while now; AM v1.8.5
is much more recent).
Probably the best thing to do then is --with-exflags=" ".
What we can do is issue a 7.0.6.1 that is identical to 7.0.6 except it is
built with newer Automake and Libtool versions. We'll make both
available, because we don't have the resources to do a full regression
test with the new stuff yet, but we recognize that some of you need stable
versions for production use.
Sorry for this hubaloo -- we're really trying to take a minimum effort on
the 7.0 series in an effort to get 7.1 out the door. It's a
limited-resources kind of issue... :-\
> Is it strange that this option gets included as a C option as well as
> C++? This is an excerpt from the output of configure:
> ...
> *** C Compiler and preprocessor
> ...
> checking whether we are using the GNU C compiler... yes
> ...
> checking for C optimization flags... -O3 -fexceptions -pthread
This is actually how it is supposed to happen, believe it or not.
Even though you can't throw or catch exceptions in C, it is possible to
throw an exception *through* C code. Consider a call stack looking like
this:
main();
some_cxx_function();
some_c_function();
some_other_cxx_function();
If some_other_cxx_function() throws an exception, it should be able to
propagate up through some_c_function() and be caught by
some_cxx_function(). In order to do this, the C compiler must know to add
in additional bootstrapping code to propagate C++ exceptions through C
functions. They don't do this by default because of the added performance
hit on every C function call (just the nature of C++ exceptions).
Pretend that some_other_cxx_function() is MPI::ERRORS_THROW_EXCEPTIONS
(well, the back-end error handler function that implements
MPI::ERRORS_THROW_EXCEPTIONS). That's why this code is necessary.
As a sidenote, if you don't use MPI::ERRORS_THROW_EXCEPTIONS in your
codes, you don't need the exception support in LAM. IIRC, the docs
explain this better than I did in this mail.
> There are also some files that are built with -O as well as -O3:
>
> compiling ROMIO in directory mpi-io
> make[4]: Entering directory
> `/tmp_mnt/netDISKS/master/netmt/LINUX_X86/rnd/lam/lam-7.0.7b1/romio/mpi-io'
> icc -O3 -fexceptions -pthread -DLAM_BUILDING=1 -O -DHAVE_ROMIOCONF_H
> -I/netDISKS/master/netmt/LINUX_X86/rnd/lam/lam-7.0.7b1/share/include
> -I/netDISKS/master/netmt/LINUX_X86/rnd/lam/lam-7.0.7b1/share/include
> -I/netDISKS/master/netmt/LINUX_X86/rnd/lam/lam-7.0.7b1/romio/mpi-io
> -I../include
> -I/netDISKS/master/netmt/LINUX_X86/rnd/lam/lam-7.0.7b1/romio/mpi-io/../adio/include
> -I../adio/include -c close.c
> icc: Command line warning: ignoring unknown option '-fexceptions'
> icc: Command line warning: overriding '-O3' with '-O'
> ...
Ick. I think ROMIO's configure is probably adding this in; we never
really checked for this duplicate case because we assumed that compilers
would just resolve to the higher optimization silently.
I'm not inspired to fix this for 7.0 because it's only a warning and icc
is [yet again] the only compiler that complains about this. But I can try
to put in some kind of check for this in 7.1.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
