The test FAILs on 32-bit targets that don't have __int128 type.

2020-03-12  Jakub Jelinek  <jakub@redhat.com>

	PR c++/93907
	* g++.dg/cpp2a/concepts-using2.C (cc): Use long long instead of
	__int128 if __SIZEOF_INT128__ isn't defined.

The problem here was that we were checking satisfaction once with 'e', a
typedef of 'void', and another time with 'void' directly, and treated them
as different for hashing based on the assumption that
canonicalize_type_argument would have already removed a typedef that wasn't
a complex dependent alias.  But that wasn't happening here, so let's add a
call.

gcc/cp/ChangeLog
2020-03-11  Jason Merrill  <jason@redhat.com>

	PR c++/93907
	* constraint.cc (tsubst_parameter_mapping): Canonicalize type
	argument.

I got a report that building Chromium fails with the "modifying a const
object" error.  After some poking I realized it's a bug in GCC, not in
their codebase.

Much like with ARRAY_REFs, which can be const even though the array
itself isn't, COMPONENT_REFs can be const although neither the object
nor the field were declared const.  So let's dial down the checking.
Here the COMPONENT_REF was const because of the "const_cast<const U &>(m)"
thing -- cxx_eval_component_reference then builds a COMPONENT_REF with
TREE_TYPE (t).

While looking into this I noticed that we don't detect modifying a const
object in certain cases like in
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94074#c2>.  That's because
we never evaluate an X::X() CALL_EXPR -- there's none.  Fixed as per
Jason's suggestion by setting TREE_READONLY on a CONSTRUCTOR after
initialization in cxx_eval_store_expression.

2020-03-11  Marek Polacek  <polacek@redhat.com>
	    Jason Merrill  <jason@redhat.com>

	PR c++/94074 - wrong modifying const object error for COMPONENT_REF.
	* constexpr.c (cref_has_const_field): New function.
	(modifying_const_object_p): Consider a COMPONENT_REF
	const only if any of its fields are const.
	(cxx_eval_store_expression): Mark a CONSTRUCTOR of a const type
	as readonly after its initialization has been done.

	* g++.dg/cpp1y/constexpr-tracking-const17.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const18.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const19.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const20.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const21.C: New test.
	* g++.dg/cpp1y/constexpr-tracking-const22.C: New test.

This adds a tests that verifies taking the split_view of a non-forward range
works correctly.  Doing so revealed a typo in one of _OuterIter's constructors.

It also revealed that the default constructor of
__gnu_test::test_range::iterator misbehaves, because by delegating to
Iter<T>(nullptr, nullptr) we perform a null-pointer deref at runtime in
input_iterator_wrapper's constructor due to the ITERATOR_VERIFY check therein.
Instead of delegating to this constructor it seems we can just inherit the
protected default constructor, which does not contain this ITERATOR_VERIFY
check.

libstdc++-v3/ChangeLog:

	* include/std/ranges (split_view::_OuterIter::_OuterIter): Typo fix,
	'address' -> 'std::__addressof'.
	* testsuite/std/ranges/adaptors/split.cc: Test taking the split_view of
	a non-forward input_range.
	* testsuite/util/testsuite_iterators.h (output_iterator_wrapper): Make
	default constructor protected instead of deleted, like with
	input_iterator_wrapper.
	(test_range::iterator): Add comment explaining that this type is used
	only when the underlying wrapper is input_iterator_wrapper or
	output_iterator_wrapper.  Remove delegating defaulted constructor so
	that the inherited default constructor is used instead.

This patch fixes a bug introduced by my earlier patch (
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541680.html ).
It introduces a new scalar builtin type that was missing in the original
patch.

Bootstrapped cleanly on arm-none-linux-gnueabihf.
Tested for regression on arm-none-linux-gnueabihf. No regression from
before the original patch.
Tests that failed or became unsupported because of the original tests
now work as they did before it.

	* config/arm/arm-builtins.c
	(arm_init_simd_builtin_scalar_types): New.
	* config/arm/arm_neon.h (vld2_bf16): Used new builtin type.
	(vld2q_bf16): Used new builtin type.
	(vld3_bf16): Used new builtin type.
	(vld3q_bf16): Used new builtin type.
	(vld4_bf16): Used new builtin type.
	(vld4q_bf16): Used new builtin type.
	(vld2_dup_bf16): Used new builtin type.
	(vld2q_dup_bf16): Used new builtin type.
	(vld3_dup_bf16): Used new builtin type.
	(vld3q_dup_bf16): Used new builtin type.
	(vld4_dup_bf16): Used new builtin type.
	(vld4q_dup_bf16): Used new builtin type.

