Re: Setting -frounding-math by default

[Gabriel Dos Reis]

On Tue, Mar 10, 2009 at 12:27 PM, Sylvain Pion
 wrote:

> Other ways might be possible.  E.g. avoiding the wrapping if
> the associativity concept/axiom is somehow local to the function
> and does not leak elsewhere if you provide an Associativity
> concept_map for double (or are "scoped concept maps" about
> this issue ?  I should learn about this.).

A general idea behind axioms is that they hold for the values and archetypes in
a generic function -- even if globally they may not be universally true.
That is the local aspect of axioms.  Of course, you can make (global)
concept_maps too.

Anyway, I think you would NOT want the compiler to disable useful
optimizations globally, but only where some transformations may not
be appropriate.

-- Gaby

Re: Setting -frounding-math by default

[Sylvain Pion]

Gabriel Dos Reis wrote:

On Tue, Mar 10, 2009 at 10:41 AM, Sylvain Pion
 wrote:

Richard Guenther wrote:

The middle-end knows about an explicit association barrier (only
used from the Fortran FE sofar), a PAREN_EXPR.  Would exposing
that to C/C++ be of any help?  For example it would, even with
-ffast-math, avoid constant folding for (x + FLT_EPS) - FLT_EPS
(which FLT_EPS such that proper rounding to the nearest integer
value is performed).

Off the top of my head, I don't see anything both really useful
and not-surprising in C/C++ here, but I may well miss something.

There are some C++0x features, axiom and constexpr, which are
related to this area.  It's not clear yet to me how all this
will interact, but I have good hope to see some connections
there (like modeling some associativity rules with axioms).


Note that axioms do not change the behaviour of a program -- assuming
the program contains `no bugs'.


I don't mean to change the behavior of a program without changing
its code.  But you can change its code so that it describes whether
a particular function can support associativity transformations.
(then it's up to the compiler to realize what the axiom is about,
but that's another story : you can imagine a simple, non-general
implementation, recognizing standard axioms as "built-ins",
and trigger the corresponding -fassociative-math on the functions
which are constrained by this concept+axiom)

One way I could imagine to have axioms and associativity rules
on FP interact in a program would be to write a wrapper type,
say std::associative, which would just wrap and forward
the operations to double, but which would, in addition, have
a concept_map for a concept whose axioms would specify the
associativity rules.  Then, if you call a function which
you know is OK if the compiler does the associativity
transformations, you can just call it with std::associative
arguments.
Other ways might be possible.  E.g. avoiding the wrapping if
the associativity concept/axiom is somehow local to the function
and does not leak elsewhere if you provide an Associativity
concept_map for double (or are "scoped concept maps" about
this issue ?  I should learn about this.).

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Sylvain Pion]

Andrew Haley wrote:

We know that's what you want.  What we don't know (well, what I don't
know) is *why*.  If you want to do something as specialized as interval
arithmetic, what's the big deal with having to pass special flags to
the compiler?


I contest the "as specialized as" comment.
I know that I may look like Don Quixote here, but you may imagine
that many people look like Panurge's sheeps to me on this point ;-)


Interval arithmetic is not supposed to be an obscure feature, it is
a way to compute with real numbers which offers many advantages compared
to the usual floating-point (FP) model (which is quite well supported by
hardware and compilers).
It directly competes with it on this ground (which means the potential
market is huge), and is easily based on it for the implementation.

Some of the reasons why it is not used as much as it could, are that it
has poor support from compilers, and could have better support from
the hardware as well (with proper hardware support, interval operations
would roughly be just as fast as floating-point, and adequate hardware
support is not hard fundamentally).  All this induces a tradition of
training and education which puts FP first, and IA in a vicious circle :
no hardware/software improvement => unfair comparison => no teaching
=> no demand => no improvement...
It would also benefit from standardization, but this is being taken
care of (see the ongoing IEEE-1788, and the std::interval proposal
for C++/TR2).

As I said in another mail, if you have code which uses interval arithmetic
deep down an application, but it happens to come from, say, Boost.Interval,
which is a library providing inline functions for efficiency reasons
(not precompiled), then you need to pass these flags when compiling the
whole application (the translation units that include those headers) as well.
And that's a pain, especially with all those template/modern libraries
which have everything in headers.  That's a concrete problem I want
to solve that affects my pet library (see my signature) and its users.


Now, what's so good about intervals that nobody sees?  I think that
nobody sees the cost of floating-point, which is that it is a complicated
model of approximation of reals, which forces tons of people to learn
details about it, while all they want is to compute with real numbers.
You need to teach all beginners the pitfalls of it, this is one of the
first things you need to do.  Doing the same thing with intervals
would be much easier to teach and give strong guarantees on results
which everybody mastering real numbers would understand easily.

Concrete example : you have heard that moto "never compare FP for
equality", which some people try to have beginners learn, while experts
know the reality behind it, which is : it depends what you do
(meaning : learn more).
With intervals, you simply get a clean semantic : true, false, or
"I don't know", which tells you that you have to do something special.
No surprise.  Everything is rock solid, and you don't need endless
discussions around "should I use -ffast-math in my code or which
subset of its sub-flags is best...".  Admittedly, filling the
"I don't know" can require some work, but it is clear where work
is needed and you may decide to ignore it (for -ffast-math users :-) ).

This was an argument for the cost of teaching to "masses" (aka "beginners",
which in fact already master real numbers maths, and which naively
expect computers to be a tool that helps them instead of a tool that
hurts their brain).
For advanced scientific computing, if you had intervals as fast as
floating-point, then a lot of complicated work on, say, static code
analysis for roundoff error propagation (the parts of it which try
to emulate IA with FP by computing bounds at compile-time), would
become pointless as the hardware would take care of it.
Also, even beyond, my guess is that formal proofs of algorithms
and programs dealing with real numbers would be much simplified
if they based their models on intervals rather than floating-point.
Try to evaluate the global educational cost of producing experts
in this area ?


My point about improving compiler support first, is that I see it
as a first step to help reaching a critical mass of applications
and users, in order to economically justify hardware support.
(at which point compiler support will be trivial, but unfortunately
we are not there yet.  It's like we had to have FP-emulators
in the past.)
I may be wrong about that.


I don't mean IA is perfect nor magic and solving everything without
thinking : certainly convergence and stability issues are similar
than with FP.  But, IMO, it's an improvement over FP which should
be considered on the same ground as the improvement that FP has been
over integers 2-3 decades ago.


Now, you know the *why*.  I'm not sure whether I convinced you,
but I'd be glad to have some help for the *how* ;-)

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, 

Re: Setting -frounding-math by default

[Gabriel Dos Reis]

On Tue, Mar 10, 2009 at 10:41 AM, Sylvain Pion
 wrote:
> Richard Guenther wrote:
>>
>> The middle-end knows about an explicit association barrier (only
>> used from the Fortran FE sofar), a PAREN_EXPR.  Would exposing
>> that to C/C++ be of any help?  For example it would, even with
>> -ffast-math, avoid constant folding for (x + FLT_EPS) - FLT_EPS
>> (which FLT_EPS such that proper rounding to the nearest integer
>> value is performed).
>
> Off the top of my head, I don't see anything both really useful
> and not-surprising in C/C++ here, but I may well miss something.
>
> There are some C++0x features, axiom and constexpr, which are
> related to this area.  It's not clear yet to me how all this
> will interact, but I have good hope to see some connections
> there (like modeling some associativity rules with axioms).

Note that axioms do not change the behaviour of a program -- assuming
the program contains `no bugs'.

