* [Bug fortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
@ 2007-02-03 16:41 ` burnus at gcc dot gnu dot org
2007-02-03 19:28 ` tkoenig at gcc dot gnu dot org
` (33 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-03 16:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug fortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
2007-02-03 16:41 ` [Bug fortran/30694] " burnus at gcc dot gnu dot org
@ 2007-02-03 19:28 ` tkoenig at gcc dot gnu dot org
2007-02-03 20:28 ` pinskia at gcc dot gnu dot org
` (32 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-02-03 19:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug fortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
2007-02-03 16:41 ` [Bug fortran/30694] " burnus at gcc dot gnu dot org
2007-02-03 19:28 ` tkoenig at gcc dot gnu dot org
@ 2007-02-03 20:28 ` pinskia at gcc dot gnu dot org
2007-02-04 0:19 ` burnus at gcc dot gnu dot org
` (31 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-02-03 20:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug fortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (2 preceding siblings ...)
2007-02-03 20:28 ` pinskia at gcc dot gnu dot org
@ 2007-02-04 0:19 ` burnus at gcc dot gnu dot org
2007-02-05 19:41 ` burnus at gcc dot gnu dot org
` (30 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-04 0:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug fortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (3 preceding siblings ...)
2007-02-04 0:19 ` burnus at gcc dot gnu dot org
@ 2007-02-05 19:41 ` burnus at gcc dot gnu dot org
2007-02-06 12:12 ` [Bug libfortran/30694] " fxcoudert at gcc dot gnu dot org
` (29 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-05 19:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (4 preceding siblings ...)
2007-02-05 19:41 ` burnus at gcc dot gnu dot org
@ 2007-02-06 12:12 ` fxcoudert at gcc dot gnu dot org
2007-02-06 12:30 ` burnus at gcc dot gnu dot org
` (28 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-02-06 12:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (5 preceding siblings ...)
2007-02-06 12:12 ` [Bug libfortran/30694] " fxcoudert at gcc dot gnu dot org
@ 2007-02-06 12:30 ` burnus at gcc dot gnu dot org
2007-02-07 17:55 ` tkoenig at gcc dot gnu dot org
` (27 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-06 12:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (6 preceding siblings ...)
2007-02-06 12:30 ` burnus at gcc dot gnu dot org
@ 2007-02-07 17:55 ` tkoenig at gcc dot gnu dot org
2007-02-14 20:21 ` fxcoudert at gcc dot gnu dot org
` (26 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-02-07 17:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (7 preceding siblings ...)
2007-02-07 17:55 ` tkoenig at gcc dot gnu dot org
@ 2007-02-14 20:21 ` fxcoudert at gcc dot gnu dot org
2007-03-25 9:49 ` fxcoudert at gcc dot gnu dot org
` (25 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-02-14 20:21 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (8 preceding siblings ...)
2007-02-14 20:21 ` fxcoudert at gcc dot gnu dot org
@ 2007-03-25 9:49 ` fxcoudert at gcc dot gnu dot org
2007-03-25 20:05 ` tkoenig at gcc dot gnu dot org
` (24 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-03-25 9:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (9 preceding siblings ...)
2007-03-25 9:49 ` fxcoudert at gcc dot gnu dot org
@ 2007-03-25 20:05 ` tkoenig at gcc dot gnu dot org
2007-04-10 19:58 ` tkoenig at gcc dot gnu dot org
` (23 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-03-25 20:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (10 preceding siblings ...)
2007-03-25 20:05 ` tkoenig at gcc dot gnu dot org
@ 2007-04-10 19:58 ` tkoenig at gcc dot gnu dot org
2007-04-15 21:12 ` tkoenig at gcc dot gnu dot org
` (22 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-04-10 19:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (11 preceding siblings ...)
2007-04-10 19:58 ` tkoenig at gcc dot gnu dot org
@ 2007-04-15 21:12 ` tkoenig at gcc dot gnu dot org
2007-04-18 21:59 ` fxcoudert at gcc dot gnu dot org
` (21 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-04-15 21:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (12 preceding siblings ...)
2007-04-15 21:12 ` tkoenig at gcc dot gnu dot org
@ 2007-04-18 21:59 ` fxcoudert at gcc dot gnu dot org
2007-04-19 20:03 ` tkoenig at gcc dot gnu dot org
` (20 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-04-18 21:59 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (13 preceding siblings ...)
2007-04-18 21:59 ` fxcoudert at gcc dot gnu dot org
@ 2007-04-19 20:03 ` tkoenig at gcc dot gnu dot org
2007-05-14 21:37 ` mmitchel at gcc dot gnu dot org
` (19 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-04-19 20:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (14 preceding siblings ...)
2007-04-19 20:03 ` tkoenig at gcc dot gnu dot org
@ 2007-05-14 21:37 ` mmitchel at gcc dot gnu dot org
2007-05-17 13:40 ` tkoenig at gcc dot gnu dot org
` (18 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2007-05-14 21:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (15 preceding siblings ...)
2007-05-14 21:37 ` mmitchel at gcc dot gnu dot org
@ 2007-05-17 13:40 ` tkoenig at gcc dot gnu dot org
2007-06-15 18:56 ` tkoenig at gcc dot gnu dot org
` (17 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-05-17 13:40 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (16 preceding siblings ...)
2007-05-17 13:40 ` tkoenig at gcc dot gnu dot org
@ 2007-06-15 18:56 ` tkoenig at gcc dot gnu dot org
2007-06-15 18:56 ` tkoenig at gcc dot gnu dot org
` (16 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-06-15 18:56 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (17 preceding siblings ...)
2007-06-15 18:56 ` tkoenig at gcc dot gnu dot org
@ 2007-06-15 18:56 ` tkoenig at gcc dot gnu dot org
2007-06-21 18:12 ` pault at gcc dot gnu dot org
` (15 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2007-06-15 18:56 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (18 preceding siblings ...)
2007-06-15 18:56 ` tkoenig at gcc dot gnu dot org
@ 2007-06-21 18:12 ` pault at gcc dot gnu dot org
2007-07-20 3:49 ` mmitchel at gcc dot gnu dot org
` (14 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: pault at gcc dot gnu dot org @ 2007-06-21 18:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (19 preceding siblings ...)
2007-06-21 18:12 ` pault at gcc dot gnu dot org
@ 2007-07-20 3:49 ` mmitchel at gcc dot gnu dot org
2007-08-08 15:08 ` fxcoudert at gcc dot gnu dot org
` (13 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2007-07-20 3:49 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (20 preceding siblings ...)
2007-07-20 3:49 ` mmitchel at gcc dot gnu dot org
@ 2007-08-08 15:08 ` fxcoudert at gcc dot gnu dot org
2007-10-09 19:28 ` mmitchel at gcc dot gnu dot org
` (12 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-08-08 15:08 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (21 preceding siblings ...)
2007-08-08 15:08 ` fxcoudert at gcc dot gnu dot org
@ 2007-10-09 19:28 ` mmitchel at gcc dot gnu dot org
2007-10-17 22:32 ` fxcoudert at gcc dot gnu dot org
` (11 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2007-10-09 19:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (22 preceding siblings ...)
2007-10-09 19:28 ` mmitchel at gcc dot gnu dot org
@ 2007-10-17 22:32 ` fxcoudert at gcc dot gnu dot org
2007-10-17 23:49 ` jvdelisle at gcc dot gnu dot org
` (10 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-10-17 22:32 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (23 preceding siblings ...)
2007-10-17 22:32 ` fxcoudert at gcc dot gnu dot org
@ 2007-10-17 23:49 ` jvdelisle at gcc dot gnu dot org
2007-10-17 23:58 ` kargl at gcc dot gnu dot org
` (9 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-10-17 23:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (24 preceding siblings ...)
2007-10-17 23:49 ` jvdelisle at gcc dot gnu dot org
@ 2007-10-17 23:58 ` kargl at gcc dot gnu dot org
2007-10-18 0:18 ` jvdelisle at gcc dot gnu dot org
` (8 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-10-17 23:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (25 preceding siblings ...)
2007-10-17 23:58 ` kargl at gcc dot gnu dot org
@ 2007-10-18 0:18 ` jvdelisle at gcc dot gnu dot org
2007-10-18 7:38 ` fxcoudert at gcc dot gnu dot org
` (7 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-10-18 0:18 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (26 preceding siblings ...)
2007-10-18 0:18 ` jvdelisle at gcc dot gnu dot org
@ 2007-10-18 7:38 ` fxcoudert at gcc dot gnu dot org
2007-10-18 18:23 ` burnus at gcc dot gnu dot org
` (6 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-10-18 7:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (27 preceding siblings ...)
2007-10-18 7:38 ` fxcoudert at gcc dot gnu dot org
@ 2007-10-18 18:23 ` burnus at gcc dot gnu dot org
2007-12-08 18:07 ` fxcoudert at gcc dot gnu dot org
` (5 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-10-18 18:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (28 preceding siblings ...)
2007-10-18 18:23 ` burnus at gcc dot gnu dot org
@ 2007-12-08 18:07 ` fxcoudert at gcc dot gnu dot org
2008-02-01 16:59 ` jsm28 at gcc dot gnu dot org
` (4 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2007-12-08 18:07 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (29 preceding siblings ...)
2007-12-08 18:07 ` fxcoudert at gcc dot gnu dot org
@ 2008-02-01 16:59 ` jsm28 at gcc dot gnu dot org
2008-02-01 17:23 ` fxcoudert at gcc dot gnu dot org
` (3 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2008-02-01 16:59 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (30 preceding siblings ...)
2008-02-01 16:59 ` jsm28 at gcc dot gnu dot org
@ 2008-02-01 17:23 ` fxcoudert at gcc dot gnu dot org
2009-07-15 9:41 ` burnus at gcc dot gnu dot org
` (2 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2008-02-01 17:23 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (31 preceding siblings ...)
2008-02-01 17:23 ` fxcoudert at gcc dot gnu dot org
@ 2009-07-15 9:41 ` burnus at gcc dot gnu dot org
2009-07-24 8:21 ` burnus at gcc dot gnu dot org
2009-12-05 21:53 ` tkoenig at gcc dot gnu dot org
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-07-15 9:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (32 preceding siblings ...)
2009-07-15 9:41 ` burnus at gcc dot gnu dot org
@ 2009-07-24 8:21 ` burnus at gcc dot gnu dot org
2009-12-05 21:53 ` tkoenig at gcc dot gnu dot org
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-07-24 8:21 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libfortran/30694] minval/maxval with +/-Inf
2007-02-03 16:17 [Bug fortran/30694] New: minval/maxval with +/-Inf tkoenig at gcc dot gnu dot org
` (33 preceding siblings ...)
2009-07-24 8:21 ` burnus at gcc dot gnu dot org
@ 2009-12-05 21:53 ` tkoenig at gcc dot gnu dot org
34 siblings, 0 replies; 36+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-12-05 21:53 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 36+ messages in thread