[Bug fortran/30694] New: minval/maxval with +/-Inf

[Bug fortran/30694] New: minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

This is strange:

$ cat minval.f90
program main
  integer :: i
  data i /z'7f800000'/
  real :: a(1)
  a(1) = transfer(i,a(1))  ! a(1) contains +Inf
  print *,a(1), minval(a)
  if (a(1) > minval(a)) print *,"Strange..."
end program main
$ gfortran minval.f90
$ ./a.out
      +Infinity  3.4028235E+38
 Strange...

Ifort gets this right:

$ ifort minval.f90
$ ./a.out
 Infinity       Infinity

We should really be initializing our starting values to +/-Inf, both
in the library and the front end.

Related, of course, to PR 30512.


-- 
           Summary: minval/maxval with +/-Inf
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tkoenig at gcc dot gnu dot org
 BugsThisDependsOn: 30512


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug fortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-02-03 16:40 -------
> We should really be initializing our starting values to +/-Inf, both
> in the library and the front end.

In principle yes, but we need still return +HUGE or -HUGE (respectively
-HUGE-1) for arrays with zero elements.

I think the standard not really defines what happens for -INF, INF or NAN.
nagf95, g95 and sunf95 also return +HUGE() not +INF.
What should be the result of  minval( [ INF, NAN ] ) or of minval([4, NAN]) ?

(I think this PR is in so far disjunct from PR 30512 as the latter regards
INTEGERs, while this PR is about REALs.)


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug fortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #2 from tkoenig at gcc dot gnu dot org  2007-02-03 19:28 -------
(In reply to comment #1)
> > We should really be initializing our starting values to +/-Inf, both
> > in the library and the front end.
> 
> In principle yes, but we need still return +HUGE or -HUGE (respectively
> -HUGE-1) for arrays with zero elements.

We could always do (assuming the array starts at 1)

   if (n <= 0) then
     aval = -HUGE_VAL
   else
     aval = a(1)
     do i=2, n
       if (a(i) > aval) aval = a(i)
     end do
   end if

Straightforward for simple cases, could get messy for
masked, multi-dimensional cases.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug fortran/30694] minval/maxval with +/-Inf

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-02-03 20:27 -------
> I think the standard not really defines what happens for -INF, INF or NAN.
> nagf95, g95 and sunf95 also return +HUGE() not +INF.
> What should be the result of  minval( [ INF, NAN ] ) or of minval([4, NAN]) ?

The Fortran 2003 standard might define what happens with the IEEE real types
but other than that I don't think INF/NAN exists really in fortran's real
types.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug fortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2007-02-04 00:19 -------
Thomas asked at c.l.f:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e3745c39a11522c5


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug fortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2007-02-05 19:40 -------
As Dick Hendrickson points out in c.l.fortran:
13.7 (the function descriptions) says

"A program is prohibited from invoking an intrinsic procedure under
circumstances where a value to be returned in a subroutine argument
or function result is outside the range of values representable by
objects of the specified type and type parameters, unless the intrinsic
module IEEE ARITHMETIC (section 14) is accessible and there is support
for an infinite or a NaN result, as appropriate."

And IEEE:
http://754r.ucbtest.org/drafts/754r.pdf

"Operations on infinite operands are usually exact and therefore signal no
exceptions."

"Every general-computational and quiet-computational operation involving one or
more input NaNs, none of them signaling, shall signal no exception, except
fusedMultiplyAdd (see 9.2) . For an operation with quiet NaN inputs other than
max and min operations, if a floating-point result is to be delivered, the
result shall be a quiet NaN, which should be one of the input NaNs."

"minNum(x,y) is the canonical floating-point number x if x < y, y if y < x, the
canonicalized floatingpoint number if one operand is a floating-point number
and the other a NaN. Otherwise it is either x or y.
maxNum(x,y) is the canonical floating-point number y if x < y, x if y < x, the
canonicalized floatingpoint number if one operand is a floating-point number
and the other a NaN. Otherwise it is either x or y."


Min/maxval should return (for REAL):
 +INF if there is an INF in the maxval argument array
 -INF if there is a -INF in the minval argument array
 NAN if the argument array only consists of NAN
 -HUGE or HUGE if there the array is zero-dimensional (after masking)