-- Gaby

Re: Setting -frounding-math by default

[Gabriel Dos Reis]

On Tue, Mar 10, 2009 at 10:31 AM, Sylvain Pion
 wrote:

[...]

> If you are looking for the Right [tm] solution, please take a look at N2811.

I'm familiar with that paper -- I should have made that disclosure in
my previous
message.

-- Gaby

Re: Setting -frounding-math by default

[Andrew Haley]

Sylvain Pion wrote:
> Joseph S. Myers wrote:
>> On Mon, 9 Mar 2009, Sylvain Pion wrote:
>>
>>> Later, 1) started to be taken care of, and it was unfortunately
>>> added under the control of the same -frounding-math option.
>>> Which now, makes it harder to come back, since we want different
>>> defaults for these two aspects.
>>>
>>> I have already mentioned in a bugzilla PR that it could be nice
>>> to have 2 options, but IIRC, I did not get any reply to this.
>>
>> Patches to split the option into two *clearly-defined* options are
>> more likely to be accepted than changing the defaults, given that the
>> fast-math and related flags have been split more than once before.
> 
> My goal is to have interval arithmetic work with the default flags,
> without more workarounds in the code (and as efficiently as possible).
> So, I'm not going to work on anything if it means only splitting it
> in separate flags, if we don't agree a priori on changing the default
> for at least one of those sub flags after that.

We know that's what you want.  What we don't know (well, what I don't
know) is *why*.  If you want to do something as specialized as interval
arithmetic, what's the big deal with having to pass special flags to
the compiler?

Andrew.

Re: Setting -frounding-math by default

[Sylvain Pion]

Richard Guenther wrote:

The middle-end knows about an explicit association barrier (only
used from the Fortran FE sofar), a PAREN_EXPR.  Would exposing
that to C/C++ be of any help?  For example it would, even with
-ffast-math, avoid constant folding for (x + FLT_EPS) - FLT_EPS
(which FLT_EPS such that proper rounding to the nearest integer
value is performed).


Off the top of my head, I don't see anything both really useful
and not-surprising in C/C++ here, but I may well miss something.

There are some C++0x features, axiom and constexpr, which are
related to this area.  It's not clear yet to me how all this
will interact, but I have good hope to see some connections
there (like modeling some associativity rules with axioms).

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Sylvain Pion]

Gabriel Dos Reis wrote:

On Tue, Mar 10, 2009 at 9:45 AM, Sylvain Pion
 wrote:

- Show quoted text -
Joseph S. Myers wrote:

On Mon, 9 Mar 2009, Sylvain Pion wrote:


Later, 1) started to be taken care of, and it was unfortunately
added under the control of the same -frounding-math option.
Which now, makes it harder to come back, since we want different
defaults for these two aspects.

I have already mentioned in a bugzilla PR that it could be nice
to have 2 options, but IIRC, I did not get any reply to this.

Patches to split the option into two *clearly-defined* options are more
likely to be accepted than changing the defaults, given that the fast-math
and related flags have been split more than once before.

My goal is to have interval arithmetic work with the default flags,
without more workarounds in the code (and as efficiently as possible).
So, I'm not going to work on anything if it means only splitting it
in separate flags, if we don't agree a priori on changing the default
for at least one of those sub flags after that.
That would be the opposite of progress for my usage, and so I would
not volunteer.


Currently, typical interval arithmetic code has to work around the fact that
there is no good way to stop constant propagation reliably (so it's using
some volatile or asm, or a big hammer like rounding-math, all these
solutions
having a performance cost).


It is not clear that constant propagation is the evil that needs to
be stopped at all cost.  Remember, there is lot under the heading
'constant propagation'.


It would be nice to improve this, but a global flag, be it dedicated,
strikes
me as a clearly suboptimal solution here anyway (and, as has been mentioned,
it causes problems with code which really needs cprop in other places).
For IA, having a __builtin_stop_constant_propagation(expression) would be
OK,


I'm not too sure you really want this, or anybody serious about
scientific computations and performance really wants that.
And how would you reconcile that with constexpr?


I agree.
If you are looking for the Right [tm] solution, please take a look at N2811.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Gabriel Dos Reis]

On Tue, Mar 10, 2009 at 9:45 AM, Sylvain Pion
 wrote:
