public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/41600] [OOP] SELECT TYPE with associate-name => exp: Arrays not supported Date: Sat, 21 Jan 2012 20:23:00 -0000 [thread overview] Message-ID: <bug-41600-4-X2lbylJUon@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-41600-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41600 --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-21 19:57:07 UTC --- (Those comments are for the example in comment 1) The ICE happens for: integer :: X = -999.0 where one calls gfc_trans_scalar_assign with ts.type == BT_INTEGER and fold convert fails to convert the constant 999.0 to an integer. Without type spec, one uses the _vtab->__def_init while with type spec, one directly assigns. That's toggled in resolve.c:7018 (resolve_allocate_expr). With type spec, one has a call to gfc_default_initializer. In principle, the FE should convert 999.0 into 999. This happens twice via gfc_convert_type_warn, which is called via: resolve_types -> resolve_values -> resolve_structure_cons. But seemingly there is still some loop whole where it does not happen. Draft: --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -3776,3 +3782,8 @@ gfc_default_initializer (gfc_typespec *ts) if (comp->initializer) - ctor->expr = gfc_copy_expr (comp->initializer); + { + ctor->expr = gfc_copy_expr (comp->initializer); + if (comp->ts.type != comp->initializer->ts.type + || comp->ts.kind != comp->initializer->ts.kind) + gfc_convert_type_warn (ctor->expr, &comp->ts, 2, false); + } * * * OK, that fixed comment 1. But comment 0 still has issues: a) As is, it fails at: hfj3af.f90:1:0: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:997 Breakpoint 1, gfc_conv_component_ref 997 gcc_assert (f2); (gdb) p f2 $1 = (tree_node *) 0x0 #1 0x00000000005d484e in gfc_conv_variable (se=0x7fffffffd130, expr=0x16c4280) at fortran/trans-expr.c:1238 #2 0x00000000005d4154 in gfc_conv_expr_val (se=0x7fffffffd130, expr=<optimized out>) at fortran/trans-expr.c:5450 #3 0x00000000005ffb96 in gfc_trans_integer_select (code=<optimized out>) at fortran/trans-stmt.c:1821 #4 gfc_trans_select (code=0x16cb9a0) at fortran/trans-stmt.c:2380 If one looks in gfc_conv_variable just before the ICEing gfc_conv_component_ref at the values, one finds: One has an EXPR_VARIABLE ("bar") which points to ("ref") to _vptr->_hash. The issue already occurs for expr->ref where one has in gfc_conv_component_ref: 991 tree f2 = c->norestrict_decl; But that's NULL. If one sets f2 to c->backend_decl, one now iterates through f2 = DECL_CHAIN (f2), does not find the suitable field, and fails at the same assert line. b) If one comments the type is(t0) line and the print line, one gets a segfault. Invalid read of size 8 at 0x5ABD0B: gfc_conv_scalarized_array_ref(gfc_se*, gfc_array_ref*) (trans-array.c:3016) by 0x5AC7A1: gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_symbol*, locus*) (trans-array.c:3112) by 0x5D47B7: gfc_conv_variable(gfc_se*, gfc_expr*) (trans-expr.c:1230) That's the line: expr = ss->info->expr; For some reason, this empty select type wants to get scalarized. The cally has: /* Handle scalarized references separately. */ if (ar->type != AR_ELEMENT) { gfc_conv_scalarized_array_ref (se, ar);
next parent reply other threads:[~2012-01-21 19:57 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-41600-4@http.gcc.gnu.org/bugzilla/> 2012-01-21 20:23 ` burnus at gcc dot gnu.org [this message] 2012-01-22 15:26 ` mikael at gcc dot gnu.org 2012-01-22 16:49 ` tobi at gcc dot gnu.org 2012-01-25 10:39 ` burnus at gcc dot gnu.org 2012-01-28 15:59 ` dominiq at lps dot ens.fr 2012-01-29 21:43 ` burnus at gcc dot gnu.org 2012-01-29 21:43 ` burnus at gcc dot gnu.org 2012-03-05 14:04 ` pault at gcc dot gnu.org 2012-05-05 8:53 ` pault at gcc dot gnu.org 2012-05-05 8:54 ` pault at gcc dot gnu.org 2012-05-05 8:57 ` pault at gcc dot gnu.org 2009-10-06 8:04 [Bug fortran/41600] New: " burnus at gcc dot gnu dot org 2010-01-30 10:38 ` [Bug fortran/41600] " janus at gcc dot gnu dot org 2010-04-18 16:24 ` dominiq at lps dot ens dot fr
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-41600-4-X2lbylJUon@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).