Bug 27094 - [4.0 Regression] tree check: expected tree_list, have omp_return in build_call
Summary: [4.0 Regression] tree check: expected tree_list, have omp_return in build_call
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.0
: P1 normal
Target Milestone: 4.1.1
Assignee: Not yet assigned to anyone
URL:
Keywords: GC, ice-on-valid-code, monitored
Depends on:
Blocks:
 
Reported: 2006-04-09 21:00 UTC by Debian GCC Maintainers
Modified: 2007-02-03 16:49 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work: 3.4.6 4.0.0 4.0.1 4.1.1 4.1.2 4.2.0
Known to fail: 4.0.2 4.1.0
Last reconfirmed: 2006-09-03 21:35:44


Attachments
test case (80.23 KB, application/octet-stream)
2006-04-09 21:01 UTC, Debian GCC Maintainers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2006-04-09 21:00:34 UTC
[ forwarded from http://bugs.debian.org/361407 ]

falk@juist:/tmp% g++ -c maria.tab.ii
maria.y: In constructor 'std::stack<_Tp, _Sequence>::stack(const _Sequence&) [with _Tp = std::pair<const Type*, unsigned int>, _Sequence = std::list<std::pair<const Type*, unsigned int>, std::allocator<std::pair<const Type*, unsigned int> > >]':
maria.y:157: internal compiler error: tree check: expected tree_list, have omp_return in build_call, at cp/call.c:329
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Attempts to reduce this fail. Looks like memory corruption. No problem 
with 4.1.

    Falk
Comment 1 Debian GCC Maintainers 2006-04-09 21:01:06 UTC
Created attachment 11229 [details]
test case
Comment 2 Andrew Pinski 2006-04-09 21:38:30 UTC
I could not reproduce this with the default gc params for checking but could with:
--param ggc-min-expand=0 --param ggc-min-heapsize=0

Which means this is a GC issue.
Comment 3 Andrew Pinski 2006-04-09 21:40:33 UTC
Reducing.
Comment 4 Volker Reichelt 2006-04-10 11:34:47 UTC
Confirmed. Reduced testcase
(compile with "g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0"):

=============================
struct A
{
    ~A();
};

struct B : A
{
    B();
};

template<int> struct C
{
    C(const B& = B());
};

C<0> c;
=============================

The regression appeared in GCC 4.0.2.

On mainline the error message reads:

PR27094.cc: In constructor 'C<<anonymous> >::C(const B&) [with int <anonymous> = 0]':
PR27094.cc:16: internal compiler error: tree check: expected tree_list, have omp_return in build_call, at cp/call.c:329
Please submit a full bug report, [etc.]

On the 4.0 and 4.1 branch we have:

PR27094.cc: In constructor 'C<<anonymous> >::C(const B&) [with int <anonymous> = 0]':
PR27094.cc:16: internal compiler error: tree check: expected tree_list, have dl_expr in build_call, at cp/call.c:330
Please submit a full bug report, [etc.]
Comment 5 Andrew Pinski 2006-04-10 16:22:45 UTC
Here is another testcase (which was reduced from the same source and gives a similar error message but does not have inheritance in it):
template<typename _Tp> struct allocator
{
    ~allocator() throw() { }
};
struct list
{
    allocator<int> _M_impl;
};
template <int>
struct stack {
  stack(const list& __c = list());
};
stack <1> a;
Comment 6 Jakub Jelinek 2006-04-12 11:46:22 UTC
It is a GC problem, when build_over_call calls mark_used, it certainly doesn't
expect mark_used to do a gcc_collect underneath it, as it has several tree
pointers stored in local variables.  I guess build_over_call isn't the only
place that trusts mark_used doesn't do that, e.g. build_call, build_op_delete_call, finish_eh_spec_block etc. likely suffer from the same problem.
The call chain that leads to ggc_collect is mark_used -> {synthetize_method,instantiate_decl} -> expand_or_defer_fn -> cgraph_finalize_function -> ggc_collect.
So, either we change mark_used to never trigger GC from underneath us
(e.g. by function_depth++; synthetise_method (...); function_depth--; and
probably similarly for instantiate_decl), or we add an argument to mark_used
if it is ok to ggc_collect (similarly to cgraph_finalize_function's NESTED
argument), or we change all mark_used callers that might suffer from this
(either by adding function_depth++/function_depth-- around the call, or by
registering its temporaries with GC before calling mark_used).
Comment 7 Mark Mitchell 2006-04-30 23:21:42 UTC
Subject: Bug 27094

Author: mmitchel
Date: Sun Apr 30 23:21:38 2006
New Revision: 113399

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113399
Log:
	PR c++/27094
	* pt.c (tsubst_default_argument): Increment function_depth around
	call to tsubst_expr.
	* parser.c (cp_parser_parameter_declaration): Likewise.
	* decl2.c (mark_used): Tidy.
	PR c++/27094
	* g++.dg/template/defarg8.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/template/defarg8.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl2.c
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog

Comment 8 Mark Mitchell 2006-04-30 23:25:47 UTC
Subject: Bug 27094

Author: mmitchel
Date: Sun Apr 30 23:25:44 2006
New Revision: 113400

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113400
Log:
	PR c++/27094
	* pt.c (tsubst_default_argument): Increment function_depth around
	call to tsubst_expr.
	* parser.c (cp_parser_parameter_declaration): Likewise.
	PR c++/27094
	* g++.dg/template/defarg8.C: New test.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/defarg8.C
Modified:
    branches/gcc-4_1-branch/gcc/cp/ChangeLog
    branches/gcc-4_1-branch/gcc/cp/parser.c
    branches/gcc-4_1-branch/gcc/cp/pt.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog

Comment 9 Mark Mitchell 2006-04-30 23:29:00 UTC
Fixed in 4.1.1.
Comment 10 Gabriel Dos Reis 2007-02-03 16:49:53 UTC
Fixed in GCC-4.1.1.