As mentioned in the PR, the generic code decides to put the a variable into
lcomm_section, which is a NOSWITCH section and thus the generic code doesn't
switch into a particular section before using
ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL, on many targets that results just in
.lcomm (or for non-local .comm) directives which don't need a switch to some
section, other targets put switch_to_section (bss_section) at the start of
that macro.
pdp11 doesn't do that (and doesn't have bss_section), and so emits the
lcomm/comm variables in whatever section is current (it has only .text/.data
and for DEC assembler rodata).

The following patch fixes that by putting it always into data section, and
additionally avoids emitting an empty line in the assembly for the lcomm
vars.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR target/94134
	* config/pdp11/pdp11.c (pdp11_asm_output_var): Call switch_to_section
	at the start to switch to data section.  Don't print extra newline if
	.globl directive has not been emitted.

	* gcc.c-torture/execute/pr94134.c: New test.

After IRA changes, atomic version will use one more register, but
non-atomic still use 2 registers, however this testcase isn't testing for
atomic feature, so I decide change the testcase to always use COUNT++
to test.

ChangeLog

gcc/testsuite/

Kito Cheng  <kito.cheng@sifive.com>

	* gcc.target/riscv/interrupt-2.c: Update testcase and expected output.

This avoids breaking the old broken pointer offsetting via
(T)(ptr - ((T)0)->x) which should have used offsetof.  Breakage
was exposed by the introduction of POINTER_DIFF_EXPR and making
PTA not considering that producing a pointer.  The mitigation
for simple cases is to canonicalize

  _2 = _1 - 8B;
  o_9 = (struct obj *) _2;

to

  o_9 = &MEM[_1 + -8B];

eliding one statement and the offending pointer subtraction.

2020-03-11  Richard Biener  <rguenther@suse.de>

	* match.pd ((T *)(ptr - ptr-cst) -> &MEM[ptr + -ptr-cst]):
	New pattern.

	* gcc.dg/torture/20200311-1.c: New testcase.

When using `check-function-bodies`, the subroutine `parse_function_bodies` uses
the `fluff` regexp to remove uninteresting assembly lines.

Arm targets generate assembly with some lines prefixed by `@`, these lines are
left by this process.

