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);
Created attachment 14291 [details] Putative patch This patch fixes the testcase. FX, I take it that you have a ready-built compiler with type-checking enabled. In that case I would ask you to try this patch. Otherwise I'll take care of this myself.
Created attachment 14292 [details] Putative patch redux Coming to think of it, the charlen thing can probably also be moved to the first switch and done unconditionally. This hasn't yet gotten the testsuite treatment from me, though.
(In reply to comment #1) > Created an attachment (id=14291) [edit] > Putative patch I thought about that, because it seems right, but the the question is: what was the intent of the original situation, which only copied typespec only for unknown types? > FX, I take it that you have a ready-built compiler with type-checking enabled. > In that case I would ask you to try this patch. Otherwise I'll take care of > this myself. I'll test it.
Subject: Re: Parentheses get wrong kind during matching fxcoudert at gcc dot gnu dot org wrote: > ------- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:26 ------- > (In reply to comment #1) >> Created an attachment (id=14291) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291&action=view) [edit] >> Putative patch > > I thought about that, because it seems right, but the the question is: what was > the intent of the original situation, which only copied typespec only for > unknown types? I'm thinking that was a case of playing it overly safe as the comment indicates. OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 for which I have no explanation at the moment, I'll have to doublecheck if it disappears without my patch. > I'll test it. Thanks! - Tobi
(In reply to comment #4) > OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 > for which I have no explanation at the moment, I'll have to doublecheck > if it disappears without my patch. Hum... Why do I keep sending regular regressions heads-up, can you remind me? ;-) http://gcc.gnu.org/ml/fortran/2007-10/msg00040.html
Subject: Re: Parentheses get wrong kind during matching fxcoudert at gcc dot gnu dot org wrote: > ------- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:40 ------- > (In reply to comment #4) >> OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 >> for which I have no explanation at the moment, I'll have to doublecheck >> if it disappears without my patch. > > Hum... Why do I keep sending regular regressions heads-up, can you remind me? > ;-) Ouch, a warning regression seemd so unlikely to happen in the tree that I thought it would be my fault, even though I very well remembered that you had sent an e-mail pointing out failures of default_format_1.f90 (which I'm seeing as well). Note to self: always memorize e-mail's from FX in their entirety :)
(In reply to comment #6) > failures of default_format_1.f90 (which I'm seeing as well) You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's what you've got these days)? That's not supposed to happen, I thought it'd be only on powerpc-darwin (which I have xfail'ed)! Could you compile it and run it under gdb, and see where it aborts? (I expect it to be the line about tiny, in which case it'd be the same failure as powerpc.)
Subject: Re: Parentheses get wrong kind during matching fxcoudert at gcc dot gnu dot org wrote: > ------- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:52 ------- > (In reply to comment #6) >> failures of default_format_1.f90 (which I'm seeing as well) > > You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's > what you've got these days)? That's not supposed to happen, I thought it'd be > only on powerpc-darwin (which I have xfail'ed)! Could you compile it and run it > under gdb, and see where it aborts? (I expect it to be the line about tiny, in > which case it'd be the same failure as powerpc.) I checked all tests individually, and both the tests related to tiny(0.0_8) fail.
(In reply to comment #8) > I checked all tests individually, and both the tests related to > tiny(0.0_8) fail. That means Apple's printf() failures to read and write denormals are not powerpc-specific. I've xfail'ed the test on all *-apple-darwin*. Thanks for testing!
(In reply to comment #2) > Created an attachment (id=14292) [edit] > Putative patch redux That patch regtests fines on x86_64-linux with type-checking enabled. It's OK to commit.
Subject: Bug 33626 Author: tobi Date: Thu Oct 4 07:34:38 2007 New Revision: 129002 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129002 Log: PR fortran/33626 fortran/ * resolve.c (resolve_operator): Always copy the type for expressions in parentheses. testsuite/ * gfortran.dg/parens_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/parens_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Fixed, isn't it?
Yes, I only happened to leave before the commit message arrived.