On 06/08/2013 08:47, Cactus wrote: > This is a comment on the item: > > use __INTEL_COMPILER instead of INTEL_COMPILER in longlong.inc files > > on Bill's list of MPIR ToDo items. > > On Linux I believe that the defines for the "Intel compiler version" are > __ICC > and __INTEL_COMPILER. On WIndows the define for the "Intel compiler > version" is __ICL. > > So anywhere where we need to determine that the Intel compiler is to be > used on both Linux and Windows we will need something like: > > #if defined(__ICC) || defined(__ICL) > ... > #endif > > The two compilers are, I believe, highly compatible but there are > differences. I think the Windows Intel compiler can handle GCC style > inline assembler and Windows style inline assembler as well. But I believe > that the Linux Intel compiler cannot handle Windows style inline assembler. > > We will hence have to be careful to use the __ICL macro if we have any > Windows style inline assembler for x86 (there is no inline assembler on > Windows x64). Otherwise, if I am right that the Windows compiler can handle > GCC style inline assembler, detecting both macros should provide the > intended performance gains on both Linux and Windows.
I have just checked this 'bug' in my MPIR GIT master and INTEL_COMPILER doesn't occur anywhere so either I made the correction or I imported it from elsewhere. On another issue, now we have moved to GIT I was hoping to gain experience with it but we have had very little going on for many months now so my experience with GIT is close to zero and I still feel very uncomfortable with it in comparison with SVN. Hence I am still very attached to the idea that there is ONE definitive version of MPIR that we know represents the MPIR that we would release if we did such a release now. Hence, while I know that my MPIR is free of the INTEL_COMPILER define, in contrast to SVN, I don't appear to have any way of ensuring that "MPIR" is free of this issue since there is no MPIR master. Maybe this is simply the result of my lack of understanding of GIT but I miss the single SVN master that we can all see as the definitive state of MPIR and which we can all update as we remove bugs. Brian (I still like SVN and its single master approach as I don't have a clue about "THE DEFINITIVE VERSION OF MPIR" > > Brian > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.