On Mon, May 23, 2005 at 10:28:05AM +0200, Uros Bizjak wrote:
> This change is needed to get i387 status word switching instructions in
> (int)->(float) conversions out of the loops, i.e.:
>
> int i;
> double d;
>
> for (x = 0... {
>i[x] = d[x];
> }
I think it would also be very useful to hav
On Sat, Jun 18, 2005 at 12:54:40PM +0200, Mattias Karlsson wrote:
> On Sat, 18 Jun 2005, Vincent Lefevre wrote:
>
> >On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
> >>As you well know, not everyone agrees this is a bug, and this does
> >>not have to do with performance. Saying over and over ag
re 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 Sophi
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 tex
me -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/
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
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
code uses it, which triggers lots of warning.
My workaround for this is to test for G++0x mode explicitly in addition,
and #error on it in my test program.
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
The problem I fear is that variadic templates are already conveniently
used as an implementation detail in libstdc++. And the warning there
is probably hidden by the "system header" warning removal machinery.
But then probably
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
But then probably, variadic templates are implemented as a GCC
extension to C++98 and they work fine with -std=c++98 despite what the
warning says. Or don't they?
Yes, but like any extension, it's nice to be able to disable them
as
Gabriel Dos Reis wrote:
On Tue, Mar 10, 2009 at 6:58 AM, Sylvain Pion
wrote:
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
The problem I fear is that variadic templates are already conveniently
used as an implementation detail in libstdc++. And the warning there
is probably hidden by
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
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
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/
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, http://cgal.org/
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
. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6588
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/
Sylvain Pion a écrit :
Naive user question : is this going to improve the efficiency
of throwing exceptions, at least in the restricted cases of :
- the catch clause contains the throw (after inlining).
I meant the try block, sorry.
- interprocedural analysis can connect
Jan Hubicka a écrit :
Sylvain Pion a écrit :
Naive user question : is this going to improve the efficiency
of throwing exceptions, at least in the restricted cases of :
There is little improvement already via EH cleanup: at least
cleanups/catch regions that turns out to be empty are now
nit and use alternative EH delivery mechanizm,
but it would be a lot of effort to implement faster variant of runtime
that works on so many targets as GCC has and the benefits would be IMO
quite low.
Possibly.
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/
Dear Richard and GCC list,
I am working on a proposal to standardize interval arithmetic in C++.
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1843.pdf)
In order to implement it efficiently, one typically needs to use the
FPU rounding modes (e.g. using fegetround and fesetround from
the RVO, even for objects defining an rvalue-ref copy
constructor, right?
BTW, http://gcc.gnu.org/projects/cxx0x.html does not yet mention the rvalue
reference patch.
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project
CGAL, http://cgal.org/
skaller wrote :
I can tell you I definitely considered using FS for the
Felix thread frame pointer to save passing that pointer
between every function..
But then, won't you end up with an implementation very similar
to __thread??
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project
particular case is connected to pragma FENV_ACCESS though. )
Also, would this work when the functions is inline?
I mean the case when the caller does not have the same attribute,
but the inlined code of the callee still respects the attribute
set for the inlined callee.
--
Sylvain Pion
IN
24 matches
Mail list logo