(for the other cases the obvious min/max values of the arguments)

For INTEGERs, we only have:
 -HUGE-1 / +HUGE for a zero-dimensional array (after masking)
(for the other cases the obvious min/max)
as NAN and +/-INF don't exists (cf. PR30512).


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-02-05 19:40:47
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-02-06 12:12 -------
(In reply to comment #5)
> Min/maxval should return (for REAL):
>  +INF if there is an INF in the maxval argument array
>  -INF if there is a -INF in the minval argument array
>  NAN if the argument array only consists of NAN
>  -HUGE or HUGE if there the array is zero-dimensional (after masking)
> (for the other cases the obvious min/max values of the arguments)
> 
> For INTEGERs, we only have:
>  -HUGE-1 / +HUGE for a zero-dimensional array (after masking)
> (for the other cases the obvious min/max)
> as NAN and +/-INF don't exists (cf. PR30512).

I agree with that. I think we need separate m4 files for integers and reals,
changing the Makefile in the following way:

Index: Makefile.am
===================================================================
--- Makefile.am (revision 121506)
+++ Makefile.am (working copy)
@@ -175,10 +175,12 @@
 generated/maxloc1_8_r16.c \
 generated/maxloc1_16_r16.c

-i_maxval_c= \
+i_maxval_i_c= \
 generated/maxval_i4.c \
 generated/maxval_i8.c \
-generated/maxval_i16.c \
+generated/maxval_i16.c
+
+i_maxval_r_c= \
 generated/maxval_r4.c \
 generated/maxval_r8.c \
 generated/maxval_r10.c \
@@ -230,10 +232,12 @@
 generated/minloc1_8_r16.c \
 generated/minloc1_16_r16.c

-i_minval_c= \
+i_minval_i_c= \
 generated/minval_i4.c \
 generated/minval_i8.c \
-generated/minval_i16.c \
+generated/minval_i16.c
+
+i_minval_r_c= \
 generated/minval_r4.c \
 generated/minval_r8.c \
 generated/minval_r10.c \
@@ -419,9 +423,9 @@
 generated/pow_c16_i16.c

 m4_files= m4/iparm.m4 m4/ifunction.m4 m4/iforeach.m4 m4/all.m4 \
-    m4/any.m4 m4/count.m4 m4/maxloc0.m4 m4/maxloc1.m4 m4/maxval.m4 \
-    m4/minloc0.m4 m4/minloc1.m4 m4/minval.m4 m4/product.m4 m4/sum.m4 \
-    m4/matmul.m4 m4/matmull.m4 \
+    m4/any.m4 m4/count.m4 m4/maxloc0.m4 m4/maxloc1.m4 m4/maxval_i.m4 \
+    m4/maxval_r.m4 m4/minloc0.m4 m4/minloc1.m4 m4/minval_i.m4 m4/minval_r.m4 \
+    m4/product.m4 m4/sum.m4 m4/matmul.m4 m4/matmull.m4 \
     m4/ctrig.m4 m4/cexp.m4 m4/chyp.m4 m4/mtype.m4 \
     m4/specific.m4 m4/specific2.m4 m4/head.m4 m4/shape.m4 m4/reshape.m4 \
     m4/transpose.m4 m4/eoshift1.m4 m4/eoshift3.m4 m4/exponent
@@ -429,8 +433,8 @@
     m4/misc_specifics.m4 m4/rrspacing.m4 m4/spacing.m4

 gfor_built_src= $(i_all_c) $(i_any_c) $(i_count_c) $(i_maxloc0_c) \
-    $(i_maxloc1_c) $(i_maxval_c) $(i_minloc0_c) $(i_minloc1_c) $(i_minval_c) \
-    $(i_product_c) $(i_sum_c) \
+    $(i_maxloc1_c) $(i_maxval_i_c) $(i_maxval_r_c) $(i_minloc0_c) \
+    $(i_minloc1_c) $(i_minval_i_c) $(i_minval_r_c) $(i_product_c) $(i_sum_c) \
     $(i_matmul_c) $(i_matmull_c) $(i_transpose_c) $(i_shape_c) $(i_eoshift1_c) 
\
     $(i_eoshift3_c) $(i_cshift1_c) $(i_reshape_c) $(in_pack_c) $(in_unpack_c)
\
     $(i_exponent_c) $(i_fraction_c) $(i_nearest_c) $(i_set_exponent_c) \
@@ -647,18 +651,24 @@
 $(i_maxloc1_c): m4/maxloc1.m4 $(I_M4_DEPS1)
        $(M4) -Dfile=$@ -I$(srcdir)/m4 maxloc1.m4 > $(srcdir)/$@

-$(i_maxval_c): m4/maxval.m4 $(I_M4_DEPS1)
-       $(M4) -Dfile=$@ -I$(srcdir)/m4 maxval.m4 > $(srcdir)/$@
+$(i_maxval_i_c): m4/maxval_i.m4 $(I_M4_DEPS1)
+       $(M4) -Dfile=$@ -I$(srcdir)/m4 maxval_i.m4 > $(srcdir)/$@

+$(i_maxval_r_c): m4/maxval_r.m4 $(I_M4_DEPS1)
+       $(M4) -Dfile=$@ -I$(srcdir)/m4 maxval_r.m4 > $(srcdir)/$@
+
 $(i_minloc0_c): m4/minloc0.m4 $(I_M4_DEPS0)
        $(M4) -Dfile=$@ -I$(srcdir)/m4 minloc0.m4 > $(srcdir)/$@

 $(i_minloc1_c): m4/minloc1.m4 $(I_M4_DEPS1)
        $(M4) -Dfile=$@ -I$(srcdir)/m4 minloc1.m4 > $(srcdir)/$@

-$(i_minval_c): m4/minval.m4 $(I_M4_DEPS1)
-       $(M4) -Dfile=$@ -I$(srcdir)/m4 minval.m4 > $(srcdir)/$@
+$(i_minval_i_c): m4/minval_i.m4 $(I_M4_DEPS1)
+       $(M4) -Dfile=$@ -I$(srcdir)/m4 minval_i.m4 > $(srcdir)/$@

+$(i_minval_r_c): m4/minval_r.m4 $(I_M4_DEPS1)
+       $(M4) -Dfile=$@ -I$(srcdir)/m4 minval_r.m4 > $(srcdir)/$@
+
 $(i_product_c): m4/product.m4 $(I_M4_DEPS1)
        $(M4) -Dfile=$@ -I$(srcdir)/m4 product.m4 > $(srcdir)/$@


I don't know what the status is of the other patch for MAXVAL/MINVAL, but we
should probably combine them into a single patch (in particular to ease the
backporting).


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |libfortran
   Last reconfirmed|2007-02-05 19:40:47         |2007-02-06 12:12:21
               date|                            |
   Target Milestone|---                         |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2007-02-06 12:30 -------
> I don't know what the status is of the other patch for MAXVAL/MINVAL, but we
> should probably combine them into a single patch (in particular to ease the
> backporting).
The status of the other patch is: Waiting for review.
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00260.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #8 from tkoenig at gcc dot gnu dot org  2007-02-07 17:54 -------

> The status of the other patch is: Waiting for review.
> http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00260.html

I can't do any regression-testing right now, because PR 30678 :-(


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-02-14 20:21 -------
We should fix {MIN,MAX}{VAL,LOC} for NaNs, as well as infinities. See
http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/e3745c39a11522c5
for details


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

------- Comment #10 from fxcoudert at gcc dot gnu dot org  2007-03-25 11:49 -------
$ cat nan.f90             
  real :: nan, x
  x = 7.2
  nan = 0.0
  nan = nan / nan

  print *, minval((/ nan, x /)), maxval((/ nan, x /))
  print *, minval((/ nan /)), maxval((/ nan /))

  print *, minloc((/ nan, x /)), maxloc((/ nan, x /))
  print *, minloc((/ nan /)), maxloc((/ nan /))
  end
$ gfortran nan.f90 && ./a.out
   7.200000       7.200000    
  3.4028235E+38 -3.4028235E+38
           1           1
           1           1

While the results for {MIN,MAX}VAL, while not perfect, are not so bad (it's a
possible interpretation of the standard), the results for {MIN,MAX}LOC are very
annoying: it means that ARRAY(MAXLOC(ARRAY)) /= MAXVAL(ARRAY) !


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #11 from tkoenig at gcc dot gnu dot org  2007-03-25 22:04 -------
I'll give this a shot.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-02-06 12:12:21         |2007-03-25 21:04:45
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #12 from tkoenig at gcc dot gnu dot org  2007-04-10 20:58 -------
Created an attachment (id=13350)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13350&action=view)
Sample implementation

