[Users] Meetig minutes

[Steven R. Brandt]

I don't see why we can't run both with and without debug. Both will 
detect different sorts of errors.

I wonder if it makes sense to have a series of short tests that run 
under valgrind.

Cheers,
Steve

On 09/26/2011 02:42 PM, Erik Schnetter wrote:
> When running test case, I would use a configuration as similar as
> possible to production runs, so that errors in production runs are
> actually caught. There are some differences between debug and
> optimized configurations, and these are mostly to help people track
> down problems, not to ensure that optimized configurations are
> correct. I would thus suggest that running test cases with an
> optimized configuration is a must, and with a debug configuration is a
> nice addition.
>
> For example, sometimes code is #ifdef'd out in optimized runs, leading
> to undefined variables that are well defined when debugging. Another
> example is vectorization that is (by default) disabled without
> optimization, because without optimization, compilers often do a
> really lousy job, and vectorized code thus runs a few times slower
> than unvectorized code.
>
> Regarding segfaults in Fortran: why don't unallocated variables lead
> to an error in Fortran? Do you refer to Fortran allocation or Cactus
> allocations here?
>
> -erik
>
> On Mon, Sep 26, 2011 at 1:20 PM, Roland Haas
> <roland.haas at physics.gatech.edu>  wrote:
>> Hello all,
>>
>>> * run testsuites for release:
>> It might be a good idea to configure the testsuite configurations with
>> DEBUG=yes to catch as many errors as possible (in particular for the daily
>> testsuite runs). Otherwise eg. variables without storage can remain
>> unnoticed under Fortran (while they casue an immediate segfault under C).
>>
>> Yours,
>> Roland
>>
>> --
>> My email is as private as my paper mail. I therefore support encrypting
>> and signing email messages. Get my PGP key from http://keys.gnupg.net.
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at einsteintoolkit.org
>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>
>>
>
>