Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

[Bugs] Assembler Errors

hyungseok
Beginner
1,231 Views
When I tested the latest ICC for my research, I found several interesting bug cases.
 
```
$ ./bin/icc32 -v
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and
will be removed from product release in the second half of 2023. The Intel(R)
oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward.
Please transition to use this compiler. Use '-diag-disable=10441' to disable
this message.  icc version 2021.8.0 (gcc version 7.5.0 compatibility)
```
 
### Emit invalid byte
 
First, ICC does not correctly check assembly syntax and produce an invalid byte.
 
```
$ cat buggy1.s
.intel_syntax noprefix
     vaddpd ZMM0, ZMM0, ZMM0, 1
 
$./bin/icc32 -c buggy1.s -o buggy1.o -diag-disable=10441
 
$ ./bin/objdump -d buggy1.o -M intel
 
buggy1.o:     file format elf32-i386
 
Disassembly of section .text:
 
00000000 <.text>:
   0: 62 f1 fd 48 58 c0     vaddpd zmm0,zmm0,zmm0
   6: 01                   .byte 0x1
 
```
We found similar cases from the following 65 opcode:
vaddpd, vaddps, vaddsd, vaddss, vcomisd, vcomiss, vcvtdq2ps, vcvtpd2dq,
vcvtpd2ps, vcvtpd2qq, vcvtph2ps, vcvtps2dq, vcvtps2pd, vcvtps2ph, vcvtps2qq,
vcvtqq2pd, vcvtqq2ps, vcvtsd2si, vcvtsd2ss, vcvtsi2ss, vcvtss2sd, vcvtss2si,
vdivpd, vdivps, vdivsd, vdivss, vexp2pd, vexp2ps, vgetexppd, vgetexpps,
vgetexpsd, vgetexpss, vmaxpd, vmaxps, vmaxsd, vmaxss, vminpd, vminps, vminsd,
vminss, vmulpd, vmulps, vmulsd, vmulss, vrangepd, vrangeps, vrangesd, vrangess,
vrcp28pd, vrcp28ps, vrcp28sd, vrcp28ss, vreducepd, vreduceps, vreducesd,
vsqrtpd, vsqrtps, vsqrtsd, vsqrtss, vsubpd, vsubps, vsubsd, vsubss, vucomisd,
and vucomiss.
 
### Transform register to label.
 
Also, ICC recognizes registers as labels when it handles to lldt, verr, and verw instructions.
```
$ cat buggy2.s
     lldt R8D
     verr RAX
     verr RSP
     verw R13D
$ ./bin/icc32 -c buggy2.s -o buggy2.o  -diag-disable=10441
 
$ objdump -d buggy2.o -M intel
 
buggy2.o:     file format elf32-i386
 
Disassembly of section .text:
 
00000000 <.text>:
   0: 0f 00 15 00 00 00 00 lldt   WORD PTR ds:0x0
   7: 0f 00 25 00 00 00 00 verr   WORD PTR ds:0x0
   e: 0f 00 25 00 00 00 00 verr   WORD PTR ds:0x0
  15: 0f 00 2d 00 00 00 00 verw   WORD PTR ds:0x0
 
```
 
### Memory size check bugs
 
ICC does not correctly check memory size when it comes to clflush, clflushopt, clwb, invlpg, prefetch, prefetcht0, prefetcht1, prefetcht2, prefetchw, and prefetchwt1 instructions.
 
