On Fri, 2019-02-22 at 14:19 +0100, Jakub Jelinek wrote:
> On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
> > gcc/fortran/ChangeLog:
> > PR middle-end/88074
> > * simplify.c (norm2_add_squared): Use mp_exp_t rather than
> > mpfr_exp_t.
>
> I have discussed this with Rich
On Fri, 22 Feb 2019, Jakub Jelinek wrote:
> On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
> > gcc/fortran/ChangeLog:
> > PR middle-end/88074
> > * simplify.c (norm2_add_squared): Use mp_exp_t rather than
> > mpfr_exp_t.
>
> I have discussed this with Richard on IRC ea
On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
> gcc/fortran/ChangeLog:
> PR middle-end/88074
> * simplify.c (norm2_add_squared): Use mp_exp_t rather than
> mpfr_exp_t.
I have discussed this with Richard on IRC earlier today, there is another
issue that mpfr_regul
On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
> gcc/fortran/simplify.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
> index fa6396b..a1df735 100644
> --- a/gcc/fortran/simplify.c
> +++ b/gcc/fortran/simpl
On Wed, 2019-02-13 at 00:09 +0100, Jakub Jelinek wrote:
> Hi!
>
> As discussed recently on the mailing list, the norm2 simplification
> doesn't
> work if we limit mpfr emin/emax to some values derived from maximum
> floating
> exponents (and precision for denormals).
>
> The following patch adjusts
Hi Steve,
On Sat, Feb 16, 2019 at 05:23:58PM +0100, Thomas Koenig wrote:
Also, we seem to have a lot of issues with IEEE flags
when calculating NORM2, this would also need to be
addressed.
Which IEEE flags and are you referring using the
Fortran modules or -ffpe-trap?
I checked out the so
On Sat, Feb 16, 2019 at 05:23:58PM +0100, Thomas Koenig wrote:
>
> Also, we seem to have a lot of issues with IEEE flags
> when calculating NORM2, this would also need to be
> addressed.
>
Which IEEE flags and are you referring using the
Fortran modules or -ffpe-trap?
--
Steve
Hi Jakub,
I checked the patch together with Richard's (by which I assume you
mean https://gcc.gnu.org/bugzilla/attachment.cgi?id=45052 ), and
thinks looked good.
So, the Fortran part of this is OK.
However, we should really also do power-of-two scaling
for the runtime method.
Also, we seem to
On Wed, Feb 13, 2019 at 10:51:07AM -0800, Steve Kargl wrote:
> To get Richard's emin/emax patch into the tree so adequate
> testing can be done prior to the 9.1 release, I'll suggest
> that we XFAIL norm2_3.f90 while we work out the details for
> norm2.
>
> Yesteraday, I looked at Jakub's patch, a
On Wed, Feb 13, 2019 at 07:30:53PM +0100, Jakub Jelinek wrote:
> On Wed, Feb 13, 2019 at 07:17:53PM +0100, Thomas Koenig wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux (together with
> > > Richard's patch), ok for trunk?
> >
> > A couple of points:
> >
> > with this patch, we
On Wed, Feb 13, 2019 at 07:17:53PM +0100, Thomas Koenig wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux (together with
> > Richard's patch), ok for trunk?
>
> A couple of points:
>
> with this patch, we will have an algorithm that will evaluate NORM2
> in a different way than bef
Hi Jakub,
Bootstrapped/regtested on x86_64-linux and i686-linux (together with
Richard's patch), ok for trunk?
A couple of points:
with this patch, we will have an algorithm that will evaluate NORM2
in a different way than before, possibly leading to regressions
in some cases where we previou
Hi!
As discussed recently on the mailing list, the norm2 simplification doesn't
work if we limit mpfr emin/emax to some values derived from maximum floating
exponents (and precision for denormals).
The following patch adjusts the computation, so that it is scaled down if
needed. In particular, i
13 matches
Mail list logo