This is how I would the implementation of minloc to behave,
shown as a sample implementation in Fortran for a 1d-array.

Now all that's left is to translate that into C and tree representations :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #13 from tkoenig at gcc dot gnu dot org  2007-04-15 22:12 -------
(In reply to comment #12)

> Now all that's left is to translate that into C and tree representations :-)

The tree stuff is hard, btw.  Still trying :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

------- Comment #14 from fxcoudert at gcc dot gnu dot org  2007-04-18 22:59 -------
(In reply to comment #13)
> The tree stuff is hard, btw.  Still trying :-)

Tree stuff? Do we generate inline code?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #15 from tkoenig at gcc dot gnu dot org  2007-04-19 21:03 -------
(In reply to comment #14)
> (In reply to comment #13)
> > The tree stuff is hard, btw.  Still trying :-)
> 
> Tree stuff? Do we generate inline code?

We generate inline code for rank 0 minval and minloc, i.e.

  real :: a(3)
  print *,minloc(a,dim=1)

Here's a partial patch for this case:

Index: gfortran.h
===================================================================
--- gfortran.h  (revision 123958)
+++ gfortran.h  (working copy)
@@ -1351,7 +1351,7 @@ extern gfc_logical_info gfc_logical_kind

 typedef struct
 {
-  mpfr_t epsilon, huge, tiny, subnormal;
+  mpfr_t epsilon, huge, tiny, subnormal, infinity;
   int kind, radix, digits, min_exponent, max_exponent;
   int range, precision;

Index: arith.c
===================================================================
--- arith.c     (revision 123958)
+++ arith.c     (working copy)
@@ -247,6 +247,10 @@ gfc_arith_init_1 (void)
        if (i == real_info->radix)
          real_info->precision++;

+      /* Infinity.  */
+      mpfr_init (real_info->infinity);
+      mpfr_set_inf (real_info->infinity, 1);
+
       mpfr_clear (a);
       mpfr_clear (b);
       mpfr_clear (c);
@@ -277,6 +281,7 @@ gfc_arith_done_1 (void)
       mpfr_clear (rp->huge);
       mpfr_clear (rp->tiny);
       mpfr_clear (rp->subnormal);
+      mpfr_clear (rp->infinity);
     }
 }

Index: trans-intrinsic.c
===================================================================
--- trans-intrinsic.c   (revision 123958)
+++ trans-intrinsic.c   (working copy)
@@ -1926,8 +1926,10 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
   tree limit;
   tree type;
   tree tmp;
+  tree tmp2;
   tree elsetmp;
   tree ifbody;
+  tree execute_loop;
   gfc_loopinfo loop;
   gfc_actual_arglist *actual;
   gfc_ss *arrayss;
@@ -1967,11 +1969,14 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
     maskss = NULL;

   limit = gfc_create_var (gfc_typenode_for_spec (&arrayexpr->ts), "limit");
+  execute_loop = gfc_create_var (boolean_type_node, "execute_loop");
+
   n = gfc_validate_kind (arrayexpr->ts.type, arrayexpr->ts.kind, false);
   switch (arrayexpr->ts.type)
     {
     case BT_REAL:
-      tmp = gfc_conv_mpfr_to_tree (gfc_real_kinds[n].huge,
arrayexpr->ts.kind);+      tmp = gfc_conv_mpfr_to_tree
(gfc_real_kinds[n].infinity,
+                                  arrayexpr->ts.kind);
       break;

     case BT_INTEGER:
@@ -2007,14 +2012,18 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s

   gcc_assert (loop.dimen == 1);

-  /* Initialize the position to zero, following Fortran 2003.  We are free
-     to do this because Fortran 95 allows the result of an entirely false
-     mask to be processor dependent.  */
-  gfc_add_modify_expr (&loop.pre, pos, gfc_index_zero_node);
+  /* Initialize the position to one.  */
+  gfc_add_modify_expr (&loop.pre, pos, gfc_index_one_node);

   gfc_mark_ss_chain_used (arrayss, 1);
   if (maskss)
     gfc_mark_ss_chain_used (maskss, 1);
+
+  /* Check whether the loop is evaluated at all.  */
+
+  tmp2 = fold_build2 (GE_EXPR, boolean_type_node, loop.to[0], loop.from[0]);
+  gfc_add_modify_expr (&se->pre, execute_loop, tmp2);
+
   /* Generate the loop body.  */
   gfc_start_scalarized_body (&loop, &body);

@@ -2050,10 +2059,9 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s

   ifbody = gfc_finish_block (&ifblock);

-  /* If it is a more extreme value or pos is still zero.  */
-  tmp = build2 (TRUTH_OR_EXPR, boolean_type_node,
-                 build2 (op, boolean_type_node, arrayse.expr, limit),
-                 build2 (EQ_EXPR, boolean_type_node, pos,
gfc_index_zero_node));
+  /* If it is a more extreme value.  */
+  tmp =  build2 (op, boolean_type_node, arrayse.expr, limit);
+
   tmp = build3_v (COND_EXPR, tmp, ifbody, build_empty_stmt ());
   gfc_add_expr_to_block (&block, tmp);

@@ -2066,36 +2074,41 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
     }
   else
     tmp = gfc_finish_block (&block);
+
   gfc_add_expr_to_block (&body, tmp);

   gfc_trans_scalarizing_loops (&loop, &body);

-  /* For a scalar mask, enclose the loop in an if statement.  */
+  /* Enclose the loop in an if statement.  We don't execute it if the
+     trip count would be zero, or if a scalar mask is false.  */
+
   if (maskexpr && maskss == NULL)
     {
       gfc_init_se (&maskse, NULL);
       gfc_conv_expr_val (&maskse, maskexpr);
-      gfc_init_block (&block);
-      gfc_add_block_to_block (&block, &loop.pre);
-      gfc_add_block_to_block (&block, &loop.post);
-      tmp = gfc_finish_block (&block);

-      /* For the else part of the scalar mask, just initialize
-        the pos variable the same way as above.  */
+      execute_loop = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
execute_loop,
+                                 maskse.expr);
+    }
+
+  gfc_init_block (&block);
+  gfc_add_block_to_block (&block, &loop.pre);
+  gfc_add_block_to_block (&block, &loop.post);

