- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I've just upgraded to the latest version of Mac OSX compiler (10.1.014), and I'm having some problems with aliasing in members of unions.
I'm compiling with -ansi-alias, and it seems that code like this:
I'm trying to find information on the aliasing rules within a union (which by definition breaks typesafe aliasing rules) and not coming up with much. If I mark the two members as volatile, everything works OK (as one might expect). What's the designed behaviour of the Intel compiler in this situation? Has it changed since the 9.1 releases?
Apparently there is an extension in gcc to make unions work correctly in this situation, but it seems like unions will never work unless the members are volatile?
I've just upgraded to the latest version of Mac OSX compiler (10.1.014), and I'm having some problems with aliasing in members of unions.
I'm compiling with -ansi-alias, and it seems that code like this:
union {breaks with 10.1.014, whereas it worked with 9.1.041.
int i;
float f;
} u;
u.f = 2.718;
printf("The memory word has value %d ", u.i);
I'm trying to find information on the aliasing rules within a union (which by definition breaks typesafe aliasing rules) and not coming up with much. If I mark the two members as volatile, everything works OK (as one might expect). What's the designed behaviour of the Intel compiler in this situation? Has it changed since the 9.1 releases?
Apparently there is an extension in gcc to make unions work correctly in this situation, but it seems like unions will never work unless the members are volatile?
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as I can make out, the remark about this being a gcc specific extension is wrong. The C standard seems to say it is OK, as long as the full definition of the union is visible where the type equivalencing occurs. Anyway, icc is intended to be gcc compatible, so it doesn't look right for icc to reject code which appears standard and acceptable to gcc when equivalent options are set, as you have done. I think that icc doesn't set -ansi-alias as a default, to maintain compatibility with Microsoft compilers, but it should be allowable to set -ansi-alias for standard-compliant code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Whether it's a gcc specific extension or not, I believe that code using unions should work with -ansi-alias set without me having to declare the members of the union volatile. This is why this example:
I think this is a bug - I can send a full test case with a build script if required.
Whether it's a gcc specific extension or not, I believe that code using unions should work with -ansi-alias set without me having to declare the members of the union volatile. This is why this example:
#if __BIG_ENDIAN__works fine with -ansi-alias on icpc 9.1, and gives the wrong answer on icpc 10.1 unless I declare the members of the Double_Long union volatile.
#define iman_ 1
#else
#define iman_ 0
#endif
union Double_Long {
double v;
int word[2];
};
inline long fast_floor(double val) {
Double_Long v; v.v = val + (68719476736.0*1.5);
return v.word[iman_]>>16;
}
I think this is a bug - I can send a full test case with a build script if required.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, preferably filed as a problem report on premier.intel.com.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page