G++ crashes using templates/aggregates. Release: 19990824 Environment: Linux pc 2.2.10 #9 Wed Jul 21 15:10:53 MEST 1999 i686 unknown How-To-Repeat: .)compile % g++ ICE2.cpp ICE2.cpp: In method `void basic_filebuf<char>::underflow()': ICE2.cpp:13: instantiated from here ICE2.cpp:9: Internal compiler error in `expand_expr', at expr.c:5701 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. -----ICE2.cpp---------------- template<typename _CharT> struct basic_filebuf { virtual void underflow() { int __size = 5; char __conv_buf[__size]; } }; template class basic_filebuf<char>; -----------------------------
Fix: 1999-08-26 Mark Mitchell <mark@codesourcery.com> * tree.c (store_parm_decls): Reset immediate_size_expand. (finish_function): Likewise.
State-Changed-From-To: open->closed State-Changed-Why: Fixed.
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>: https://gcc.gnu.org/g:8c57a6b7959dcf16ed5321cd5214f66e7e6ad4d7 commit r17-1357-g8c57a6b7959dcf16ed5321cd5214f66e7e6ad4d7 Author: Jerry DeLisle <jvdelisle@gcc.gnu.org> Date: Wed May 27 15:10:07 2026 -0700 fortran: ICE or wrong-code for ASSOCIATE selector that is a type-bound user-defined operator Three related bugs prevented ASSOCIATE selectors that are type-bound user-defined operator expressions from compiling correctly. Bug 1 (class.cc): find_typebound_proc_uop returned NULL immediately when the derived type has no f2k_derived namespace, bypassing the parent-type inheritance walk. This caused inherited UDOs to be silently not found. Fix: set root = NULL and let the loop reach the parent type instead. Bug 2 (resolve.cc): resolve_typebound_procedures called resolve_symbol on the parent type only after an early return that fires when the derived type has no direct type-bound bindings. This left parent-type bindings unresolved when searched via gfc_find_typebound_user_op. Fix: move resolve_symbol(super_type) before the early return. Bug 3 (match.cc): match_association_list did not handle ASSOCIATE selectors of the form .uop. expr or the nested case .uop2. (.uop1. expr). When the selector's type was BT_UNKNOWN at parse time the name of the associate variable was left untyped, producing a "Syntax error in expression" ICE in the body of the ASSOCIATE construct. Fix: add three helpers before match_association_list: - resolve_assoc_operand: attempts gfc_resolve_expr on EXPR_FUNCTION operands and falls back to gfc_find_dt_in_generic for constructor calls whose argument types are not yet known. - infer_typebound_uop_type: reads the return type of a type-bound UDO directly from specific_st->n.tb->u.specific->n.sym without calling gfc_resolve_symbol, avoiding a resolve_symbol_called race condition. - extend_assoc_op: walks the expression tree bottom-up, propagating types through INTRINSIC_PARENTHESES wrappers before calling the two helpers above on each INTRINSIC_USER node. When the selector is an INTRINSIC_USER EXPR_OP with BT_UNKNOWN type, call extend_assoc_op on the operands, then gfc_extend_expr (errors suppressed). Accept the result when gfc_extend_expr returns MATCH_YES or when it returns MATCH_ERROR but has already converted the node to EXPR_COMPCALL with a known type (the full resolution pass finishes it). Assisted by: Claude Sonnet 4.6 PR fortran/125528 gcc/fortran/ChangeLog: PR fortran/125528 * class.cc (find_typebound_proc_uop): Set root = NULL instead of returning NULL when derived type lacks f2k_derived, so parent-type type-bound procedures and operators are still found via inheritance. * match.cc (resolve_assoc_operand): New helper. (infer_typebound_uop_type): New helper. (extend_assoc_op): New helper. (match_association_list): Handle ASSOCIATE selectors that are type-bound user-defined operator expressions, including nested cases. * resolve.cc (resolve_typebound_procedures): Move resolve_symbol call for the parent type before the early return so inherited type-bound bindings are resolved even when the child type has none of its own. gcc/testsuite/ChangeLog: PR fortran/125528 * gfortran.dg/associate_80.f90: New test.
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>: https://gcc.gnu.org/g:2851a6b21c89d80b81f9ce06cdfb943a172eca42 commit r17-1358-g2851a6b21c89d80b81f9ce06cdfb943a172eca42 Author: Jerry DeLisle <jvdelisle@gcc.gnu.org> Date: Wed May 27 21:00:19 2026 -0700 fortran: ICE in DO CONCURRENT with DEFAULT(NONE) inside ASSOCIATE Two bugs in check_default_none_expr caused a segfault when a DO CONCURRENT with inline type-spec iterators (e.g. "integer :: i = 1:10") contained an ASSOCIATE construct. Bug 1: sym->ns->code was used to locate the ext.concur.forall_iterator list. When a symbol's namespace is an ASSOCIATE body, sym->ns->code is an EXEC_BLOCK node, not the DO CONCURRENT node; reading ext.concur from it interprets the wrong union member and yields a garbage pointer. Fix: use d->code instead, the DO CONCURRENT gfc_code node passed through the walker's data parameter, which is always the correct node. Bug 2: inline type-spec iterators are shadow iterators, stored internally with a leading underscore prepended to the name. The comparison of the iterator's symtree name against the user-visible sym->name must skip that underscore by advancing iter_name one character when iter->shadow is set. PR fortran/125529 Assisted by: Claude Sonnet 4.6 gcc/fortran/ChangeLog: PR fortran/125529 * resolve.cc (check_default_none_expr): Use d->code instead of sym->ns->code to locate the DO CONCURRENT forall_iterator list, avoiding a wrong-union-member read when the symbol's namespace is an ASSOCIATE body. Skip leading underscore when comparing iterator names for shadow iterators. gcc/testsuite/ChangeLog: PR fortran/125529 * gfortran.dg/do_concurrent_assoc_default_none.f90: New test. (cherry picked from commit afe36f5576f07a5650ed8e2d9ade58d2e7e27021)
The releases/gcc-16 branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>: https://gcc.gnu.org/g:37724f8a90f0b9ebc5d8883ea0af71edaef2cc35 commit r16-9106-g37724f8a90f0b9ebc5d8883ea0af71edaef2cc35 Author: Jerry DeLisle <jvdelisle@gcc.gnu.org> Date: Wed May 27 21:00:19 2026 -0700 fortran: ICE in DO CONCURRENT with DEFAULT(NONE) inside ASSOCIATE Two bugs in check_default_none_expr caused a segfault when a DO CONCURRENT with inline type-spec iterators (e.g. "integer :: i = 1:10") contained an ASSOCIATE construct. Bug 1: sym->ns->code was used to locate the ext.concur.forall_iterator list. When a symbol's namespace is an ASSOCIATE body, sym->ns->code is an EXEC_BLOCK node, not the DO CONCURRENT node; reading ext.concur from it interprets the wrong union member and yields a garbage pointer. Fix: use d->code instead, the DO CONCURRENT gfc_code node passed through the walker's data parameter, which is always the correct node. Bug 2: inline type-spec iterators are shadow iterators, stored internally with a leading underscore prepended to the name. The comparison of the iterator's symtree name against the user-visible sym->name must skip that underscore by advancing iter_name one character when iter->shadow is set. Assisted by: Claude Sonnet 4.6 PR fortran/125529 gcc/fortran/ChangeLog: * resolve.cc (check_default_none_expr): Use d->code instead of sym->ns->code to locate the DO CONCURRENT forall_iterator list, avoiding a wrong-union-member read when the symbol's namespace is an ASSOCIATE body. Skip leading underscore when comparing iterator names for shadow iterators. gcc/testsuite/ChangeLog: * gfortran.dg/do_concurrent_assoc_default_none.f90: New test. (cherry picked from commit 7fd7fdfa4c228089277ddfbadda55dc8c3077726)
The releases/gcc-16 branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>: https://gcc.gnu.org/g:dfe38eb88b4e69be691e3495038d292edff77f36 commit r16-9107-gdfe38eb88b4e69be691e3495038d292edff77f36 Author: Jerry DeLisle <jvdelisle@gcc.gnu.org> Date: Wed May 27 15:10:07 2026 -0700 fortran: ICE or wrong-code for ASSOCIATE selector that is a type-bound user-defined operator Three related bugs prevented ASSOCIATE selectors that are type-bound user-defined operator expressions from compiling correctly. Bug 1 (class.cc): find_typebound_proc_uop returned NULL immediately when the derived type has no f2k_derived namespace, bypassing the parent-type inheritance walk. This caused inherited UDOs to be silently not found. Fix: set root = NULL and let the loop reach the parent type instead. Bug 2 (resolve.cc): resolve_typebound_procedures called resolve_symbol on the parent type only after an early return that fires when the derived type has no direct type-bound bindings. This left parent-type bindings unresolved when searched via gfc_find_typebound_user_op. Fix: move resolve_symbol(super_type) before the early return. Bug 3 (match.cc): match_association_list did not handle ASSOCIATE selectors of the form .uop. expr or the nested case .uop2. (.uop1. expr). When the selector's type was BT_UNKNOWN at parse time the name of the associate variable was left untyped, producing a "Syntax error in expression" ICE in the body of the ASSOCIATE construct. Add three helpers before match_association_list: - resolve_assoc_operand: attempts gfc_resolve_expr on EXPR_FUNCTION operands and falls back to gfc_find_dt_in_generic for constructor calls whose argument types are not yet known. - infer_typebound_uop_type: reads the return type of a type-bound UDO directly from specific_st->n.tb->u.specific->n.sym without calling gfc_resolve_symbol, avoiding a resolve_symbol_called race condition. - extend_assoc_op: walks the expression tree bottom-up, propagating types through INTRINSIC_PARENTHESES wrappers before calling the two helpers above on each INTRINSIC_USER node. When the selector is an INTRINSIC_USER EXPR_OP with BT_UNKNOWN type, call extend_assoc_op on the operands, then gfc_extend_expr (errors suppressed). Accept the result when gfc_extend_expr returns MATCH_YES or when it returns MATCH_ERROR but has already converted the node to EXPR_COMPCALL with a known type (the full resolution pass finishes it). Assisted-by: Claude Sonnet 4.6 PR fortran/125528 gcc/fortran/ChangeLog: * class.cc (find_typebound_proc_uop): Set root = NULL instead of returning NULL when derived type lacks f2k_derived, so parent-type type-bound procedures and operators are still found via inheritance. * match.cc (resolve_assoc_operand): New helper. (infer_typebound_uop_type): New helper. (extend_assoc_op): New helper. (match_association_list): Handle ASSOCIATE selectors that are type-bound user-defined operator expressions, including nested cases. * resolve.cc (resolve_typebound_procedures): Move resolve_symbol call for the parent type before the early return so inherited type-bound bindings are resolved even when the child type has none of its own. gcc/testsuite/ChangeLog: * gfortran.dg/associate_80.f90: New test. (cherry picked from commit 6340639219bb2d1816c94e5de76ec3642453bcb2)