I've observed an LTO wrong-code bug with a large testcase in GCC 12,
that results from TYPE_TYPELESS_STORAGE not being set consistently on
type variants.

Specifically, in the LTO stage of compilation, there is an aggregate
type passed to get_alias_set, whose TYPE_MAIN_VARIANT does not have
TYPE_TYPELESS_STORAGE set.  However, the TYPE_CANONICAL of that main
variant *does* have have TYPE_TYPELESS_STORAGE set; note that the use
of TYPE_CANONICAL in get_alias_set comes after the check of
TYPE_TYPELESS_STORAGE.  The effect is that when (one-argument)
record_component_aliases is called, the recursive call to
get_alias_set gives alias set 0, and the aggregate type ends up not
being considered to alias its members, with wrong-code consequences.

I haven't managed to produce a self-contained executable testcase to
demonstrate this, but it clearly seems appropriate for
TYPE_TYPELESS_STORAGE to be consistent on type variants, so this patch
makes it so, which appears to be sufficient to resolve the bug.  I've
attached a reduced test to
<https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614278.html>
that does at least demonstrate main-variant versions of a type (SB in
this test) being written out to LTO IR both with and without
TYPE_TYPELESS_STORAGE, although not the subsequent consequences of a
type without TYPE_TYPELESS_STORAGE with a TYPE_CANONICAL (as
constructed after LTO type merging) with TYPE_TYPELESS_STORAGE and
following wrong-code.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

	* stor-layout.cc (finalize_type_size): Copy TYPE_TYPELESS_STORAGE
	to variants.

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>

libstdc++-v3/ChangeLog:

	* include/experimental/bits/simd_x86.h
	(_SimdImplX86::_S_divides): Replace test for __GCC_IEC_559 == 0
	with __RECIPROCAL_MATH__.

Clang ICEs on _SimdImplX86::_S_divides. The function is only working
around a missed optimization and not necessary for correctness.
Therefore, don't use it for Clang.

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>

libstdc++-v3/ChangeLog:

	* include/experimental/bits/simd_detail.h: Don't define
	_GLIBCXX_SIMD_WORKAROUND_PR90993 for Clang.
	* include/experimental/bits/simd_x86.h (_S_divides): Remove
	check for __clang__.

gcc/fortran/ChangeLog:

	PR fortran/99036
	* decl.cc (gfc_match_modproc): Reject MODULE PROCEDURE if not in a
	generic module interface.

gcc/testsuite/ChangeLog:

	PR fortran/99036
	* gfortran.dg/pr99036.f90: New test.

Clang fails to compile some constant expressions involving simd.
Therefore, just disable this non-conforming extension for clang.

Fix AVX512 blend implementation for Clang. It was converting the bitmask
to bool before, which is obviously wrong. Instead use a Clang builtin to
convert the bitmask to vector-mask before using a vector blend ?:. A
similar change is required for the masked unary implementation, because
the GCC builtins do not exist on Clang.

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>

libstdc++-v3/ChangeLog:

	* include/experimental/bits/simd_detail.h: Don't declare the
	simd API as constexpr with Clang.
	* include/experimental/bits/simd_x86.h (__movm): New.
	(_S_blend_avx512): Resolve FIXME. Implement blend using __movm
	and ?:.
	(_SimdImplX86::_S_masked_unary): Clang does not implement the
	same builtins. Implement the function using __movm, ?:, and -
	operators on vector_size types instead.

When parsing a default member init we just build a CONVERT_EXPR for
converting to a virtual base, and then expand that into the more complex
form when we actually use the DMI in a constructor.  But that wasn't working
for the template case where we are considering the conversion at the point
that the constructor needs the DMI instantiation, so it seemed like we were
in a constructor already.  And then when the other constructor tries to
reuse the instantiation, it sees uses of the first constructor's parameters,
and dies.  So ensure that we get the CONVERT_EXPR in this case, too.

	PR c++/106890

gcc/cp/ChangeLog:

	* init.cc (maybe_instantiate_nsdmi_init): Don't leave
	current_function_decl set to a constructor.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/nsdmi-template25.C: New test.

We currently allow VARYING lhs GORI calculations to continue if there is
a relation present in the hope it will eventually better refine a result.
This adds a check that the relation is relevant to the outgoing range
calculation first.  If it is not relevant, stop calculating.

	PR tree-optimization/109192
	* gimple-range-gori.cc (gori_compute::compute_operand_range):
	Terminate gori calculations if a relation is not relevant.
	* value-relation.h (value_relation::set_relation): Allow
	equality between op1 and op2 if they are the same.