As an example of some lines prefixed by `@': the assembly output from the
`stacktest1` function in "bfloat16_simd_3_1.c" is:

        .align  2
        .global stacktest1
        .arch armv8.2-a
        .syntax unified
        .arm
        .fpu neon-fp-armv8
        .type   stacktest1, %function
stacktest1:
        @ args = 0, pretend = 0, frame = 8
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        sub     sp, sp, #8
        add     r3, sp, #6
        vst1.16 {d0[0]}, [r3]
        vld1.16 {d0[0]}, [r3]
        add     sp, sp, #8
        @ sp needed
        bx      lr
        .size   stacktest1, .-stacktest1

It seems that previous uses of `check-function-bodies` in the arm backend have
avoided problems with such lines since they use the `...` regexp in each place
such fluff occurs.

I'm currently writing a patch that I'd like to match the entire function body,
so I'd like to remove such `@` lines automatically.

gcc/testsuite/ChangeLog:

2020-03-11  Matthew Malcomson  <matthew.malcomson@arm.com>

	* lib/scanasm.exp (parse_function_bodies): Lines starting with '@' also
	counted as fluff.

The issue is that tree_is_indexable doesn't return the same result for
a FIELD_DECL with QUAL_UNION_TYPE and the QUAL_UNION_TYPE, resulting
in two instances of the QUAL_UNION_TYPE in the bytecode.  The result
for the type is the correct one (false, since it is variably modified)
while the result for the field is falsely true because:

  else if (TREE_CODE (t) == FIELD_DECL
           && lto_variably_modified_type_p (DECL_CONTEXT (t)))
    return false;

is not satisfied.  The reason for this is that the DECL_QUALIFIER of
fields of a QUAL_UNION_TYPE depends on a discriminant in Ada, which
means that the size of the type does too (CONTAINS_PLACEHOLDER_P),
which in turn means that it is reset to a mere PLACEHOLDER_EXPR by
free_lang_data, which finally means that the size of DECL_CONTEXT is
too, so RETURN_TRUE_IF_VAR is false.

In other words, the CONTAINS_PLACEHOLDER_P property of the DECL_QUALIFIER
of fields of a QUAL_UNION_TYPE hides the variably_modified_type_p property
of  these fields, if you look from the outside.

	PR middle-end/93961
	* tree.c (variably_modified_type_p) <RECORD_TYPE>: Recurse into
	fields whose type is a qualified union.

If the type is derived in the current compilation unit, and Allocate
is not overridden on derivation (as is typically the case with
Root_Storage_Pool_With_Subpools), the entity for Allocate of the
derived type is an alias for System.Storage_Pools.Subpools.Allocate.

The main assertion in gnat_to_gnu_entity fails in this case, since
this is not a definition and Is_Public is false (since the entity
is nested in the same compilation unit).

2020-03-11  Richard Wai  <richard@annexi-strayline.com>

	* gcc-interface/decl.c (gnat_to_gnu_entity): Also test Is_Public on
	the Alias of the entitiy, if is present, in the main assertion.

abs_hwi asserts that the argument is not HOST_WIDE_INT_MIN and as the
(invalid) testcase shows, the function can be called with such an offset.
The following patch is IMHO minimal fix, absu_hwi unlike abs_hwi allows even
that value and will return (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN
in that case.  The function then uses moffset in two spots which wouldn't
care if the value is (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN or
HOST_WIDE_INT_MIN and wouldn't accept it (!moffset and
aarch64_uimm12_shift (moffset)), then in one spot where the signedness of
moffset does matter and using unsigned is the right thing -
moffset < 0x1000000 - and finally has code which will handle even this
value right; the assembler doesn't really care for DImode immediates if
        mov     x1, -9223372036854775808
or
        mov     x1, 9223372036854775808
is used and similarly it doesn't matter if we add or sub it in DImode.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR target/94121
	* config/aarch64/aarch64.c (aarch64_add_offset_1): Use absu_hwi
	instead of abs_hwi, change moffset type to unsigned HOST_WIDE_INT.

	* gcc.dg/pr94121.c: New test.

Jeff has recently fixed dump_histogram_value to use std::abs instead of abs,
because on FreeBSD apparently the ::abs isn't overloaded and only has
int abs (int);
Seems on Solaris /usr/include/iso/stdlib_iso.h abs has:
int abs (int);
long abs (long);
overloads but already not
long long abs (long long);
and there is another abs use in get_nth_most_common_value, also on int64_t.
The long long std::abs (long long); overload is there only in C++11 and we
in GCC10 still support C++98.

Martin has said that a counter should never be INT64_MIN, so IMHO it is
better to use abs_hwi which will assert that.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR bootstrap/93962
	* value-prof.c (dump_histogram_value): Use abs_hwi instead of
	std::abs.
	(get_nth_most_common_value): Use abs_hwi instead of abs.

As e.g. decimal_from_decnumber shows, the REAL_VALUE_TYPE representation
contains a decimal128 embedded in ->sig only if it is rvc_normal, for
other kinds like rvc_inf or rvc_nan, ->sig is ignored and everything is
contained in the REAL_VALUE_TYPE flags (cl, sign, signalling and decimal).
decimal_to_binary which is used when folding a decimal{32,64,128} constant
to a binary floating point type ignores this and thus folds infinities and
NaNs into +0.0.
The following patch fixes that by only doing that for rvc_normal.
Similarly to the binary to decimal folding, it goes through a string, in
order to e.g. deal with canonical NaN mantissas, or binary float formats
that don't support infinities and/or NaNs.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/94111
	* dfp.c (decimal_to_binary): Only use decimal128ToString if from->cl
	is rvc_normal, otherwise use real_to_decimal to print the number to
	string.

	* gcc.dg/dfp/pr94111.c: New test.

As the testcase shows, arithmetics that for -ftrapv would need multiple
basic blocks can show up not just in nb_bytes expressions where we
are calling rewrite_to_non_trapping_overflow for a while already,
but also in the pointer expression to the start of the region.
While the testcase covers just the first hunk and I've failed to create
a testcase for the latter, it is at least in theory possible too, so I've
adjusted that hunk too.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/94114
	* tree-loop-distribution.c (generate_memset_builtin): Call
	rewrite_to_non_trapping_overflow even on mem.
	(generate_memcpy_builtin): Call rewrite_to_non_trapping_overflow even
	on dest and src.

	* gcc.dg/pr94114.c: New test.

... a call to ranges::begin on an input range.

This implements LWG 3286.  The new wording for the single-argument constructor
for subrange is implemented by splitting the constructor into two delegating
constructors, one constrained by _S_store_size and the other by !_S_store_size.

Tested on x86_64-pc-linux-gnu, both added tests fail before the patch and pass
with the patch.

libstdc++-v3/ChangeLog:

	LWG 3286 ranges::size is not required to be valid after a call to
	ranges::begin on an input range
	* include/std/ranges (subrange::subrange): Split single-argument
	constructor into two, one constrained by _S_store_size and another by
	!_S_store_size.
	(take_view::begin): Call size() before calling ranges::begin(_M_base).
	* testsuite/std/ranges/adaptors/lwg3286.cc: New test.
	* testsuite/std/ranges/subrange/lwg3286.cc: New test.

Fix length computation for movsi_insv which resulted in regressions due to out of range branches on the bfin port.

	* config/bfin/bfin.md (movsi_insv): Add length attribute.

This is a bad interaction between sharing a constructor for an array
and stripping its trailing zero-initializers.  Here we reuse a ctor
and then strip its 0s.  This breaks overload resolution in this test:
D can be initialized from {} but not from {0}, so if we truncate the
constructor not to include the zero, the F(D) overload becomes valid
and then we get the ambiguous conversion error.

	PR c++/94124 - wrong conversion error with non-viable overload.
	* decl.c (reshape_init_array_1): Unshare a constructor if we
	stripped trailing zero-initializers.

	* g++.dg/cpp0x/initlist-overload1.C: New test.

My change in r10-4394 to only update clones when we actually instantiate a
deferred noexcept-spec broke this because deferred parsing updates the
primary function but not the clones.  For GCC 10, let's just revert it.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  <jason@redhat.com>

	PR c++/93901
	* pt.c (maybe_instantiate_noexcept): Always update clones.

reshape_init only wants to work on BRACE_ENCLOSED_INITIALIZER_P, i.e. raw
initializer lists, and here was getting a CONSTRUCTOR that had already been
processed for type A<int>.  maybe_aggr_guide should also use that test.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  <jason@redhat.com>

	PR c++/93956
	* pt.c (maybe_aggr_guide): Check BRACE_ENCLOSED_INITIALIZER_P.

PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
relates to max of '-inf' and 'nan'. This regression occur on P9 because
P9 new instruction 'xsmaxcdp' is generated. 
And for C code `a < b ? b : a` is also generated as `xsmaxcdp` under -O2
for P9. While this instruction behavior more like C/C++ semantic (a>b?a:b).

This generates prevents 'xsmaxcdp' to be generated for those cases.
'xsmincdp' also is handled in patch.

gcc/
2020-03-10  Jiufu Guo  <guojiufu@linux.ibm.com>

	PR target/93709
	* gcc/config/rs6000/rs6000.c (rs6000_emit_p9_fp_minmax): Check
	NAN and SIGNED_ZEROR for smax/smin.

gcc/testsuite
2020-03-10  Jiufu Guo  <guojiufu@linux.ibm.com>

	PR target/93709
	* gcc.target/powerpc/p9-minmax-3.c: New test.

These direct uses of _M_current should all be __current() so they are
valid when the base type doesn't satisfy the forward_range concept.

	* include/std/ranges (split_view::_OuterIter::__at_end): Use __current
	instead of _M_current.
	(split_view::_OuterIter::operator++): Likewise.

The patch for 66139 exposed a long-standing bug with
split_nonconstant_init (since 4.7, apparently): initializion of individual
elements of an aggregate are not a full-expressions, but
split_nonconstant_init was making full-expressions out of them.  My fix for
66139 extended the use of split_nonconstant_init, and thus the bug, to
aggregate initialization of temporaries within an expression, in which
context (PR94041) the bug is more noticeable.  PR93922 is a problem with my
implementation strategy of splitting out at gimplification time, introducing
function calls that weren't in the GENERIC.  So I'm going to revert the
patch now and try again for GCC 11.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  <jason@redhat.com>

	PR c++/93922
	PR c++/94041
	PR c++/52320
	PR c++/66139
	* cp-gimplify.c (cp_gimplify_init_expr): Partially revert patch for
	66139: Don't split_nonconstant_init.  Remove pre_p parameter.

PR target/90763
	* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
	clause to handle P9V_BUILTIN_VEC_LXVL with const arguments.

	* gcc.target/powerpc/pr90763.c: New.

Also introduce the _M_i_current() accessors to solve the problem of
access to the private member of _OuterIter from the iter_move and
iter_swap overloads (which are only friends of _InnerIter not
_OuterIter).

	* include/std/ranges (transform_view::_Iterator::__iter_move): Remove.
	(transform_view::_Iterator::operator*): Add noexcept-specifier.
	(transform_view::_Iterator::iter_move): Inline __iter_move body here.
	(split_view::_OuterIter::__current): Add noexcept.
	(split_view::_InnerIter::__iter_swap): Remove.
	(split_view::_InnerIter::__iter_move): Remove.
	(split_view::_InnerIter::_M_i_current): New accessors.
	(split_view::_InnerIter::__at_end): Use _M_i_current().
	(split_view::_InnerIter::operator*): Likewise.
	(split_view::_InnerIter::operator++): Likewise.
	(iter_move(const _InnerIter&)): Likewise.
	(iter_swap(const _InnerIter&, const _InnerIter&)): Likewise.
	* testsuite/std/ranges/adaptors/split.cc: Check noexcept-specifier
	for iter_move and iter_swap on split_view's inner iterator.

Function 'find_simple_exit' is used only from loop-iv.c
In 2004-2006 it was also used in predict.c, but since r118694
(992c31e6) it does not.

gcc/ChangeLog:
	* loop-iv.c (find_simple_exit): Make it static.
	* cfgloop.h: Remove the corresponding prototype.

gcc/ChangeLog:
	* ddg.c (create_ddg): Fix intendation.
	(set_recurrence_length): Likewise.
	(create_ddg_all_sccs): Likewise.

The function needs more than 8 SSE registers, avoid
false positives triggered by SSE spills for 32bit targets.

	* g++.dg/pr80481.C (dg-final): Scan for SSE reg-reg moves only.

This reverts commit d48e1175.

2020-03-10  Jeff Law  <law@redhat.com>

	Revert:
	2020-02-29  Jeff Law  <law@redhat.com>

	* gcc.target/xstormy16/sfr/06_sfrw_to_var.c: Update expected output.

G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.

	PR c++/94117
	* include/std/ranges (ranges::transform_view::_Iterator::iter_move):
	Change expression in noexcept-specifier to match function body.

The 24_iterators/ostream_iterator/1.cc test uses VERIFY and so is
obviously meant to have been run, not just compiled.

	* testsuite/23_containers/unordered_set/allocator/ext_ptr.cc: Add
	comment explaining multiple dg-do directives.
	* testsuite/24_iterators/ostream_iterator/1.cc: Fix do-do directive
	so test is run as well as compiled.

In r10-1938-g460bf043 *testdi_1 has been
changed, so that if the mask has upper 32-bits 0 and then at least one bit
set, it requires CCZmode rather than CCNOmode, because in that case it uses
testl instruction rather than testq and so the SF flag wouldn't respect the
state of the 64-bit result.
The *testqi_ext_3 define_insn_and_split needs to match that though,
otherwise it can create an RTL pattern that used to match *testdi_1 but
doesn't anymore and we'd ICE due to an unrecognizable insn.

2020-03-10  Jakub Jelinek  <jakub@redhat.com>

	PR target/94088
	* config/i386/i386.md (*testqi_ext_3): Call ix86_match_ccmode with
	CCZmode instead of CCNOmode if operands[2] has DImode and pos + len
	is 32.

	* gcc.target/i386/pr94088.c: New test.

	* sv.po: Update.

gcc/ChangeLog
2020-03-09  Jason Merrill  <jason@redhat.com>

	* gdbinit.in (pgs): Fix typo in documentation.

	* da.po: Update.

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create &TARGET_EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper<E>::operator E(&operator~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create &TARGET_EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  <polacek@redhat.com>

	PR c++/92031 - bogus taking address of rvalue error.
	PR c++/91465 - ICE with template codes in check_narrowing.
	PR c++/93870 - wrong error when converting template non-type arg.
	PR c++/94068 - ICE with template codes in check_narrowing.
	* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
	in a template when not ck_identity and we're dealing with a class.
	(convert_like_real) <case ck_ref_bind>: Return IMPLICIT_CONV_EXPR
	in a template if we need a temporary.
	* decl.c (compute_array_index_type_loc): Remove
	instantiate_non_dependent_expr_sfinae call.  Call
	fold_non_dependent_expr instead of maybe_constant_value.
	(build_explicit_specifier): Don't instantiate or create a sentinel
	before converting the expression.
	* except.c (build_noexcept_spec): Likewise.
	* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
	Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
	build_converted_constant_expr returned.
	* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
	of maybe_constant_value.

	* g++.dg/cpp0x/conv-tmpl2.C: New test.
	* g++.dg/cpp0x/conv-tmpl3.C: New test.
	* g++.dg/cpp0x/conv-tmpl4.C: New test.
	* g++.dg/cpp0x/conv-tmpl5.C: New test.
	* g++.dg/cpp0x/conv-tmpl6.C: New test.
	* g++.dg/cpp1z/conv-tmpl1.C: New test.