Junio C Hamano wrote:
> Another issue, especially with your "openssl sha1 removal" patch, is if we
> can assume gcc everywhere. As far as I can tell, block-sha1/sha1.c will
> be the first unconditional use of inline asm or statement expression on
> i386/amd64. Are folks on Solaris and other platforms Ok with this?
The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
I think __x86_64 and __amd64 where appropriate. So, compilation with
the SUNWspro compiler on x86 is currently unaffected by these changes and
falls back to the generic routines.
It seems that v5.10 of the compiler can grok both the __asm__ statements
and the ({...}) naked block notation and passes all of the tests when the
block_sha1 code is modified to add defined(__i386) to each of the macro
statements.
The 5.8 version cannot grok the naked block, and requires spelling __asm__
as __asm for inline assembly. Even then it appears that there is a bug in
the assembly that is produced (a google search told me so), so the assembly
code does not successfully compile.
I haven't had much time to think about how or whether to address this.
Adding something like the following would get ugly real quick:
(defined(__i386) && defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
For now, the code compiles fine using the SUNWspro compiler on x86 even if
it is suboptimal compared to gcc. It is still an improvement over the
mozilla code.
-brandon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html