[Speex-dev] [patch] Mac Universal Binaries

[Jean-Marc Valin]

>> Well, AFAIK C89 says the behaviour in undefined, so I wouldn't rely on
>> that too much. Even on PPC, it's quite possible someday the gcc folks
>> will be able to 1) determine at compile time that a conversion somewhere
>> will overflow and 2) optimise it out (since it's undefined anyway) or do
>> other funny things with it. That's why I wouldn't depend on the right
>> thing happening, even on PPC.
> 
> Except for one thing. I have an M4 macro which tests for the behaviour
> at configure time. The result of that test is then used at compile
> time.
> 
> I think its reasonable to expect that the same version of gcc is used 
> at configure and compile times :-).

Not quite. What I'd be worried about is that in some very particular
circumstances, gcc be able to figure out that "OK, this float->int
conversion at line X is guaranteed to overflow, so I'll just ignore it
(or actively do something stupid)". This could even happen in cases
where gcc compiles N versions of your code (to optimise for different
input patterns) and it could cause one of the versions to have a
predictable overflow.

As long as the input is not predictable at compile time, gcc should be
doing the right thing, which is to use the conversion instruction
blindly. However, as soon as an overflow becomes predictable at compile
time (due do some constraints on the input), it could be dangerous. It's
basically the same thing for integer overflows. If an add or a sub is
guaranteed to overflow, gcc is allowed to optimise it away (not sure
whether it actually does that at the moment though).

>> I'm afraid I haven't been Doing It Your Way so far
> 
> Never too late to start :-).
> 
>> :-( But I'm quite willing to integrate contributed test cases :-)
> 
> I'll put it on my todo list. I should get around to it some time
> after hell freezes over :-).

OK, let me know when hell freezes over so I can prepare :-)

	Jean-Marc