Hello, On Sat, 2012-12-22 at 04:07 -0500, John Cotton Ericson wrote: > Hello, > > 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: > https://github.com/Ericson2314/Voxlap > > 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 > backend. > > 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. This is difficult to answer. I guess the best thing to do in this case would be a full analysis of the code and see how it works and what it's trying to do. I'd suggest to create a pure standard C/C++ version of the code with MSVC, step by step, verifying after each modification that everything still works as expected. For that version it might be simpler to just remove all the ifdef stuff, just to keep it simple. Having a bunch of test cases would be certainly helpful here, too. Then, once the pure C/C++ version works, try compiling it with GCC, initially without optimizations such as -ffast-math. Quickly looking over the code, I'd suspect that there are bugs in the inline asm codes. Also, "optimizations" such as found in the functions "static inline void clearbufbyte (void *d, long c, long a)" or "dmulshr0" are ... from the past, I guess. Another thing that sometimes can be a pain is intentional or unintentional usage of undefined behavior. For example: some_type* p = ...; *p++ = *(p - 1); I'm not sure whether the code you mention has any of these, but that kind of stuff could also be a bug source. Last but not least, you haven't mentioned which GCC version you're using. It would be good to know that. Cheers, Oleg
