Bowtie-1.2 will not compile with Intel

[ghost]

Is there any instructions around for building bowtie-1.2 with the Intel C++ compiler. I am moving forward slowly by modifying header files, which does not seem to be the optimal solution. Any help in this area would be appreciated.

[ch4rr0]

I will look into and get back to you ASAP.

[zyndagj]

Hello,

Has there been any development on supporting the intel compiler?

Thanks,
Greg Zynda

[ch4rr0]

Hello @zyndagj, @mjarsulic

Apologies for the late response.

I was able to get bowtie compiled on macOS using ICPC albeit with lots of warnings. My (rudimentary) changes are below. I will give Linux a shot tomorrow and post the changes if they are any different, and will also provide an official statement on whether or not we plan on officially supporting ICC/ICPC.

index 65196f0..5f91fd4 100644
--- a/Makefile
+++ b/Makefile
@@ -46,8 +46,8 @@ ifneq (,$(findstring Darwin,$(shell uname)))
MACOS_VER_MAJOR = $(shell uname -r | cut -d. -f1)
MACOS_VER_GT_12 = $(shell [ $(MACOS_VER_MAJOR) -gt 12 ] && echo true)
ifeq (true, $(MACOS_VER_GT_12))

•           CPP = clang++
  

•           CC = clang
  

•           CPP = icpc 
  

•           CC = icc
            override EXTRA_FLAGS += -stdlib=libstdc++
    endif
  

endif
diff --git a/SeqAn-1.1/platform_linux_gcc.h b/SeqAn-1.1/platform_linux_gcc.h
index a385cea..abdfe7b 100644
--- a/SeqAn-1.1/platform_linux_gcc.h
+++ b/SeqAn-1.1/platform_linux_gcc.h
@@ -19,7 +19,7 @@
#define finline inline

// default 64bit type
-typedef int64_t __int64;
+// typedef int64_t __int64;

//define SEQAN_SWITCH_USE_FORWARDS to use generated forwards
diff --git a/SeqAn-1.1/seqan/platform.h b/SeqAn-1.1/seqan/platform.h
index d032011..bc344cc 100644
--- a/SeqAn-1.1/seqan/platform.h
+++ b/SeqAn-1.1/seqan/platform.h
@@ -20,7 +20,7 @@

// default 64bit type
#ifndef __int64
-typedef int64_t __int64;
+// typedef int64_t __int64;
#endif

//define SEQAN_SWITCH_USE_FORWARDS to use generated forwards
diff --git a/processor_support.h b/processor_support.h
index f68ee65..b07d8dd 100644
--- a/processor_support.h
+++ b/processor_support.h
@@ -44,8 +44,8 @@ public:

 try {

#if ( defined(USING_INTEL_COMPILER) || defined(USING_MSC_COMPILER) )

•    __cpuid((void *) &regs,0); // test if __cpuid() works, if not catch the exception
  

•    __cpuid((void *) &regs,0x1); // POPCNT bit is bit 23 in ECX
  

•    __cpuid((int *) &regs,0); // test if __cpuid() works, if not catch the exception
  

•    __cpuid((int *) &regs,0x1); // POPCNT bit is bit 23 in ECX
  

#elif defined(USING_GCC_COMPILER)
__get_cpuid(0x1, &regs.EAX, &regs.EBX, &regs.ECX, &regs.EDX);
#else

[zyndagj]

Do you have a separate branch that incorporates these changes? I think the markdown interpreter removed some of the syntax, preventing a patch.

[ch4rr0]

Sorry about that. I will have the changes (for linux and macOS) pushed to a branch by tomorrow am. I hope that works for you.

[zyndagj]

That works! Thanks for the prompt reply.

[ch4rr0]

I was busy looking into another issue. I am getting started on this right now.

[ch4rr0]

I pushed the changes to this branch - https://github.com/BenLangmead/bowtie/tree/bt-v1.2.1. The changes are by no means final, and therefore may be revised before the next bowtie release. Your feedback is appreciated.

Thanks

[zyndagj]

I can report that I compiled this branch of bowtie using the intel 15 compiler without any warnings with the following commands.

git clone https://github.com/BenLangmead/bowtie.git
cd bowtie
git checkout bt-v1.2.1
make CC=icc CXX=icpc EXTRA_FLAGS="-I${TBBROOT}/include -L${TBBROOT}/lib/intel64/gcc4.4 -xHOST"

I am currently testing the output to make sure alignments are comparable to gcc builds.

[boegel]

Has anyone tried building Bowtie 1.2.1.1 with the Intel compilers, or do you have suggestions to fix compilation errors like this:

/prefix/software/GCCcore/6.4.0/bin/../include/c++/6.4.0/bits/stl_algobase.h(343): error: no operator "=" matches these operands
            operand types are: HitSink::batch = HitSink::batch
  	      *__result = std::move(*__first);

see also #77 (comment)