Compiler errors with XE 2013 update 3 and Xcode 4.6.1

Compiler errors with XE 2013 update 3 and Xcode 4.6.1

I reported this a while back but it still hasn't been fixed in update 3 and has existed ever since XE 2013 was released.  I've been using icc since version 9 and have never had a problem compiling with icc until XE 2013.  I'm currently forced to stick with icc 12.1 and Xcode 4.3.3 because Xcode 4.6 isn't compatible with icc 12.1 but I can't compile/link my code with icc 13.

The problem is while compiling, I get an error such as:

as:file(/var/folders/1x/3r5xn5m12zl0rxbmj69htmnr0000gn/T/icc-13as_.s) Can't open source file for input! No such file or directory.Command /usr/bin/icc-13.0 failed with exit code 1

Sometimes it only happens to one file, sometimes it's multiple files.  It's not always the same files.  If I clean and rebuild, I'll get a different set of files that get the error.  If I build again without cleaning, the files that wouldn't compile the first time get compiled but then I get a whole lot of missing symbols at the linking step.  I don't think it's a problem with my development environment because I've setup a freshly installed 10.8 system with Xcode 4.6.* and tried compiling my code with the exact same problems.  As I mentioned earlier, I have no problem when using Xcode 4.3.3 with icc 12.1; this problem is unique to icc 13.

My guess is that icc 13 has problems compiling in parallel.  If I limit the number of concurrent compile tasks in Xcode to 1 using

defaults write com.apple.dt.Xcode IDEBuildOperationMaxNumberOfConcurrentCompileTasks 1

I have no problem with icc 13.  This isn't a practical solution though because it's painfully slow. Any ideas?

7 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

>>My guess is that icc 13 has problems compiling in parallel. If I limit the number of concurrent compile tasks in Xcode to 1 using
>>
>>defaults write com.apple.dt.Xcode IDEBuildOperationMaxNumberOfConcurrentCompileTasks 1
>>
>>I have no problem with icc 13. This isn't a practical solution though because it's painfully slow. Any ideas?

I'm confused because it was just announced that a problem with parallel compiling is solved.

Or,

Is it Solved for Windows platforms and still Not Solved for all the rest platforms? Could Intel software engineers clarify, please?

I think the problem with XE 2013 for Windows was that update 2 broke compiling files in parallel whereas it has never worked properly on the Mac version for me.  I find it hard to believe that I'm the only Mac user that has come across this problem so I have to believe that I'm affected because my project has 1000+ files not including headers.

From looking at the error message, it looks like icc is using icc-13as_.s as a temp filename.  If so, it makes you wonder how it ever works when files are built in parallel.

I've found a solution to the problem which I hope will be fixed in a future update.  I use the -save-temps option to leave the temporary files behind.  Unfortunately, they're left behind in my project directory so I have a pre- and post-build script that cleans up the .s files that are left behind.  I also had to turn off precompiled header support for llvm.

Hi chinhster,

Sorry for the delayed response.  We are interested in reproducing this problem.  Is it possible for you to upload your project or email it to me?  I'm sending you my email thru a private message.

Thank you.
--
Feilong H.
Intel Developer Support

Tools Knowledge Base:  http://software.intel.com/en-us/articles/tools

引文:

chinhster 写道:
I find it hard to believe that I'm the only Mac user that has come across this problem so I have to believe that I'm affected because my project has 1000+ files not including headers.

From looking at the error message, it looks like icc is using icc-13as_.s as a temp filename.  If so, it makes you wonder how it ever works when files are built in parallel.

Hi chinhster,

We tried very hard to reproduce this issue -- including parallel compilation of a project with 10000 files... to no avail. Everything works fine.

The *.s file name compiler generates should include a random combination of numbers and letters after "as_" suffix (we use mkstemp to produce it). We have no idea why in your case this random combination is not added properly.

Any help with reproducing this issue would be very much appreciated.

Andrey

Hi chinhster,

Finally, I got some good news! Engineering team believes that they've found the reason of the failure and will fix it in next 14.0 update (Update 2), which is expected in Q1'14. Please note that the schedule is subject to change without any notices.

We are sorry for taking so long to catch and fix the defect. Appreciate your patience and testing. If you wish to make sure our fix resolves the problem, I can ask engineering team to provide patched 14.0 compiler for testing.

Thanks,
Feilong

Hi chinhster, All,

This has been fixed in 14.0 Update 2, available now.

Thank you for your patience -- and sorry for not catching and fixing the bug sooner.

Yours,
Andrey
 

登陆并发表评论。