Re: [PATCH, c++]: Fix PR c++/31488 by Introducing LANG_HOOKS_SET_IS_AGGR_TYPE language hook.

[Ian Lance Taylor <iant at google dot com>]

Uros Bizjak <ubizjak@gmail.com> writes:

> There is currently no way to communicate from target backend to the
> frontend that certain RECORD_TYPE structure is an aggregate. An
> example is alpha backend that creates RECORD_TYPE to pass variable
> arguments. Since this structure is not considered as non-POD by c++
> frontend, several java testcases fail (please see PR c++/31488 and a
> classpath bug it blocks for more info):
>
> FAIL: natgetargssize.cc compilation
> FAIL: natgetlocalvartable.cc compilation
> FAIL: natgetstacktrace.cc compilation
> FAIL: natevents.cc compilation
> FAIL: natgetallthreads.cc compilation
> FAIL: natgeterrorname.cc compilation
> FAIL: natgetmethodname.cc compilation
>
> Attached patch introduces LANG_HOOKS_SET_IS_AGGR_TYPE language hook to
> give backends the ability to mark certain structures as POD.

I won't object if a C++ maintainer approves this patch, but this feels
like the wrong approach to me.  It effectively means that every target
backend which defines va_list as a record type must know to call this
new langhook.  That is fragile; target backend writers should not have
to know about details of the C++ IR.

The code is already calling lang_hooks.types.make_type.  What would
happen if we changed cxx_make_type to make RECORD_TYPE default to
being POD?

Ian