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.


Reply via email to