On Tuesday, August 6, 2013 10:18:05 AM UTC+2, Cactus wrote: > > 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. > > It seems that Bill's repo is a little behind yours so does not include you ICC fixes. (Just look at the commit lists on both github repos.)
> 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. > I think the easiest way is to decide of one of the git repo being the canonical one, in the spirirt of the central svn server. The main advantage of git is that you can still read logs, commit, push thing on your own repo even when you don't have internet access, or when the one administrating the canonical repo is unavailable. Then all your changes can get merged into the canonical repo by its admin, and you can merge changes made by others and merged into the canonical repo into your repo as well. Of course with SVN it's easier to track bug down as you don't have any choice: as soon as you push it gets to the central server. The way I configure my local repo (i.e. on my computer, not my github account) to follow my github repo and the "canonical one" is as follow: * I initially forked the "canonical" repo on github, this used to ease "pull requests" but I think it's not necessary anymore with the github updates, * I then "git clone ssh://<github> <local-name>" the github repo on my devel pc, this way I can later just "git push origin <branch-name>" my changes back to my github repo * I add the canonical repo (let's say Bill's one) as a remote "git add remote wbhart https://github.com/wbhart/mpir"; To update my local repo then: * "git fetch --all" to sync all remote branches (including the "origin" one, which in my setup reflects my github repo), note this won't change anything in your local branches in contrary to "git pull" which is kind of evil and should only be used if you want a read-only access to a repo * (you first have to make sure to be in your local branch: "git checkout master" in case you wandered around) * I merge back the updated canonical branch into my local branch: "git merge hart/master"; of course there might be conflicts, if so, I fix them * (a nice feature here is that git nows that my local branch comes from the github repo and will tell me that my local branch is now a few commits ahead of the github one) * I push my updated local branch to my github repo "git push origin master" If the admin wants to pick some of my changes and integrate them he basically do the same: * add the branch as a remote * merge the branch into master, or cherry-pick commits for more fine-grained control of what goes in Github also gives you the opportunity to do that from the web interface using "pull requests". Best, > > 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.
