headers
Jerry DeLisle | 1 Jul 01:49
Picon

Re: [Patch, libgfortran] [4.4/4.5 Regression] Endless loop in internal write

Thomas Koenig wrote:
> Hi Jerry,
> 
> I committed the following test case as obvious to 4.5 (and HJ backported
> it to 4.4 before I could, thanks):
> 
> 2009-06-30  Thomas Koenig  <tkoenig <at> gcc.gnu.org>
> 
>         PR fortran/40576
>         * gfortran.dg/internal_write_1.f90:  New testcase.
> 
> Thanks for the quick fix!
> 
> 	Thomas
> 
Thanks for the test case, I was hoping somebody would grab at it.

Jerry
Permalink | Reply | 0 comments |
headers
Daniel Franke | 2 Jul 12:02
Picon

-f[no-]finite-math-only


Dear all,

some Fortran77 code I inherited gives wrong results if compiled 
with '-ffast-math', especially with '-ffinite-math-only' enabled 
('-ffast-math -fno-finite-math-only' seems to work).

As '-ffinite-math-only' does "Allow optimizations for floating-point 
arithmetic that assume that arguments and results are not NaNs or +-Infs", it 
is to assume that the code uses either or both. If so, it's very likely that 
this was not intended by the original author.

Any pointers on how to track down these issues in ~25kloc of Fortran77 to 
double check what's going on?

Thanks

	Daniel

P.S. Not using '-ffast-math' would of course be an option, but knowing that 
there might be something fishy going on with NaN/Inf does not improve the 
confidence in the application's results ...
Permalink | Reply | 0 comments |
headers
Richard Guenther | 2 Jul 13:26
Picon

Re: -f[no-]finite-math-only

On Thu, Jul 2, 2009 at 12:02 PM, Daniel Franke<franke.daniel <at> gmail.com> wrote:
>
> Dear all,
>
> some Fortran77 code I inherited gives wrong results if compiled
> with '-ffast-math', especially with '-ffinite-math-only' enabled
> ('-ffast-math -fno-finite-math-only' seems to work).
>
> As '-ffinite-math-only' does "Allow optimizations for floating-point
> arithmetic that assume that arguments and results are not NaNs or +-Infs", it
> is to assume that the code uses either or both. If so, it's very likely that
> this was not intended by the original author.
>
> Any pointers on how to track down these issues in ~25kloc of Fortran77 to
> double check what's going on?

The code is likely using isinf/isnan intrinsics (if such exist) or
comparisons like x != x which check for NaN.  Those are optimized
away with -ffinite-math-only.

Richard.

> Thanks
>
>
>        Daniel
>
>
> P.S. Not using '-ffast-math' would of course be an option, but knowing that
> there might be something fishy going on with NaN/Inf does not improve the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Kicko | 2 Jul 14:58
Picon

Donate for text link

Hi Gnu,

Thank you for great OSS project. I would like to make donation for you. 
Could you please place my text link on your homepage 
(http://gcc.gnu.org/fortran/). It would link to my software downloads 
website, anchor text "Software Download".

Please let me know.

Regards,
Martin
Permalink | Reply | 0 comments |
headers
Michael Matz | 2 Jul 15:29
Picon
Favicon

[patch] PR32131: allocatable arrays have stride 1

Hi,

this provides one solution to PR32131.  leslie3d (amongst other benchmark) 
exhibits this problem.  It can't vectorize the interesting loops because 
the stride is unknown.  The general solution implies versioning for 
stride, for which we also have a patch.  But for allocatable arrays (as is 
the case with leslie3d) we can do much easier and even generate better 
initial code.  Their lowest dimension always has stride 1, so adjusting 
gfc_conv_descriptor_stride_get() is enough (on top of richis recent 
improvements to alias disambiguation) to vectorize everything interesting 
in leslie.  Its runtime drops from 960 to 823 seconds, 14% improvement.

I regression tested with the fortran testsuite, and had to adjust one 
testcase (funnily also extracted from leslie :) ).  We don't expect six 
accesses to stride members anymore, but only four.

Okay for trunk?

Ciao,
Michael.
--

-- 
fortran/
	PR fortran/32131
	* trans-array.c (gfc_conv_descriptor_stride_get): Return
	constant one for strides in the first dimension of ALLOCATABLE
	arrays.

testsuite/
	PR fortran/32131
	* gfortran.dg/pr32921.f: Adjust.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tobias Burnus | 2 Jul 16:41
Picon

Re: [patch] PR32131: allocatable arrays have stride 1

Michael Matz wrote:
> Their lowest dimension always has stride 1, so adjusting 
> gfc_conv_descriptor_stride_get() is enough (on top of richis recent 
> improvements to alias disambiguation) to vectorize everything interesting 
> in leslie.  Its runtime drops from 960 to 823 seconds, 14% improvement.
>   
Impressive what a that small patch can do. Thanks for the patch.

> Okay for trunk?
>   
Yes, the patch is OK.

 * * *

I wonder whether one couldn't extend the patch to explicit shape,
automatic arrays and assumed-size arrays; here also the innermost
dimension should have stride=1. (For pointers and for nonallocatable
assumed-shape arrays, this assumption is moot.)