The following avoids looking at STMT_SLP_TYPE apart from the only
place needing it - transform and analysis of non-SLP loop stmts.
In particular it doesn't have a reliable meaning on SLP representatives
which are also passed as stmt_vinfo to vectorizable_* routines.  The
proper way to check in those is to look for the slp_node argument
instead.

	PR tree-optimization/109219
	* tree-vect-loop.cc (vectorizable_reduction): Check
	slp_node, not STMT_SLP_TYPE.
	* tree-vect-stmts.cc (vectorizable_condition): Likewise.
	* tree-vect-slp.cc (vect_slp_analyze_node_operations_1):
	Remove assertion on STMT_SLP_TYPE.

	* gcc.dg/torture/pr109219.c: New testcase.

On Tue, Mar 21, 2023 at 12:35:19PM +0000, Andrew Stubbs wrote:
> >   /* Ensure the the in-branch simd clones are used on targets that support them.
> >      Some targets use another call for the epilogue loops.  */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 2 "vect" { target { ! aarch64*-*-* } } } } */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 3 "vect" { target aarch64*-*-* } } } */
> > +/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 2 "vect" } } */
>
> I suppose those comments are now obsolete.

Oops, fixed thusly.

2023-03-21  Jakub Jelinek  <jakub@redhat.com>

	PR testsuite/108898
	* gcc.dg/vect/vect-simd-clone-16.c: Remove parts of comment mentioning
	epilogue loops.
	* gcc.dg/vect/vect-simd-clone-17.c: Likewise.
	* gcc.dg/vect/vect-simd-clone-18.c: Likewise.

As mentioned in the PR, vect-simd-clone-1[678]{,f}.c tests FAIL on
x86_64-linux with -m64/-march=cascadelake or -m32/-march=cascadelake,
there are 3 matches for the calls rather than expected two.
As suggested by Richi, this patch changes those tests to use
--param vect-epilogues-nomask=0 such that it is more predictable on how
many calls will show up.  In the non-[a-f] suffixed tests, the
scan-tree-dump-times patterns were expecting 2 for non-aarch64 and 3 for
aarch64, which is a puzzle for me, because vect_simd_clones effective
target is apparently never true on aarch64 (just on x86 in some cases and
on amdgcn; perhaps something to change for GCC14, but I guess too late
for stage4).  That said, I have looked at aarch64 dumps and see only 2
calls with --param vect-epilogues-nomask=0 and 3 with --param
vect-epilogues-nomask=1 or without it, so I have tweaked those to always
expect the same thing.  Another thing is some tests uselessly had
-fdump-tree-optimized in dg-options even when they don't scan anything
there.

Tested on x86_64-linux with
make -j32 -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-*.c \
--target_board='unix{-m64/-march=x86-64,-m64/-march=cascadelake,-m32/-march=i686,-m32/-march=cascadelake}'"
and aarch64-linux (where all tests are UNSUPPORTED before/after).

2023-03-21  Jakub Jelinek  <jakub@redhat.com>

	PR testsuite/108898
	* gcc.dg/vect/vect-simd-clone-16.c: Add --param vect-epilogues-nomask=0
	to dg-additional-options.  Always expect just 2 foo.simdclone calls.
	* gcc.dg/vect/vect-simd-clone-16f.c: Add
	--param vect-epilogues-nomask=0 to dg-additional-options.
	* gcc.dg/vect/vect-simd-clone-17.c: Likewise.  Always expect just 2
	foo.simdclone calls.
	* gcc.dg/vect/vect-simd-clone-17d.c: Remove -fdump-tree-optimized from
	dg-additional-options.
	* gcc.dg/vect/vect-simd-clone-17e.c: Likewise.
	* gcc.dg/vect/vect-simd-clone-17f.c: Likewise.  Add
	--param vect-epilogues-nomask=0 to dg-additional-options.
	* gcc.dg/vect/vect-simd-clone-18.c: Add --param vect-epilogues-nomask=0
	to dg-additional-options.  Always expect just 2 foo.simdclone calls.
	* gcc.dg/vect/vect-simd-clone-18f.c: Add
	--param vect-epilogues-nomask=0 to dg-additional-options.

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>

libstdc++-v3/ChangeLog:

	* testsuite/experimental/simd/tests/operators.cc: Clang doesn't
	define __GCC_IEC_559. Use __STDC_IEC_559__ instead.