> - Show quoted text -
> Joseph S. Myers wrote:
>>
>> On Mon, 9 Mar 2009, Sylvain Pion wrote:
>>
>>> Later, 1) started to be taken care of, and it was unfortunately
>>> added under the control of the same -frounding-math option.
>>> Which now, makes it harder to come back, since we want different
>>> defaults for these two aspects.
>>>
>>> I have already mentioned in a bugzilla PR that it could be nice
>>> to have 2 options, but IIRC, I did not get any reply to this.
>>
>> Patches to split the option into two *clearly-defined* options are more
>> likely to be accepted than changing the defaults, given that the fast-math
>> and related flags have been split more than once before.
>
> My goal is to have interval arithmetic work with the default flags,
> without more workarounds in the code (and as efficiently as possible).
> So, I'm not going to work on anything if it means only splitting it
> in separate flags, if we don't agree a priori on changing the default
> for at least one of those sub flags after that.
> That would be the opposite of progress for my usage, and so I would
> not volunteer.
>
>
> Currently, typical interval arithmetic code has to work around the fact that
> there is no good way to stop constant propagation reliably (so it's using
> some volatile or asm, or a big hammer like rounding-math, all these
> solutions
> having a performance cost).

It is not clear that constant propagation is the evil that needs to
be stopped at all cost.  Remember, there is lot under the heading
'constant propagation'.

> It would be nice to improve this, but a global flag, be it dedicated,
> strikes
> me as a clearly suboptimal solution here anyway (and, as has been mentioned,
> it causes problems with code which really needs cprop in other places).
> For IA, having a __builtin_stop_constant_propagation(expression) would be
> OK,

I'm not too sure you really want this, or anybody serious about
scientific computations and performance really wants that.
And how would you reconcile that with constexpr?

-- Gaby

Re: Setting -frounding-math by default

[Richard Guenther]

On Tue, Mar 10, 2009 at 4:45 PM, Sylvain Pion
 wrote:
> - Show quoted text -
> Joseph S. Myers wrote:
>>
>> On Mon, 9 Mar 2009, Sylvain Pion wrote:
>>
>>> Later, 1) started to be taken care of, and it was unfortunately
>>> added under the control of the same -frounding-math option.
>>> Which now, makes it harder to come back, since we want different
>>> defaults for these two aspects.
>>>
>>> I have already mentioned in a bugzilla PR that it could be nice
>>> to have 2 options, but IIRC, I did not get any reply to this.
>>
>> Patches to split the option into two *clearly-defined* options are more
>> likely to be accepted than changing the defaults, given that the fast-math
>> and related flags have been split more than once before.
>
> My goal is to have interval arithmetic work with the default flags,
> without more workarounds in the code (and as efficiently as possible).
> So, I'm not going to work on anything if it means only splitting it
> in separate flags, if we don't agree a priori on changing the default
> for at least one of those sub flags after that.
> That would be the opposite of progress for my usage, and so I would
> not volunteer.
>
>
> Currently, typical interval arithmetic code has to work around the fact that
> there is no good way to stop constant propagation reliably (so it's using
> some volatile or asm, or a big hammer like rounding-math, all these
> solutions
> having a performance cost).
> It would be nice to improve this, but a global flag, be it dedicated,
> strikes
> me as a clearly suboptimal solution here anyway (and, as has been mentioned,
> it causes problems with code which really needs cprop in other places).
> For IA, having a __builtin_stop_constant_propagation(expression) would be
> OK,
> which would reliably stop constant propagation on an expression, for
> example.
> I don't think there's anything like that already in GCC.
> That would be a real improvement, and would even improve the speed
> of interval arithmetic implementations as a bonus (because it wouldn't
> do any harm for the non-constant cases).
> I'm not sure what you think about such a built-in : it's more general
> than FP expressions, but may be only useful there in practice (?).
> Maybe it might even be able to replace most concrete needs for this
> aspect of -frounding-math.
> Moreover, I don't know how hard it would be to implement.  What do you
> think?
>
> (Of course this would still not be perfect to me : the ideal compiler
> interface for IA for me is something along the lines of what is described
> in N2811 which attaches a compile-time rounding mode to the operations.
> But at least this first step would mean progress, and might be otherwise
> useful, I don't know.)
>
> A quick audit says that the rest of -frounding-math seems indeed like it's
> about
> expression transformations which are valid when rounding is to the nearest.
> Maybe this part can indeed be seen as a subset of -fassociative-math
> as Paolo mentioned, which may or may not reserve a dedicated flag.
> (certainly I would push for these transformations to not be performed
> by default, just like -fassociative-math)
>
>
>
> FYI, "grep flag_rounding_math" gives the following uses of -frounding-math,
> with my interpretations :
>
> gcc/config/i386/i386.md
>
>  used to allow the selection of an SSE insn for a round operation
>  when the conditions are sufficiently relaxed (as far as I understood)
>
> gcc/config/arm/arm.c
>
>  triggers an ABI related thing in the ASM files.
>  (I have no clue how -frounding-math could possibly
>  affect the ABI, but I know nothing about ARM)
>
> gcc/flags.h
>
>  affects definition of HONOR_SIGN_DEPENDENT_ROUNDING
>  which is used in many places in fold-const and simplify-rtx
>  for expression transformations.
>
> gcc/builtins.def
>
>  affects definition of ATTR_MATHFN_FPROUNDING
>  which triggers const/pure attributes on "cmath" built-ins it seems.
>
> gcc/builtins.c
> gcc/fold-const.c
>
>  used for preventing constant folding in some cases
>
> gcc/opts.c
>
>  fast-math => no-rounding-math
>
> gcc/convert.c
>
>  guard  (float)-x => -(float)x  transformation
>
> gcc/simplify-rtx.c
>
>  guard constant folding
>
>
>
> I have not checked all this as carefully as can be, but enough
> to convince me that a good split of -frounding-math might indeed
> be between (1) stopping constant propagation (where the question
> is whether a builtin_stop_cprop(e) covers all needs), and
> (2) "associative-math"-like transformations which could be disabled
> by default.

The middle-end knows about an explicit association barrier (only
used from the Fortran FE sofar), a PAREN_EXPR.  Would exposing
that to C/C++ be of any help?  For example it would, even with
-ffast-math, avoid constant folding for (x + FLT_EPS) - FLT_EPS
(which FLT_EPS such that proper rounding to the nearest integer
value is performed).

Richard.

> - Show quoted text -
>
> --
> Sylvain Pion
> INRIA Sophia-Antipolis
> Geometrica Project-Team
> CGAL, http:/

Re: Setting -frounding-math by default

[Sylvain Pion]

Joseph S. Myers wrote:

On Mon, 9 Mar 2009, Sylvain Pion wrote:


Later, 1) started to be taken care of, and it was unfortunately
added under the control of the same -frounding-math option.
Which now, makes it harder to come back, since we want different
defaults for these two aspects.

