Retain GCC syntax compatibility while building on Windows?

[M_G]

Hello all,

I work for a company that develops a product which ships on Linux and Windows. Portions of the code make heavy use of GCC-specific syntax, and therefore we use a mix of MinGW GCC and MSVC to build for Windows. This hybrid build unfortunately cannot be debugged on Windows using either GCC or Visual Studio, so we are looking to consolidate on one tool and I'm currently evaluating the Intel compiler.

Does the Intel compiler for Windows provide an option where it will accept GCC-syntax code but still output MSVC-compatible shared libraries? Based on the documentation, it looks like I need something similar to the 'fms-dialect' option, but reversed. Any help or insight is greatly appreciated.

Thanks,

Mario

[JenniferJ]

Hi,
Our coming compiler 13.0 does have a new option "/Qgcc-dialect" that would be the solution for you then.

But our 13.0 beta has just ended though. let me check if we could provide the13.0 beta download at least so you can give it a try.

Jennifer

[SergeyKostrov]

Hi Mario,

Quoting M G

...Portions of the code make heavy use of GCC-specific syntax, and therefore we use a mix of MinGW GCC and MSVC to build
for Windows. This hybrid build unfortunately cannot be debugged on Windows using either GCC or Visual Studio...

I'd like to share some experience on resolving a similar problem.

A project I'm currently working for is highly portable and could be compiled with:

- Microsoft C++ compilers (Visual Sudio 98\2005\2008\2010Professional Editionor Express Edition)
-Intel C++ Compiler XE ( Version 12.x.x \Integrated with Visual Studio 2005 Professional Edition)
- MinGW C++ compiler ( Version 3.4.2\Integrated with Visual Studio 2005 Professional Edition )
- Borland C++ compiler ( Version 5.x.x\Integrated with Visual Studio 2005 Professional Edition )
- Turbo C++ compiler ( Version 3.x.x\Integrated with Visual Studio 2005 Professional Edition )

The high level of portability was achieved by introducing three abstraction layers:

- Hardware Run-Time( "wraps" any usageof Assembler,SSE, SSE2, intrinsic functions,etc)
- C Run-Time("wraps" anycallsto CRT-functions)
- Platform Run-Time ( "wraps" any calls to a platform dependent APIs, like Win32 API for a Windows OS, etc)

First two layersisolated codesfromANY Microsoft technologies. However, all development and debuggingare
done on a 32-bitWindows XP usingsome version ofVisual Studio. MinGW, Borland and Turbo C++ compilers are
integrated using makefile projects.

A very strict constraintis imposed: it is NOT allowed to call"something" directly andit has to be "wrapped"
by some codein some abstraction layer.

I wouldn't call the source codes as "hybrid" because they are, as I've mentioned before, highly portable. An overall
structure of all these abstraction layers was a result of a significant R&D ( more than 6 months ), then it was
integrated with some number of existing C/C++projects ( more than 9 months ), and some tune ups (during last 1.5 years ).

If your project wasn't designed from the beginning in a similar way you shouldrely on some "magic technology",
like latest version of some C++ compiler.

Take into account that a consolidation with one C++ compiler is NOT a solution of all problems and this is
exactly what wasn't on the list during ourR&D phase. An opposite target was set: let's try to compile codes with
as many as possible modern and legacy C++compilers.

Best regards,
Sergey