-      gfc_init_block (&elseblock);
-      gfc_add_modify_expr (&elseblock, pos, gfc_index_zero_node);
-      elsetmp = gfc_finish_block (&elseblock);
+  tmp = gfc_finish_block (&block);
+
+  /* For the else part of the scalar mask, just initialize
+     the pos variable the same way as above.  */
+
+  gfc_init_block (&elseblock);
+  gfc_add_modify_expr (&elseblock, pos, gfc_index_zero_node);
+  elsetmp = gfc_finish_block (&elseblock);
+
+  tmp = build3_v (COND_EXPR, execute_loop, tmp, elsetmp);
+  gfc_add_expr_to_block (&block, tmp);
+
+  gfc_add_block_to_block (&se->pre, &block);

-      tmp = build3_v (COND_EXPR, maskse.expr, tmp, elsetmp);
-      gfc_add_expr_to_block (&block, tmp);
-      gfc_add_block_to_block (&se->pre, &block);
-    }
-  else
-    {
-      gfc_add_block_to_block (&se->pre, &loop.pre);
-      gfc_add_block_to_block (&se->pre, &loop.post);
-    }
   gfc_cleanup_loop (&loop);

   /* Return a value in the range 1..SIZE(array).  */

The problem with this is that it doesn't handle the loop

    do n=1, size(a)
       if (mask(n)) then
          real_minloc_mask(1) = n
          exit
       end if
    end do

