This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC vs MSVC compiler issues in a port

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 ?
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,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]