Hello,
as discussed in the PR, this seems like a simple enough approach to handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Some key missing things:
- handle C, not just C++ (I don't care, but some people probably do)
- handle vectors (for
On Sat, 22 Jun 2019, Marc Glisse wrote:
> as discussed in the PR, this seems like a simple enough approach to handle
> FENV functionality safely, while keeping it possible to implement
> optimizations in the future.
Could you give a high-level description of the implementation approach,
and how
On Sun, 23 Jun 2019, Marc Glisse wrote:
> For constant expressions, I see a difference between
> constexpr double third = 1. / 3.;
> which really needs to be done at compile time, and
> const double third = 1. / 3.;
> which will try to evaluate the rhs as constexpr, but where the program is
> stil
On Mon, 24 Jun 2019, Richard Biener wrote:
> On the patch I'd name _DIV _RDIV (to match the tree code we are dealing
> with). You miss _NEGATE and also the _FIX_TRUNC and _FLOAT in
> case those might trap with -ftrapping-math. There are also internal
Negation (and abs and copysign) can never ra
On Wed, 7 Aug 2019, Joseph Myers wrote:
On Sat, 22 Jun 2019, Marc Glisse wrote:
as discussed in the PR, this seems like a simple enough approach to handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Could you give a high-level description of
On Thu, 8 Aug 2019, Marc Glisse wrote:
> > FENV_ROUND (and FENV_DEC_ROUND) shouldn't be that hard, given the
>
> On the glibc side I expect it to be a lot of work, it seems to require a
> correctly rounded version of all math functions...
No, it doesn't. 18661-4 reserves cr* names for correctly
On Thu, 8 Aug 2019, Joseph Myers wrote:
On Thu, 8 Aug 2019, Marc Glisse wrote:
FENV_ROUND (and FENV_DEC_ROUND) shouldn't be that hard, given the
On the glibc side I expect it to be a lot of work, it seems to require a
correctly rounded version of all math functions...
No, it doesn't. 1866
On Mon, 24 Jun 2019, Marc Glisse wrote:
> > OK, fair enough. I just hoped that global
> >
> > double x = 1.0/3.0;
> >
> > do not become runtime initializers with -frounding-math ...
>
> Ah, I wasn't thinking of globals. Ignoring the new pragma fenv_round, which I
> guess could affect this (the
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
>Hello,
>
>as discussed in the PR, this seems like a simple enough approach to
>handle
>FENV functionality safely, while keeping it possible to implement
>optimizations in the future.
>
>Some key missing things:
>- handle C, not just C++
On Sat, 22 Jun 2019, Richard Biener wrote:
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
Hello,
as discussed in the PR, this seems like a simple enough approach to
handle
FENV functionality safely, while keeping it possible to implement
optimizations in the future.
Some key missi
On Sun, Jun 23, 2019 at 12:22 AM Marc Glisse wrote:
>
> On Sat, 22 Jun 2019, Richard Biener wrote:
>
> > On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse
> > wrote:
> >> Hello,
> >>
> >> as discussed in the PR, this seems like a simple enough approach to
> >> handle
> >> FENV functionality saf
On Mon, 24 Jun 2019, Richard Biener wrote:
On Sun, Jun 23, 2019 at 12:22 AM Marc Glisse wrote:
On Sat, 22 Jun 2019, Richard Biener wrote:
On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse wrote:
Hello,
as discussed in the PR, this seems like a simple enough approach to
handle
FENV funct
On Mon, Jun 24, 2019 at 3:47 PM Marc Glisse wrote:
>
> On Mon, 24 Jun 2019, Richard Biener wrote:
>
> > On Sun, Jun 23, 2019 at 12:22 AM Marc Glisse wrote:
> >>
> >> On Sat, 22 Jun 2019, Richard Biener wrote:
> >>
> >>> On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse
> >>> wrote:
> Hell
On Mon, 24 Jun 2019, Richard Biener wrote:
-frounding-math is supposed to be equivalent to "#pragma stdc fenv_access
on" covering the whole program.
For constant expressions, I see a difference between
constexpr double third = 1. / 3.;
which really needs to be done at compile time, and
const do
On 22/06/2019 23:21, Marc Glisse wrote:
> We should care about the C standard, and do whatever makes sense for C++
> without expecting the C++ standard to tell us exactly what that is. We
> can check what visual studio and intel do, but we don't have to follow them.
>
> -frounding-math is suppose
On Mon, Jun 24, 2019 at 4:57 PM Marc Glisse wrote:
>
> On Mon, 24 Jun 2019, Richard Biener wrote:
>
> -frounding-math is supposed to be equivalent to "#pragma stdc fenv_access
> on" covering the whole program.
>
> For constant expressions, I see a difference between
> cons
On Mon, 24 Jun 2019, Szabolcs Nagy wrote:
On 22/06/2019 23:21, Marc Glisse wrote:
We should care about the C standard, and do whatever makes sense for C++
without expecting the C++ standard to tell us exactly what that is. We
can check what visual studio and intel do, but we don't have to foll
Hello,
just posting the current version of this patch, in case people have
comments.
Some changes: the inline asm is introduced during expansion, and the thing
is controlled by a different flag (it should be controlled by the pragma,
but that's starting to be too many pieces to implement at
18 matches
Mail list logo