icc -masm=intel generating invalid/unrecognized assembly?

[Sylvain_C_]

Hello,

I am building code that contains some asm() blocks written following Intel assembly syntax. When I compile this code for the MIC with -masm=intel, I get an assembler error, which is not related to the asm() blocks. Attached is a simple repro case that produces the following error:

$icc -masm=intel -mmic repro.c
/tmp/iccNPhpMMas_.s: Assembler messages:
/tmp/iccNPhpMMas_.s:51: Error: operand size mismatch for `vaddpd'

The offending instruction is:

vaddpd    zmm0{k1}, zmm0, QWORD PTR .L_2il0floatpacket.1[rip]{1to8}

I am running icc 13.1.0 under Linux x64. Is Intel-syntax assembly supported under this configuration? Is this a known issue, and is there any workaround (besides rewriting assembly blocks using AT&T syntax)?

Thanks.

[Kevin_D_Intel]

I can reproduce this, but I do not currently know what triggers the error. I will report this to Development and post again when I know more about that.

The option would not prevent using asm in your code; it influences the assembly dialect used for the assembly listing file. You should be able to compile w/o the option for producing a native executable if that was the interest.

[Sylvain_C_]

Thanks!

I cannot compile without -masm=intel, because the code contains asm blocks using Intel syntax such as:

asm("add %0, 7" : "+r" (a) : );

instead of the AT&T syntax traditionally used in gcc-style asm statements:

asm("addl $7, %0" : "+r" (a) :);

These instructions will fail to assemble unless the assembler is set to expect Intel syntax. Compiling with -masm=intel has been working fine with both gcc and icc for non-MIC targets.

I believe I can avoid the issue by emitting assembler directives enabled by conditional compilation:

#ifdef ATT_SYNTAX

#define ASM_PREFIX ".intel_syntax noprefix \n"

#define ASM_SUFFIX ".att_syntax \n"

#else

#define ASM_PREFIX

#define ASM_SUFFIX

#endif

asm(ASM_PREFIX "add %0, 7" ASM_SUFFIX : "+r" (a) : );

This way, the assembly generated remains valid regardless of the syntax used for code generation. Is there by any chance a built-in preprocessor macro that reports the value of the -masm option?

[Sylvain_C_]

Forget what I said, the workaround above does not work (neither in icc nor gcc). It just generates garbage that mixes both dialects, since the compiler now believes the asm statements use AT&T syntax.
The code really needs to be compiled with the -masm=intel option.

[Kevin_D_Intel]

Sorry to hear this issue is blocking your progress. Our compiler Developer confirmed the asm generated by the compiler is correct and indicates the underlying issue (and error) involves the GNU assembler provided as part of MPSS in support of Xeon Phi™. I will route this issue to the MPSS Development team for further analysis and post again when I hear more.

[Kevin_D_Intel]

I just learned there is a change/fix to the assembler targeted for an MPSS release tentatively in the mid-Q1 '14 timeframe.

I will keep you updated on the availability as I learn it.

[Sylvain_C_]

Thank you Kevin for following up on this issue.
I am looking forward for this MPSS release.

[Kevin_D_Intel]

I just learned and confirmed your test case now compiles successfully using the updated GNU assembler provided with the MPSS 3.2 release. Hopefully you will be able to move forward with your development after obtaining the new release.
Refer to Intel® Manycore Platform Software Stack (MPSS) for information about available releases.

[Sylvain_C_]

Great! Thanks again for for your help in getting the issue fixed.