Re: GCC vs MSVC compiler issues in a port

[John Cotton Ericson <Ericson2314 at yahoo dot com>]

On 12/22/2012 11:30 AM, Andrew Haley wrote:
> You need to start with an unoptimized build; does it crash in the same 
> way? What about building with -Wall ?
I have been using no optimization other than -ffast-math. Whether or not 
I used -msse and -march=native or -mi386 I get arithmetic overflows 
without -ffast-math.

I am looking at the warnings with -Wall. Nothing too interesting but 
I'll try to resolve them.

On 12/22/2012 07:10 AM, Oleg Endo wrote:
> 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.
I agree, I tried to make my inline assembly as match the original as 
much is possible. But you just can't rule it out while it's still there. 
For testing would you recommend something like 
http://check.sourceforge.net/ ?
> 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.
Yes, voxlap is quite the time capsule. Whatever version of MSVC the 
original author used must have been perfectly awful.
> 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.
Hopefully with -Wall I will catch things like this.
> Last but not least, you haven't mentioned which GCC version you're 
> using. It would be good to know that.
On Linux I have 4.7.2.

Another possible lead is that I have heard that switching between Intel 
and at&t syntax in inline assembly blocks messes with gcc extended asm. 
I often have whole blocks Intel and  noprefix to make comparing the MSVC 
inline asm easier.

Thanks, both of you,

John