I have already mentioned in a bugzilla PR that it could be nice
to have 2 options, but IIRC, I did not get any reply to this.


Patches to split the option into two *clearly-defined* options are more 
likely to be accepted than changing the defaults, given that the fast-math 
and related flags have been split more than once before.


My goal is to have interval arithmetic work with the default flags,
without more workarounds in the code (and as efficiently as possible).
So, I'm not going to work on anything if it means only splitting it
in separate flags, if we don't agree a priori on changing the default
for at least one of those sub flags after that.
That would be the opposite of progress for my usage, and so I would
not volunteer.


Currently, typical interval arithmetic code has to work around the fact that
there is no good way to stop constant propagation reliably (so it's using
some volatile or asm, or a big hammer like rounding-math, all these solutions
having a performance cost).
It would be nice to improve this, but a global flag, be it dedicated, strikes
me as a clearly suboptimal solution here anyway (and, as has been mentioned,
it causes problems with code which really needs cprop in other places).
For IA, having a __builtin_stop_constant_propagation(expression) would be OK,
which would reliably stop constant propagation on an expression, for example.
I don't think there's anything like that already in GCC.
That would be a real improvement, and would even improve the speed
of interval arithmetic implementations as a bonus (because it wouldn't
do any harm for the non-constant cases).
I'm not sure what you think about such a built-in : it's more general
than FP expressions, but may be only useful there in practice (?).
Maybe it might even be able to replace most concrete needs for this
aspect of -frounding-math.
Moreover, I don't know how hard it would be to implement.  What do you think?

(Of course this would still not be perfect to me : the ideal compiler
interface for IA for me is something along the lines of what is described
in N2811 which attaches a compile-time rounding mode to the operations.
But at least this first step would mean progress, and might be otherwise
useful, I don't know.)

A quick audit says that the rest of -frounding-math seems indeed like it's about
expression transformations which are valid when rounding is to the nearest.
Maybe this part can indeed be seen as a subset of -fassociative-math
as Paolo mentioned, which may or may not reserve a dedicated flag.
(certainly I would push for these transformations to not be performed
by default, just like -fassociative-math)



FYI, "grep flag_rounding_math" gives the following uses of -frounding-math,
with my interpretations :

gcc/config/i386/i386.md

 used to allow the selection of an SSE insn for a round operation
 when the conditions are sufficiently relaxed (as far as I understood)

gcc/config/arm/arm.c

 triggers an ABI related thing in the ASM files.
 (I have no clue how -frounding-math could possibly
  affect the ABI, but I know nothing about ARM)

gcc/flags.h

 affects definition of HONOR_SIGN_DEPENDENT_ROUNDING
 which is used in many places in fold-const and simplify-rtx
 for expression transformations.

gcc/builtins.def

 affects definition of ATTR_MATHFN_FPROUNDING
 which triggers const/pure attributes on "cmath" built-ins it seems.

gcc/builtins.c
gcc/fold-const.c

 used for preventing constant folding in some cases

gcc/opts.c

 fast-math => no-rounding-math

gcc/convert.c

 guard  (float)-x => -(float)x  transformation

gcc/simplify-rtx.c

 guard constant folding



I have not checked all this as carefully as can be, but enough
to convince me that a good split of -frounding-math might indeed
be between (1) stopping constant propagation (where the question
is whether a builtin_stop_cprop(e) covers all needs), and
(2) "associative-math"-like transformations which could be disabled
by default.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Joseph S. Myers]

On Mon, 9 Mar 2009, Sylvain Pion wrote:

> Later, 1) started to be taken care of, and it was unfortunately
> added under the control of the same -frounding-math option.
> Which now, makes it harder to come back, since we want different
> defaults for these two aspects.
> 
> I have already mentioned in a bugzilla PR that it could be nice
> to have 2 options, but IIRC, I did not get any reply to this.

Patches to split the option into two *clearly-defined* options are more 
likely to be accepted than changing the defaults, given that the fast-math 
and related flags have been split more than once before.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Setting -frounding-math by default

[Joseph S. Myers]

On Mon, 9 Mar 2009, Sylvain Pion wrote:

> - C++ does not have it, so what's the plan for C++ ?

That's for C++ maintainers, possibly guided by anything that goes in the 
C++ standard.

The pragma syntax is a fairly small part of the work, as would be control 
of the options at a per-function level.  The large parts would be:

* Disabling all problematic optimizations when the relevant options are 
set.

* Control on a per-operation level, so block-level pragmas don't act like 
function-level ones and you can inline functions with different settings 
without making the most conservative settings apply to the merged 
function.

Note that these large parts are language-independent.

> > GCC maintainers must also bear in mind the bulk of users for whom the
> > default options, complete with other issues such as x87 excess precision,
> > are just fine, and the value of good benchmark scores in marketing GCC.
> > (You will of course nevertheless note that I have fixed PR 323 for C for
> > 4.5.)
> 
> Yep, I did note, and this is impressive work.
> Though, as a C++ user, I won't see the benefit of it for now unfortunately :(

The C++ maintainers (or others) are of course free to implement 
appropriate semantics for C++.  (I don't think C++0x has followed C99 in 
providing any standard way to handle excess precision, but I imagine 
something reasonable and GCC-specific could be defined, just as I made 
GCC-specific interpretations of areas in which C99 was silent.  There has 
certainly been some suggestion that Fortran might wish to implement 
something .

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Setting -frounding-math by default

[Paolo Bonzini]

>> I think 2) is taken care of by -fassociative-math, or it should at least.
>
> I don't think it is (I haven't checked), and I don't see why it should.
> This transformation has nothing to do with associativity : unless I'm
> mistaken, it is always valid when rounding is to the nearest or towards
> zero.