Our documentation sadly talks about elt_type arr[0]; as zero-length arrays,
not arrays with zero elements.  Unfortunately, those aren't the only arrays
which can have zero size, the same size can be also result of zero-length
element, like in GNU C struct whatever {} or in GNU C/C++ if the element
type is [0] array or combination thereof (dunno if Ada doesn't allow
something similar too).  One can't do much with them, taking address of
their elements, (no-op) copying of the elements in and out.  But they
behave differently from arr[0] arrays e.g. in that using non-zero indexes
in them (as long as they are within bounds as for normal arrays) is valid.

I think this naming inaccuracy resulted in Martin designing
special_array_member in an inconsistent way, mixing size zero array members
with array members of one or two or more elements and then using the
size zero interchangeably with zero elements.

The following patch changes that (but doesn't do any
documentation/diagnostics renaming, as this is really a corner case),
such that int_0/trail_0 for consistency is just about [0] arrays
plus [] for the latter, not one or more zero sized elements case.

The testcase has one xfailed case for where perhaps in later GCC versions
we could add extra code to handle it, for some reason we don't diagnose
out of bounds accesses for the zero sized elements cases.  It will be
harder because e.g. FRE will canonicalize &var.fld[0] and &var.fld[10]
to just one of them because they are provably the same address.
But the important thing is to fix this regression (where we warn on
completely valid code in the Linux kernel).  Anyway, for further work
on this we don't really need any extra help from special_array_member,
all code can just check integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (type))),
it doesn't depend on the position of the members etc.

2023-03-21  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/109215
	* tree.h (enum special_array_member): Adjust comments for int_0
	and trail_0.
	* tree.cc (component_ref_sam_type): Clear zero_elts if memtype
	has zero sized element type and the array has variable number of
	elements or constant one or more elements.
	(component_ref_size): Adjust comments, formatting fix.

	* gcc.dg/Wzero-length-array-bounds-3.c: New test.

This flag allows us to restore old (pre-6.8) behavior of the
@{summary,}content commands, so that texi2any continues to emit
summarycontents first.

maintainer-scripts/ChangeLog:

	* update_web_docs_git: Set CONTENTS_OUTPUT_LOCATION=inline in
	order to put @shortcontents above contents.

gcc/ChangeLog:

	* configure.ac: Add check for the Texinfo 6.8
	CONTENTS_OUTPUT_LOCATION customization variable and set it if
	supported.
	* configure: Regenerate.
	* Makefile.in (MAKEINFO_TOC_INLINE_FLAG): New variable.  Set by
	configure.ac to -c CONTENTS_OUTPUT_LOCATION=inline if
	CONTENTS_OUTPUT_LOCATION support is detected, empty otherwise.
	($(build_htmldir)/%/index.html): Pass MAKEINFO_TOC_INLINE_FLAG.

This commit fixes up an instance of the index entry mis-ordering that
occurred between the formulation and application of commit
r13-6310-gf33d7a88d069d1.

gcc/ChangeLog:

	* doc/extend.texi: Associate use_hazard_barrier_return index
	entry with its attribute.
	* doc/invoke.texi: Associate -fcanon-prefix-map index entry with
	its attribute

maintainer-scripts/ChangeLog:

	* update_web_docs_git (CSS): Update CSS reference to point to
	/texinfo-manuals.css.

The @gol macro appears to have existed as a workaround for a bug in old
versions of makeinfo and/or texinfo.tex, where they would, in some types
of output, fail to emit line breaks in @gccoptlists.  After updating
texinfo.tex, I noticed that this behavior appears to no longer be
exhibited, instead, both acted correctly and inserted newlines.  The
(groff) manual output also appears unaffected.

gcc/ChangeLog:

	* doc/implement-c.texi: Remove usage of @gol.
	* doc/invoke.texi: Ditto.
	* doc/sourcebuild.texi: Ditto.
	* doc/include/gcc-common.texi: Remove @gol.  In new Makeinfo and
	texinfo.tex versions, the bug it was working around appears to
	be gone.

gcc/fortran/ChangeLog:

	* invoke.texi: Remove usages of @gol.
	* intrinsic.texi: Ditto.

gcc/ChangeLog:

	* doc/include/texinfo.tex: Update to 2023-01-17.19.

The @defbuiltin{,x} macros are convenience macros for the often-repeated
task of defining a built-in function in extend.texi.  Usage of this
macro should lead to a higher degree of consistency across pieces of
text written by different people, and provide a better reading
experience, as they prevent easy-to-make errors, like forgetting index
entries for these functions.

gcc/ChangeLog:

	* doc/include/gcc-common.texi: Add @defbuiltin{,x} and
	@enddefbuiltin for defining built-in functions.
	* doc/extend.texi: Apply @defbuiltin{,x} to many, but not all,
	places where it should be used.

