From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5462 invoked by alias); 5 Nov 2008 11:45:13 -0000 Received: (qmail 28118 invoked by uid 48); 5 Nov 2008 11:43:52 -0000 Date: Wed, 05 Nov 2008 11:45:00 -0000 Message-ID: <20081105114352.28116.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/35983] C_LOC in derived type constructor gives weird result In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikael dot morin at tele2 dot fr" 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: 2008-11/txt/msg00375.txt.bz2 ------- Comment #2 from mikael dot morin at tele2 dot fr 2008-11-05 11:43 ------- There is a reset of the expression to NULL_EXPR in case we encounter c_null_ptr or c_null_funptr. However, the if conditions for this relies on the is_iso_c attribute, which is the case of c_loc. This patch changes this behavior by relying on the symtree names instead. Index: trans-expr.c =================================================================== --- trans-expr.c (révision 141583) +++ trans-expr.c (copie de travail) @@ -3689,15 +3682,16 @@ gfc_trans_structure_assign (tree dest, gfc_expr * { /* Skip absent members in default initializers. */ if (!c->expr) - continue; + continue; /* Update the type/kind of the expression if it represents either C_NULL_PTR or C_NULL_FUNPTR. This is done here because this may be the first place reached for initializing output variables that have components of type C_PTR/C_FUNPTR that are initialized. */ - if (c->expr->ts.type == BT_DERIVED && c->expr->ts.derived - && c->expr->ts.derived->attr.is_iso_c) - { + if (c->expr->symtree && c->expr->symtree->name + && (!strcmp ("c_null_ptr", c->expr->symtree->name) + || !strcmp ("c_null_funptr", c->expr->symtree->name))) + { c->expr->expr_type = EXPR_NULL; c->expr->ts.type = c->expr->ts.derived->ts.type; c->expr->ts.f90_type = c->expr->ts.derived->ts.f90_type; With this patch alone, I still get wrong-code though (pointer uninitialized instead of nullified). I've had to revert this patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150#c7 to have it working. There is only one regression, c_loc_tests_12.f03. That one is expected, and we are back at PR35150. I looked at that one too, but I must admit I'm at least as confused as FX when he fixed it. If some middle-end gurus could take a look/give some tips there... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35983