```
$ cat buggy3.s
.intel_syntax noprefix
    clwb WORD PTR [RAX+1]
    invlpg WORD PTR [RAX+1]
    clflush ZMMWORD PTR [RAX]
    prefetch QWORD PTR [RAX]
    prefetchw YMMWORD PTR [RAX+1]
    clflushopt WORD PTR [RAX]
    prefetcht0 YMMWORD PTR [RAX]
    prefetcht1 DWORD PTR [RAX+1]
    prefetcht2 ZMMWORD PTR [RAX+1]
    prefetchwt1 ZMMWORD PTR [RAX+1]
 
$ ./bin/icc64 -c buggy3.s -o buggy3.o -diag-disable=10441
 
$ ./bin/objdump -d buggy3.o -M intel
 
buggy3.o:     file format elf64-x86-64
 
 
Disassembly of section .text:
 
0000000000000000 <.text>:
   0: 66 0f ae 70 01       clwb   BYTE PTR [rax+0x1]
   5: 0f 01 78 01           invlpg BYTE PTR [rax+0x1]
   9: 0f ae 38             clflush BYTE PTR [rax]
   c: 48 0f 0d 00           rex.W prefetch BYTE PTR [rax]
  10: 0f 0d 48 01           prefetchw BYTE PTR [rax+0x1]
  14: 66 0f ae 38           clflushopt BYTE PTR [rax]
  18: 0f 18 08             prefetcht0 BYTE PTR [rax]
  1b: 0f 18 50 01           prefetcht1 BYTE PTR [rax+0x1]
  1f: 0f 18 58 01           prefetcht2 BYTE PTR [rax+0x1]
  23: 0f 0d 50 01           prefetchwt1 BYTE PTR [rax+0x1]
```
 
### Operand type check bugs

ICC transforms a memory operand as immediate value in case of
loop, loope, and jexcz instructions.
 
```
$ cat buggy4.s
.intel_syntax noprefix
     loop YMMWORD PTR [1]
     jecxz YMMWORD PTR [1]
     loope XMMWORD PTR [1]
 
$ ./bin/icc64 -c buggy4.s -o buggy4.o
 
$ ./bin/objdump -d buggy4.o -M intel
 
buggy4.o:     file format elf64-x86-64
 
 
Disassembly of section .text:
 
0000000000000000 <.text>:
   0: e2 00                 loop   0x2
   2: 67 e3 00             jecxz  0x5
   5: e1 00                 loope  0x7
```
0 Kudos
10 Replies
NoorjahanSk_Intel
Moderator
1,162 Views

Hi,


Thanks for posting in Intel Communities.


The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler.


We suggest you to use latest Intel oneAPI DPC++/C++ Compiler (ICX) instead of Intel C++ classic compiler(icc).


If you still face the same issue with icx compiler, the please provide us with below details so that we can investigate at our end.


1. sample reproducer and steps you have followed to observe these results.

2. Also please provide the expected result we should see here in all cases.

3. OS details.

4. Hardware Details


Thanks & Regards,

Noorjahan.


0 Kudos
hyungseok
Beginner
1,136 Views

Hi, Noorjahan

 

Thank you for replay.

 

The all reported results were already tested with ICPC in Intel(R) oneAPI.

    ./bin/icc32 = oneapi/compiler/2023.0.0/linux/bin/ia32/icpc

    ./bin/icc64 = oneapi/compiler/2023.0.0/linux/bin/intel64/icpc

So, you can reproduce all the bugs I reported

 

2. Expected Results
- I expect ICPC precisely checks assembly syntax and print error message when the given assembly code is incorrect.
 
3. OS: Ubuntu 20.04
 
4. H/W: Intel Xeon E5, 512 GB RAM
 
 
Thank you.
 
B.R.
Hyungseok
0 Kudos
NoorjahanSk_Intel
Moderator
1,089 Views

Hi,


Thank you providing the details.


Could you please provide a sample code(.c/.cpp) instead of assembly code which replicates your issue so that we can try investigating it at our end?


Also please let us know whether you observe similar issue with latest Intel oneAPI C++ compiler(ICX) compiler.


Thanks & Regards,

Noorjahan.


0 Kudos
hyungseok
Beginner
1,072 Views

Hi, Noorjahan

 

I conducted testing on assembly code, rather than a high-level language like C/C++.

Under specific conditions, ICPC/ICX might generate the aforementioned code, but I haven't verified it as of now.

