This is the mail archive of the
mailing list for the GCC project.
Re: GCC vs MSVC compiler issues in a port
- From: John Cotton Ericson <Ericson2314 at yahoo dot com>
- To: Oleg Endo <oleg dot endo at t-online dot de>, Andrew Haley <aph at redhat dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Sun, 23 Dec 2012 00:39:39 -0500
- Subject: Re: GCC vs MSVC compiler issues in a port
- References: <50D57597.email@example.com> <50D57838.firstname.lastname@example.org> <1356178252.30211.22.camel@yam-132-YW-E178-FTW>
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
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,