The function declarations were updated to use `const scope', but the
static asserts were not.
Reviewed-on: https://github.com/dlang/druntime/pull/3470
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime 98c6ff0c.
Addresses the following clang warning:
gcc/tree-ssa-dom.c:652:33: warning: private field 'm_simplifier' is not used [-Wunused-private-field]
gcc/ChangeLog:
* tree-ssa-dom.c: Remove m_simplifier.
In preparation of PR99928 patch review, I've prepared testcases with clauses
that need more interesting handling on combined/composite constructs,
in particular firstprivate, lastprivate, firstprivate+lastprivate, linear
(explicit on non-iv, explicit on simd iv, implicit on simd iv, implicit on
simd iv declared in the construct), reduction (scalars, array sections of
array variables, array sections with pointer bases) and in_reduction.
OpenMP 5.0 had the wording broken for reduction, the intended rule to use
map(tofrom:) on target when combined with it was bound only on inscan modifier
presence which makes no sense, as then inscan may not be used, this has
been fixed in 5.1 and I'm just assuming 5.1 wording for that.
There are various cases where e.g. from historical or optimization reasons
GCC slightly deviates from the rules, but in most cases it is something
that shouldn't be really observable, e.g. whether
#pragma omp parallel for firstprivate(x)
is handled as
#pragma omp parallel shared(x)
#pragma omp for firstprivate(x)
or
#pragma omp parallel firstprivate(x)
#pragma omp for
shouldn't be possible to distinguish in user code. I've added FIXMEs
in the testcases about that, but maybe we just should keep it as is
(alternative would be to do it in standard compliant way and transform
into whatever we like after gimplification (e.g. early during omplower)).
Some cases we for historical reasons implement even with clauses on
constructs which in the standard don't accept them that way and then
handling those magically in omp lowering/expansion, in particular e.g.
#pragma omp parallel for firstprivate(x) lastprivate(x)
we treat as
#pragma omp parallel firstprivate(x) lastprivate(x)
#pragma omp for
even when lastprivate is not valid on parallel. Maybe one day we
could change that if we make sure we don't regress generated code quality.
I've also found a bug in OpenMP 5.0/5.1,
#pragma omp parallel sections firstprivate(x) lastprivate(x)
incorrectly says that it should be handled as
#pragma omp parallel firstprivate(x)
#pragma omp sections lastprivate(x)
which when written that way results in error; filed as
https://github.com/OpenMP/spec/issues/2758
to be fixed in OpenMP 5.2. GCC handles it the way it used to do
and users expect, so nothing to fix on the GCC side.
Also, we don't support yet in_reduction clause on target construct,
which means the -11.c testcase can't include any tests about in_reduction
handling on all the composite constructs that include target.
The work found two kinds of bugs on the GCC side, one is the known thing
that we implement still the 4.5 behavior and don't mark for
lastprivate/linear/reduction the list item as map(tofrom:) as mentioned
in PR99928. These cases are xfailed in the tests.
And another one is with r21 and r28 in -{8,9,10}.c tests - we don't add
reduction clause on teams for
#pragma omp {target ,}teams distribute simd reduction(+:r)
even when the spec says that teams shouldn't receive reduction only
when combined with loop construct.
In
make check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} gomp.exp=pr99928*'
testing this shows:
# of expected passes 5648
# of expected failures 872
and with Tobias' patch applied:
# of expected passes 5648
# of unexpected successes 384
# of expected failures 488
2021-05-13 Jakub Jelinek <jakub@redhat.com>
PR middle-end/99928
* c-c++-common/gomp/pr99928-1.c: New test.
* c-c++-common/gomp/pr99928-2.c: New test.
* c-c++-common/gomp/pr99928-3.c: New test.
* c-c++-common/gomp/pr99928-4.c: New test.
* c-c++-common/gomp/pr99928-5.c: New test.
* c-c++-common/gomp/pr99928-6.c: New test.
* c-c++-common/gomp/pr99928-7.c: New test.
* c-c++-common/gomp/pr99928-8.c: New test.
* c-c++-common/gomp/pr99928-9.c: New test.
* c-c++-common/gomp/pr99928-10.c: New test.
* c-c++-common/gomp/pr99928-11.c: New test.
Fix a warning when building on machines that don't have 32-bit pointers
gcc/testsuite:
PR target/100563
* gcc.dg/pr100563.c (dg-options): Add -wno-pointer-to-int-cast.
contrib/ChangeLog:
* mklog.py: Put PR entries before all ChangeLog entries
(will be added to all ChangeLog locations by Daily bump script).
* test_mklog.py: Test the new behavior.
Normally we expect the gimple optimizers to fold away comparisons that
are always true, but at some lower optimization levels this is not
always the case, so the back-end has to be able to generate correct
code in these cases.
In this example, we have a comparison of the form
(unsigned long long) op <= ~0ULL
which, of course is always true.
Normally, in the arm back-end we handle these expansions where the
immediate cannot be handled directly by adding 1 to the constant and
then adjusting the comparison operator:
(unsigned long long) op < CONST + 1
but we cannot do that when the constant is already the largest value.
Fortunately, we observe that the comparisons we need to handle this
way are either always true or always false, so instead of forming a
comparison against the maximum value, we can replace it with a
comparison against the minimum value (which just happens to also be a
constant we can handle. So
op1 <= ~0ULL -> op1 >= 0U
op1 > ~0ULL -> op1 < 0U
op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1)
op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1)
gcc:
PR target/100563
* config/arm/arm.c (arm_canonicalize_comparison): Correctly
canonicalize DImode inequality comparisons against the
maximum integral value.
gcc/testsuite:
* gcc.dg/pr100563.c: New test.
As mentioned in the PR, we don't support arithmetic right V2DImode or
V4DImode on x86 without -mavx512vl or -mxop. The ISAs indeed don't have
{,v}psraq instructions until AVX512VL, but we actually can emulate it quite
easily.
One case is arithmetic >> 63, we can just emit {,v}pxor; {,v}pcmpgt for
that for SSE4.2+, or for SSE2 psrad $31; pshufd $0xf5.
Then arithmetic >> by constant > 32, that can be done with {,v}psrad $31
and {,v}psrad $(cst-32) and two operand permutation,
arithmetic >> 32 can be done as {,v}psrad $31 and permutation of that
and the original operand. Arithmetic >> by constant < 32 can be done
as {,v}psrad $cst and {,v}psrlq $cst and two operand permutation.
And arithmetic >> by variable scalar amount can be done as
arithmetic >> 63, logical >> by the amount, << by (64 - amount of the
>> 63 result; note that the vector << 64 result in 0) and oring together.
I had to improve the permutation generation so that it actually handles
the needed permutations (or handles them better).
2021-05-13 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/98856
* config/i386/i386.c (ix86_shift_rotate_cost): Add CODE argument.
Expect V2DI and V4DI arithmetic right shifts to be emulated.
(ix86_rtx_costs, ix86_add_stmt_cost): Adjust ix86_shift_rotate_cost
caller.
* config/i386/i386-expand.c (expand_vec_perm_2perm_interleave,
expand_vec_perm_2perm_pblendv): New functions.
(ix86_expand_vec_perm_const_1): Use them.
* config/i386/sse.md (ashr<mode>3<mask_name>): Rename to ...
(<mask_codefor>ashr<mode>3<mask_name>): ... this.
(ashr<mode>3): New define_expand with VI248_AVX512BW iterator.
(ashrv4di3): New define_expand.
(ashrv2di3): Change condition to TARGET_SSE2, handle !TARGET_XOP
and !TARGET_AVX512VL expansion.
* gcc.target/i386/sse2-psraq-1.c: New test.
* gcc.target/i386/sse4_2-psraq-1.c: New test.
* gcc.target/i386/avx-psraq-1.c: New test.
* gcc.target/i386/avx2-psraq-1.c: New test.
* gcc.target/i386/avx-pr82370.c: Adjust expected number of vpsrad
instructions.
* gcc.target/i386/avx2-pr82370.c: Likewise.
* gcc.target/i386/avx512f-pr82370.c: Likewise.
* gcc.target/i386/avx512bw-pr82370.c: Likewise.
* gcc.dg/torture/vshuf-4.inc: Add two further permutations.
* gcc.dg/torture/vshuf-8.inc: Likewise.
ix86_expand_sse_movcc has special TARGET_XOP handling and the recent
addition of support of v*cond* patterns for V2SFmode results in
ICEs because the expected pattern doesn't exist. We can handle it
using 128-bit vpcmov (if we ignore the upper 64 bits like we ignore in
other TARGET_MMX_WITH_SSE support).
2021-05-13 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/100581
* config/i386/i386-expand.c (ix86_expand_sse_movcc): Force mode
sizes < 16 to a register when constructing vpcmov pattern.
* config/i386/mmx.md (*xop_pcmov_<mode>): Use MMXMODE124 mode.
gcc/testsuite/
PR target/100581
* g++.target/i386/pr100581.C: New test.
gcc/ChangeLog:
* gcov-io.c (gcov_write_block): Remove.
(gcov_write_words): Likewise.
(gcov_read_words): Re-implement using gcov_read_bytes.
(gcov_allocate): Remove.
(GCOV_BLOCK_SIZE): Likewise.
(struct gcov_var): Remove most of the fields.
(gcov_position): Implement with ftell.
(gcov_rewrite): Remove setting of start and offset fields.
(from_file): Re-format.
(gcov_open): Remove setbuf call. It should not be needed.
(gcov_close): Remove internal buffer handling.
(gcov_magic): Use __builtin_bswap32.
(gcov_write_counter): Use directly gcov_write_unsigned.
(gcov_write_string): Use direct fwrite and do not round
to 4 bytes.
(gcov_seek): Use directly fseek.
(gcov_write_tag): Use gcov_write_unsigned directly.
(gcov_write_length): Likewise.
(gcov_write_tag_length): Likewise.
(gcov_read_bytes): Use directly fread.
(gcov_read_unsigned): Use gcov_read_words.
(gcov_read_counter): Likewise.
(gcov_read_string): Use gcov_read_bytes.
* gcov-io.h (GCOV_WORD_SIZE): Adjust to reflect
that size is not in bytes, but words (4B).
(GCOV_TAG_FUNCTION_LENGTH): Likewise.
(GCOV_TAG_ARCS_LENGTH): Likewise.
(GCOV_TAG_ARCS_NUM): Likewise.
(GCOV_TAG_COUNTER_LENGTH): Likewise.
(GCOV_TAG_COUNTER_NUM): Likewise.
(GCOV_TAG_SUMMARY_LENGTH): Likewise.
libgcc/ChangeLog:
* libgcov-driver.c: Fix GNU coding style.
default_zero_call_used_regs currently requires all potentially zeroed
registers to offer a move opcode that accepts zero as an operand.
This is not the case e.g. for ARM's r12/ip in Thumb mode, and it was
not the case of FP registers on AArch64 as of GCC 10.
This patch introduces a fallback strategy to zero out registers,
copying from registers that have already been zeroed. Adjacent
sources to make up wider modes are also supported.
This does not guarantee that there will be some zeroed-out register to
use as the source, but it expands the cases in which the default
implementation works out of the box.
for gcc/ChangeLog
* targhooks.c (default_zero_call_used_regs): Retry using
successfully-zeroed registers as sources.
gcc/ChangeLog:
* omp-low.c (finish_taskreg_scan): Use the proper detach decl.
libgomp/ChangeLog:
* testsuite/libgomp.c-c++-common/task-detach-12.c: New test.
* testsuite/libgomp.fortran/task-detach-12.f90: New test.
The previous changes to irange::constant_p return TRUE for
VARYING, since VARYING has numerical end points like any other
constant range. The problem is that some users of constant_p
depended on constant_p excluding the full domain. The
range handler for __builtin_clz, that is shared between ranger
and vr_values, is one such user.
This patch excludes varying_p(), to match the original behavior
for clz.
gcc/ChangeLog:
PR c/100521
* gimple-range.cc (range_of_builtin_call): Skip out on
processing __builtin_clz when varying.
This warning is of questionable value when it's emitted when
instantiating a template, as in the following testcase. It could be
silenced by writing hb(i) << 1 instead of 2 * hb(i) but that's
unnecessary obfuscation.
gcc/cp/ChangeLog:
* pt.c (tsubst_copy_and_build): Add warn_int_in_bool_context
sentinel.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wint-in-bool-context-2.C: New test.
Add nvptx option -mptx that sets the ptx ISA version. This is currently
hardcoded to 3.1.
Tested libgomp on x86_64-linux with nvptx accelerator, both with default set to
3.1 and 6.3.
gcc/ChangeLog:
2021-05-12 Tom de Vries <tdevries@suse.de>
PR target/96005
* config/nvptx/nvptx-opts.h (enum ptx_version): New enum.
* config/nvptx/nvptx.c (nvptx_file_start): Print .version according
to ptx_version_option.
* config/nvptx/nvptx.h (TARGET_PTX_6_3): Define.
* config/nvptx/nvptx.md (define_insn "nvptx_shuffle<mode>")
(define_insn "nvptx_vote_ballot"): Use sync variant for
TARGET_PTX_6_3.
* config/nvptx/nvptx.opt (ptx_version): Add enum.
(mptx): Add option.
* doc/invoke.texi (Nvidia PTX Options): Add mptx item.
This amends the fix for PR100053 where I failed to amend all edge
tests in dominated_by_p_w_unex.
2021-05-12 Richard Biener <rguenther@suse.de>
PR tree-optimization/100566
* tree-ssa-sccvn.c (dominated_by_p_w_unex): Properly handle
allow_back for all edge queries.
* gcc.dg/torture/pr100566.c: New testcase.
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/pstl/alg_nonmodifying/find_end.cc:
Increase dg-timeout-factor to 4. Fix -Wunused-parameter
warnings. Replace bitwise AND with logical AND in loop
condition.
* testsuite/25_algorithms/pstl/alg_nonmodifying/search_n.cc:
Replace bitwise AND with logical AND in loop condition.
* testsuite/util/pstl/test_utils.h: Remove unused parameter
names.
If a header doesn't end with a new-line, with -fdirectives-only we right now
preprocess it as
int i = 1;# 2 "pr100392.c" 2
i.e. the line directive isn't on the next line, which means we fail to parse
it when compiling.
GCC 10 and earlier libcpp/directives-only.c had for this:
if (!pfile->state.skipping && cur != base)
{
/* If the file was not newline terminated, add rlimit, which is
guaranteed to point to a newline, to the end of our range. */
if (cur[-1] != '\n')
{
cur++;
CPP_INCREMENT_LINE (pfile, 0);
lines++;
}
cb->print_lines (lines, base, cur - base);
}
and we have the assertion
/* Files always end in a newline or carriage return. We rely on this for
character peeking safety. */
gcc_assert (buffer->rlimit[0] == '\n' || buffer->rlimit[0] == '\r');
So, this patch just does readd the more less same thing, so that we emit
a newline after the inline even when it wasn't there before.
2021-05-12 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/100392
* lex.c (cpp_directive_only_process): If buffer doesn't end with '\n',
add buffer->rlimit[0] character to the printed range and
CPP_INCREMENT_LINE and increment line_count.
* gcc.dg/cpp/pr100392.c: New test.
* gcc.dg/cpp/pr100392.h: New file.
Silents the following warning:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
gcc/testsuite/ChangeLog:
* lib/lto.exp: When running tests without jobserver, one can see
the following warning for tests that use 1to1 partitioning.
This splits can_associate_p into checks for SSA defs and checks
for the type so it can be called from is_reassociable_op to
catch cases not catched by the earlier fix.
2021-05-11 Richard Biener <rguenther@suse.de>
PR tree-optimization/100519
* tree-ssa-reassoc.c (can_associate_p): Split into...
(can_associate_op_p): ... this
(can_associate_type_p): ... and this.
(is_reassociable_op): Call can_associate_op_p.
(break_up_subtract_bb): Call the appropriate predicates.
(reassociate_bb): Likewise.
* gcc.dg/torture/pr100519.c: New testcase.
Size_In_Slots uses the Nkind to look up the size in a table indexed
by Nkind. This patch fixes a couple of places where the Nkind is
wrong (uninitialized or zeroed out) so Size_In_Slots cannot be used.
gcc/ada/
PR ada/100564
* atree.adb (Change_Node): Do not call Zero_Slots on a Node_Id
when the Nkind has not yet been set; call the other Zero_Slots
that takes a range of slot offsets. Call the new Mutate_Kind
that takes an Old_Size, for the same reason -- the size cannot
be computed without the Nkind.
(Mutate_Nkind): New function that allows specifying the Old_Size.
(Size_In_Slots): Assert that the Nkind has proper (nonzero) value.
* atree.ads: Minor reformatting.
gcc/ChangeLog:
* lto-wrapper.c (print_lto_docs_link): New function.
(run_gcc): Print warning about missing job server detection
after we know NR of partitions. Do the same for -flto{,=1}.
* opts.c (get_option_html_page): Support -flto option.
In this testcase the compile unit consists of a single
text section with a single embedded DECL_IGNORED_P function.
So we have a kind of multi-range text section here.
To avoid an ICE in output_rnglists we need to make sure
that have_multiple_function_sections is set to true.
This is a regression from
e69ac02037 ("Add line debug info for virtual thunks")
2021-05-12 Bernd Edlinger <bernd.edlinger@hotmail.de>
PR debug/100515
* dwarf2out.c (dwarf2out_finish): Set
have_multiple_function_sections with multi-range text_section.
* gcc.dg/debug/dwarf2/pr100515.c: New testcase.
This makes the rtvec_alloc argument size_t catching overflow and
truncated arguments (from "invalid" testcases), verifying the
argument against INT_MAX which is the limit set by the int
typed rtvec_def.num_elem member.
2021-05-12 Richard Biener <rguenther@suse.de>
PR middle-end/100547
* rtl.h (rtvec_alloc): Make argument size_t.
* rtl.c (rtvec_alloc): Verify the count is less than INT_MAX.
The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear
in multiple functions.
Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again
can be reused in multiple functions.
Neither of that is a major problem, DEBUG_EXPRs are just magic value holders
and what value they stand for is independent in each function and driven by
what debug stmts or DEBUG_INSNs they are bound to.
Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode
or some vector mode depending on whether current function's enabled ISAs
support that vector mode or not. On the following testcase, we expand it
first in foo function without AVX2 enabled and so the DEBUG_EXPR is
BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with
AVX2 enabled and expansion ICEs because of a mode mismatch.
The following patch fixes that by forcing recreation of a DEBUG_EXPR if
there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs
will be still reused in between functions otherwise and within the same
function the mode should be always the same.
2021-05-12 Jakub Jelinek <jakub@redhat.com>
PR middle-end/100508
* cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector
type, don't reuse DECL_RTL if it has different mode, instead force
creation of a new DEBUG_EXPR.
* gcc.dg/gomp/pr100508.c: New test.
> Somewhere in RTL (_M_value&1)==_M_value is turned into (_M_value&-2)==0,
> that could be worth doing already in GIMPLE.
Apparently it is
/* Simplify eq/ne (and/ior x y) x/y) for targets with a BICS instruction or
constant folding if x/y is a constant. */
if ((code == EQ || code == NE)
&& (op0code == AND || op0code == IOR)
&& !side_effects_p (op1)
&& op1 != CONST0_RTX (cmp_mode))
{
/* Both (eq/ne (and x y) x) and (eq/ne (ior x y) y) simplify to
(eq/ne (and (not y) x) 0). */
...
/* Both (eq/ne (and x y) y) and (eq/ne (ior x y) x) simplify to
(eq/ne (and (not x) y) 0). */
Yes, doing that on GIMPLE for the case where the not argument is constant
would simplify the phiopt follow-up (it would be single imm use then).
On Thu, May 06, 2021 at 09:42:41PM +0200, Marc Glisse wrote:
> We can probably do it in 2 steps, first something like
>
> (for cmp (eq ne)
> (simplify
> (cmp (bit_and:c @0 @1) @0)
> (cmp (@0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); })))
>
> to get rid of the double use, and then simplify X&C==0 to X<=~C if C is a
> mask 111...000 (I thought we already had a function to detect such masks, or
> the 000...111, but I can't find them anymore).
Ok, here is the first step then.
2021-05-12 Jakub Jelinek <jakub@redhat.com>
Marc Glisse <marc.glisse@inria.fr>
PR tree-optimization/94589
* match.pd ((X & Y) == X -> (X & ~Y) == 0,
(X | Y) == Y -> (X & ~Y) == 0): New GIMPLE simplifications.
* gcc.dg/tree-ssa/pr94589-1.c: New test.
C2X adds #elifdef and #elifndef preprocessor directives; these have
also been proposed for C++. Implement these directives in libcpp
accordingly.
In this implementation, #elifdef and #elifndef are treated as
non-directives for any language version other than c2x and gnu2x (if
the feature is accepted for C++, it can trivially be enabled for
relevant C++ versions). In strict conformance modes for prior
language versions, this is required, as illustrated by the
c11-elifdef-1.c test added.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
libcpp/
* include/cpplib.h (struct cpp_options): Add elifdef.
* init.c (struct lang_flags): Add elifdef.
(lang_defaults): Update to include elifdef initializers.
(cpp_set_lang): Set elifdef for pfile based on language.
* directives.c (STDC2X, ELIFDEF): New macros.
(EXTENSION): Increase value to 3.
(DIRECTIVE_TABLE): Add #elifdef and #elifndef.
(_cpp_handle_directive): Do not treat ELIFDEF directives as
directives for language versions without the #elifdef feature.
(do_elif): Handle #elifdef and #elifndef.
(do_elifdef, do_elifndef): New functions.
gcc/testsuite/
* gcc.dg/cpp/c11-elifdef-1.c, gcc.dg/cpp/c2x-elifdef-1.c,
gcc.dg/cpp/c2x-elifdef-2.c: New tests.
Resolves:
PR middle-end/21433 - The COMPONENT_REF case of expand_expr_real_1 is probably wrong
gcc/ChangeLog:
PR middle-end/21433
* expr.c (expand_expr_real_1): Replace unreachable code with an assert.
The libcpp function cpp_avoid_paste is used to insert whitespace in
preprocessed output where needed to avoid two consecutive
preprocessing tokens, that logically (e.g. when stringized) do not
have whitespace between them, from being incorrectly lexed as one when
the preprocessed input is reread by a compiler.
This fails to allow for digit separators, so meaning that invalid
code, that has a CPP_NUMBER (from a macro expansion) followed by a
character literal, can result in preprocessed output with a valid use
of digit separators, so that required syntax errors do not occur when
compiling with -save-temps. Fix this by handling that case in
cpp_avoid_paste (as with other cases in cpp_avoid_paste, this doesn't
try to check whether the language version in use supports digit
separators; it's always OK to have unnecessary whitespace in
preprocessed output).
Note: there are other cases, with various kinds of wide character or
string literal following a CPP_NUMBER, where spurious pasting of
preprocessing tokens can occur but the sequence of tokens remains
invalid both before and after that pasting. Maybe cpp_avoid_paste
should also handle those cases (and similar cases after a CPP_NAME),
to ensure the sequence of preprocessing tokens in preprocessed output
is exactly right, whether or not it affects whether syntax errors
occur. This patch only addresses the case with digit separators where
invalid code can fail to be diagnosed without the space inserted.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
libcpp/
* lex.c (cpp_avoid_paste): Do not allow pasting CPP_NUMBER with
CPP_CHAR.
gcc/testsuite/
* g++.dg/cpp1y/digit-sep-paste.C, gcc.dg/c2x-digit-separators-3.c:
New tests.