To do this, one would need to update trans.c's gfc_array_kind, which
currently only has GFC_ARRAY_UNKNOWN, GFC_ARRAY_ASSUMED_SHAPE,
GFC_ARRAY_POINTER; maybe adding a GFC_ARRAY_CONTIGUOUS would be best?

Tobias

PS: To other readers: If one passes an allocatable array as via
vector-section and strides as actual argument, then the dummy argument
cannot be allocatable. If it is allocatable, it must be contiguous as
one cannot allocate with strides; thus this patch should be save. (For
pointers, the world is different.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tobias Burnus | 2 Jul 16:55
Picon

Re: [patch] PR32131: allocatable arrays have stride 1

Tobias Burnus wrote:
> I wonder whether one couldn't extend the patch to explicit shape,
> automatic arrays and assumed-size arrays; here also the innermost
> dimension should have stride=1.
Actually, this is already the case - sorry for not testing it before.

> maybe adding a GFC_ARRAY_CONTIGUOUS would be best?
>   
That would still make sense - as soon as we have Fortran 2008's
CONTIGUOUS attribute.

Tobias
Permalink | Reply | 0 comments |
headers
Kaveh R. Ghazi | 2 Jul 19:24
Picon
Favicon

Re: [PATCH]: Use mpc_pow in the fortran frontend

From: "Tobias Burnus" <burnus <at> net-b.de>

> PS: For those not following the MPC development, missing (C99/F2008)
> functions are mpc_acos, mpc_asin, mpc_atan, mpc_acosh, mpc_asinh,
> mpc_atanh. And MPFR misses (F2008) SCALED_ERFC. The implementation of
> all of those is planned; the inverse complex trigonometric/hyperbolic
> function will (hopefully) happen in the next few months.

The "arc" functions haven't been written yet in MPC, but as you say, they 
are planned (soon).

However what is the status of csinh/ccosh/ctanh and ctan in fortran?  These 
are currently available in MPC and could be added right now if the rest of 
the necessary infrastructure was put in place in the fortran frontend.  I 
believe C99 fallback implementations are included in 
libgfortran/intrinsics/c99_functions.c, so that shouldn't be a blocker.

        Thanks,
        --Kaveh
Permalink | Reply | 8 comments |
headers
Jakub Jelinek | 3 Jul 17:32
Picon
Favicon

[PATCH] Fix integer maxloc

Hi!

While gfc_conv_intrinsic_minmaxval computes limit = -HUGE-1 for
BT_INTEGER maxloc correctly, gfc_conv_intrinsic_minmaxloc does not, although
it computes -HUGE - 1, it assigns it to limit already when it is -HUGE.

Ok for trunk/4.4?

2009-07-03  Jakub Jelinek  <jakub <at> redhat.com>

	* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): For integer
	maxloc initialize limit to -huge-1 rather than just -huge.

	* gfortran.dg/maxloc_1.f90: New test.

--- gcc/fortran/trans-intrinsic.c.jj	2009-06-30 13:10:18.000000000 +0200
+++ gcc/fortran/trans-intrinsic.c	2009-07-03 17:09:02.000000000 +0200
@@ -2190,12 +2190,12 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
      possible value is HUGE in both cases.  */
   if (op == GT_EXPR)
     tmp = fold_build1 (NEGATE_EXPR, TREE_TYPE (tmp), tmp);
-  gfc_add_modify (&se->pre, limit, tmp);
-
   if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
     tmp = fold_build2 (MINUS_EXPR, TREE_TYPE (tmp), tmp,
 		       build_int_cst (type, 1));

+  gfc_add_modify (&se->pre, limit, tmp);
+
   /* Initialize the scalarizer.  */
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tobias Burnus | 3 Jul 20:27
Picon

Re: [PATCH] Fix integer maxloc


Jakub Jelinek wrote:
> While gfc_conv_intrinsic_minmaxval computes limit = -HUGE-1 for
> BT_INTEGER maxloc correctly, gfc_conv_intrinsic_minmaxloc does not, although
> it computes -HUGE - 1, it assigns it to limit already when it is -HUGE.
>
> Ok for trunk/4.4?
>   
OK thanks for the patch!

Tobias

> 2009-07-03  Jakub Jelinek  <jakub <at> redhat.com>
>
> 	* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): For integer
> 	maxloc initialize limit to -huge-1 rather than just -huge.
>
> 	* gfortran.dg/maxloc_1.f90: New test.
>
> --- gcc/fortran/trans-intrinsic.c.jj	2009-06-30 13:10:18.000000000 +0200
> +++ gcc/fortran/trans-intrinsic.c	2009-07-03 17:09:02.000000000 +0200
> @@ -2190,12 +2190,12 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
>       possible value is HUGE in both cases.  */
>    if (op == GT_EXPR)
>      tmp = fold_build1 (NEGATE_EXPR, TREE_TYPE (tmp), tmp);
> -  gfc_add_modify (&se->pre, limit, tmp);
> -
>    if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
>      tmp = fold_build2 (MINUS_EXPR, TREE_TYPE (tmp), tmp,
>  		       build_int_cst (type, 1));
(Continue reading)

Permalink | Reply | 0 comments |

Gmane