(-a) * b => -(a * b) is definitely reassociation (-a is -1 * a); no
reassociation has to be valid in any rounding mode, which means two
things: 1) it can be done even when other rounding-mode-dependent
optimizations are disabled via flag_rounding_math (good); 2) it would
also enable other optimization that you might not want (bad).

Paolo

Re: Setting -frounding-math by default

[Sylvain Pion]

Paolo Bonzini wrote:

Sylvain Pion wrote:

Andrew Thomas Pinski wrote:

The fact is that Roger's patch introduced a regression (this word
should be clear enough here), in that some users now have their old
code broken, and they are forced to add the -frounding-math option
(after having lost some time finding about this non trivial issue).
This is a long term hindrance.

Actually before roger's patch the default is the same. Just there was
no way to turn it off.

Actually, there are 2 things controlled by -frounding-math :
1) constant propagation of FP operations
2) generic transformations like (-a)*b <-> -(a*b)


I think 2) is taken care of by -fassociative-math, or it should at least.


I don't think it is (I haven't checked), and I don't see why it should.
This transformation has nothing to do with associativity : unless I'm
mistaken, it is always valid when rounding is to the nearest or towards
zero.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Sylvain Pion]

Joseph S. Myers wrote:

On Sun, 8 Mar 2009, Sylvain Pion wrote:


this pragma.  I nevertheless try to find grants for funding
people to implement some related things in GCC.  And I also
contribute time to help in the guidance of GCC with my
expertise in this particular area, even if it requires a lot
of time to convince people.  So, please...


Finding funding for implementing standard pragmas and completing the 
-frounding-math implementation is likely to be more productive than 
arguing about a default for an option that is known to have problems.


I disagree.  My opinion is that :
- the C99 pragma is not the best thing that can be done, and if after
 10 years nobody has done it in GCC, it can also mean that it does not
 feel the needs as correctly as it was supposed to.
- C++ does not have it, so what's the plan for C++ ?

Related to this, I argue that -frounding-math is not appropriately
defined (see my other mail on splitting it in 2 parts, with different
defaults for these 2 parts).

So we must discuss it *before* we start hacking on code or funding proposals.

All the people discussing the issue are familiar with the floating point 
optimization issues in GCC.  (I have added many such bugs to the 
dependencies of bug 16989 in the past to help track them, and just added 
some more.)  Since as far as I know all work done on the floating-point 
issues has been done as volunteers, time spent discussing the defaults is 
only going to mean time not available for implementing this or other 
features.


Please step back and listen, it is sometimes worth it.


The default is in accordance with standard requirements, and more more
conservative than other compilers which tend to enable their -ffast-math
equivalents by default rather than just -fno-rounding-math.

At least these others have chosen to do it more consistently.
They don't claim their default is anything sane at all for
serious FP computations, which at least is clear.


GCC does not try to make such a claim; it depends entirely on your 
definition of "serious FP computations", which is clearly a bikeshed


Sure.

discussion even if the discussion of defaults isn't.  GCC provides various 
options and documents the defaults.  The defaults are deliberate decisions 
(and as such the adoption of those decisions cannot meaningfully be 
considered a regression: it's not a bug but a feature), but are more 
likely to change in the other direction from what you want.


Which makes it yet another case that translation-unit level defaults
won't solve this issue, and that these things should be made controllable
at a finer granularity, in the source code.
This is what the C99 pragma is supposed to do, but as I said, it would
not be ideal anyway even if implemented.

It is incomplete as it would prevent constant propagation through
directed rounding operations.

C++0x aims at improving the situation concerning constant propagation,
with "constexpr".

I have therefore worked on N2811
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2008/n2811.pdf
in order to provide a way to do things better than the pragma
and with a better interaction with constant propagation.
This proposal is aimed at being ideal for interval arithmetic
and related ocmputations dealing with the rounding mode
(I'll issue a revision of the document soon, based on the feedback
I got at Summit).
This is C++ syntax, but the core proposal is basically to add
compiler built-ins to do FP operations with a specified rounding
mode, so you may imagine a C or Fortran interface as well.

(I don't claim N2811 is as complete as we could imagine it,
it is driven my the interval arithmetic needs, and I would love
to see other experts comment on it)


A more general side remark is that it is really a pitty that the expertise
in these domains is split among the C, C++ and Fortran committees.
This is a reason why I proposed to create a dedicated working group
for scientific computing in C++ (which might actually get real) and
which would allow to gather scientific experts and focus on scientific
aspects (numerics being one of them), while still having a relation
with the dominant language, C++, but without bothering non-C++
experts too much with purely C++ aspects.



Moreover, standards are far from saying anything about the best default
for -frounding-math, it's a GCC matter.  And GCC maintainers should
be able to listen to expert users to help them making good choices.


GCC maintainers must also bear in mind the bulk of users for whom the 
default options, complete with other issues such as x87 excess precision, 
are just fine, and the value of good benchmark scores in marketing GCC.  
(You will of course nevertheless note that I have fixed PR 323 for C for 
4.5.)


Yep, I did note, and this is impressive work.
Though, as a C++ user, I won't see the benefit of it for now unfortunately :(

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Paolo Bonzini]

Sylvain Pion wrote:
> Andrew Thomas Pinski wrote:
>>> The fact is that Roger's patch introduced a regression (this word
>>> should be clear enough here), in that some users now have their old
>>> code broken, and they are forced to add the -frounding-math option
>>> (after having lost some time finding about this non trivial issue).
>>> This is a long term hindrance.
>>
>> Actually before roger's patch the default is the same. Just there was
>> no way to turn it off.
> 
> Actually, there are 2 things controlled by -frounding-math :
> 1) constant propagation of FP operations
> 2) generic transformations like (-a)*b <-> -(a*b)

I think 2) is taken care of by -fassociative-math, or it should at least.

Paolo

Re: Setting -frounding-math by default

[Sylvain Pion]

Andrew Thomas Pinski wrote:

The fact is that Roger's patch introduced a regression (this word
should be clear enough here), in that some users now have their old
code broken, and they are forced to add the -frounding-math option
(after having lost some time finding about this non trivial issue).
This is a long term hindrance.


