- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear developers,
Please consider the following code snippet.
Compiled with GCC or Clang, it prints "abcdefghijklmno" but with ICC, it prints junk bytes.
The problem here is that when an entry allows only memory constraint, both GCC and Clang interpret the following expression as an lvalue, whereas ICC interpret it as an expression either way.
Thus, here, the token %1 is "expected" to be substituted by the address of the memory block pointed by s but is substituted by an address that point to the value of s here.
This behavior is not really documented, but still, casting a pointer to an array type is suggested in the examples given by GCC here.
So, I am wondering if this difference is made on purpose by ICC or if it could be considered as a bug.
Best regards,
Frédéric Recoules
#include <stdio.h> static inline void copy128(void *d, const void *s) { __asm__("movaps %1, %%xmm0 \n\t" "movaps %%xmm0, %0 \n\t" : "=m"(*(char (*)[16])d) : "m" (*(const char (*)[16])s) : "xmm0"); } int main (int argc, char *argv[]) { const char t[16] = "abcdefghijklmno"; char u[16]; copy128(u, t); printf("%s\n", u); return 0; }
- Tags:
- Bug
- CC++
- Development Tools
- Intel® C++ Compiler
- Intel® Parallel Studio XE
- Intel® System Studio
- Optimization
- Parallel Computing
- Vectorization
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Frédéric,
Thanks for reaching out to us!
We are able to reproduce the issue you are facing in our environment. We are working with the concerned team and we will let you know the status.
Regards
Goutham.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Goutham,
I am sorry that I have only just answered, but I wish to thank you for the support.
Yet, I do not really need this issue to be fixed.
If I wanted to make it work, I would cast the pointer to a compound type (struct or union) containing an array instead of a raw array. I saw this behavior in FFMPEG:
# 67 "./libavutil/x86/intreadwrite.h" static inline void AV_COPY128(void *d, const void *s) { struct v {uint64_t v[2];}; __asm__("movaps %1, %%xmm0 \n\t" "movaps %%xmm0, %0 \n\t" : "=m"(*(struct v*)d) : "m" (*(const struct v*)s) : "xmm0"); }
I am more interested in your thought on this issue.
And if it would not be fixed, I would appreciate you to add a note in your documentation as a known issue that a given array in an input entry will not be interpreted as GCC uses to.
Regards,
Frédéric
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I think that is a good workaround.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the confirmation!
As this issue has been resolved, we will no longer respond to this thread.
If you require any additional assistance from Intel, please start a new thread.
Any further interaction in this thread will be considered community only.
Have a Good day.
Thanks & Regards
Goutham
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page