From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25864 invoked by alias); 11 Jan 2012 23:32:43 -0000 Received: (qmail 25854 invoked by uid 22791); 11 Jan 2012 23:32:42 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jan 2012 23:32:26 +0000 From: "mikael at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument Date: Wed, 11 Jan 2012 23:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: mikael at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: mikael at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.4.7 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg01323.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #18 from Mikael Morin 2012-01-11 23:31:32 UTC --- (In reply to comment #17) > I think the proper solution is to remove the trans-stmt.c manual scalarization > and handle somewhere in trans-{array,expr}.c the array bounds. > Some of it might actually be dead code. I don't see where the `temp' variable is used. > Stupid attempts fail for various reasons: Changing the BT_CLASS to BT_DERIVED > in gfc_trans_allocate does not work as one the offsets will no longer be > class._size (why?). Keeping BT_CLASS but removing the gfc_add_data_component > in trans-stmt.c will ICE for dataref - and removing that as well will lead to > valid code with class._size, but without scalarization loop ... Below is my `stupid' attempt at the not-so-proper solution: it does an `intelligent' e->ts.type == BT_CLASS in the new conditions in gfc_conv_procedure_call. It passes gfortran.dg/*elemental* and gfortran.dg/*class*. But it is admittedly somewhat hackish. diff --git a/trans-expr.c b/trans-expr.c index a2268a1..1a24d4b 100644 --- a/trans-expr.c +++ b/trans-expr.c @@ -3259,6 +3259,35 @@ conv_isocbinding_procedure (gfc_se * se, gfc_symbol * sym, } +static bool +needs_class_data_ref (gfc_expr *e) +{ + gfc_ref *ref; + bool result; + + if (e->expr_type != EXPR_VARIABLE) + return false; + + if (e->symtree->n.sym->ts.type == BT_CLASS) + result = true; + + for (ref = e->ref; ref; ref = ref->next) + { + if (ref->type != REF_COMPONENT) + { + result = false; + continue; + } + + if (ref->u.c.component->ts.type == BT_CLASS) + result = true; + else if (!strcmp (ref->u.c.component->name, "_data")) + result = false; + } + + return result; +} + /* Generate code for a procedure call. Note can return se->post != NULL. If se->direct_byref is set then se->expr contains the return parameter. Return nonzero, if the call has alternate specifiers. @@ -3435,7 +3464,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, else gfc_conv_expr_reference (&parmse, e); - if (fsym && fsym->ts.type == BT_DERIVED && e->ts.type == BT_CLASS) + if (fsym && fsym->ts.type == BT_DERIVED && needs_class_data_ref (e)) parmse.expr = gfc_class_data_get (parmse.expr); /* The scalarizer does not repackage the reference to a class @@ -3514,7 +3543,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, if (fsym && fsym->ts.type == BT_DERIVED - && e->ts.type == BT_CLASS) + && needs_class_data_ref (e)) parmse.expr = gfc_class_data_get (parmse.expr); /* A class array element needs converting back to be a