Actually before roger's patch the default is the same. Just there was no 
way to turn it off.


Actually, there are 2 things controlled by -frounding-math :
1) constant propagation of FP operations
2) generic transformations like (-a)*b <-> -(a*b)

At the time Roger's patch went in, I believe that only 2) was concerned,
and GCC did not try to do anything special about 1).
And *this*, is the "regression" I'm complaining about.

Later, 1) started to be taken care of, and it was unfortunately
added under the control of the same -frounding-math option.
Which now, makes it harder to come back, since we want different
defaults for these two aspects.

I have already mentioned in a bugzilla PR that it could be nice
to have 2 options, but IIRC, I did not get any reply to this.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Richard Guenther]

On Mon, Mar 9, 2009 at 12:35 AM, Joseph S. Myers
 wrote:
> - Show quoted text -
> On Mon, 9 Mar 2009, Steven Bosscher wrote:
>
>> On Mon, Mar 9, 2009 at 12:24 AM, Joseph S. Myers
>>  wrote:
>> >  The defaults are deliberate decisions
>> > (and as such the adoption of those decisions cannot meaningfully be
>> > considered a regression: it's not a bug but a feature), but are more
>> > likely to change in the other direction from what you want.
>>
>> I wish the same "not a bug but a feature" measure would be applied to
>> some of the "optimization" regressions (those in Bugzilla and those
>> holding up big cleanups).
>
> I hope we judge optimizations based on whether they seem to improve (or
> not make worse) important benchmarks on important targets rather than the
> impossible standard of not making *any* code worse.  (And cleanups
> likewise on not making a range of benchmarks worse.)
>
> A particular case made worse may still be a regression, but it could quite
> reasonably be a P4 or P5 regression depending on how much code is
> affected.

It's pretty hard to qualify them as more or less important.  So unless
we get completely swamped in P2s like that I'd rather stay to the
current policy.  A more reasonable thing would be to downgrade
optimization regressions once they shipped in a stable release, thus
only make optimization regressions against the previous release
series >P3.

Richard.

> --
> - Show quoted text -
> Joseph S. Myers
> jos...@codesourcery.com

Re: Setting -frounding-math by default

[Joseph S. Myers]

On Sun, 8 Mar 2009, Richard Guenther wrote:

> We try to have a sensible default setting that doesn't prevent constant 
> folding (which -frounding-math does).

-ftrapping-math implemented according to its specification would prevent a 
lot of constant folding (at least, the "inexact" and other exceptions from 
constant expressions not in static initializers should be preserved, 
although you could fold a complicated expression down to a simpler one 
that still gives the right set of exceptions).  I suspect we might 
therefore end up wanting a weaker version of -ftrapping-math as the 
default with the full present specification of -ftrapping-math not being 
the default if it gets implemented.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Setting -frounding-math by default

[Joseph S. Myers]

On Mon, 9 Mar 2009, Steven Bosscher wrote:

> On Mon, Mar 9, 2009 at 12:24 AM, Joseph S. Myers
>  wrote:
> >  The defaults are deliberate decisions
> > (and as such the adoption of those decisions cannot meaningfully be
> > considered a regression: it's not a bug but a feature), but are more
> > likely to change in the other direction from what you want.
> 
> I wish the same "not a bug but a feature" measure would be applied to
> some of the "optimization" regressions (those in Bugzilla and those
> holding up big cleanups).

I hope we judge optimizations based on whether they seem to improve (or 
not make worse) important benchmarks on important targets rather than the 
impossible standard of not making *any* code worse.  (And cleanups 
likewise on not making a range of benchmarks worse.)

A particular case made worse may still be a regression, but it could quite 
reasonably be a P4 or P5 regression depending on how much code is 
affected.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Setting -frounding-math by default

[Steven Bosscher]

On Mon, Mar 9, 2009 at 12:24 AM, Joseph S. Myers
 wrote:
>  The defaults are deliberate decisions
> (and as such the adoption of those decisions cannot meaningfully be
> considered a regression: it's not a bug but a feature), but are more
> likely to change in the other direction from what you want.

I wish the same "not a bug but a feature" measure would be applied to
some of the "optimization" regressions (those in Bugzilla and those
holding up big cleanups).

Gr.
Steven

Re: Setting -frounding-math by default

[Joseph S. Myers]

On Sun, 8 Mar 2009, Sylvain Pion wrote:

> this pragma.  I nevertheless try to find grants for funding
> people to implement some related things in GCC.  And I also
> contribute time to help in the guidance of GCC with my
> expertise in this particular area, even if it requires a lot
> of time to convince people.  So, please...

Finding funding for implementing standard pragmas and completing the 
-frounding-math implementation is likely to be more productive than 
arguing about a default for an option that is known to have problems.  
All the people discussing the issue are familiar with the floating point 
optimization issues in GCC.  (I have added many such bugs to the 
dependencies of bug 16989 in the past to help track them, and just added 
some more.)  Since as far as I know all work done on the floating-point 
issues has been done as volunteers, time spent discussing the defaults is 
only going to mean time not available for implementing this or other 
features.

> > The default is in accordance with standard requirements, and more more
> > conservative than other compilers which tend to enable their -ffast-math
> > equivalents by default rather than just -fno-rounding-math.
> 
> At least these others have chosen to do it more consistently.
> They don't claim their default is anything sane at all for
> serious FP computations, which at least is clear.

GCC does not try to make such a claim; it depends entirely on your 
definition of "serious FP computations", which is clearly a bikeshed 
discussion even if the discussion of defaults isn't.  GCC provides various 
options and documents the defaults.  The defaults are deliberate decisions 
(and as such the adoption of those decisions cannot meaningfully be 
considered a regression: it's not a bug but a feature), but are more 
likely to change in the other direction from what you want.

> Moreover, standards are far from saying anything about the best default
> for -frounding-math, it's a GCC matter.  And GCC maintainers should
> be able to listen to expert users to help them making good choices.

GCC maintainers must also bear in mind the bulk of users for whom the 
default options, complete with other issues such as x87 excess precision, 
are just fine, and the value of good benchmark scores in marketing GCC.  
(You will of course nevertheless note that I have fixed PR 323 for C for 
4.5.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Setting -frounding-math by default

[Andrew Thomas Pinski]

Sent from my iPhone

On Mar 8, 2009, at 3:26 PM, Sylvain Pion  
 wrote:



Joseph S. Myers a écrit :

On Sun, 8 Mar 2009, Sylvain Pion wrote:

http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00104.html
introduced the -frounding-math option, and changed
the default behavior of GCC to optimize "unsafely".
That is a misleading description.  The cautionary text added by  
that patch is still present:

   This option is experimental and does not currently guarantee to
   disable all GCC optimizations that are affected by rounding mode.
This is still true.  GCC did not before the patch, did not after  
the patch and does not now fully support disabling optimizations  
that are unsafe in the presence of rounding mode changes; a few  
affected optimizations are disabled, but noone has seriously  
attempted to cover them all.  GCC was "unsafe" before the patch and  
remains so whether or not you use the option.


You are playing with words.  Please step back and look at the facts
for a moment.

The fact is that Roger's patch introduced a regression (this word
should be clear enough here), in that some users now have their old
code broken, and they are forced to add the -frounding-math option
(after having lost some time finding about this non trivial issue).
This is a long term hindrance.


Actually before roger's patch the default is the same. Just there was  
no way to turn it off.





Even if -frounding-math is not 100% correct, it makes things work
(more precisely, lack of it breaks code), and this is the only
thing that matters here.



I am tired of waiting for a solution in GCC,

http://gcc.gnu.org/faq.html#support
There are plenty of bug reports for floating-point issues, and a  
lack of volunteers fixing them, so perhaps you should not expect  
filing more bugs to help, but "waiting for a solution" isn't listed  
there at all.


Thanks for this first-level hotline support reply.
You should probably learn to whom you are replying to.
In particular, I did send patches to GCC several times,
look at the changelogs.  I know what this is all about.
And I know that it is beyond my time availability to learn
enough to contribute patches for big things like supporting
this pragma.  I nevertheless try to find grants for funding
people to implement some related things in GCC.  And I also
contribute time to help in the guidance of GCC with my
expertise in this particular area, even if it requires a lot
of time to convince people.  So, please...


I'm willing to contribute a patch that changes the default,
if this pleases you.  It will take me 30 minutes, and would
take only 5 for a professional GCC developers since I have
to setup the environment.

The hard part, the most time consuming part here, is the discussion
on the rationale, which is why I ended up with the decision of
sending this mail rather than a patch directly.


Moreover, when reading Roger's mail I refered to, it explicitly
said that support for the pragma was "intended to come next".
So "waiting for a fix" was what I was supposed to do, once this
patch went in GCC, that introduced a regression.




Somehow, I also think that this -fno-rounding-math default is
inconsistent with the general policy of defaults in GCC which
is to aim at safety and correctness first.
The default is in accordance with standard requirements, and more  
more conservative than other compilers which tend to enable their - 
ffast-math equivalents by default rather than just -fno-rounding- 
math.


At least these others have chosen to do it more consistently.
They don't claim their default is anything sane at all for
serious FP computations, which at least is clear.

Moreover, standards are not perfect.  In particular, in this area,
C++ doesn't say much (I don't care about C, which lacks way too many
necessary features for serious general scientific programming anyway).
C++0x currently adopts C99's fesetround() without the pragma, so it's
in an inconsistent state.  I nevertheless try to have this fixed
properly before C++0x is out (I was at Summit last week to defend
my N2811 paper around precisely this issue, for example).

Moreover, standards are far from saying anything about the best  
default

for -frounding-math, it's a GCC matter.  And GCC maintainers should
be able to listen to expert users to help them making good choices.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Richard Guenther]

On Sun, Mar 8, 2009 at 11:26 PM, Sylvain Pion
 wrote:
> Joseph S. Myers a écrit :
>>
>> On Sun, 8 Mar 2009, Sylvain Pion wrote:
>>
>>> http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00104.html
>>> introduced the -frounding-math option, and changed
>>> the default behavior of GCC to optimize "unsafely".
>>
>> That is a misleading description.  The cautionary text added by that patch
>> is still present:
>>
>>    This option is experimental and does not currently guarantee to
>>    disable all GCC optimizations that are affected by rounding mode.
>>
>> This is still true.  GCC did not before the patch, did not after the patch
>> and does not now fully support disabling optimizations that are unsafe in
>> the presence of rounding mode changes; a few affected optimizations are
>> disabled, but noone has seriously attempted to cover them all.  GCC was
>> "unsafe" before the patch and remains so whether or not you use the option.
>
> You are playing with words.  Please step back and look at the facts
> for a moment.
>
> The fact is that Roger's patch introduced a regression (this word
> should be clear enough here), in that some users now have their old
> code broken, and they are forced to add the -frounding-math option
> (after having lost some time finding about this non trivial issue).
> This is a long term hindrance.
>
> Even if -frounding-math is not 100% correct, it makes things work
> (more precisely, lack of it breaks code), and this is the only
> thing that matters here.

Your position is clear.  There is others complaining about the exact opposite
of course - those that see -ffast-math "violating IEEE" and that want
"fast math",
but IEEE by default.  Whatever that means to them, of course.  We try
to have a sensible
default setting that doesn't prevent constant folding (which
-frounding-math does).

