This is the mail archive of the
mailing list for the GCC project.
GCC vs MSVC compiler issues in a port
- From: John Cotton Ericson <Ericson2314 at yahoo dot com>
- To: gcc-help at gcc dot gnu dot org
- Date: Sat, 22 Dec 2012 04:07:04 -0500
- Subject: GCC vs MSVC compiler issues in a port
- References: <50D57597.firstname.lastname@example.org>
For a little over a year I have worked on porting the a voxel engine
called Voxlap to work on Linux. My code is here:
I now can compile the same code with both MSVC and gcc. The MSVC code
runs well enough, but the gcc version does not. Specifically when I run
the MSVC version, everything in-game renders, and a bit of text is
thrown on top as a watermark. When I run the gcc version, all I get is
a black window and that water mark. The problem is exactly whether I
compile on windows with mingw or compile on linux. In both cases I am
compiling the same branch with most of the inline assembly converted to
C, and in both cases I compile against the SDL backend, not the direct X
Because I have done my best to hold everything else constant, I am
pretty convinced this error is either due to some subtle difference's in
the two compile's understanding of the C semantics, or an error in the
gcc version of what inline assembly remains (inline assembly being the
only code I can think of which is #ifdefed based on the compiler).
After a couple of months of sporadically trying to solve this issue, I
am at a loss what to do next. As I did not write the original renderer,
and thus I am only so familiar with it's inner workings. I was hoping
somebody more experience with porting or more knowledge of subtle
differences between gcc and MSVC would be able to help me solve this
issue, which should be the last before I have a basic gcc version ready.
Here is a list of the only "leads" I can think of:
* If I do not use -ffast-math, the gcc version crashes almost
immediately due to an arithmetic overflow. I do not think the MSVC
version with any flags I tried ever had this problem
* I think I onced compared the symbol tables of the same object file
compiled with each compiler and found some differences. However, I have
no idea what differences there are acceptable (besides different
name-mangling schemes) and what ones are not.
* What inline assembly assembly remains is #ifdef-d based on the
compiler. This is the only code I can think of that is compiler-specific.
While the code is saved as a C++ file it contains almost no c++-specific
syntax. A couple of people have asked me about this from time to time,
so I'd include the answer as an addendum.
I wrote a pretty decent (I hope?) history of the port which may be found
in the readme. It may be of use.