https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |iains at gcc dot gnu.org
--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #15)
> Fixed on trunk by r15-7259-gd0f230adf0e888
This regresses obj-c++ with NeXT runtime
the previous (CONST_DECL) case contains...
/* CONST_DECL without TREE_STATIC are enumeration values and
thus not lvalues. With TREE_STATIC they are used by ObjC++
in objc_build_string_object and need to be considered as
lvalues. */
the CONST_DECL case then falls through into the processing for VAR_DECL, and
then tries to DECL_MERGEABLE - which ICEs because it's not a VAR.
====
perhaps:
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index fb6b2b18e94..fba026d2efb 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -213,7 +213,8 @@ lvalue_kind (const_tree ref)
&& DECL_IN_AGGR_P (ref))
return clk_none;
- if (DECL_MERGEABLE (ref))
+ if ((TREE_CODE (ref) == CONST_DECL && TREE_STATIC (ref))
+ || DECL_MERGEABLE (ref))
return clk_ordinary | clk_mergeable;
/* FALLTHRU */
====
(imo) It would be useful to allow more use of CONST_DECL this way where we have
code like contracts that generates a lot of const objects - doing it manually
with read-only vars and invented local names is less obvious. I think Richi
also has a long-term objective to use it in some way to optimise strings.