I don't have a solution for you unfortunately, other than finally
trying to implement
FENV access.  But that requires a considerable amount of ressources
that I cannot
see being spent at any point in time.

Thanks,
Richard.

Re: Setting -frounding-math by default

[Sylvain Pion]

Joseph S. Myers a écrit :

On Sun, 8 Mar 2009, Sylvain Pion wrote:


http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00104.html
introduced the -frounding-math option, and changed
the default behavior of GCC to optimize "unsafely".


That is a misleading description.  The cautionary text added by that patch 
is still present:


This option is experimental and does not currently guarantee to
disable all GCC optimizations that are affected by rounding mode.

This is still true.  GCC did not before the patch, did not after the patch 
and does not now fully support disabling optimizations that are unsafe in 
the presence of rounding mode changes; a few affected optimizations are 
disabled, but noone has seriously attempted to cover them all.  GCC was 
"unsafe" before the patch and remains so whether or not you use the 
option.


You are playing with words.  Please step back and look at the facts
for a moment.

The fact is that Roger's patch introduced a regression (this word
should be clear enough here), in that some users now have their old
code broken, and they are forced to add the -frounding-math option
(after having lost some time finding about this non trivial issue).
This is a long term hindrance.

Even if -frounding-math is not 100% correct, it makes things work
(more precisely, lack of it breaks code), and this is the only
thing that matters here.



