Matching of parentheses sometimes can end up giving wrong kind values to
expressions. In the following example, output should only be ones, as all
expressions have kind=1. What has me worried in particular is the difference
between the last two cases.
$ cat a.f90
logical(kind=1) :: i, j
integer(kind=1) :: a, b
print *, kind(i .and. j)
print *, kind(.not. (i .and. j))
print *, kind((a + b))
print *, kind((42_1))
print *, kind((j .and. i))
print *, kind((.true._1))
end
$ gfortran a.f90 && ./a.out
1
4
1
1
4
1
This bug is the reason why intrinsic_associated_2.f90 fails with type checking
enabled, and also fails with -fdefault-integer-8. This
intrinsic_associated_2.f90 failure can (and should, in my opinion) also be
fixed by the following patch.
Index: trans-expr.c
===================================================================
--- trans-expr.c (revision 128951)
+++ trans-expr.c (working copy)
@@ -592,7 +592,7 @@ gfc_conv_unary_op (enum tree_code code,
All other unary operators have an equivalent GIMPLE unary operator. */
if (code == TRUTH_NOT_EXPR)
se->expr = build2 (EQ_EXPR, type, operand.expr,
- build_int_cst (type, 0));
+ build_int_cst (TREE_TYPE (operand.expr), 0));
else
se->expr = build1 (code, type, operand.expr);
--
Summary: Parentheses get wrong kind during matching
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: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33626
