On 28 Aug., 13:46, Martin Albrecht <[email protected]> wrote: > Just to emphasise: I am looking for a way to maintain consistency with > M4RI and not a way to figure out whether the machine supports SSE2. > This, we already check for in M4RI. If we are using SSE2 in M4RI > (which we for example don't do on Opterons even though they support it > for performance reasons) then some functions and some parts of the > matrix layout are changed. Thus, want Sage and PolyBoRi to agree with > M4RI.
So I don't really understand what your problem is. If 'configure' determined the machine supports SSE2, __M4RI_HAVE_SSE2 is set to 1, but even if that's the case, you should still also test __SSE2__ when compiling code later (including code *using* the library). Does your trouble reduce to *enabling* SSE2 when compiling later, if you *know* that the machine [in theory] supports it and you want to use it? If so, in which contexts? > > If the actual machine supports SSE2, gcc normally enables -msse2, > > unless it is "ill-configured" or you pass contrary options, like for > > example -march=i486. > > It seems cicero is ill-configured. :-) I.e., just passing '-msse2' (without any other processor/ architecture-specific options) to gcc there solves your problem? Do you use the *same* functions in both cases, and untagged differing matrix layout, without any global "flag" indicating that, such that this extends to a compatibility problem between code [even when compiled on the same machine], some using "SSE2 mode", some not? Is there a specific ticket (other than the M4RIE one) for this issue? If not, you can open one and cc me. I'm also on #sagemath btw., or feel free to mail me off-list. -leif -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
