public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/64137] New: Fortran FE builds invalid GENERIC
@ 2014-12-01 13:32 rguenth at gcc dot gnu.org
2014-12-01 13:45 ` [Bug fortran/64137] " rguenth at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-12-01 13:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64137
Bug ID: 64137
Summary: Fortran FE builds invalid GENERIC
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
#6 0x000000000085f420 in gfc_conv_intrinsic_minmaxloc (se=0x7fffffffd150,
expr=0x235ba70, op=GT_EXPR)
at /space/rguenther/tramp3d/trunk/gcc/fortran/trans-intrinsic.c:3734
(gdb) l
3729 possible value is HUGE in both cases. */
3730 if (op == GT_EXPR)
3731 tmp = fold_build1_loc (input_location, NEGATE_EXPR, TREE_TYPE
(tmp), tmp);
3732 if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
3733 tmp = fold_build2_loc (input_location, MINUS_EXPR, TREE_TYPE (tmp),
tmp,
3734 build_int_cst (type, 1));
the body of the 2nd if builds REAL_CST - INTEGER_CST for at least
gfortran.dg/maxloc_2.f90 at -O1+. Currently it is lucky that fold-const.c
10523 /* A - B -> A + (-B) if B is easily negatable. */
10524 if (negate_expr_p (arg1)
10525 && !TYPE_OVERFLOW_SANITIZED (type)
(gdb) l
10526 && ((FLOAT_TYPE_P (type)
10527 /* Avoid this transformation if B is a positive
REAL_CST. */
10528 && (TREE_CODE (arg1) != REAL_CST
10529 || REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1))))
10530 || INTEGRAL_TYPE_P (type)))
10531 return fold_build2_loc (loc, PLUS_EXPR, type,
10532 fold_convert_loc (loc, type, arg0),
10533 fold_convert_loc (loc, type,
10534 negate_expr (arg1)));
applies as that fold_convert()s to REAL after negating the integer, hiding
this bug. When I move that to match.pd patterns that no longer happens,
but we simply get -Huge + -1 with bogus types here.
Not sure what is intended here (integer Huge or Float 1).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/64137] Fortran FE builds invalid GENERIC
2014-12-01 13:32 [Bug fortran/64137] New: Fortran FE builds invalid GENERIC rguenth at gcc dot gnu.org
@ 2014-12-01 13:45 ` rguenth at gcc dot gnu.org
2014-12-01 18:22 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-12-01 13:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64137
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2014-12-01
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Index: gcc/fortran/trans-intrinsic.c
===================================================================
--- gcc/fortran/trans-intrinsic.c (revision 218211)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -3729,7 +3729,7 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
possible value is HUGE in both cases. */
if (op == GT_EXPR)
tmp = fold_build1_loc (input_location, NEGATE_EXPR, TREE_TYPE (tmp), tmp);
- if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
+ if (op == GT_EXPR && arrayexpr->ts.type == BT_INTEGER)
tmp = fold_build2_loc (input_location, MINUS_EXPR, TREE_TYPE (tmp), tmp,
build_int_cst (type, 1));
works for me. So I suppose this is a wrong-code bug as we shouldn't have
subtracted 1 off -Huge (what's that anyway?) But then is "integer -Huge"
C INT_MIN + 1?
Anyway, testing the above.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/64137] Fortran FE builds invalid GENERIC
2014-12-01 13:32 [Bug fortran/64137] New: Fortran FE builds invalid GENERIC rguenth at gcc dot gnu.org
2014-12-01 13:45 ` [Bug fortran/64137] " rguenth at gcc dot gnu.org
@ 2014-12-01 18:22 ` burnus at gcc dot gnu.org
2014-12-02 8:51 ` rguenth at gcc dot gnu.org
2014-12-02 8:52 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-12-01 18:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64137
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> - if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
> + if (op == GT_EXPR && arrayexpr->ts.type == BT_INTEGER)
> works for me.
Looks good to me. Thanks for the patch and debugging!
[Seems to be a copy'n'paste error from gfc_conv_intrinsic_minmaxval, which
returns the value (= int or float) such that expr->ts.type works; the code in
gfc_conv_intrinsic_minmaxloc return a location which is always an int.]
> So I suppose this is a wrong-code bug as we shouldn't have
> subtracted 1 off -Huge (what's that anyway?) But then is "integer -Huge"
> C INT_MIN + 1?
HUGE(variable) is a function which returns the largest possible value for that
variable, i.e. MAX_INT for a default-kind integer or FLT_MAX for a default-kind
real variable.
For MAXLOC, one starts with "val = <smallest possible value>", which is MIN_INT
== -MAX_INT - 1 == -HUGE() - 1 for int or FLT_MIN == -HUGE() for real with
-ffinite-math or otherwise -INF for reals.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/64137] Fortran FE builds invalid GENERIC
2014-12-01 13:32 [Bug fortran/64137] New: Fortran FE builds invalid GENERIC rguenth at gcc dot gnu.org
2014-12-01 13:45 ` [Bug fortran/64137] " rguenth at gcc dot gnu.org
2014-12-01 18:22 ` burnus at gcc dot gnu.org
@ 2014-12-02 8:51 ` rguenth at gcc dot gnu.org
2014-12-02 8:52 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-12-02 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64137
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Dec 2 08:50:57 2014
New Revision: 218259
URL: https://gcc.gnu.org/viewcvs?rev=218259&root=gcc&view=rev
Log:
2014-12-02 Richard Biener <rguenther@suse.de>
PR fortran/64137
* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Check
proper expressions type, use proper type for computing
-Huge - 1.
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/64137] Fortran FE builds invalid GENERIC
2014-12-01 13:32 [Bug fortran/64137] New: Fortran FE builds invalid GENERIC rguenth at gcc dot gnu.org
` (2 preceding siblings ...)
2014-12-02 8:51 ` rguenth at gcc dot gnu.org
@ 2014-12-02 8:52 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-12-02 8:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64137
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-12-02 8:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-01 13:32 [Bug fortran/64137] New: Fortran FE builds invalid GENERIC rguenth at gcc dot gnu.org
2014-12-01 13:45 ` [Bug fortran/64137] " rguenth at gcc dot gnu.org
2014-12-01 18:22 ` burnus at gcc dot gnu.org
2014-12-02 8:51 ` rguenth at gcc dot gnu.org
2014-12-02 8:52 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).