This commit addresses a few minor errors that were spotted while testing
the GCC manual with a few people, and while working on wider changes.

gcc/ChangeLog:

	* doc/extend.texi (Formatted Output Function Checking): New
	subsection for  grouping together printf et al.
	(Exception handling) Fix missing @ sign before copyright
	header, which lead to the copyright line leaking into
	'(gcc)Exception handling'.
	* doc/gcc.texi: Set document language to en_US.
	(@copying): Wrap front cover texts in quotations, move in manual
	description text.

The GCC manual has multiple indices.  By creating an appendix which
lists them, we help makeinfo present a more accessible way for the
reader to see all the indices.

gcc/ChangeLog:

	* doc/gcc.texi: Add the Indices appendix, to make texinfo
	generate nice indices overview page.

The following adds a missing range-op for __builtin_expect which
helps -Wuse-after-free to detect the case a realloc original
pointer is used when the result was NULL.  The implementation
should handle all argument one pass-through builtins we handle
in the fnspec machinery, but that's defered to GCC 14.

The gcc.dg/tree-ssa/ssa-lim-21.c testcase needs adjustment because

   for (int j = 0; j < m; j++)
     if (__builtin_expect (m, 0))
       for (int i = 0; i < m; i++)

is now correctly optimized to a unconditional jump by EVRP - m
cannot be zero when the outer loop is entered.  I've adjusted
the outer loop to iterate 'n' times which makes us apply store-motion
to 'count' and 'q->data1' but only out of the inner loop and
as expected not apply store motion to 'q->data' at all.

The gcc.dg/predict-20.c testcase relies on broken behavior of
profile estimation when trying to handle __builtin_expect values
flowing into PHI nodes.  I have opened PR109210 and removed
the expected matching from the testcase.

	PR tree-optimization/109170
	* gimple-range-op.cc (cfn_pass_through_arg1): New.
	(gimple_range_op_handler::maybe_builtin_call): Handle
	__builtin_expect via cfn_pass_through_arg1.

	* gcc.dg/Wuse-after-free-pr109170.c: New testcase.
	* gcc.dg/tree-ssa/ssa-lim-21.c: Adjust.
	* gcc.dg/predict-20.c: Likewise.

2023-03-21  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
	PR fortran/109206
	* trans-array.cc (gfc_trans_array_constructor_value): Correct
	incorrect setting of typespec.

2023-03-21  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
	PR fortran/109209
	* resolve.cc (generate_component_assignments): Restore the
	exclusion of allocatable components from the loop.

gcc/testsuite/
	PR fortran/109209
	* gfortran.dg/pr109209.f90: New test.

The bootstrap tool mc is built using $(CXX) and it is missing
$(CXXFLAGS).

gcc/m2/ChangeLog:

	* Make-lang.in (m2/mc-boot/$(SRC_PREFIX)%.o): Add $(CXXFLAGS).
	(m2/mc-boot-ch/$(SRC_PREFIX)%.o): Add $(CXXFLAGS).
	(m2/mc-boot-ch/$(SRC_PREFIX)%.o): Add $(CXXFLAGS).
	(m2/mc-boot/main.o): Add $(CXXFLAGS).

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

libstdc++-v3/ChangeLog:

	* src/filesystem/ops-common.h (get_temp_directory_from_env): Fix
	formatting.

	* sv.po: Update.

gcc/fortran/ChangeLog:

	PR fortran/109216
	* invoke.texi: Correct documentation of how underscores are appended
	to external names.

When I implemented explicit(bool) in r9-3735, I added this code to
add_template_candidate_real:
+  /* Now the explicit specifier might have been deduced; check if this
+     declaration is explicit.  If it is and we're ignoring non-converting
+     constructors, don't add this function to the set of candidates.  */
+  if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn))
+    return NULL;
but as this test demonstrates, that's incorrect when we're initializing
from a {}: for list-initialization we consider explicit constructors and
complain if one is chosen.

	PR c++/109159

gcc/cp/ChangeLog:

	* call.cc (add_template_candidate_real): Add explicit decls to the
	set of candidates when the initializer is a braced-init-list.

libstdc++-v3/ChangeLog:

	* testsuite/20_util/pair/cons/explicit_construct.cc: Adjust dg-error.
	* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
	* testsuite/23_containers/span/explicit.cc: Likewise.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/explicit16.C: New test.

