Menu
▾
▴
quesa-develop
|
From: Sean M. <se...@ro...> - 2009-04-22 16:58:41
|
Hi again, I have three more concerns/suggestions/questions: 1) In Quesa-common.xcconfig we have: GCC_FAST_MATH = YES From my understanding, this option is not generally recommended. Is it really needed? 2) In Quesa.h we have: #pragma options align=power Is this really needed? Can we wrap it in #if TARGET_RT_MAC_CFM so that it only applies to Mac OS 9? 3) In Debug, the static library is named libQuesaD.a and in Release it is libQuesa.a. Why is this? For CodeWarrior this would be handy, but for Xcode it is annoying because Xcode does not allow different libraries to be used in different configurations. The only way to do that with Xcode is to pass -libQuesa as a linker flag and change library search paths between Debug and Release. This requires the libs to have the same name. Patch attached for consideration. -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: James W. W. <os...@jw...> - 2009-04-24 15:47:54
Attachments:
smime.p7s
|
On Apr 22, 2009, at 9:58 AM, Sean McBride wrote: > 1) In Quesa-common.xcconfig we have: > GCC_FAST_MATH = YES > > From my understanding, this option is not generally recommended. Is > it > really needed? Can you give me any references? I googled it, and couldn't find any recommendations one way or another. But to me, the word "fast" is a recommendation. > 2) In Quesa.h we have: > #pragma options align=power > > Is this really needed? Can we wrap it in #if TARGET_RT_MAC_CFM so > that > it only applies to Mac OS 9? It probably is a relic of QD3D. I expect that as long as the alignment of the header agrees with the alignment used to build Quesa, then it shouldn't matter. So I think we can wrap it as you suggest. > 3) In Debug, the static library is named libQuesaD.a and in Release it > is libQuesa.a. Why is this? For CodeWarrior this would be handy, but > for Xcode it is annoying because Xcode does not allow different > libraries to be used in different configurations. The only way to do > that with Xcode is to pass -libQuesa as a linker flag and change > library > search paths between Debug and Release. This requires the libs to > have > the same name. I don't know why, and wouldn't object to changing it. (I always use Quesa as a framework.) However, I don't think it's exactly true that Xcode doesn't allow different libraries to be used in different configurations. You can use a trick of putting symbolic links in the build product Release and Debug folders, and then putting one of those links in the project with a Build Product-relative path. |
|
From: Sean M. <se...@ro...> - 2009-04-24 15:56:43
|
On 4/24/09 8:47 AM, James W. Walker said: >> 1) In Quesa-common.xcconfig we have: >> GCC_FAST_MATH = YES >> >> From my understanding, this option is not generally recommended. Is >> it >> really needed? > >Can you give me any references? I googled it, and couldn't find any >recommendations one way or another. But to me, the word "fast" is a >recommendation. Xcode's 'Research Assistant' has this to say: "Enables some floating point optimizations that are not IEEE754- compliant, but which usually work. Programs which require strict IEEE compliance may not work with this option. [GCC_FAST_MATH, -ffast-math]" gcc's man page says: "-ffast-math Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, - ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx- limited-range. This option causes the preprocessor macro "__FAST_MATH__" to be defined. This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions." I agree 'fast' sounds like a recommendation, they probably should have called it GCC_BROKEN_MATH. :) >> 2) In Quesa.h we have: >> #pragma options align=power >> >> Is this really needed? Can we wrap it in #if TARGET_RT_MAC_CFM so >> that >> it only applies to Mac OS 9? > >It probably is a relic of QD3D. I expect that as long as the >alignment of the header agrees with the alignment used to build Quesa, >then it shouldn't matter. So I think we can wrap it as you suggest. Great. >> 3) In Debug, the static library is named libQuesaD.a and in Release it >> is libQuesa.a. Why is this? For CodeWarrior this would be handy, but >> for Xcode it is annoying because Xcode does not allow different >> libraries to be used in different configurations. The only way to do >> that with Xcode is to pass -libQuesa as a linker flag and change >> library >> search paths between Debug and Release. This requires the libs to >> have >> the same name. > > >I don't know why, and wouldn't object to changing it. (I always use >Quesa as a framework.) However, I don't think it's exactly true that >Xcode doesn't allow different libraries to be used in different >configurations. You can use a trick of putting symbolic links in the >build product Release and Debug folders, and then putting one of those >links in the project with a Build Product-relative path. Up to you of course, it's not a big bother for my version to be 1 character off the standard version. :) -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: Jose' C. <cru...@ce...> - 2009-04-24 16:07:28
|
Il giorno 24/apr/09, alle ore 17:56, Sean McBride ha scritto: > > I agree 'fast' sounds like a recommendation, they probably should have > called it GCC_BROKEN_MATH. :) better call it GCC_DIFFERENTLY_INEXACT_BUT_MAYBE_A_LITTLE_FASTER :-) Pax et Bonum # Dott. José Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,3923101 0372,460602 http://www.linkedin.com/in/jcruanyes |
|
From: James W. W. <os...@jw...> - 2009-04-24 16:15:21
Attachments:
smime.p7s
|
On Apr 24, 2009, at 8:56 AM, Sean McBride wrote: > This option should never be turned on by any -O option since it can > result in incorrect output for programs which depend on an exact > implementation of IEEE or ISO rules/specifications for math > functions." > > I agree 'fast' sounds like a recommendation, they probably should have > called it GCC_BROKEN_MATH. :) I would tend to assume that "programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions" would not include Quesa. |
|
From: Stefan H. <st...@to...> - 2009-04-27 16:10:17
|
At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on. >gcc's man page says: > >"-ffast-math >Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, - >ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx- >limited-range. >This option causes the preprocessor macro "__FAST_MATH__" to be defined. > >This option should never be turned on by any -O option since it can >result in incorrect output for programs which depend on an exact >implementation of IEEE or ISO rules/specifications for math functions." > >I agree 'fast' sounds like a recommendation, they probably should have >called it GCC_BROKEN_MATH. :) Stefan http://www.topoi.ch |
|
From: James W. W. <os...@jw...> - 2009-04-27 16:20:29
Attachments:
smime.p7s
|
On Apr 27, 2009, at 9:04 AM, Stefan Huber wrote: > At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ > is on. Please tell me more. How do they work differently when it is off? |
|
From: Sean M. <se...@ro...> - 2009-04-27 16:28:32
|
On 4/27/09 9:20 AM, James W. Walker said: >> At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ >> is on. > >Please tell me more. How do they work differently when it is off? The gcc man page does discuss this somewhat. It says: "-ffast-math Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, - ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx- limited-range." Then for -ffinite-math-only it says: "Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs." -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: Stefan H. <st...@to...> - 2009-04-27 17:34:07
|
>>At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on. > >Please tell me more. How do they work differently when it is off? About two years ago I ported an app that relies on nan, etc. from CW to Xcode. The main problem is (as far as I remember) that isnan, isinf and similar functions always return false if __FAST_MATH__ is on. Quesa does not use these functions. BTW CWs "Relaxed IEEE Floating Point" setting works perfectly well with nan. Stefan http://www.topoi.ch |
|
From: James W. <ja...@fr...> - 2009-04-27 17:52:09
|
Stefan Huber wrote: >>> At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on. >> Please tell me more. How do they work differently when it is off? > > About two years ago I ported an app that relies on nan, etc. from CW > to Xcode. The main problem is (as far as I remember) that isnan, > isinf and similar functions always return false if __FAST_MATH__ is > on. Quesa does not use these functions. > > BTW CWs "Relaxed IEEE Floating Point" setting works perfectly well with nan. Quesa does use isfinite, and I'm sure I would have noticed if it wasn't working... rendering with shadows requires an infinite yon, and E3ViewAngleAspectCamera::GetFrustumMatrix uses isfinite to do the right thing in that case. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Stefan H. <st...@to...> - 2009-04-27 19:35:17
|
>Stefan Huber wrote: > >>> At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on. >>> Please tell me more. How do they work differently when it is off? >> >> About two years ago I ported an app that relies on nan, etc. from CW >> to Xcode. The main problem is (as far as I remember) that isnan, >> isinf and similar functions always return false if __FAST_MATH__ is >> on. Quesa does not use these functions. >> >> BTW CWs "Relaxed IEEE Floating Point" setting works perfectly well with nan. > >Quesa does use isfinite, and I'm sure I would have noticed if it wasn't >working... rendering with shadows requires an infinite yon, and >E3ViewAngleAspectCamera::GetFrustumMatrix uses isfinite to do the right >thing in that case. I've tested __FAST_MATH__ is on for floats again (Xcode 2.4.1): you are right : isfinite and isinf work correctly for std::numeric_limits<float>::infinity() but: isnan returns 0 (instead of 1) and isfinite returns 1 (instead of 0) for std::numeric_limits<float>::quiet_NaN() It seems that inf works but nan does not. Stefan http://www.topoi.ch |
|
From: James W. <ja...@fr...> - 2009-04-28 00:52:06
|
Stefan Huber wrote: > I've tested __FAST_MATH__ is on for floats again (Xcode 2.4.1): > > you are right : > isfinite and isinf work correctly for std::numeric_limits< float > >::infinity() > > but: > isnan returns 0 (instead of 1) and isfinite returns 1 (instead of 0) for > std::numeric_limits< float >::quiet_NaN() > > It seems that inf works but nan does not. > OK, I have turned off GCC_FAST_MATH. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |