Nikos Mavrogiannopoulos <[email protected]> writes: > Looks nice. About the __attribute__((constructor)), you are > restricting it to GNUC only, while it seems to be available more > widely.
I do have a configure check, setting HAVE_GCC_ATTRIBUTE, based on compiling a test program using __attribute__((noreturn)). Maybe I could use that, and the __sun hack? I know both intel and llvm compilers attempt to be gcc compatible (sometimes too compatible, I've heard some versions of the intel compiler added __GNUC__ as a predefined...). Ideally it would be nice with a configure test that checks that constructors actually work, but that's hard to do when cross compiling. > It's early, but it would be nice if the arm neon code was part of fat as well. Sure, that's the next step, once I have a structure I think is workable. Does anyone have a pointer to how to check cpu capabilities on ARM? Another question: We need some kind of memory barrier when writing and/or reading the initialized flag. The (unlikely) failure case is a thread reading the initialized flag, getting 1, and then reading one of the function pointers, and getting a too old value. What barrier-instruction(s) should be used, on x86_64 and ARM? It's probably easiest to add any needed sychronization functions to cpuid.asm, to avoid relying on compiler-specific features. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