The following two testcases are miscompiled, because we keep TREE_READONLY
on the vars even when they are (possibly) dynamically initialized by a TLS
wrapper function.  Normally cp_finish_decl drops TREE_READONLY from vars
which need dynamic initialization, but for TLS we do this kind of
initialization upon every access to those variables.  Keeping them
TREE_READONLY means e.g. PRE can hoist loads from those before loops
which contain the TLS wrapper calls, so we can access the TLS variables
before they are initialized.

2023-03-20  Jakub Jelinek  <jakub@redhat.com>

	PR c++/109164
	* cp-tree.h (var_needs_tls_wrapper): Declare.
	* decl2.cc (var_needs_tls_wrapper): No longer static.
	* decl.cc (cp_finish_decl): Clear TREE_READONLY on TLS variables
	for which a TLS wrapper will be needed.

	* g++.dg/tls/thread_local13.C: New test.
	* g++.dg/tls/thread_local13-aux.cc: New file.
	* g++.dg/tls/thread_local14.C: New test.
	* g++.dg/tls/thread_local14-aux.cc: New file.

This patch reworks how the complex multiply and divide built-in functions are
done.  Previously GCC created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit.  However, it did not
support __ibm128 complex multiply and divide if long double is IEEE 128-bit.

This code does not create the built-in declaration with the changed name.
Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name
before it is written out to the assembler file like it now does for all of the
other long double built-in functions.

2023-03-20   Michael Meissner  <meissner@linux.ibm.com>

gcc/

	PR target/109067
	* config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
	(init_float128_ieee): Delete code to switch complex multiply and divide
	for long double.
	(complex_multiply_builtin_code): New helper function.
	(complex_divide_builtin_code): Likewise.
	(rs6000_mangle_decl_assembler_name): Add support for mangling the name
	of complex 128-bit multiply and divide built-in functions.

gcc/testsuite/

	PR target/109067
	* gcc.target/powerpc/divic3-1.c: New test.
	* gcc.target/powerpc/divic3-2.c: Likewise.
	* gcc.target/powerpc/mulic3-1.c: Likewise.
	* gcc.target/powerpc/mulic3-2.c: Likewise.

gcc/fortran/ChangeLog:

	PR fortran/109186
	* simplify.cc (gfc_simplify_nearest): Fix off-by-one error in setting
	up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

	PR fortran/109186
	* gfortran.dg/nearest_6.f90: New test.

When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
for the MEM operand which causes an unrecognizable insn ICE.  The solution
is to use the correct TMODE mode.

2023-03-20  Peter Bergner  <bergner@linux.ibm.com>

gcc/
	PR target/109178
	* config/rs6000/rs6000-builtin.cc (stv_expand_builtin): Use tmode.

gcc/testsuite/
	PR target/109178
	* gcc.target/powerpc/pr109178.c: New test.

I've noticed this testcase FAILs on i686-linux with
-fstack-protector-strong.

sizeof (auto_vec<int, 8>) == 16, which in this case contains
4-byte m_vec (which points to to m_auto), then 8-byte m_auto
which contains just 8-byte m_vecpfx and finally 1 byte m_data,
rest is padding.  We then try to push 2 ints to it, so 8 bytes,
starting at the end of m_vecpfx aka address of m_data, but there
is just 1 byte + 3 bytes of padding.
In the lp64 case, I think sizeof (auto_vec<int, 8>) == 24,
because there is 8-byte m_vec, 8-byte m_vecpfx and 1-byte m_char
all with 8-byte alignment.

2023-03-20  Jakub Jelinek  <jakub@redhat.com>

	* g++.dg/torture/20230313.C (auto_vec): Change m_data type
	from char to char [2 * sizeof (int)].

The presence of a template-head on this constructor is a copy & paste
error from the primary template.

libstdc++-v3/ChangeLog:

	PR libstdc++/109182
	* include/std/expected (expected<void>::expected(in_place_t)):
	Remove template-head.

2023-03-20  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
	PR fortran/87127
	* resolve.cc (check_host_association): If an external function
	is typed but not declared explicitly to be external, change the
	old symbol from a variable to an external function.

gcc/testsuite/
	PR fortran/87127
	* gfortran.dg/external_procedures_4.f90: New test.

gcc/fortran/ChangeLog:

	PR fortran/85877
	* resolve.cc (resolve_fl_procedure): Check for an explicit interface
	of procedures with the BIND(C) attribute (F2018:15.4.2.2).

gcc/testsuite/ChangeLog:

	PR fortran/85877
	* gfortran.dg/pr85877.f90: New test.

gcc/fortran/ChangeLog:

	* gfortran.texi: Mention behavior on overflow.