I know the MSVC compile is a bit slower and produces slightly smaller MP3s, but my question is whether or not this is ABXable with --alt-preset standard? Like, am I getting a better MP3 with the ICL compile or is it negligable? My ears just aren't good enough - anyone?

The difference shouldn't be noticeable, but I'd never trust an ICL compile myself.

Could you please explain that a little more?

ICL occasionally miscompiles stuff, you don't always notice it right away.

The 'trusted' LAME compiles have been checked though, so they should be safe.

Well, I'd say that msvc also sometimes miscompiles things and gcc too.

Those are just programs made by programmers, there can be bugs.

The difference is in the frequency.

I'm really curious to know speed and quality results of these compilers:

- DJGPP
- LCC-Win32
- Digital Mars
- Borland
- Open Watcom
- MinGW
- TenDRA



Thanx a lot !

Both DJGPP and MinGW are based upon GCC and other GNU utils.
DJGPP = DOS port
MinGW = native Win32 port
Additionally there is cygwin, which is a UNIX compatibility layer for Win32 used to port *nix apps over with almost no modifications to the original code.

dev0

Err?

Isn't the same source code compiled with whatever compiler supposed to generate the same results each time? How does it come that there's a difference between ICL and MSVC compiles? That an issue with the math libraries they use?

No, the results will depend on the optimizations the compiler performs. For example, one time a wrote a simple reverb that worked perfectly in VC++ and blew up in ICL release mode (worked fine in ICL debug mode).

Chun-Yu:

I have a nice example, using 2 lines of integer C code without any library call, which gives the wrong result in VC++ and the right one on all other compilers

Reported to M$ 3 years ago, still not fixed.

The thing is, when dealing with floating point numbers, some compilers round differently and use different precisions. as a result. MSVC tends to make mp3s a bit smaller than the recommended ICL compile.

I'm still wondering if this is an audible difference... anyone?

Really? What is it?

I have a stronger example on my main computer (currently inaccesible / put in boxes - I'm moving places).

However, I can remember of this one:

void testing()
{
int toto=32;
int u=1<<32; // gives u=0 - ok
int v=1<<toto; // gives u=1 instead of 0
}

Microsoft claims a correct result is not guaranteed with toto >= 32. I answered them: in this case, why do I see no compilation warning - you bunch of morons

For the record, this behavior is related with Intel's x86 SHR and SHL instructions - which are badly implemented since the 8086

This strange behavior (using VC++) was a major factor in the failure of digital signature authentication units for ballistic missiles in the U.S army.

Cheers

You are writing code that is undefined per spec and you complain the result is undefined?

Pot. Kettle. Black.

Actually the spec is vague and permissive on this point. This is very much like the max_huff "bug" in winamp versions of the past..

Anyway, that was just an example I had in mind. The real one is in an obscure path on the other pc


umm.. What do you mean?

Well, this seems like a bug in MSVC, the behaviour is probably defined in IEEE standard...
But it might be that you've enabled some math optimizations similar to GCCs -ffast-math

Not completely: they say that an undefined behaviour is allowed in the case "left or right shift over X bits or more" where X is the integer type's number of bits.


Nope.. plain default config of VC++ 6.0. BTW, it's not floating-point stuff (so FP math optimizations would have few effect on this - if any).

Actually -ffast-math does also fixed-point optimisations...
-funsafe-math-optimizations does only floating-point ones.
-ffast-math implies -funsafe-math-optmizations

Is there any standard which specifies proper behaviour?

<edit>
Spelling, spelling, spelling... (that should be my mantra)
</edit>