- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there,
I'm in the middle of porting a 2 million line code base from PC (built with MSVC) to mac and was having trouble with bus errors when compiles some projects, so I decided to upgrade from update 4 to update 7. Previously to get around the fact that MSVC waves through so much non-standard code I was compiling with "-fms-dialect=10 -U_MSC_VER" which worked a treat. However, on upgrading to update 7, non of my projects build as I get loads of errors, including:
/Developer/SDKs/MacOSX10.6.sdk/usr/include/unistd.h(422): error: expected a "{"
int close(int) __DARWIN_ALIAS_C(close);
I've traced this back and__DARWIN_ALIAS_C is defined as:
__asm("_" __STRING(sym) __DARWIN_SUF_NON_CANCELABLE __DARWIN_SUF_UNIX03)
which I believe to be a gcc asm block. It is therefore my assertion that using -fms-dialect has made icc too compatible with MSVC and thus cannot compile anything that pulls in OSX code.
Can anything be done about this, or am I going to have to roll back to update 4 and try something else to get around my bus errors?
Thanks for any help.
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You maytry -fms-dialect=10 for part of code where you need Micosoft compatibility and rest of the code may compiler without it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, that's not really an option without creating a lot of work. As I said in the original post, I'm porting a massive code base that was developed on PC's and you wouldn't believe (or maybe you would) how many ways the microsoft compiler differs from gcc. I could have saved myself about 2 weeks worth of work if I'ld found out about the compatibility switch sooner :)
The problem I was trying to fix by updating only seems to occur when we use the unity file method of speeding up compilation (including all cpp files in one big include file) so I can always revert to compiling the files individually. I guess I was just hoping for an acknowledgement that the loss of compatibility for both methods of declaring inline assembly is a known issue and will be resolved :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would be nice if you can attach a small reproducer for the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As is the case with so many things - i cannot reproduce this in a small case - and infact, having uninstalled icc completely then reinstalled it, I cannot reproduce it in our project either. Chalk it up to gremlins I guess.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are happy to learn that the reinstallation of icc resolved theissue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just installed update 8 to fix a bus termination error and the problem is back again.
Easy way to reproduce, use the following on the command line: -fms-dialect=10 -fasm-blocks and create a new source file with #include in it.
Easy way to reproduce, use the following on the command line: -fms-dialect=10 -fasm-blocks and create a new source file with #include

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