Re: program errors with GNU Fortran
On 6/16/23 12:18 PM, Michael Schneider via Fortran wrote: Hello, I'm looking for a forum that can provide answers to questions arising with GNU Fortran. Is this the right place? Mike Schneider We have a Mattermost instance I can invite you to for general discussions and other topics. I can send you an invitation if you would like. Send me a note with a little about yourself. Regards, Jerry
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
Hi Paul, On 6/17/23 11:14, Paul Richard Thomas via Gcc-patches wrote: Hi All, The attached patch is amply described by the comments and the changelog. It also includes the fix for the memory leak in decl.cc, as promised some days ago. OK for trunk? I hate to say it, but you forgot to add the testcase again... :-( The patch fixes your "extended" testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900#c2 but the original one in comment ICEs for me here: % gfc-14 pr107900.f90 f951: internal compiler error: Segmentation fault 0x1025c2f crash_signal ../../gcc-trunk/gcc/toplev.cc:314 0x9d31d3 resolve_select_type ../../gcc-trunk/gcc/fortran/resolve.cc:9791 0x9cef5e gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:12588 0x9d2431 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.cc:18057 0x9d24fe gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:18092 0x9cf0ee gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:18077 0x9cf0ee resolve_block_construct ../../gcc-trunk/gcc/fortran/resolve.cc:10971 0x9cf0ee gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:12596 0x9d2431 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.cc:18057 0x9d24fe gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:18092 0x9b11f1 resolve_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:6864 0x9b11f1 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7120 0xa033ef gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:229 It hits an assert here: 9790 st = gfc_find_symtree (ns->sym_root, name); 9791 gcc_assert (st->n.sym->assoc); My tree is slightly modified, but the changes should not have any effect here. Can you please have a look, too? Thanks, Harald Regards Paul PS This leaves 89645 and 99065 as the only real blockers to PR87477. These will take a little while to fix. They come about because the type of the associate name is determined by that of a derived type function that hasn't been parsed at the time that component references are being parsed. If the order of the contained procedures is reversed, both test cases compile correctly. The fix will comprise matching the component name to the accessible derived types, while keeping track of all the references in case the match is ambiguous and has to be fixed up later.
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
On Sat, Jun 17, 2023 at 10:14:43AM +0100, Paul Richard Thomas via Fortran wrote: > > PS This leaves 89645 and 99065 as the only real blockers to PR87477. > Hate to be the bearer of bad news, but Neil Carlson has added a couple PRs about associate that may not be listed in 87447. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 For the second one, if I suppress the bogus error message, the compiler runs into a new error message. The second error message indicates the associate-name is not an unexpected coarray. I haven't determined how to propagate the information that the selector is a coarray to the associate-name. -- Steve
Re: [PATCH v6 0/4] P1689R5 support
On Fri, Jun 16, 2023 at 23:55:53 -0400, Jason Merrill wrote: > I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g. > > FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors) > Excess errors: > /home/jason/gt/gcc/testsuite/g++.dg/modules/ben-1_a.C:9:1: internal > compiler error: Segmentation fault > 0x19e2f3c crash_signal > /home/jason/gt/gcc/toplev.cc:314 > 0x340f3f8 mkdeps::vec::size() const > /home/jason/gt/libcpp/mkdeps.cc:57 > 0x340dc1f apply_vpath > /home/jason/gt/libcpp/mkdeps.cc:194 > 0x340e08e deps_add_dep(mkdeps*, char const*) > /home/jason/gt/libcpp/mkdeps.cc:318 > 0xea7b51 module_client::open_module_client(unsigned int, char const*, > mkdeps*, void (*)(char const*), char const*) > /home/jason/gt/gcc/cp/mapper-client.cc:291 > 0xef2ba8 make_mapper > /home/jason/gt/gcc/cp/module.cc:14042 > 0xf0896c get_mapper(unsigned int, mkdeps*) > /home/jason/gt/gcc/cp/module.cc:3977 > 0xf032ac name_pending_imports > /home/jason/gt/gcc/cp/module.cc:19623 > 0xf03a7d preprocessed_module(cpp_reader*) > /home/jason/gt/gcc/cp/module.cc:19817 > 0xe85104 module_token_cdtor(cpp_reader*, unsigned long) > /home/jason/gt/gcc/cp/lex.cc:548 > 0xf467b2 cp_lexer_new_main > /home/jason/gt/gcc/cp/parser.cc:756 > 0xfc1e3a c_parse_file() > /home/jason/gt/gcc/cp/parser.cc:49725 > 0x11c5bf5 c_common_parse_file() > /home/jason/gt/gcc/c-family/c-opts.cc:1268 Thanks. I missed a `nullptr` check before calling `deps_add_dep`. I think I got misled by `make check` returning a zero exit code even if there are failures. Thanks, --Ben
[Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
Hi All,
The attached patch is amply described by the comments and the
changelog. It also includes the fix for the memory leak in decl.cc, as
promised some days ago.
OK for trunk?
Regards
Paul
PS This leaves 89645 and 99065 as the only real blockers to PR87477.
These will take a little while to fix. They come about because the
type of the associate name is determined by that of a derived type
function that hasn't been parsed at the time that component references
are being parsed. If the order of the contained procedures is
reversed, both test cases compile correctly. The fix will comprise
matching the component name to the accessible derived types, while
keeping track of all the references in case the match is ambiguous and
has to be fixed up later.
Change107900.Logs
Description: Binary data
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index d09c8bc97d9..844345df77e 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1086,6 +1086,8 @@ char_len_param_value (gfc_expr **expr, bool *deferred)
p = gfc_copy_expr (*expr);
if (gfc_is_constant_expr (p) && gfc_simplify_expr (p, 1))
gfc_replace_expr (*expr, p);
+ else
+gfc_free_expr (p);
if ((*expr)->expr_type == EXPR_FUNCTION)
{
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index e6a4337c0d2..ab5f94e9f03 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -1875,6 +1875,13 @@ gfc_get_symbol_decl (gfc_symbol * sym)
&& !(sym->attr.use_assoc && !intrinsic_array_parameter)))
gfc_defer_symbol_init (sym);
+ /* Nullify so that select type doesn't fall over if the variable
+ is not associated. */
+ if (sym->ts.type == BT_CLASS && UNLIMITED_POLY (sym)
+ && sym->attr.flavor == FL_VARIABLE && !sym->assoc
+ && !sym->attr.dummy && CLASS_DATA (sym)->attr.class_pointer)
+gfc_defer_symbol_init (sym);
+
if (sym->ts.type == BT_CHARACTER
&& sym->attr.allocatable
&& !sym->attr.dimension
@@ -1906,6 +1913,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
gcc_assert (!sym->value || sym->value->expr_type == EXPR_NULL);
}
+
gfc_finish_var_decl (decl, sym);
if (sym->ts.type == BT_CHARACTER)
@@ -4652,6 +4660,21 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block)
if (sym->assoc)
continue;
+ /* Nullify unlimited polymorphic variables so that they do not cause
+ segfaults in select type, when the selector is an intrinsic type. */
+ if (sym->ts.type == BT_CLASS && UNLIMITED_POLY (sym)
+ && sym->attr.flavor == FL_VARIABLE && !sym->assoc
+ && !sym->attr.dummy && CLASS_DATA (sym)->attr.class_pointer)
+ {
+ gfc_expr *lhs = gfc_lval_expr_from_sym (sym);
+ gfc_expr *rhs = gfc_get_null_expr (NULL);
+ tmp = gfc_trans_pointer_assignment (lhs, rhs);
+ gfc_init_block ();
+ gfc_add_expr_to_block (, tmp);
+ gfc_add_init_cleanup (block, gfc_finish_block (), NULL);
+ continue;
+ }
+
if (sym->ts.type == BT_DERIVED
&& sym->ts.u.derived
&& sym->ts.u.derived->attr.pdt_type)
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 45a984b6bdb..eeae13998a3 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -10034,6 +10034,19 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
build_zero_cst (TREE_TYPE (lse.string_length)));
}
+ /* Unlimited polymorphic arrays, nullified in gfc_trans_deferred_vars,
+ arrive here as a scalar expr. Find the descriptor data field. */
+ if (expr1->ts.type == BT_CLASS && UNLIMITED_POLY (expr1)
+ && expr2->expr_type == EXPR_NULL
+ && !expr1->ref && !expr1->rank
+ && (CLASS_DATA (expr1)->attr.dimension
+ || CLASS_DATA (expr1)->attr.codimension))
+ {
+ lse.expr = gfc_get_class_from_expr (lse.expr);
+ lse.expr = gfc_class_data_get (lse.expr);
+ lse.expr = gfc_conv_descriptor_data_get (lse.expr);
+ }
+
gfc_add_modify (, lse.expr,
fold_convert (TREE_TYPE (lse.expr), rse.expr));
