[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #1 from brolley at redhat dot com 2007-06-05 19:57 --- Created an attachment (id=13659) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13659&action=view) Proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #2 from brolley at redhat dot com 2007-06-05 20:09 --- The macro invocation "TYPE_MODE (type)" causes the ICE when tree checking is enabled because TREE_CODE_CLASS (type) is ERROR_MARK. Checking for this before checking the tree and returning NULL_TREE allows the compiler to generate the expected message. Note that this bug exists in 4.2 and 4.3 but did not result in an ICE during my initial testing because tree checking is disabled on those branches by default. -- brolley at redhat dot com changed: What|Removed |Added CC| |brolley at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #3 from brolley at redhat dot com 2007-06-05 20:11 --- Typo (sorry!) "4.2 and 4.3" above should be "4.1 and 4.2" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
--- Comment #6 from brolley at redhat dot com 2007-06-07 15:48 ---
As Andrew Pinski has noted, 4.2.0 rejects the code with a proper error message.
The latest trunk does the same. The change which fixes this is
2006-08-20 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/28341
* tree.c (cast_valid_in_integral_constant_expression_p): New
function.
* cp-tree.h (tsubst_copy_and_build): Adjust prototype.
* pt.c (tsubst_expr): Add integral_constant_expression_p
parameter.
(fold_non_dependent_expr): Adjust callers of
tsubst_{expr,copy_and_build}.
(tsubst_friend_function): Likewise.
(tsubst_template_arg): Likewise.
(tsubst_default_argument): Likewise.
(tsubst_decl): Likewise.
(tsubst): Likewise.
(tsubst_omp_clasuses): Likewise.
(regenerate_decl_fromp_template): Likewise.
(instantiate_decl): Likewise.
(tsubst_initializer_list): Likewise.
(tsubst_enum): Likewise.
(tsubst_expr): Use RECUR throughout.
(tsubst_copy_and_build): Change definition of RECUR. Do not allow
invalid casts in integral constant expressions.
I'm attaching a patch for gcc-4_1_branch which brings in this change.
--
brolley at redhat dot com changed:
What|Removed |Added
CC| |brolley at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
--- Comment #7 from brolley at redhat dot com 2007-06-07 15:49 --- Created an attachment (id=13665) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13665&action=view) Proposed Patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #5 from brolley at redhat dot com 2007-06-08 15:41 --- OK, I've looked into this a bit more. For inspiration I looked into where the error is generated when an incomplete struct is used instead of an unsized array. I found it in: cxx_incomplete_type_diagnostic called by complete_type_or_else called by build_new_1 I also discovered that this sequence of calls should have detected an unsized array and generated the message we want. The reason it didn't is because this knowledge is forgotten in cp_parser_new_type_id (in the case of "new A") or in build_new_1 (in the case of "new (A)") when the top level array bound is stripped off. This is done (in both cases) before complete_type_or_else is called. Now, the transformation in cp_parser_new_type_id is unnecessary since the same transformation is done in build_new_1 and (as noted above) it is not performed in the case of "new (A)". This gives us the opportunity to generate the error in build_new_1 by calling complete_type_or_else before the transformation. I'm attaching a patch which implements these two changes. The patch generates the error "31743.C:2: error: invalid use of array with unspecified bounds" which is analogous to the message generated when an incomplete struct is used. Andrew's patch is not necessary for the generation of the error, but it makes sense to punt early in array_type_nelts_top when dealing with error_mark_node regardless. Tested against the trunk with no regressions in "make check-gcc". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #7 from brolley at redhat dot com 2007-06-08 15:46 --- Small optimization. We need only call complete_type_or_else once we know it's an array type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #6 from brolley at redhat dot com 2007-06-08 15:42 --- Created an attachment (id=13667) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13667&action=view) New proposed patch -- brolley at redhat dot com changed: What|Removed |Added Attachment #13659|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #8 from brolley at redhat dot com 2007-06-08 15:47 --- Created an attachment (id=13668) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13668&action=view) Improvement on previous patch -- brolley at redhat dot com changed: What|Removed |Added Attachment #13667|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug c++/31992] [4.1/4.2/4.3 regression] ICE initializing static variable of template class
--- Comment #1 from brolley at redhat dot com 2007-07-05 20:05 --- I've worked on this a bit and just realized that it's assigned to Mark Mitchell. However, here's what I've learned, in case it helps... The segfault occurs in convert_for_initialization because the TREE_TYPE of rhs is NULL_TREE. This is because the tree is a SCOPE_REF referring to A and i. The TREE_TYPE was set to NULL_TREE because A is a dependent type. Now, it's documented in build_qualified_name in cp/tree.c that a SCOPE_REF has NULL type in the event that the expression represents a dependent type. However, since i does not depend on any of the template parameters of A, I think that A::i is not a dependent type and that the TREE_TYPE should have been set to the type of i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31992
