[Developers] g++ warning: operation on *bla* may be undefined
Steve White
steve.white at aei.mpg.de
Thu Oct 26 12:38:17 CDT 2006
Hi,
I have reverted a copy on Belladonna, made realclean, re-configured
and built Carpet code with the reverted copy with WARN=yes.
The result is, that pgCC does not warn of unused parameters with the
old scheme, while with the new scheme, it does.
For perspective however, I present the warning output of one Carpet file,
as it was *before* the recent patch. This needs tweeking anyway.
I think Gcc is a more important compiler than pgCC to our community right
now, especially among those who look at warning messages.
Furthermore, the previous code was much wierder than the patch I applied.
I think it's just better as it is.
If Erik has a clever solution, let's see it.
pgCC warning output ============================================>>
Preprocessing /home/swhite/Cactus/arrangements/Carpet/Carpet/src/Checksum.cc
Compiling /home/swhite/Cactus/arrangements/Carpet/Carpet/src/Checksum.cc
T1 prod<T1, N2>(const vect<T1, N2> &) [with T1=int, N2=(int)3]:
984, Loop not vectorized: contains call
vect<T1, N2>::vect<int, (int)3>(const T1 &) [with T1=int, N2=(int)3]:
52, Loop unrolled 3 times (completely unrolled)
void std::__destroy_aux<T1>(T1, T1, const std::__false_type &) [with T1=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *]:
112, Loop not vectorized: contains call
void std::__destroy_aux<T1>(T1, T1, const std::__false_type &) [with T1=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *]:
112, Loop not vectorized: contains call
void std::__destroy_aux<T1>(T1, T1, const std::__false_type &) [with T1=Carpet::ckdesc *]:
112, Loop not vectorized: contains call
__CPR1086____copy__tm__1010_PQ2_3std493vector__tm__478_Q2_3std214vector__tm__199_Q2_3std76vector__tm__62_Q2_6Carpet6ckdescQ2_3std35allocator__tm__18_Q2_J97JJ104JQ2_3std103allocator__tm__86_Q2_3stdJ77JQ2_3std243allocator__tm__225_Q2_3stdJ51JPQ2_3stdJ25Jl__3stdFZ1ZT1Z2ZRCQ2_3std26random_access_iterator_tagPZ3Z_Z2Z:
141, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=const std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *, T2=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=const std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *, T2=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=const Carpet::ckdesc *, T2=Carpet::ckdesc *, T3=long]:
141, Loop not vectorized due to data dependency
Loop unrolled 2 times
void std::__destroy_aux<T1>(T1, T1, const std::__false_type &) [with T1=std::vector<std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>>, std::allocator<std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>>>> *]:
112, Loop not vectorized: contains call
__CPR1095____copy_backward__tm__1010_PQ2_3std493vector__tm__478_Q2_3std214vector__tm__199_Q2_3std76vector__tm__62_Q2_6Carpet6ckdescQ2_3std35allocator__tm__18_Q2_J106JJ113JQ2_3std103allocator__tm__86_Q2_3stdJ86JQ2_3std243allocator__tm__225_Q2_3stdJ60JPQ2_3stdJ34Jl__3stdFZ1ZT1Z2ZRCQ2_3std26random_access_iterator_tagPZ3Z_Z2Z:
179, Loop not vectorized: contains call
__CPR1041__fill__tm__1008_PQ2_3std493vector__tm__478_Q2_3std214vector__tm__199_Q2_3std76vector__tm__62_Q2_6Carpet6ckdescQ2_3std35allocator__tm__18_Q2_J95JJ102JQ2_3std103allocator__tm__86_Q2_3stdJ75JQ2_3std243allocator__tm__225_Q2_3stdJ49JQ2_3stdJ23J__3stdFZ1ZT1RCZ2Z_v:
329, Loop not vectorized: contains call
void std::__destroy_aux<T1>(T1, T1, const std::__false_type &) [with T1=std::vector<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>, std::allocator<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>>> *]:
112, Loop not vectorized: contains call
void std::__destroy_aux<T1>(T1, T1, const std::__false_type &) [with T1=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *]:
112, Loop not vectorized: contains call
void std::__destroy_aux<T1>(T1, T1, const std::__false_type &) [with T1=Carpet::ckdesc4 *]:
112, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>, std::allocator<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>>> *, T2=std::vector<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>, std::allocator<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>>> *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=const std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *, T2=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=const Carpet::ckdesc4 *, T2=Carpet::ckdesc4 *, T3=long]:
141, Loop not vectorized: contains call
__CPR1087____copy__tm__1011_PCQ2_3std493vector__tm__478_Q2_3std214vector__tm__199_Q2_3std76vector__tm__62_Q2_6Carpet6ckdescQ2_3std35allocator__tm__18_Q2_J98JJ105JQ2_3std103allocator__tm__86_Q2_3stdJ78JQ2_3std243allocator__tm__225_Q2_3stdJ52JPQ2_3stdJ26Jl__3stdFZ1ZT1Z2ZRCQ2_3std26random_access_iterator_tagPZ3Z_Z2Z:
141, Loop not vectorized: contains call
T2 std::__copy_backward<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>, std::allocator<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>>> *, T2=std::vector<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>, std::allocator<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>>> *, T3=long]:
179, Loop not vectorized: contains call
void std::fill<T1, T2>(T1, T1, const T2 &) [with T1=std::vector<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>, std::allocator<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>>> *, T2=std::vector<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>, std::allocator<std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>>>]:
329, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *, T2=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy_backward<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *, T2=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *, T3=long]:
179, Loop not vectorized: contains call
void std::fill<T1, T2>(T1, T1, const T2 &) [with T1=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>> *, T2=std::vector<Carpet::ckdesc4, std::allocator<Carpet::ckdesc4>>]:
329, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=Carpet::ckdesc4 *, T2=Carpet::ckdesc4 *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy_backward<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=Carpet::ckdesc4 *, T2=Carpet::ckdesc4 *, T3=long]:
179, Loop not vectorized: contains call
void std::fill<T1, T2>(T1, T1, const T2 &) [with T1=Carpet::ckdesc4 *, T2=Carpet::ckdesc4]:
329, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *, T2=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy_backward<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *, T2=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *, T3=long]:
179, Loop not vectorized: contains call
void std::fill<T1, T2>(T1, T1, const T2 &) [with T1=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>> *, T2=std::vector<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>, std::allocator<std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>>>]:
329, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *, T2=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *, T3=long]:
141, Loop not vectorized: contains call
T2 std::__copy_backward<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *, T2=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *, T3=long]:
179, Loop not vectorized: contains call
void std::fill<T1, T2>(T1, T1, const T2 &) [with T1=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>> *, T2=std::vector<Carpet::ckdesc, std::allocator<Carpet::ckdesc>>]:
329, Loop not vectorized: contains call
T2 std::__copy<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=Carpet::ckdesc *, T2=Carpet::ckdesc *, T3=long]:
141, Loop not vectorized due to data dependency
Loop unrolled 2 times
T2 std::__copy_backward<T1, T2, T3>(T1, T1, T2, const std::random_access_iterator_tag &, T3 *) [with T1=Carpet::ckdesc *, T2=Carpet::ckdesc *, T3=long]:
179, Loop not vectorized due to data dependency
Loop unrolled 2 times
void std::fill<T1, T2>(T1, T1, const T2 &) [with T1=Carpet::ckdesc *, T2=Carpet::ckdesc]:
329, Loop not vectorized: not countable
Carpet::CalculateChecksums(const _cGH *, Carpet::checktimes):
47, Loop not vectorized: too deeply nested
52, Loop not vectorized: too deeply nested
54, Loop not vectorized: too deeply nested
65, Loop not vectorized: contains call
77, Loop not vectorized: contains call
82, Loop unrolled 4 times
Carpet::CheckChecksums(const _cGH *, Carpet::checktimes):
113, Loop not vectorized: too deeply nested
118, Loop not vectorized: too deeply nested
120, Loop not vectorized: too deeply nested
131, Loop not vectorized: contains call
143, Loop not vectorized: contains call
149, Loop unrolled 4 times
Postprocessing /home/swhite/Cactus/arrangements/Carpet/Carpet/src/Checksum.cc
On 26.10.06, Steve White wrote:
> Pardon me,
>
> Why are we reverting?
>
> It works on all compilers I know of.
> I just get warnings on pgCC...I'm not even sure they weren't there before.
>
>
>
> On 26.10.06, Tom Goodale wrote:
> >
> > Ok, this is getting silly. As I said before, the easiest solution looks
> > like to revert to the previous system, which works for everything except
> > the latest g++, and then add the attribute stuff for that using Erik's
> > detection mechanism to see if it's available. We know that both these
> > approaches work where they are valid so wouldn't need to experiment any
> > more and come up with yet another in the long line of kludges.
> >
> > Tom
> >
> > On Thu, 26 Oct 2006, Erik Schnetter wrote:
> >
> > >If I remember correctly, gcc suppresses warnings about var being unused
> > >when you add the no-op expression
> > >
> > > int x = sizeof(var);
> > >
> > >to the source code. Other compilers suppress warnings when you add the
> > >no-op expression
> > >
> > > int * y = & var + 1;
> > >
> > >to the source code. If you want to suppress warnings for all compilers,
> > >combine both approaches:
> > >
> > > int x = sizeof(var);
> > > int * y = & var + 1;
> > >
> > >Thus, both compilers will see that var is used in some way.
> > >
> > >-erik
> > >
> > >On Oct 26, 2006, at 17:40:23, Steve White wrote:
> > >
> > >>No comprendo.
> > >>
> > >>On 26.10.06, Erik Schnetter wrote:
> > >>>Idea: Try
> > >>>
> > >>> sizeof var + whatever-term-works-for-the-other-compilers,
> > >>>
> > >>>this way each compiler sees the variable used.
> > >>>
> > >>>-erik
> > >>>
> > >>>On Oct 26, 2006, at 17:09:40, Steve White wrote:
> > >>>
> > >>>>Well, the mechanism I put in works for gcc...
> > >>>>It seems the pgCC doesn't consider sizeof( var ) to be a "use" of var.
> > >>>>I'm looking at an alternative.
> > >>>>
> > >>>>On 26.10.06, Erik Schnetter wrote:
> > >>>>>gcc has __attribute__((unused)) to mark variables that are
> > >>>>>intentionally unused. This suppresses this warning. Other compilers
> > >>>>>may have similar ways for annotating variables.
> > >>>>>
> > >>>>>I have implemented a bit of generic infrastructure to declare
> > >>>>>variables, which makes it easier to experiment with these things. I
> > >>>>>have also implemented autodetecting whether __attribute__((unused))
> > >>>>>is supported, so that it is used when present, and an old-style
> > >>>>>mechanism is used otherwise. A similar thing is done for Fortran
> > >>>>>code.
> > >>>>>
> > >>>>>The changes are straightforward, but touch quite a number of files.
> > >>>>>I would need to isolate them from other changes, and then they need
> > >>>>>to be tested thoroughly. I can do the first part if you are
> > >>>>>interested.
> > >>>>>
> > >>>>>We discussed this before, and then the consensus was that using
> > >>>>>__attribute__((unused)) was not worth the effort because the existing
> > >>>>>mechanisms were sufficient. Maybe this has changed with gcc 4 having
> > >>>>>become too clever.
> > >>>>>
> > >>>>>-erik
> > >>>>>
> > >>>>>On Oct 26, 2006, at 15:50:38, Steve White wrote:
> > >>>>>
> > >>>>>>Hi again.
> > >>>>>>
> > >>>>>>Unfortunately, Portland Group's C++ compiler (which I hadn't tried
> > >>>>>>in my tests) now warns:
> > >>>>>>
> > >>>>>> variable "parameter_name" was set but never used
> > >>>>>>
> > >>>>>>for every CCTK parameter. I don't think it was warning about the
> > >>>>>>old code.
> > >>>>>>
> > >>>>>>It seems that one can't please everybody.
> > >>>>>>
> > >>>>>>
> > >>>>>>On 20.10.06, Steve White wrote:
> > >>>>>>>Hi,
> > >>>>>>>
> > >>>>>>>This is concerned with g++ warnings like:
> > >>>>>>>
> > >>>>>>> Preprocessing arrangements/Carpet/Carpet/src/Timing.cc
> > >>>>>>> Compiling arrangements/Carpet/Carpet/src/Timing.cc
> > >>>>>>> configs/chain_gcc_carpet/build/Carpet/Timing.cc:
> > >>>>>>> In function ?void Carpet::InitTimingVariables(const
> > >>>>>>> cGH*)?:
> > >>>>>>> configs/chain_gcc_carpet/build/Carpet/Timing.cc:120:
> > >>>>>>> warning: operation on ?cctki_use? may be undefined
> > >>>>>>>
> > >>>>>>>The culprit was in generated bindings code meant to get rid of
> > >>>>>>>warnings
> > >>>>>>>about unused variables corresponding to Cactus parameters
> > >>>>>>>included in
> > >>>>>>>code by the DECLARE_CCTK_PARAMETERS macro.
> > >>>>>>>
> > >>>>>>>Typically, a struct was defined to hold copies of the macros, then
> > >>>>>>>such very interesting constructs would appear.
> > >>>>>>>
> > >>>>>>>const void *PRIVATE_CACTUS_STRUCT_use = ( \
> > >>>>>>> PRIVATE_CACTUS_STRUCT_use = &cctk_run_title, \
> > >>>>>>> PRIVATE_CACTUS_STRUCT_use = &*PRIVATE_CACTUS_STRUCT_use \
> > >>>>>>>)
> > >>>>>>>
> > >>>>>>>This code replaces that with a do-nothing enum declaration
> > >>>>>>>enum {
> > >>>>>>> dummy_cctk_run_title = sizeof( cctk_run_title )
> > >>>>>>> //,etc.
> > >>>>>>>};
> > >>>>>>>The nature of all the entities involved is here much clearer,
> > >>>>>>>both to
> > >>>>>>>compilers and to me.
> > >>>>>>>
> > >>>>>>>Like the existing solution, this permits the user to proceed to
> > >>>>>>>make more
> > >>>>>>>declarations after the DECLARE_CCTK_PARAMETERS macro (simply
> > >>>>>>>putting a list
> > >>>>>>>of variable assignments after the declaration would not have that
> > >>>>>>>property).
> > >>>>>>>
> > >>>>>>>See also the patches list posting of the same name, and PR 2070
> > >>>>>>>http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view%
> > >>>>>>>20audit-trail&database=cactus&pr=2070
> > >>>>>>>for a patch.
> > >>>>>>>
> > >>>>>>>It has been tested on Gnu 4x, Intel 9x, IBM XL
> > >>>>>>>
> > >>>>>>>Cheers!
> > >>>>>>>
> > >>>>>>
> > >>>>>>--
> > >>>>>>Steve White : Programmer
> > >>>>>>Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-
> > >>>>>>Institut
> > >>>>>>Am M?hlenberg 1, D-14476 Golm, Germany
> > >>>>>>+49-331-567-7625
> > >>>>>>
> > >>>>>>_______________________________________________
> > >>>>>>Developers mailing list
> > >>>>>>Developers at cactuscode.org
> > >>>>>>http://www.cactuscode.org/mailman/listinfo/developers
> > >>>>>
> > >>>>>
> > >>>>>--
> > >>>>>Erik Schnetter <schnetter at cct.lsu.edu>
> > >>>>>
> > >>>>>My email is as private as my paper mail. I therefore support
> > >>>>>encrypting
> > >>>>>and signing email messages. Get my PGP key from www.keyserver.net.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>_______________________________________________
> > >>>>>Developers mailing list
> > >>>>>Developers at cactuscode.org
> > >>>>>http://www.cactuscode.org/mailman/listinfo/developers
> > >>>>
> > >>>>
> > >>>>--
> > >>>>Steve White : Programmer
> > >>>>Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-
> > >>>>Institut
> > >>>>Am M?hlenberg 1, D-14476 Golm, Germany
> > >>>>+49-331-567-7625
> > >>>>
> > >>>>_______________________________________________
> > >>>>Developers mailing list
> > >>>>Developers at cactuscode.org
> > >>>>http://www.cactuscode.org/mailman/listinfo/developers
> > >>>
> > >>>
> > >>>--
> > >>>Erik Schnetter <schnetter at cct.lsu.edu>
> > >>>
> > >>>My email is as private as my paper mail. I therefore support encrypting
> > >>>and signing email messages. Get my PGP key from www.keyserver.net.
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>>_______________________________________________
> > >>>Developers mailing list
> > >>>Developers at cactuscode.org
> > >>>http://www.cactuscode.org/mailman/listinfo/developers
> > >>
> > >>
> > >>--
> > >>Steve White : Programmer
> > >>Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut
> > >>Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625
> > >>
> > >>_______________________________________________
> > >>Developers mailing list
> > >>Developers at cactuscode.org
> > >>http://www.cactuscode.org/mailman/listinfo/developers
> > >
> > >
> > >
>
> > _______________________________________________
> > Developers mailing list
> > Developers at cactuscode.org
> > http://www.cactuscode.org/mailman/listinfo/developers
>
>
> --
> Steve White : Programmer
> Max-Planck-Institut für Gravitationsphysik Albert-Einstein-Institut
> Am Mühlenberg 1, D-14476 Golm, Germany +49-331-567-7625
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
--
Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany +49-331-567-7625
More information about the Developers
mailing list