* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
@ 2021-06-18 13:04 ` rguenth at gcc dot gnu.org
2021-06-18 13:29 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-06-18 13:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.2
Known to work| |10.3.1
Priority|P3 |P4
Keywords| |ice-on-valid-code,
| |needs-bisection, wrong-code
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
2021-06-18 13:04 ` [Bug fortran/101123] " rguenth at gcc dot gnu.org
@ 2021-06-18 13:29 ` jakub at gcc dot gnu.org
2021-06-18 16:23 ` anlauf at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-06-18 13:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-06-18
CC| |anlauf at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords|needs-bisection |
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r11-2746-g3c04bd60e56da399a441f73ebb687b5039b9cf3f
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
2021-06-18 13:04 ` [Bug fortran/101123] " rguenth at gcc dot gnu.org
2021-06-18 13:29 ` jakub at gcc dot gnu.org
@ 2021-06-18 16:23 ` anlauf at gcc dot gnu.org
2021-06-18 16:28 ` dominiq at lps dot ens.fr
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-06-18 16:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
--- Comment #2 from anlauf at gcc dot gnu.org ---
Why on Earth would somebody really want to combine legacy MAX0 with
IMPLICIT INTEGER*4 and -fdefault-integer-8?
Reduced testcase:
SUBROUTINE TEST
IMPLICIT INTEGER*4 (I-N)
MAXMN=MAX0(M,N)
END
Dump tree:
__attribute__((fn spec (". ")))
void test ()
{
integer(kind=4) m;
integer(kind=4) maxmn;
integer(kind=4) n;
{
integer(kind=4) M.0;
M.0 = m;
M.0 = MAX_EXPR <n, M.0>;
maxmn = (integer(kind=4)) (integer(kind=8)) M.0;
}
}
Is the dump tree inaccurate? It matches my expectation.
Note: the code compiles with MAX0 replaced by (the generic) MAX.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
` (2 preceding siblings ...)
2021-06-18 16:23 ` anlauf at gcc dot gnu.org
@ 2021-06-18 16:28 ` dominiq at lps dot ens.fr
2021-06-18 16:40 ` anlauf at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-06-18 16:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I think this PR should be closed as invalid.
When using -fdefault_*, it is the user's responsibility to check that the
promotion is compatible with procedure arguments: MAX0 is expecting INTEGER(4)
and is given INTEGER(8).
The code compiles if MAX0 is replaced with the generic function MAX.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
` (3 preceding siblings ...)
2021-06-18 16:28 ` dominiq at lps dot ens.fr
@ 2021-06-18 16:40 ` anlauf at gcc dot gnu.org
2021-06-18 16:44 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-06-18 16:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
--- Comment #4 from anlauf at gcc dot gnu.org ---
Untested potential fix:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 73b0bcc9dea..e578449995a 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4147,10 +4147,7 @@ gfc_conv_intrinsic_minmax (gfc_se * se, gfc_expr * expr,
enum tree_code op)
build_empty_stmt (input_location));
gfc_add_expr_to_block (&se->pre, tmp);
}
- if (TREE_CODE (type) == INTEGER_TYPE)
- se->expr = fold_build1_loc (input_location, FIX_TRUNC_EXPR, type, mvar);
- else
- se->expr = convert (type, mvar);
+ se->expr = convert (type, mvar);
}
Not sure if there is some cornercase which will get mishandled.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
` (4 preceding siblings ...)
2021-06-18 16:40 ` anlauf at gcc dot gnu.org
@ 2021-06-18 16:44 ` jakub at gcc dot gnu.org
2021-06-18 17:25 ` anlauf at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-06-18 16:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is clearly a FE bug:
gfc_conv_intrinsic_minmax does:
if (TREE_CODE (type) == INTEGER_TYPE)
se->expr = fold_build1_loc (input_location, FIX_TRUNC_EXPR, type, mvar);
else
se->expr = convert (type, mvar);
and as type (in this kase integer(kind=8)) is INTEGER_TYPE, it creates a
FIX_TRUNC_EXPR. But that is only valid if mvar has floating point type, which
is not the case here.
Why don't you do se->expr = convert (type, mvar); unconditionally? That should
create FIX_TRUNC_EXPR for the FLOAT_TYPE -> INTEGER_TYPE conversion as well,
but will handle correctly even INTEGER_TYPE -> INTEGER_TYPE conversions etc.?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
` (5 preceding siblings ...)
2021-06-18 16:44 ` jakub at gcc dot gnu.org
@ 2021-06-18 17:25 ` anlauf at gcc dot gnu.org
2021-06-18 17:34 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-06-18 17:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Why don't you do se->expr = convert (type, mvar); unconditionally? That
> should
> create FIX_TRUNC_EXPR for the FLOAT_TYPE -> INTEGER_TYPE conversion as well,
> but will handle correctly even INTEGER_TYPE -> INTEGER_TYPE conversions etc.?
Will do. This also regtests cleanly.
Will prepare a testcase also for the related pr100283 which is fixed with
this change and commit shortly.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
` (6 preceding siblings ...)
2021-06-18 17:25 ` anlauf at gcc dot gnu.org
@ 2021-06-18 17:34 ` cvs-commit at gcc dot gnu.org
2021-06-19 18:16 ` cvs-commit at gcc dot gnu.org
2021-06-19 18:19 ` anlauf at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-18 17:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:
https://gcc.gnu.org/g:6fc543396345900f460c9fa7121239cb1ebbc3a3
commit r12-1650-g6fc543396345900f460c9fa7121239cb1ebbc3a3
Author: Harald Anlauf <anlauf@gmx.de>
Date: Fri Jun 18 19:34:15 2021 +0200
Fortran - fix conversion to result type for the min/max intrinsic
gcc/fortran/ChangeLog:
PR fortran/100283
PR fortran/101123
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Unconditionally
convert result of min/max to result type.
gcc/testsuite/ChangeLog:
PR fortran/100283
PR fortran/101123
* gfortran.dg/min0_max0_1.f90: New test.
* gfortran.dg/min0_max0_2.f90: New test.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
` (7 preceding siblings ...)
2021-06-18 17:34 ` cvs-commit at gcc dot gnu.org
@ 2021-06-19 18:16 ` cvs-commit at gcc dot gnu.org
2021-06-19 18:19 ` anlauf at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-19 18:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:
https://gcc.gnu.org/g:e5220a731229eaa7be42232c6e9a9dd881fed2b9
commit r11-8624-ge5220a731229eaa7be42232c6e9a9dd881fed2b9
Author: Harald Anlauf <anlauf@gmx.de>
Date: Fri Jun 18 19:34:15 2021 +0200
Fortran - fix conversion to result type for the min/max intrinsic
gcc/fortran/ChangeLog:
PR fortran/100283
PR fortran/101123
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Unconditionally
convert result of min/max to result type.
gcc/testsuite/ChangeLog:
PR fortran/100283
PR fortran/101123
* gfortran.dg/min0_max0_1.f90: New test.
* gfortran.dg/min0_max0_2.f90: New test.
(cherry picked from commit 6fc543396345900f460c9fa7121239cb1ebbc3a3)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
2021-06-18 13:03 [Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8 rguenth at gcc dot gnu.org
` (8 preceding siblings ...)
2021-06-19 18:16 ` cvs-commit at gcc dot gnu.org
@ 2021-06-19 18:19 ` anlauf at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-06-19 18:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and on 11-branch. Closing.
^ permalink raw reply [flat|nested] 11+ messages in thread