I am tired of waiting for a solution in GCC,


http://gcc.gnu.org/faq.html#support

There are plenty of bug reports for floating-point issues, and a lack of 
volunteers fixing them, so perhaps you should not expect filing more bugs 
to help, but "waiting for a solution" isn't listed there at all.


Thanks for this first-level hotline support reply.
You should probably learn to whom you are replying to.
In particular, I did send patches to GCC several times,
look at the changelogs.  I know what this is all about.
And I know that it is beyond my time availability to learn
enough to contribute patches for big things like supporting
this pragma.  I nevertheless try to find grants for funding
people to implement some related things in GCC.  And I also
contribute time to help in the guidance of GCC with my
expertise in this particular area, even if it requires a lot
of time to convince people.  So, please...


I'm willing to contribute a patch that changes the default,
if this pleases you.  It will take me 30 minutes, and would
take only 5 for a professional GCC developers since I have
to setup the environment.

The hard part, the most time consuming part here, is the discussion
on the rationale, which is why I ended up with the decision of
sending this mail rather than a patch directly.


Moreover, when reading Roger's mail I refered to, it explicitly
said that support for the pragma was "intended to come next".
So "waiting for a fix" was what I was supposed to do, once this
patch went in GCC, that introduced a regression.




Somehow, I also think that this -fno-rounding-math default is
inconsistent with the general policy of defaults in GCC which
is to aim at safety and correctness first.


The default is in accordance with standard requirements, and more more 
conservative than other compilers which tend to enable their -ffast-math 
equivalents by default rather than just -fno-rounding-math.


At least these others have chosen to do it more consistently.
They don't claim their default is anything sane at all for
serious FP computations, which at least is clear.

Moreover, standards are not perfect.  In particular, in this area,
C++ doesn't say much (I don't care about C, which lacks way too many
necessary features for serious general scientific programming anyway).
C++0x currently adopts C99's fesetround() without the pragma, so it's
in an inconsistent state.  I nevertheless try to have this fixed
properly before C++0x is out (I was at Summit last week to defend
my N2811 paper around precisely this issue, for example).

Moreover, standards are far from saying anything about the best default
for -frounding-math, it's a GCC matter.  And GCC maintainers should
be able to listen to expert users to help them making good choices.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Re: Setting -frounding-math by default

[Joseph S. Myers]

On Sun, 8 Mar 2009, Sylvain Pion wrote:

> http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00104.html
> introduced the -frounding-math option, and changed
> the default behavior of GCC to optimize "unsafely".

That is a misleading description.  The cautionary text added by that patch 
is still present:

This option is experimental and does not currently guarantee to
disable all GCC optimizations that are affected by rounding mode.

This is still true.  GCC did not before the patch, did not after the patch 
and does not now fully support disabling optimizations that are unsafe in 
the presence of rounding mode changes; a few affected optimizations are 
disabled, but noone has seriously attempted to cover them all.  GCC was 
"unsafe" before the patch and remains so whether or not you use the 
option.

> I am tired of waiting for a solution in GCC,

http://gcc.gnu.org/faq.html#support

There are plenty of bug reports for floating-point issues, and a lack of 
volunteers fixing them, so perhaps you should not expect filing more bugs 
to help, but "waiting for a solution" isn't listed there at all.

> Somehow, I also think that this -fno-rounding-math default is
> inconsistent with the general policy of defaults in GCC which
> is to aim at safety and correctness first.

The default is in accordance with standard requirements, and more more 
conservative than other compilers which tend to enable their -ffast-math 
equivalents by default rather than just -fno-rounding-math.

-- 
Joseph S. Myers
jos...@codesourcery.com

Setting -frounding-math by default

[Sylvain Pion]

I would like to argue that the default behavior should
be -frounding-math, which is safer than the opposite
used currently.

Back in 2003, the following patch by Roger Sayle :
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00104.html
introduced the -frounding-math option, and changed
the default behavior of GCC to optimize "unsafely".

Have a look at the arguments there.  An important argument was
that this patch was supposed to be a first step, and that
"pragma STDC FENV_ACCESS" support would come as a follow up
patch.  We are still waiting for it, or any other mean
to be able to select the safe option from inside the source
code (or automatic detection of calls to fesetround() in a
program to trigger -frounding-math in many relevant cases).
I, for example, had some hope when the "option attributes"
patches went in recently, but it finally did not cover this
question.

If support for such options had indeed been contributed,
things would have been different.  But there is a main
issue now for developers of things like interval arithmetic.
This kind of code needs this option for working correctly,
and since this is typically code which goes in a library,
it means all their users need to care about setting this option
for their own programs (think about an STL-like implementation
with inline functions in headers, and this is what happens
in practice here).

We frequently get bug reports by CGAL users about that, and
this even forced me to try to implement an attempt at run-time
detection of the presence of -fno-rounding-math to ease debuggability.
I'm sure Boost.Interval must has the same issue.
I am tired of waiting for a solution in GCC, and loosing time
with this problem, and I think the real bug here is in GCC.


As far as performance is concerned, I'm not sure what the
regression impact of switching the default would look like.
Programs already using -ffast-math would not be affected anyway.
It might be nice to see the effect on SPEC or other standard benchmarks,
and it might also be nice to check how many programs are forced
to add the -frounding-math for correctness.

Somehow, I also think that this -fno-rounding-math default is
inconsistent with the general policy of defaults in GCC which
is to aim at safety and correctness first.

I would be glad to read your opinions on this.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/