[pgrouting-users] importance of -frounding-math compilation flag?
woklist at kyngchaos.com
Mon Mar 18 06:29:14 PDT 2013
On Mar 16, 2013, at 11:04 PM, Stephen Woodbridge wrote:
> On 3/16/2013 8:36 PM, William Kyngesburye wrote:
>> On Mar 16, 2013, at 6:47 PM, Stephen Woodbridge wrote:
>>> On 3/16/2013 6:20 PM, William Kyngesburye wrote:
>>>> I'm recompiling pgrouting on OS X Lion, using the clang
>>>> compiler. clang does not have the -frounding-math option.
>>>> I found one reference that the clang equivalent is
>>>> --disable-fpmath, but that just causes and error "unsupported
>>>> option '--disable-fpmath'". I could find no documentation that
>>>> clang has or had this option, or something similar.
>>>> Is the rounding behavior critical?
>>> I do not know for a fact one way or the other, But I'm guess that
>>> this options probably is not critical for MOST pgrouting
>>> Where it MIGHT be important is for the CGAL library and/or GAUL
>>> libraries. CGAL specifically does a lot of math. You might check
>>> those packages so see what they do with respect to fp rounding on
>>> OS X.
>>> If anyone knows more about this please correct this AND we should
>>> document it somewhere for future reference.
>> I didn't need to recompile CGAL, so I didn't see a problem there.
>> But I see that it also uses -frounding-math for GCC, but nothing for
>> clang. The changes log does say CGAL fully supports clang as of CGAL
>> 4.1, so maybe rounding behavior is not an issue or the code works
>> around it.
>> All I could find in GAUL is a macro define for ROUND which looks like
>> proper rounding towards 0.
>> I found another reference, for CGAL and OSX/clang:
>> I guess we're screwed, if the rounding behavior is important to
>> compiler optimization in CGAL and pgRouting. (the previous reference
>> for the supposed --disable-fpmath option was from Fink. Never liked
> OK, so CGAL is only used for building drive time polygons. The rest of pgRouting should work just fine. I am also considering removing CGAL in Rev 2.0 and using a much smaller and simpler code set that I have used in the past.
> This rounding issue might be a more serious issue GEOS which is the underlying geometery library used in postGIS, so I wonder what they are doing about this.
I found a round function is GEOS, which is a complex (overly?) if-then. If all the rounding behavior affects is a round function, then GEOS is OK. Makes sense - it probably came out of converting the JTS Java to C. I read that the Java rounding behavior is down, not the standard to 0, so JTS probably had the function already.
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."
More information about the Pgrouting-users