at all, and my attempts to generate it using the scalarizer
have ended in ICEs (so far).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[mmitchel at gcc dot gnu dot org]

------- Comment #16 from mmitchel at gcc dot gnu dot org  2007-05-14 22:26 -------
Will not be fixed in 4.2.0; retargeting at 4.2.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.0                       |4.2.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #17 from tkoenig at gcc dot gnu dot org  2007-05-17 14:40 -------
Created an attachment (id=13569)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13569&action=view)
partial implementation

Here's a partial implementation that seems to get
things right for the (min)|(max)loc0 generated files.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|tkoenig at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #18 from tkoenig at gcc dot gnu dot org  2007-06-15 18:55 -------
Due to huge time constraints, I won't be able to
do anything with this for the next few weeks. Unassigning
myself for the time.

If anybody wants to look over my partial patch and fly with it,
he's welcome :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[pault at gcc dot gnu dot org]

------- Comment #19 from pault at gcc dot gnu dot org  2007-06-21 18:12 -------
(In reply to comment #18)
> Due to huge time constraints, I won't be able to
> do anything with this for the next few weeks. Unassigning
> myself for the time.
> If anybody wants to look over my partial patch and fly with it,
> he's welcome :-)

My patch to 31726 fixes the inline stuff, or it does not break it, at least.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.1                       |4.2.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-03-25 21:04:45         |2007-08-08 15:08:16
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[mmitchel at gcc dot gnu dot org]

------- Comment #20 from mmitchel at gcc dot gnu dot org  2007-10-09 19:22 -------
Change target milestone to 4.2.3, as 4.2.2 has been released.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.2                       |4.2.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

------- Comment #21 from fxcoudert at gcc dot gnu dot org  2007-10-17 22:32 -------
I've been thinking about MINVAL((/NaN,NaN/)), ie minval of an array containing
only NaNs, over and over again, and it's a tough choice. Here's what compilers
currently output for MINVAL and MAXVAL:

Intel: Inf, -Inf
Sun: -NaN, -NaN (yes, that's a negative NaN; don't ask)
g95: Huge, -Huge
gfortran: Huge, -Huge
portland: NaN, -Huge
MIPSpro: Inf, NaN
IBM: Huge, -Huge

So: we can take portland and MIPSpro out, they lack consistency; Intel goes for
infinities, and I don't see how they can justify this in any way, so let's take
them out also. The only two options worth considering are NaN (as Sun does) and
Huge (as Intel and g95 do). Both have pros and cons. The main pro for NaN is
that it ensures that MAXVAL((/x,x/)) is always equal to MAX(x,x), even when x
is a NaN. The main pro for Huge is that it is more consistent with the way NaN
are ignored: for all other purposes, NaNs in the array are handled as if the
mask for that element was .false., so why single out the "only NaNs" case?

Since different compilers already give different answers for this problem, I
guess we can pick the solution we're most comfortable with. Unless people feel
strongly against it, I'd like to go with Huge, because 1. I'm more convinced by
arguments in favour of it, and 2. it's probably easier/faster/more efficient to
implement, because it doesn't need yet another special case.

Opinions welcome. (What a long rant.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[jvdelisle at gcc dot gnu dot org]

------- Comment #22 from jvdelisle at gcc dot gnu dot org  2007-10-17 23:49 -------
Well this is just one little opinion:

There is no way that it is realistic to get a valid number out of a NaN
or a group of NaNs.  It can only be NaN.  It's like a place from which there is
no return.  Maybe we should define a new type called "Useless" so that people
understand what a NaN is. :)

Returning anything else would mask that the array was all NaNs and give a false
sense that all is OK, when its not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[kargl at gcc dot gnu dot org]

------- Comment #23 from kargl at gcc dot gnu dot org  2007-10-17 23:57 -------
(In reply to comment #22)
> Well this is just one little opinion:
> 
> There is no way that it is realistic to get a valid number out of a NaN
> or a group of NaNs.  It can only be NaN.

Read the hypot man page.

     hypot(infinity, v) = hypot(v, infinity) = +infinity for all v, including
     NaN.

So one can get a non-NaN when an NaN is involved in a computation.

For the task at hand, I think gfortran should be compatible with either
g95 or Intel, and because g95 and gfortran already agree the decision is
moot.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[jvdelisle at gcc dot gnu dot org]

------- Comment #24 from jvdelisle at gcc dot gnu dot org  2007-10-18 00:18 -------
Ok for hypot, and that may make sense knowing the nature of the function. 
Minval is not a complex or transcendental function.  I should not write in
loose general terms.

So maybe approach the question differently.  Which element in an array of NaNs
is the smallest one and what is its value?  If I pick any one element, its
"value" is NaN.  It does not matter which one I select, its "value" always
comes out NaN.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

------- Comment #25 from fxcoudert at gcc dot gnu dot org  2007-10-18 07:38 -------
(In reply to comment #24)
> So maybe approach the question differently.  Which element in an array of NaNs
> is the smallest one and what is its value?  If I pick any one element, its
> "value" is NaN.  It does not matter which one I select, its "value" always
> comes out NaN.

I understand your argument, but there are other arguments that are, I think, at
least equally valid and convincing. As I said, MINVAL basically ignores NaNs,
so an array containing only NaNs is equivalent to an empty array: its MINVAL is
+Huge. Note that having MINVAL = +Huge is, in itself, a telltale sign that
something is wrong, if there is no mask present.

Now, I have another question: what happens for mixed NaNs? For example, in your
scheme, what would be the value of MAXVAL((/sNaN, qNaN/))?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

------- Comment #26 from burnus at gcc dot gnu dot org  2007-10-18 18:22 -------
If I understand it correctly, there is a difference between
IEEE 754-1989 and the current draft of IEEE 754 (duped IEEE 754r), see also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/33055faef528c075

IEEE 754r says that all operations with NaN yield NaN except of min and max
which give only NaN if all (i.e. both) arguments are NaN.

IEEE 754-1989 had no min/max functions and thus always NaN have to be produced
for maxval( huge(x), NAN ).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[jsm28 at gcc dot gnu dot org]

------- Comment #27 from jsm28 at gcc dot gnu dot org  2008-02-01 16:53 -------
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.3                       |4.2.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.4                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

------- Comment #28 from burnus at gcc dot gnu dot org  2009-07-15 09:41 -------
(In reply to comment #24)
> So maybe approach the question differently.  Which element in an array of NaNs
> is the smallest one and what is its value?  If I pick any one element, its
> "value" is NaN.  It does not matter which one I select, its "value" always
> comes out NaN.

Well, according to IEEE 754:2008 the result is the "canonicalized" NaN, which
is implementation defined. NaNs have a sign and may have different bit patterns
("payload") but I think we can ignore those. To be conforming, the NaN should
match one of the NaNs in the list. (I think the latter will automatically be
the case, but even if not, I think essentially no one will care.)

(In reply to comment #25)
> Now, I have another question: what happens for mixed NaNs? For example, in 
> your scheme, what would be the value of MAXVAL((/sNaN, qNaN/))?

If FP trapping is enabled => SIGFPE, if not, treat it like a quiet NaN. Whether
MAXVAL([x,y]) returns X or Y is implementation defined and thus the result can
be an (untrapped) sNan or qNaN.

For completeness, IEEE 754:2008 defines (in 5.3.1):

"maxNum(x, y) is the canonicalized number y if x < y, x if y < x, the
canonicalized number if one operand is a number and the other a quiet NaN.
Otherwise it is either x or y, canonicalized (this means results might differ
among implementations). When either x or y is a signaling NaN, then the result
is according to 6.2."

(Note regarding "floating-point number": That includes +/-INF but not NaN.)

and (in 6.2.3)

"If two or more inputs are NaN, then the payload of the resulting NaN should be
identical to the payload of one of the input NaNs if representable in the
destination format. This standard does not specify which of the input NaNs will
provide the payload."

 * * *

See also PR 40643.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

------- Comment #29 from burnus at gcc dot gnu dot org  2009-07-24 08:21 -------
Probably fixed by the commit of PR 40643 comment 7

Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150041
Log:
        PR fortran/40643
        PR fortran/31067


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug libfortran/30694] minval/maxval with +/-Inf

[tkoenig at gcc dot gnu dot org]

------- Comment #30 from tkoenig at gcc dot gnu dot org  2009-12-05 21:53 -------
(In reply to comment #29)
> Probably fixed by the commit of PR 40643 comment 7
> 
> Author: jakub
> Date: Fri Jul 24 07:57:13 2009
> New Revision: 150041
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150041
> Log:
>         PR fortran/40643
>         PR fortran/31067
> 

Yes, this is fixed.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694