[pgrouting-users] importance of -frounding-math compilation flag?

[William Kyngesburye]

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
>>> functions.
>>> 
>>> 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:
>> 
>> http://jamesgregson.blogspot.com/2012/06/cgal-build-issues-under-os-x-107.html
>> 
>> 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
>> Fink.)
> 
> 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>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what does that remind me of?  Ah, yes - life."

- Marvin