[Users] compiler warning for McLachlan

[Roland Haas]

Hello Ian, all,

> And why would changing the default for VECTORISE_INLINE adversely
> affect these? I'm trying to understand Frank's statement that "people
> are bound to stumble over this when they try the released version".
> Frank, did you mean the soon-to-be  (ET_2011_10)  released version?
> Or the previously released version?  If we change the default to
> VECTORISE_INLINE = no now, then no-one will run into this problem in
> the soon-to-be released version.  Since the change to McLachlan
> didn't exist in the previously released version, it won't affect
> those.
Well someone might have non-simfactory options lists (those exist :-) ) 
and *that* one might say VECTORISE = yes which they want for their own 
private Kranc generated thorn. This way they would stumble across this.

I had wondered about that before: the method to support multiple orders 
of differentiation used in WeylScal4 and Kranc2BSSN.m was not used 
because it requires "unrolling" (exploding really) all choices for the 
combination of parameters at compile time? With lots of "schedule ... 
AS" statements the schedule does not look any different.

What happens if a user tries VECTORISE=yes on say a head of Ranger? Will 
they bring down the node or just have unexplainable compile errors in 
Kranc's generated code?

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20110927/2d4afe55/attachment.bin