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
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.
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
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
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
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
>
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
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
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
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
>
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
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
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:
>
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
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
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
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++
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
18 matches
Mail list logo