I have a belief that any errors in this code could potentially impact the reliability of the software product, as inline assembly is permitted in C/C++.

 

Thanks, 

Hyungseok Kim

0 Kudos
NoorjahanSk_Intel
Moderator
989 Views

Hi,

 

Regarding the issue of emitting an invalid byte with ICC compiler, we tried with ICX compiler, and is generating a correct assembly. ICC is deprecated, we recommend you to use the ICX compiler instead of ICC. 

Please refer to the below results with the ICX compiler(2023.2).

NoorjahanSk_Intel_0-1697536051921.png

 

Regarding other issues, we were also able to observe similar behavior. Could you please provide an expected result for the remaining cases( Transform register to label, Memory size check bugs, Operand type check bugs)for 64 bits so that it will be helpful for us to investigate more on your issue?

 

Thanks & Regards,

Noorjahan.

 

0 Kudos
hyungseok
Beginner
943 Views

Hi, Noorjahan

 

Thank you for reply. 

I checked that the latest ICX is free from the bug found in buggy1.s.

Additionally, ICX also share similar problems regarding other issues. 

Assembly lines in buggy files contains syntax errors according to Intel manual.

However, the current ICX does not identify these errors.

I believe ICX should strictly check assembly syntax to prevent mis-use of assembly.

 

Best Regards,

Hyungseok Kim

0 Kudos
NoorjahanSk_Intel
Moderator
928 Views

Hi,


>>latest ICX is free from the bug found in buggy1.s.

Thank you for trying with icx compiler.


>>Assembly lines in buggy files contains syntax errors according to Intel manual.

Could you please let us know which Intel manual you are referring here?


Also please let us know 

What is the reason you had to dig deeper into the assembly?

How do the issues affect your job (or is it just an observation?)


Thanks & Regards,

Noorjahan.


0 Kudos
hyungseok
Beginner
917 Views

Hi, Noorjahan.

 

We are researchers developing a way to test assemblers.

We found those bugs in the course of our research.

 

Also, we referred the manual provided on the Intel website

I have attached the relevant pages from the latest Intel Manual (September 2023)

that relate to the error code.

 

buggy2.s

(Vol.2C 5-156) VERR instruction only can accept a 16-bit register or 16-bit memory as its operand.

Thus, 'verr RAX' is incorrect.

buggy2.png

buggy3.s
(Vol.2A 3-152) CLFLUSH instruction only can accept a 8-bit memory as its operand.

Thus, 'clflush ZMMWORD PTR [RAX]' is incorrect.

buggy3.png

 

buggy4.s

(Vol.2A 3-615) LOOPE instruction only can accept a 8-bit size relative address as its operand.

Thus, 'loope XMMWORD PTR [1]' is incorrect.

buggy4.png

Best Regards,

Hyungseok Kim

0 Kudos
NoorjahanSk_Intel
Moderator
742 Views

Hi,


buggy2.s:

RAX is recognized as a label instead of register, which is a immediate-like memory operand. So the compilers are correct.


buggy3.s:

CLWB takes a 8-bit memory operand. So "clwb WORD PTR [RAX+1]" is incorrect. Instead, we should use "clwb BYTE PTR [RAX+1]" so that icx compiler can accept it.


Regarding buggy4.s, our developers are working on it. We will get back to you soon. 


Thanks & Regards,

Noorjahan


0 Kudos
hyungseok
Beginner
289 Views

Hi, Noorjahan.

 

Thank you for your response. I have a few opinions regarding this matter.

 

buggy2.s:

If an assembler interprets a register name as a label, it can lead to ambiguity.

For instance, if an assembler permits using "RAX" as a label, it becomes uncertain what the instruction "call RAX" actually means.

Therefore, I believe it is preferable for an assembler to prohibit the use of register names as labels.

 

buggy3.s:

You are right. That is incorrect syntax.

I believe that an assembler ought to generate an error message whenever encountering invalid syntax.

 

Best Regards,

Hyungseok

0 Kudos
Reply