Here we're treating deeming the non-dependent variable template-id
tag<int> as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR
an empty type, which causes the call to finish_template_variable from
finish_id_expression_1 to be unreachable at template parse time. Thus
we're led into thinking tag<int>.var<void> refers to a dependent name.
This patch fixes this by making finish_id_expression_1 instantiate a
variable template-id as long as it's not dependent according to the
dependence test in lookup_and_finish_template_variable rather than
according to type_dependent_expression_p.
PR c++/108848
gcc/cp/ChangeLog:
* pt.cc (finish_template_variable): Move dependence check
to here from ...
(lookup_and_finish_template_variable): ... here.
* semantics.cc (finish_id_expression_1): Call
finish_template_variable sooner, before (and regardless of) the
type_dependent_expression_p test.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/noexcept1.C: Don't expect a bogus "different
exception specifier" error. Expect a separate "not usable
in a constant expression" error.
* g++.dg/cpp1y/var-templ75.C: New test.
* g++.dg/cpp1y/var-templ76.C: New test.
This is a bug in tree-ssa-uninit.cc.
When doing the following:
/* Ignore the call to .DEFERRED_INIT that define the original
var itself as the following case:
temp = .DEFERRED_INIT (4, 2, “alt_reloc");
alt_reloc = temp;
In order to avoid generating warning for the fake usage
at alt_reloc = temp.
*/
We need to compare the var name inside the .DEFERRED_INIT call
(the 3rd argument) and the name for the LHS variable. if they are the same,
we will NOT report the warning.
There is one issue when we get the name for the LHS variable. when the
variable doesn't have a DECL_NAME (it's not a user declared variable,
which is the case for this bug):
_1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
D.2389 = _1;
The current checking just ignores this case, and still report the warning.
The fix is very simple, when getting the name for the LHS variable, we should
consider this case and come up with the name the same way as we construct the
3rd argument for the call to .DEFERRED_INIT (please refer to the routine
"gimple_add_init_for_auto_var")
PR middle-end/107411
gcc/ChangeLog:
PR middle-end/107411
* gimplify.cc (gimple_add_init_for_auto_var): Use sprintf to replace
xasprintf.
* tree-ssa-uninit.cc (warn_uninit): Handle the case when the
LHS varaible of a .DEFERRED_INIT call doesn't have a DECL_NAME.
gcc/testsuite/ChangeLog:
PR middle-end/107411
* g++.dg/pr107411.C: New test.
In this test, we get a bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer<Tp>::value;
to bool. Then ensure_literal_type_for_constexpr_object thinks the object
isn't literal and an error is reported.
This is another case of the interaction between tf_partial and 'auto',
where the auto was not reduced so the deduction failed. In more detail:
we have
Wrap1<int>()
in the code and we need to perform OR -> fn_type_unification. The targ
list is incomplete, so we do
tsubst_flags_t ecomplain = complain | tf_partial | tf_fndecl_type;
fntype = tsubst (TREE_TYPE (fn), explicit_targs, ecomplain, NULL_TREE);
where TREE_TYPE (fn) is struct integral_constant <T402> (void). Then
we substitute the return type, which results in tsubsting is_pointer_v<int>.
is_pointer_v is a variable template with a placeholder type:
template <class Tp>
constexpr auto is_pointer_v = is_pointer<Tp>::value;
so we find ourselves in lookup_and_finish_template_variable. tf_partial is
still set, so finish_template_variable -> instantiate_template -> tsubst
won't reduce the level of auto. But then we do mark_used which eventually
calls do_auto_deduction which clears tf_partial, because we want to replace
the auto now. But we hadn't reduced auto's level so this fails. And
since we're not in an immediate context, we emit a hard error.
I suppose that when we reach lookup_and_finish_template_variable it's
probably time to clear tf_partial. (I added an assert and our testsuite
doesn't have a test whereby we get to lookup_and_finish_template_variable
while tf_partial is still active.)
PR c++/108550
gcc/cp/ChangeLog:
* pt.cc (lookup_and_finish_template_variable): Clear tf_partial.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ70.C: New test.
* g++.dg/cpp1y/var-templ71.C: New test.
* g++.dg/cpp1y/var-templ72.C: New test.
Since r11-557, cp_finish_decl can call check_initializer even in
a template for a constexpr initializer. That ultimately leads to
convert_for_assignment and check_address_or_pointer_of_packed_member,
where we crash, because it doesn't expect that the CALL_EXPR is
a function object. Q has a constexpr operator(), but since we're
in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just
a VAR_DECL; it hasn't been converted to Q::operator<int>(&q, 0) yet.
I propose to robustify check_address_or_pointer_of_packed_member.
var-templ74.C has an XFAIL, subject to 107939.
I noticed that our -Waddress-of-packed-member tests weren't testing
member functions, added thus. (I was tempted to check
FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.)
PR c++/107938
gcc/c-family/ChangeLog:
* c-warn.cc (check_address_or_pointer_of_packed_member): Check
POINTER_TYPE_P.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ73.C: New test.
* g++.dg/cpp1y/var-templ74.C: New test.
* g++.dg/warn/Waddress-of-packed-member3.C: New test.
While this isn't really a regression, the -fstrict-flex-arrays*
option is new in GCC 13 and so I think we should make -fsanitize=bounds
play with it well from the beginning.
The current behavior is that -fsanitize=bounds considers all trailing
arrays as flexible member-like arrays and both -fsanitize=bounds and
-fsanitize=bounds-strict because of a bug don't even instrument
[0] arrays at all, not as trailing nor when followed by other members.
I think -fstrict-flex-arrays* options can be considered as language
mode changing options, by default flexible member-like arrays are
handled like flexible arrays, but that option can change the set of
the arrays which are treated like that. So, -fsanitize=bounds should
change with that on what is considered acceptable and what isn't.
While -fsanitize=bounds-strict should reject them all always to
continue previous behavior.
The following patch implements that. To support [0] array instrumentation,
I had to change the meaning of the bounds argument to .UBSAN_BOUNDS,
previously it was the TYPE_MAX_VALUE of the domain unless ignore_off_by_one
(used for taking address of the array element rather than accessing it;
in that case 1 is added to the bound argument) and the later lowered checks
were if (index > bound) report_failure ().
The problem with that is that for [0] arrays where (at least for C++)
the max value is all ones, for accesses that condition will be never true;
for addresses of elements it was working (in C++) correctly before.
This patch changes it to add 1 + ignore_off_by_one, so -1 becomes 0 or
1 for &array_ref and changing the lowering to be if (index >= bound)
report_failure (). Furthermore, as C represents the [0] arrays with
NULL TYPE_MAX_VALUE, I treated those like the C++ ones.
2023-02-28 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/108894
gcc/
* ubsan.cc (ubsan_expand_bounds_ifn): Emit index >= bound
comparison rather than index > bound.
* gimple-fold.cc (gimple_fold_call): Use tree_int_cst_lt
rather than tree_int_cst_le for IFN_UBSAN_BOUND comparison.
* doc/invoke.texi (-fsanitize=bounds): Document that whether
flexible array member-like arrays are instrumented or not depends
on -fstrict-flex-arrays* options of strict_flex_array attributes.
(-fsanitize=bounds-strict): Document that flexible array members
are not instrumented.
gcc/c-family/
* c-common.h (c_strict_flex_array_level_of): Declare.
* c-common.cc (c_strict_flex_array_level_of): New function,
moved and renamed from c-decl.cc's strict_flex_array_level_of.
* c-ubsan.cc (ubsan_instrument_bounds): Fix comment typo. For
C check c_strict_flex_array_level_of whether a trailing array
should be treated as flexible member like. Handle C [0] arrays.
Add 1 + index_off_by_one rather than index_off_by_one to bounds
and use tree_int_cst_lt rather than tree_int_cst_le for idx vs.
bounds comparison.
gcc/c/
* c-decl.cc (strict_flex_array_level_of): Move to c-common.cc
and rename to c_strict_flex_array_level_of.
(is_flexible_array_member_p): Adjust caller.
gcc/testsuite/
* gcc.dg/ubsan/bounds-4.c: New test.
* gcc.dg/ubsan/bounds-4a.c: New test.
* gcc.dg/ubsan/bounds-4b.c: New test.
* gcc.dg/ubsan/bounds-4c.c: New test.
* gcc.dg/ubsan/bounds-4d.c: New test.
* g++.dg/ubsan/bounds-1.C: New test.
This implements LWG 3527 which fixes the handling of pair<T&&, U&&> in
std::uses_allocator_construction_args.
libstdc++-v3/ChangeLog:
PR libstdc++/108952
* include/bits/uses_allocator_args.h
(uses_allocator_construction_args): Implement LWG 3527.
* testsuite/20_util/pair/astuple/get-2.cc: New test.
* testsuite/20_util/scoped_allocator/108952.cc: New test.
* testsuite/20_util/uses_allocator/lwg3527.cc: New test.
This avoids overwriting tail padding when algorithms like std::copy are
used to write a single value through a pointer to a base subobject.
The pointer arithmetic on a Base* is valid for N==1, but the copy/move
operation needs to be done using assignment, not a memmove or memcpy of
sizeof(Base) bytes.
Instead of putting a check for N==1 in all of copy, copy_n, move etc.
this adds it to the __copy_move and __copy_move_backward partial
specializations used for trivially copyable types. When N==1 those
partial specializations dispatch to new static member functions of the
partial specializations for non-trivial types, so that a copy/move
assignment is done appropriately for the _IsMove constant.
libstdc++-v3/ChangeLog:
PR libstdc++/108846
* include/bits/stl_algobase.h (__copy_move<false, false, RA>)
Add __assign_one static member function.
(__copy_move<true, false, RA>): Likewise.
(__copy_move<IsMove, true, RA>): Do not use memmove for a single
value.
(__copy_move_backward<IsMove, true, RA>): Likewise.
* testsuite/25_algorithms/copy/108846.cc: New test.
* testsuite/25_algorithms/copy_backward/108846.cc: New test.
* testsuite/25_algorithms/copy_n/108846.cc: New test.
* testsuite/25_algorithms/move/108846.cc: New test.
* testsuite/25_algorithms/move_backward/108846.cc: New test.
For the common case of converting valid text this improves performance
significantly.
libstdc++-v3/ChangeLog:
* src/c++11/codecvt.cc: Add [[likely]] and [[unlikely]]
attributes.
There are no messages about padding for targets that don't
pad, i.e. default_packed. Noticed for cris-elf, verified
for pru-elf at gcc-testresults@.
testsuite:
* gcc.dg/plugin/infoleak-vfio_iommu_type1.c: Don't xfail bogus
message for "default_packed" targets.
As recommended by testsuite maintainer: Regression analysis
works only if the string is the same.
testsuite:
* lib/multiline.exp (handle-multiline-outputs): Shorten
message to the same for fail and pass.
Reacting to a long-standing XPASS for CRIS. This one is
slightly brown paper-bag level; it was never the here-removed
xfailed scan that failed and I didn't notice that XPASS when
reporting success on the commit as a whole. It's not logical to
re-read what was just-written even with overlap issues, and I'm
sure that edit was originally a copy-pasto. I checked
historical m68k-linux and pru-elf test-results too, to verify
that I got that part right.
PR testsuite/91419
* gcc.dg/tree-ssa/pr91091-2.c:15 Remove xfail for RHS.
Reacting to a long-standing XPASS for CRIS. Maybe better do
as https://gcc.gnu.org/PR79356#c11 suggests: xfail it for
x86 only ...except I see m68k also does not xpass.
testsuite:
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Add CRIS to the list
of targets excluding xfail on lines 50 and 51.
For cris-elf before this patch, ever since it was added,
this test gets:
Running /x/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/Wuse-after-free-2.c (test for warnings, line 115)
FAIL: gcc.dg/Wuse-after-free-2.c (test for warnings, line 116)
and comparing tree dumps with a native x86_64-pc-linux-gnu
run shows a suspicious difference in the "180t.ivopts" dump.
Indeed -fno-ivopts makes the warning appear for cris-elf
too. It was suggested to simply add -fno-ivopts to the
test-flags, like before -fno-tree-loop-distribute-patterns
was added; thus.
PR tree-optimization/108828
* gcc.dg/Wuse-after-free-2.c: Add -fno-ivopts.
gcc/fortran/ChangeLog:
PR fortran/108937
* trans-intrinsic.cc (gfc_conv_intrinsic_ibits): Handle corner case
LEN argument of IBITS equal to BITSIZE(I).
gcc/testsuite/ChangeLog:
PR fortran/108937
* gfortran.dg/ibits_2.f90: New test.
According to Intel ISA manual, fprem and fprem1 return NaN when invalid
arithmetic exception is generated. This is documented in Table 8-10 of the
ISA manual and makes these two instructions fully IEEE compatible.
The reverted patch was based on the data from table 3-30 and 3-31 of the
Intel ISA manual, where results in case of st(0) being infinity or
st(1) being 0 are not specified.
2023-02-27 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/108922
Revert:
* config/i386/i386.md (fmodxf3): Enable for flag_finite_math_only only.
(fmod<mode>3): Ditto.
(fpremxf4_i387): Ditto.
(reminderxf3): Ditto.
(reminder<mode>3): Ditto.
(fprem1xf4_i387): Ditto.
In 2011, the rtl.texi documentation was updated to reflect that the
modes of the RTX unary operations FFS, POPCOUNT and PARITY should
match those of their operands. Unfortunately, some of the transformations
in simplify-rtx.cc predate this tightening of RTL semantics, and have
not (until now) been updated/fixed. i.e. The POPCOUNT and PARITY
optimizations were "correct" when I added them back in 2007.
2023-02-27 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* simplify-rtx.cc (simplify_unary_operation_1) <case FFS>: Avoid
generating FFS with mismatched operand and result modes, by using
an explicit SIGN_EXTEND/ZERO_EXTEND.
<case POPCOUNT>: Likewise, for POPCOUNT of ZERO_EXTEND.
<case PARITY>: Likewise, for PARITY of {ZERO,SIGN}_EXTEND.
The pattern parameter to memset is second. Correct an obvious mistake
in libm2pim/sckt.cc.
libgm2/ChangeLog:
PR modula2/108944
* libm2pim/sckt.cc (getLocalIP): Correct parameter order.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
This fixes some header-defined functions that are undesirably declared
static and weren't caught by the "^static inline" pattern used for the
main patch r13-6096-gcb3e0eac262e55.
gcc/ChangeLog:
* hash-table.h (gt_pch_nx(hash_table<D>)): Remove static.
* lra-int.h (lra_change_class): Likewise.
* recog.h (which_op_alt): Likewise.
* sel-sched-ir.h (sel_bb_empty_or_nop_p): Declare inline
instead of static.
This is a complicated API that should be clearly documented.
Also improve the comment on basic_ios::_M_setstate.
libstdc++-v3/ChangeLog:
* include/bits/basic_ios.h (basic_ios::_M_setstate): Add
caveat to comment.
* include/bits/basic_string.h (resize_and_overwrite): Add
doxygen comment.
This patch introduces the use of CLAMPS instruction when the instruction
is configured.
/* example */
int test(int a) {
if (a < -512)
return -512;
if (a > 511)
return 511;
return a;
}
;; prereq: TARGET_CLAMPS
test:
clamps a2, a2, 9
ret.n
gcc/ChangeLog:
* config/xtensa/xtensa-protos.h (xtensa_match_CLAMPS_imms_p):
New prototype.
* config/xtensa/xtensa.cc (xtensa_match_CLAMPS_imms_p):
New function.
* config/xtensa/xtensa.h (TARGET_CLAMPS): New macro definition.
* config/xtensa/xtensa.md (*xtensa_clamps): New insn pattern.
The PCH mechanism first tries to map the .gch file to the virtual memory
space pointed to by TRY_EMPTY_VM_SPACE during the compilation process.
The original value of TRY_EMPTY_VM_SPACE macro is 0x8000000000,
but like la464 only has 40 bits of virtual address space, this value
just exceeds the address range.
If we want to support chips with less than 40 bits virtual addresses,
then the value of this macro needs to be set small. I think setting
this value small will increase the probability of virtual address
mapping failure. And the purpose of pch is to make compilation faster,
but I think we rarely compile on embedded systems. So this situation
may not be within our consideration.
So change the value of this macro to 0x1000000000.
gcc/ChangeLog:
* config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value of
the macro to 0x1000000000.
The projects-pim-run-pass-tower.exp test blocks indefinitely
on some platforms. This patch disables it for now - it should
be enabled once a cross platform fix for RTint.mod is found.
Even disable the trivial execution test.
gcc/testsuite/ChangeLog:
* gm2/projects/pim/run/pass/tower/projects-pim-run-pass-tower.exp:
Also add conditional to gm2-simple-execute.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
The projects-pim-run-pass-tower.exp test blocks indefinitely
on some platforms. This patch disables it for now - it should
be enabled once a cross platform fix for RTint.mod is found.
gcc/testsuite/ChangeLog:
* gm2/projects/pim/run/pass/tower/projects-pim-run-pass-tower.exp
(gm2_run_tower_test): New global variable. Add conditional
before invoking gm2-local-exec.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
This avoids making the associted_dummy field point to a new memory chunk
if it's already pointing somewhere, in which case doing so would leak the
previously allocated chunk.
PR fortran/108923
gcc/fortran/ChangeLog:
* intrinsic.cc (get_intrinsic_dummy_arg,
set_intrinsic_dummy_arg): Rename the former to the latter.
Remove the return value, add a reference to the lhs as argument,
and do the pointer assignment inside the function. Don't do
it if the pointer is already non-NULL.
(sort_actual): Update caller.
I see overlong lines in the output when a test fails, for
example for a bug exposed for cris-elf and pru-elf in
gcc.dg/analyzer/allocation-size-multiline-3.c:
Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern lines 16-25 not found: "\s*int32_t \*ptr = alloca \(99\);[^\n\r]*\n \^~~~~~\n 'test_constant_99': events 1-2[^\n\r]*\n \|[^\n\r]*\n \| int32_t \*ptr = alloca \(99\);[^\n\r]*\n \| \^~~~~~\n \| \|[^\n\r]*\n \| \(1\) allocated 99 bytes here[^\n\r]*\n \| \(2\) assigned to 'int32_t \*' \{aka 'int \*'\} here; 'sizeof \(int32_t \{aka int\}\)' is '4'[^\n\r]*\n \|[^\n\r]*\n"
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern lines 34-43 not found: " int32_t \*ptr = alloca \(n \* 2\);[^\n\r]*\n \^~~~~~\n 'test_symbolic': events 1-2[^\n\r]*\n \|[^\n\r]*\n \| int32_t \*ptr = alloca \(n \* 2\);[^\n\r]*\n \| \^~~~~~\n \| \|[^\n\r]*\n \| \(1\) allocated 'n \* 2' bytes here[^\n\r]*\n \| \(2\) assigned to 'int32_t \*' \{aka 'int \*'\} here; 'sizeof \(int32_t \{aka int\}\)' is '4'[^\n\r]*\n \|[^\n\r]*\n"
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess errors)
That multiline-pattern-quoted-on-a-single-line is redundant
when also outputting "lines 16-25" and "lines 34-43". It's
also so noisy that it can be mistaken for a testsuite error.
If there's a need to inspect it, it can be seen at
verbose-level 4, i.e. persons interested in seeing it
without editing sources can just add "-v -v -v -v".
Let's "prune" the pattern from regular output, instead producing:
Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern lines 16-25 not found
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern lines 34-43 not found
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess errors)
* lib/multiline.exp (handle-multiline-outputs): Don't include the
quoted multiline pattern in the pass/fail output.
gcc/
PR target/108919
* config/xtensa/xtensa-protos.h
(xtensa_prepare_expand_call): Rename to xtensa_expand_call.
* config/xtensa/xtensa.cc (xtensa_prepare_expand_call): Rename
to xtensa_expand_call.
(xtensa_expand_call): Emit the call and add a clobber expression
for the static chain to it in case of windowed ABI.
* config/xtensa/xtensa.md (call, call_value, sibcall)
(sibcall_value): Call xtensa_expand_call and complete expansion
right after that call.
gcc/testsuite/
* gcc.target/xtensa/pr108919.c: New test.
When the dummy argument of the bind(C) proc is 'pointer, intent(out)', the conversion
of the GFC to the CFI bounds can be skipped: it is not needed and avoids issues with
noninit memory.
Note that the 'cfi->base_addr = gfc->addr' assignment is kept as the C code of a user
might assume that a nullified pointer arrives as NULL (or even a specific value).
For instance, gfortran.dg/c-interop/section-{1,2}.f90 assumes the value NULL.
Note 2: The PR is about a may-be-uninitialized warning with intent(out). In the PR's
testcase, the pointer was nullified and should not have produced that warning.
That is a diagnostic issue, now tracked as PR middle-end/108906 as the issue in principle
still exists (e.g. with 'intent(inout)'). [But no longer for intent(out).]
Note 3: With undefined pointers and no 'intent', accessing uninit memory is unavoidable
on the caller side as the compiler cannot know what the C function does (but this usage
determines whether the pointer is permitted be undefined or whether the bounds must be
gfc-to-cfi converted).
gcc/fortran/ChangeLog:
PR fortran/108621
* trans-expr.cc (gfc_conv_gfc_desc_to_cfi_desc): Skip setting of
bounds of CFI desc for 'pointer,intent(out)'.
gcc/testsuite/ChangeLog:
PR fortran/108621
* gfortran.dg/c-interop/fc-descriptor-pr108621.f90: New test.
Add the rest of the weak-*.f90 testcases.
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_finish_var_decl): Apply attribute.
(generate_local_decl): Add diagnostic for dummy and local variables.
gcc/testsuite/ChangeLog:
* gfortran.dg/weak-2.f90: New test.
* gfortran.dg/weak-3.f90: New test.
Signed-off-by: Rimvydas Jasinskas <rimvydas.jas@gmail.com>
This fixes a memory leak by accompanying the release of
gfc_actual_arglist elements' memory with a release of the
associated_dummy field memory (if allocated).
Actual argument copy is adjusted as well so that each copy can free
its field independently.
PR fortran/108923
gcc/fortran/ChangeLog:
* expr.cc (gfc_free_actual_arglist): Free associated_dummy
memory.
(gfc_copy_actual_arglist): Make a copy of the associated_dummy
field if it is set in the original element.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
PR libstdc++/108856
* include/experimental/bits/simd_builtin.h
(_SimdImplBuiltin::_S_masked_unary): More efficient
implementation of masked inc-/decrement for integers and floats
without AVX2.
* include/experimental/bits/simd_x86.h
(_SimdImplX86::_S_masked_unary): New. Use AVX512 masked subtract
builtins for masked inc-/decrement.
The following avoids default-initializing auto_vec storage for
non-POD T since that's not what the allocated storage fallback
will do and it's also not expected for existing cases like
auto_vec<std::pair<unsigned, unsigned>, 64> elts;
which exist to optimize the allocation.
It also fixes the array accesses done by vec<vl_embed> to not
use its own m_vecdata member but instead access the container
provided storage via pointer arithmetic.
* vec.h (vec<T, A, vl_embed>::m_vecdata): Remove.
(vec<T, A, vl_embed>::m_vecpfx): Align as T to avoid
changing alignment of vec<T, A, vl_embed> and simplifying
address.
(vec<T, A, vl_embed>::address): Compute as this + 1.
(vec<T, A, vl_embed>::embedded_size): Use sizeof the
vector instead of the offset of the m_vecdata member.
(auto_vec<T, N>::m_data): Turn storage into
uninitialized unsigned char.
(auto_vec<T, N>::auto_vec): Allow allocation of one
stack member. Initialize m_vec in a special way to
avoid later stringop overflow diagnostics.
* vec.cc (test_auto_alias): New.
(vec_cc_tests): Call it.
