When we use get_ref_base_and_extent during VN and that ends up using
global ranges to restrict the range of a ref we have to take care
of not using the same expression in the hashtable as for a ref that
could not use that global range.  The following attempts to ensure
this by applying similar logic as get_ref_base_and_extent to
copy_reference_ops_from_ref so they behave consistent.

	PR tree-optimization/113831
	PR tree-optimization/108355
	* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): When
	we see variable array indices and get_ref_base_and_extent
	can resolve those to constants fix up the ops to constants
	as well.
	(ao_ref_init_from_vn_reference): Use 'off' member for
	ARRAY_REF and ARRAY_RANGE_REF instead of recomputing it.
	(valueize_refs_1): Also fixup 'off' of ARRAY_RANGE_REF.

	* gcc.dg/torture/pr113831.c: New testcase.
	* gcc.dg/tree-ssa/ssa-fre-104.c: Likewise.

As detailed in PR modula2/113888, the 32-bit libm2pim/target.c doesn't
assemble in a Linux/sparc64 multilib build.  However, the root cause is
that the HAVE_EXP10* macros are never defined.  While I was at it, I
checked for other cases where the code uses HAVE_* macros that are
missing from config.h.in.

This patch adds the missing checks, changes the configure checks where
the names don't match what's used in the code, or corrects the code to
use the right names.

So far tested on sparc64-unknown-linux-gnu by building libgm2 (32 and
64-bit) and running the gm2 tests.

2024-02-12  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	libgm2:
	PR modula2/113888
	* configure.ac (GM2_CHECK_LIB): Rename gettimeofday guard to
	HAVE_GETTIMEOFDAY.
	(GM_CHECK_LIB): Check for settimeofday.
	(GM2_CHECK_LIB): Check for exp10, exp10f, exp10l in libm.
	(AC_CHECK_DECLS): Check for getenv.
	* configure, config.h.in: Regenerate.
	* libm2pim/dtoa.cc: Rename <strings.h>, <string.h> guards to
	HAVE_STRINGS_H, HAVE_STRING_H.
	* libm2pim/ldtoa.cc: Likewise.

When build with "-Werror=format-diag", there will be one misspelled
term args as below. This patch would like fix it by taking the term
arguments instead.

../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node*
riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree,
vec<tree_node*, va_gc>*)':
../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error:
misspelled term 'args' in format; use 'arguments' instead
[-Werror=format-diag]
 4633 |     error_at (loc, "no matching function call to %qE with empty
      args", fndecl);

gcc/ChangeLog:

	* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin):
	Replace args to arguments for misspelled term.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr113766-1.c: Adjust the test cases.

Signed-off-by: Pan Li <pan2.li@intel.com>

For devices that see a part for the flash memory in the RAM address space,
bit-field NVMCTRL_CTRLB.FLMAP must match the value of symbol __flmap.
This is achieved by dragging in startup code from lib<mcu>.a.
The mechanism is the same like for libgcc's __do_copy_data and __do_clear_bss.
The code is implemented in AVR-LibC #931 and can be dragged by referencing
__do_flmap_init.

In addition to setting FLMAP, that code also sets bit FLMAPLOCK provided
symbol __flmap_lock has a non-zero value.  This protects FLMAP from future
changes.

When the __do_flmap_init code is not wanted, the symbol can be satisfied by
linking with  -Wl,--defsym,__do_flmap_init=0

gcc/
	PR target/112944
	* config/avr/gen-avr-mmcu-specs.cc (print_mcu) [have_flmap]:
	<*link_rodata_in_ram>: Spec undefs symbol __do_flmap_init
	when not linked with -mrodata-in-ram.

This makes sure to elide degenerate virtual PHIs when moving stores
across early exits.

	PR tree-optimization/113863
	* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
	Record crossed virtual PHIs.
	* tree-vect-loop.cc (move_early_exit_stmts): Elide crossed
	virtual PHIs.

	* gcc.dg/vect/pr113863.c: New testcase.

2024-02-11  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

	* gcc.c-torture/execute/ieee/cdivchkf.c: Use ilogb and
	__builtin_fmax instead of ilogbf and __builtin_fmaxf.

On darwin, symbols are prefixed with underscore, and
the order of operands is reversed.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/asm-raw-symbol.c: Adjust asm patterns.

2024-02-11  John David Anglin  <danglin@gcc.gnu.org>

libgomp/ChangeLog:

	PR libgomp/113843
	* configure.tgt (hppa*-*-linux*): Define config_path.

The test case for PR97969 needs updates in order to comply with recent
changes in GCC14.  Without these changes, failures like this can be seen
on arm-none-eabi:

.../pr97969.c:6:9: error: type defaults to 'int' in declaration of 'a' [-Wimplicit-int]
.../pr97969.c:34:1: error: return type defaults to 'int' [-Wimplicit-int]
.../pr97969.c:40:3: error: implicit declaration of function 'ae' [-Wimplicit-function-declaration]
.../pr97969.c:42:3: error: implicit declaration of function 'af' [-Wimplicit-function-declaration]
.../pr97969.c:43:7: error: implicit declaration of function 'ag' [-Wimplicit-function-declaration]
.../pr97969.c:46:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
.../pr97969.c:48:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
.../pr97969.c:50:8: error: implicit declaration of function 'setjmp' [-Wimplicit-function-declaration]
.../pr97969.c:51:5: error: implicit declaration of function 'ah' [-Wimplicit-function-declaration]
.../pr97969.c:52:5: error: implicit declaration of function 'ai' [-Wimplicit-function-declaration]
.../pr97969.c:54:5: error: implicit declaration of function 'aj' [-Wimplicit-function-declaration]

Patch has been verified on Linux.

gcc/testsuite/ChangeLog:

	* gcc.target/arm/pr97969.c: Update to comply with GCC14 changes.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

ChangeLog:

	* MAINTAINERS: Add myself to write after approval and DCO.

Signed-off-by: Alexander Westbrooks <alexanderw@gcc.gnu.org>

See PR90698. On Xcode 15, the tests currently lead to a segfault of the
clang assembler.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/pr113689-1.c: Skip test on darwin.
	* gcc.target/i386/pr113689-2.c: Likewise.
	* gcc.target/i386/pr113689-3.c: Likewise.

gcc/testsuite/ChangeLog:

	* gcc.dg/ssp-2.c: Ignore warning that
	-multiply_defined is obsolete

Since my r11-532 changes to implement DR2237, for this test:

  template<typename T>
  struct S {
    S<T>();
  };

in C++20 we emit the ugly:

q.C:3:8: error: expected unqualified-id before ')' token
    3 |   S<T>();

which doesn't explain what the problem is.  This patch improves that
diagnostic, reduces the error to a pedwarn, and adds a -Wc++20-compat
diagnostic.  We now say:

q.C:3:7: warning: template-id not allowed for constructor in C++20 [-Wtemplate-id-cdtor]
    3 |   S<T>();
q.C:3:7: note: remove the '< >'

This patch also fixes
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202#c8>
where the C++20 diagnostic was missing altogether:  The problem was that I checked
for CPP_TEMPLATE_ID too early, at a point at which cp_parser_template_id may not
have been called yet.  So let's check for it at the end of the function, after
the tentative parse and rollback.

-Wc++20-compat triggered in libitm/; I sent a patch for that.

	DR 2237
	PR c++/107126
	PR c++/97202

gcc/c-family/ChangeLog:

	* c-opts.cc (c_common_post_options): In C++20 or with -Wc++20-compat,
	turn on -Wtemplate-id-cdtor.
	* c.opt (Wtemplate-id-cdtor): New.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_unqualified_id): Downgrade the DR2237 error to
	a pedwarn.
	(cp_parser_constructor_declarator_p): Likewise.

gcc/ChangeLog:

	* doc/invoke.texi: Document -Wtemplate-id-cdtor.

gcc/testsuite/ChangeLog:

	* g++.dg/DRs/dr2237.C: Adjust dg-error.
	* g++.dg/parse/constructor2.C: Likewise.
	* g++.dg/template/error34.C: Likewise.
	* g++.old-deja/g++.pt/ctor2.C: Likewise.
	* g++.dg/DRs/dr2237-2.C: New test.
	* g++.dg/DRs/dr2237-3.C: New test.
	* g++.dg/DRs/dr2237-4.C: New test.
	* g++.dg/DRs/dr2237-5.C: New test.
	* g++.dg/warn/Wtemplate-id-cdtor-1.C: New test.
	* g++.dg/warn/Wtemplate-id-cdtor-2.C: New test.
	* g++.dg/warn/Wtemplate-id-cdtor-3.C: New test.
	* g++.dg/warn/Wtemplate-id-cdtor-4.C: New test.

gcc/testsuite/ChangeLog:

	* gcc.dg/darwin-ld-2.c: Ignore warning
	that -bind_at_load is deprecated.

torture/bitint-37.c test FAILed on i686-linux e.g. on
signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
__builtin_add_overflow.  With 64-bit limbs, we use 4 .UADDC calls in
the IL, 2 in a loop (which handles the first 8 limbs), then one partial
limb (we use 63 bits from that) and finally last_ovf case due to the
mixing of signed vs. unsigned.
But with 32-bit limbs, we use 5 .UADDC calls in the IL, 2 in a loop (which
handles the first 16 limbs), then one full limb above that, one partial
(31 bits) and finally last_ovf case, and for the last_ovf case the code
computed incorrect idx and so partly did the wrong thing, e.g. overwrote
the result from the previous .UADDC.

Fixed thusly.

2024-02-10  Jakub Jelinek  <jakub@redhat.com>

	* gimple-lower-bitint.cc (itint_large_huge::lower_addsub_overflow): Fix
	computation of idx for i == 4 of bitint_prec_huge.

The ia32 _BitInt support revealed a bug in floatbitint?d.c.
As can be even guessed from how the code is written in the loop,
the intention was to set inexact to non-zero whenever the remainder
after division wasn't zero, but I've ended up just checking whether
the 2 least significant limbs of the remainder were non-zero.
Now, in the dfp/bitint-4.c test in one case the remainder happens
to have least significant 64 bits zero and then the higher limbs are
non-zero; with 32-bit limbs that means 2 least significant limbs are zero
and so the code acted as if it was exactly divisible.

Fixed thusly.

2024-02-10  Jakub Jelinek  <jakub@redhat.com>

	* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Or in all remainder
	limbs into inexact rather than just first two.
	* soft-fp/floatbitintsd.c (__bid_floatbitintsd): Likewise.
	* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.

I've tried last night to enable _BitInt support for i?86-linux, and
a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly
didn't do what it was supposed to do.

Fixed thusly.

2024-02-10  Jakub Jelinek  <jakub@redhat.com>

	* soft-fp/fixddbitint.c (__bid_fixddbitint): Fix up
	BIL_TYPE_SIZE == 32 shifts.
	* soft-fp/fixsdbitint.c (__bid_fixsdbitint): Likewise.
	* soft-fp/fixtdbitint.c (__bid_fixtdbitint): Likewise.
	* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Likewise.
	* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.

As the following testcases show, the gimple-low outlining of assume
magic functions handled volatile automatic vars (including
parameters/results) like non-volatile ones except it copied volatile
to the new PARM_DECL, which has the undesirable effect that a load
from the volatile var is passed to IFN_ASSUME and so there is a
side-effect there even when side-effects of the assume attribute
shouldn't be evaluated.

The following patch fixes that by passing address of the volatile
variables/parameters/results instead and doing loads or stores from it
or to it where it was originally accessed in the assume attribute
expression.

2024-02-10  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/110754
	* gimple-low.cc (assumption_copy_decl): For TREE_THIS_VOLATILE
	decls create PARM_DECL with pointer to original type, set
	TREE_READONLY and keep TREE_THIS_VOLATILE, TREE_ADDRESSABLE,
	DECL_NOT_GIMPLE_REG_P and DECL_BY_REFERENCE cleared.
	(adjust_assumption_stmt_op): For remapped TREE_THIS_VOLATILE decls
	wrap PARM_DECL into a simple TREE_THIS_NO_TRAP MEM_REF.
	(lower_assumption): For TREE_THIS_VOLATILE vars pass ADDR_EXPR
	of the var as argument.

	* gcc.dg/attr-assume-6.c: New test.
	* g++.dg/cpp23/attr-assume12.C: New test.

In the previous patch I haven't touched the gcc diagnostic routines,
using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
want the strings to be translatable.  We already have %w[diox] for
HOST_WIDE_INT arguments, this patch adds t and z modifiers for those.

2024-02-10  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* pretty-print.cc (pp_integer_with_precision): Handle precision 3 for
	size_t and precision 4 for ptrdiff_t.  Formatting fix.
	(pp_format): Document %{t,z}{d,i,u,o,x}.  Implement t and z modifiers.
	Formatting fixes.
	(test_pp_format): Test t and z modifiers.
	* gcc.cc (read_specs): Use %td instead of %ld and casts to long.
gcc/c-family/
	* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
	(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
	z modifiers.
gcc/fortran/
	* error.cc (error_print): Handle z and t modifiers on d, i and u.
	* check.cc (gfc_check_transfer): Use %zd instead of %ld and casts to
	long.
	* primary.cc (gfc_convert_to_structure_constructor): Use %td instead
	of %ld and casts to long.

I went through suspicios %l in format strings of *printf family functions
combined with casts to (long) or (unsigned long) and tried to find out the
types of the original expressions that were cast.
Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_*
macros together with cast to fmt_size_t for those, and then there were
quite a few HOST_WIDE_INTs cast to long, used HOST_WIDE_INT_PRINT_* for
those without casts.  There was one case of a weird unsigned int variable
used with %lu and (long) cast too.

2024-02-10  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* ipa-icf.cc (sem_item_optimizer::process_cong_reduction,
	sem_item_optimizer::dump_cong_classes): Use HOST_SIZE_T_PRINT_UNSIGNED
	and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
	* tree.cc (print_debug_expr_statistics): Use HOST_SIZE_T_PRINT_DEC
	and casts to fmt_size_t instead of "%ld" and casts to long.
	(print_value_expr_statistics, print_type_hash_statistics): Likewise.
	* dwarf2out.cc (output_macinfo_op): Use HOST_WIDE_INT_PRINT_UNSIGNED
	instead of "%lu" and casts to unsigned long.
	* gcov-dump.cc (dump_gcov_file): Use %u instead of %lu and casts to
	unsigned long.
	* tree-ssa-dom.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC
	and casts to fmt_size_t instead of "%ld" and casts to long.
	* cfgexpand.cc (dump_stack_var_partition): Use
	HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu"
	and casts to unsigned long.
	* gengtype.cc (adjust_field_rtx_def): Likewise.
	* tree-into-ssa.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC
	and casts to fmt_size_t instead of "%ld" and casts to long.
	* postreload-gcse.cc (dump_hash_table): Likewise.
	* ggc-page.cc (alloc_page): Use HOST_SIZE_T_PRINT_UNSIGNED
	and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
	(ggc_internal_alloc, ggc_free): Likewise.
	* genpreds.cc (write_lookup_constraint_1): Likewise.
	(write_insn_constraint_len): Likewise.
	* tree-dfa.cc (dump_dfa_stats): Use HOST_SIZE_T_PRINT_DEC
	and casts to fmt_size_t instead of "%ld" and casts to long.
	* varasm.cc (output_constant_pool_contents): Use
	HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long.
	* var-tracking.cc (dump_var): Likewise.
gcc/c-family/
	* c-ada-spec.cc (dump_template_types): Use HOST_SIZE_T_PRINT_UNSIGNED
	and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
gcc/c/
	* c-decl.cc (get_parm_array_spec): Use HOST_WIDE_INT_PRINT_UNSIGNED
	instead of "%lu" and casts to unsigned long or unsigned long long.
gcc/cp/
	* tree.cc (debug_binfo): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld"
	and casts to long.
	* pt.cc (print_template_statistics): Use HOST_SIZE_T_PRINT_DEC
	and casts to fmt_size_t instead of "%ld" and casts to long.
	* class.cc (dump_class_hierarchy_1): Use HOST_WIDE_INT_PRINT_UNSIGNED
	instead of "%lu" and casts to unsigned long.  For TYPE_ALIGN, use
	%u instead of %lu and drop casts to unsigned long.
	* parser.cc (cp_lexer_peek_nth_token): Use HOST_SIZE_T_PRINT_DEC
	and casts to fmt_size_t instead of "%ld" and casts to long.
gcc/fortran/
	* trans-common.cc (build_common_decl): Use %wu instead of %lu and
	casts to unsigned long.
	* resolve.cc (resolve_ordinary_assign): Use %wd instead of %ld and
	casts to long.
	* array.cc (gfc_resolve_character_array_constructor): Likewise.
	* data.cc (create_character_initializer): Likewise.
gcc/jit/
	* jit-playback.cc (new_bitcast): Use HOST_WIDE_INT_PRINT_DEC instead
	of "%ld" and casts to long.
gcc/lto/
	* lto-common.cc (print_lto_report_1): Use HOST_SIZE_T_PRINT_DEC
	and casts to fmt_size_t instead of "%ld" and casts to long.  Use
	%d instead of %ld and casts to long for searches and collisions.

Test-cases, with constexpr-reinterpret3.C dg-ice:ing the PR c++/113545 bug.

Regarding the request in the comment, A dg-do run when there's an ICE
will cause some CI's to signal an error for the run being "UNRESOLVED"
(compilation failed to produce executable).  Note that dejagnu (1.6.3)
itself doesn't consider this an error.

gcc/testsuite:
	PR c++/113545
	* g++.dg/cpp1y/constexpr-reinterpret3.C,
	g++.dg/cpp1y/constexpr-reinterpret4.C: New tests.

Re-write address arithmetic in gm2-libs/SArgs.mod:GetArg
to avoid (void *) computation.  mc treats ADDRESS as (char *)
but does not cast user type (PtrToChar) to (char *) when
performing address arithmetic.

gcc/m2/ChangeLog:

	PR modula2/113848
	* gm2-libs/SArgs.mod (GetArg): Re-write address arithmetic
	to avoid (void *) computation.

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

Here we crash on this invalid code because we seem to infinitely recurse
and end up with __type_pack_element with index that doesn't tree_fits_shwi_p
which then crashes on tree_to_shwi.

Thanks to Jakub for suggesting a nicer fix than my original one.

	PR c++/113834

gcc/cp/ChangeLog:

	* semantics.cc (finish_type_pack_element): Perform range checking
	before tree_to_shwi.

gcc/testsuite/ChangeLog:

	* g++.dg/ext/type_pack_element4.C: New test.

Here the problem is that we give hard errors while substituting
template parameters during overload resolution of is_throwable
which has an invalid throw in decltype.

The backtrace shows that fn_type_unification -> instantiate_template
-> tsubst* passes complain=0 as expected, but build_throw doesn't
have a complain parameter.  So let's add one.  Also remove a redundant
local variable which I should have removed in my P2266 patch.

There's still one problem for which I opened <https://gcc.gnu.org/PR113853>.
We need to patch up treat_lvalue_as_rvalue_p and remove the dg-bogus.

Thanks to Patrick for notifying me of this PR.  This doesn't fully fix
113789; there I think I'll have to figure our why a candidate wasn't
discarded from the overload set.

	PR c++/98388

gcc/cp/ChangeLog:

	* coroutines.cc (coro_rewrite_function_body): Pass tf_warning_or_error
	to build_throw.
	(morph_fn_to_coro): Likewise.
	* cp-tree.h (build_throw): Adjust.
	* except.cc (expand_end_catch_block): Pass tf_warning_or_error to
	build_throw.
	(build_throw): Add a tsubst_flags_t parameter.  Use it.  Remove
	redundant variable.  Guard an inform call.
	* parser.cc (cp_parser_throw_expression): Pass tf_warning_or_error
	to build_throw.
	* pt.cc (tsubst_expr) <case THROW_EXPR>: Pass complain to build_throw.

libcc1/ChangeLog:

	* libcp1plugin.cc (plugin_build_unary_expr): Pass tf_error to
	build_throw.

gcc/testsuite/ChangeLog:

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

	PR fortran/113799

gcc/fortran/ChangeLog:

	* arith.cc (reduce_unary): Remember any overflow encountered during
	reduction of unary arithmetic operations on array constructors and
	continue, and return error status, but terminate on serious errors.

gcc/testsuite/ChangeLog:

	* gfortran.dg/arithmetic_overflow_2.f90: New test.

Since is_same has a fallback native implementation, and
_GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which
implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME
definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead.

libstdc++-v3/ChangeLog:

	* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME):
	Removed.
	* include/std/type_traits (is_same): Use
	_GLIBCXX_USE_BUILTIN_TRAIT instead of
	_GLIBCXX_HAVE_BUILTIN_IS_SAME.
	(is_same_v): Likewise.

Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

Here when streaming in the fields of the as-base version of
_Formatting_scanner<int> we end up overwriting ANON_AGGR_TYPE_FIELD
of the anonymous union type, since it turns out this type is shared
between the original FIELD_DECL and the as-base FIELD_DECL copy (copied
during layout_class_type).  ANON_AGGR_TYPE_FIELD first gets properly set
to the original FIELD_DECL when streaming in the canonical definition of
_Formatting_scanner<int>, and then gets overwritten to the as-base
FIELD_DECL when streaming in the the as-base definition.  This leads to
lookup_anon_field later giving the wrong answer when resolving the
_M_values use at instantiation time.

This patch makes us avoid overwriting ANON_AGGR_TYPE_FIELD when streaming
in an as-base class definition; it should already be properly set at that
point.

	PR c++/112580

gcc/cp/ChangeLog:

	* module.cc (trees_in::read_class_def): When streaming in
	an anonymous union field of an as-base class, don't overwrite
	ANON_AGGR_TYPE_FIELD.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/anon-3_a.H: New test.
	* g++.dg/modules/anon-3_b.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>

lower-bitint: Fix handling of VIEW_CONVERT_EXPRs to minimally supported huge INTEGER_TYPEs [PR113783]

On the following testcases memcpy lowering folds the calls to
reading and writing of MEM_REFs with huge INTEGER_TYPEs - uint256_t
with OImode or uint512_t with XImode.  Further optimization turn
the load from MEM_REF from the large/huge _BitInt var into VIEW_CONVERT_EXPR
from it to the uint256_t/uint512_t.  The backend doesn't really
support those except for "movoi"/"movxi" insns, so it isn't possible
to handle it like casts to supportable INTEGER_TYPEs where we can
construct those from individual limbs - there are no OImode/XImode shifts
and the like we can use.
So, the following patch makes sure for such VCEs that the SSA_NAME operand
of the VCE lives in memory and then turns it into a VIEW_CONVERT_EXPR so
that we actually load the OImode/XImode integer from memory (i.e. a mov).
We need to make sure those aren't merged with other
operations in the gimple_lower_bitint hunks.
For SSA_NAMEs which have underlying VAR_DECLs that is all we need, those
VAR_DECL have ARRAY_TYPEs.
For SSA_NAMEs which have underlying PARM_DECLs or RESULT_DECLs those have
BITINT_TYPE and I had to tweak expand_expr_real_1 for that so that it
doesn't try convert_modes on those when one of the modes is BLKmode - we
want to fall through into the adjust_address on the MEM.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113783
	* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Look
	through VIEW_CONVERT_EXPR for final cast checks.  Handle
	VIEW_CONVERT_EXPRs from large/huge _BitInt to > MAX_FIXED_MODE_SIZE
	INTEGER_TYPEs.
	(gimple_lower_bitint): Don't merge mergeable operations or other
	casts with VIEW_CONVERT_EXPRs to > MAX_FIXED_MODE_SIZE INTEGER_TYPEs.
	* expr.cc (expand_expr_real_1): Don't use convert_modes if either
	mode is BLKmode.

	* gcc.dg/bitint-88.c: New test.

build_conflict_bit_table uses %ld format string for
(long) some_int_expression * sizeof (something)
argument, that doesn't work on LLP64 hosts because the
expression has then size_t aka unsigned long long type there.
It can be fixed with
(long) (some_int_expression * sizeof (something))
but it means the value is truncated if it doesn't fit into long.
Ideally we'd use %zd or %zu modifiers here, but it is unclear if we
can rely on it on all hosts, it has been introduced in C99 and C++11
includes C99 by reference, but in reality whether this works or not
depends on the host C library and some of them are helplessly obsolete.

This patch instead introduces new macros HOST_SIZE_T_PRINT_* which
one can use in *printf family function format strings and cast to
fmt_size_t type.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	* hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
	HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
	HOST_SIZE_T_PRINT_HEX_PURE): Define.
	* ira-conflicts.cc (build_conflict_bit_table): Use it.  Formatting
	fixes.

Some exports were missed from the GCC-13 cycle, these are added here
along with the bitint-related ones added in GCC-14.

libgcc/ChangeLog:

	* config/i386/libgcc-darwin.ver: Export bf and bitint-related
	synbols.

The asm goto expansion ICEs on the following testcase (which normally
is rejected later), because expand_asm_stmt emits the code to copy
the large var out of the out operand to its memory location into
after_rtl_seq ... after_rtl_end sequence and because it is asm goto,
it duplicates the sequence on each successor edge of the asm goto.
The problem is that with -mstringop-strategy=byte_loop that sequence
contains loops, so CODE_LABELs, JUMP_INSNs, with other strategies
could contain CALL_INSNs etc.
But the copying is done using a loop doing
emit_insn (copy_insn (PATTERN (curr)));
which does the right thing solely for INSNs, it will do the wrong thing
for JUMP_INSNs, CALL_INSNs, CODE_LABELs (with RTL checking even ICE on
them), BARRIERs and the like.

The following patch partially fixes it (with the hope that such stuff only
occurs in asms that really can't be accepted; if one uses say "=rm" or
"=g" constraint then the operand uses the memory directly and nothing is
copied) by using the
duplicate_insn_chain function which is used e.g. in RTL loop unrolling and
which can handle JUMP_INSNs, CALL_INSNs, BARRIERs etc.
As it is meant to operate on sequences inside of basic blocks, it doesn't
handle CODE_LABELs (well, it skips them), so if we need a solution that
will be correct at runtime here for those cases, we'd need to do further
work (e.g. still use duplicate_insn_chain, but if we notice any CODE_LABELs,
walk the sequence again, add copies of the CODE_LABELs and then remap
references to the old CODE_LABELs in the copied sequence to the new ones).
Because as is now, if the code in one of the sequence copies (where the
CODE_LABELs have been left out) decides to jump to such a CODE_LABEL, it
will jump to the CODE_LABEL which has been in the original sequence (which
the code emits on the last edge, after all, duplicating the sequence
EDGE_COUNT times and throwing away the original was wasteful, compared to
doing that just EDGE_COUNT - 1 times and using the original.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/113415
	* cfgexpand.cc (expand_asm_stmt): For asm goto, use
	duplicate_insn_chain to duplicate after_rtl_seq sequence instead
	of hand written loop with emit_insn of copy_insn and emit original
	after_rtl_seq on the last edge.

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

Due to -fnon-call-exceptions the bitint lowering adds new EH edges
in various places, so that the EH edge points from handling (e.g. load or
store) of each of the limbs.  The problem is that the EH edge destination
as shown in the testcase can have some PHIs.  If it is just a virtual
PHI, no big deal, the pass uses TODO_update_ssa_only_virtuals, but if
it has other PHIs, I think we need to copy the values from the preexisting
corresponding EH edge (which is from the original stmt to the EH pad)
to the newly added EH edge, so that the PHI arguments are the same rather
than missing (which ICEs during checking at the end of the pass).

This patch adds a function to do that and uses it whenever adding EH edges.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113818
	* gimple-lower-bitint.cc (add_eh_edge): New function.
	(bitint_large_huge::handle_load,
	bitint_large_huge::lower_mergeable_stmt,
	bitint_large_huge::lower_muldiv_stmt): Use it.

	* gcc.dg/bitint-89.c: New test.

The following patch is the optimization part of PR113774, where in
handle_cast we emit some conditionals which are always true and presumably
VRP would figure that out later and clean it up, except that instead
thread1 is invoked and threads everything through the conditions, so we end
up with really ugly code which is hard to be cleaned up later and then
run into PR113831 VN bug and miscompile stuff.

handle_cast computes low and high as limb indexes, where idx < low
doesn't need any special treatment, just uses the operand's limb,
idx >= high cases all the bits in the limb are an extension (so, for
unsigned widening cast all those bits are 0, for signed widening cast
all those bits are equal to the in earlier code computed sign mask,
narrowing cast don't trigger this code) and then the idx == low && idx <
high case if it exists need special treatment (some bits are copied, others
extended, or all bits are copied but sign mask needs to be computed).

The code already attempted to optimize away some unneeded casts, in the
first hunk below e.g. for the case like 257 -> 321 bit extension, where
low is 4 and high 5 and we use a loop handling the first 4 limbs (2
iterations) with m_upwards_2limb 4 - no special handling is needed in the
loop, and the special handling is done on the first limb after the loop
and then the last limb after the loop gets the extension only, or
in the second hunk where can emit a single comparison instead of
2 e.g. for the low == high case - that must be a zero extension from
multiple of limb bits, say 192 -> 328, or for the case where we know
the idx == low case happens in the other limb processed in the loop, not
the current one.

But the testcase shows further cases where we always know some of the
comparisons can be folded to true/false, in particular there is
255 -> 257 bit zero extension, so low 3, high 4, m_upwards_2limb 4.
The loop handles 2 limbs at the time and for the first limb we were
emitting idx < low ? operand[idx] : 0; but because idx goes from 0
with step 2 2 iterations, idx < 3 is always true, so we can just
emit operand[idx].  This is handled in the first hunk.  In addition
to fixing it (that is the " - m_first" part in there) I've rewritten
it using low to make it more readable.

Similarly, in the other limb we were emitting
idx + 1 <= low ? (idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx]) : 0
but idx + 1 <= 3 is always true in the loop, so all we should emit is
idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx],
Unfortunately for the latter, when single_comparison is true, we emit
just one comparison, but the code which fills the branches will fill it
with the operand[idx] and 0 cases (for zero extension, for sign extension
similarly), not the operand[idx] (aka copy) and operand[idx] & 0x7ff....ff
(aka most significant limb of the narrower precision) cases.  Instead
of making the code less readable by using single_comparison for that and
handling it in the code later differently I've chosen to just emit
a condition which will be always true and let cfg cleanup clean it up.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113774
	* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't
	emit any comparison if m_first and low + 1 is equal to
	m_upwards_2limb, simplify condition for that.  If not
	single_comparison, not m_first and we can prove that the idx <= low
	comparison will be always true, emit instead of idx <= low
	comparison low <= low such that cfg cleanup will optimize it at
	the end of the pass.

	* gcc.dg/torture/bitint-57.c: New test.

When running the testsuite for newlib nano, the --specs=nano.specs
option is used.  This option prepends cpp_unique_options with
"-isystem =/include/newlib-nano" so that the newlib nano header files
override the newlib standard ones.  As the -isystem option is prepended,
the -quiet option is no longer the first option to cc1.  Adjust the test
accordingly.

Patch has been verified on Windows and Linux.

gcc/testsuite/ChangeLog:

	* gcc.misc-tests/options.exp: Allow other options before the
	-quite option for cc1.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

libstdc++-v3/ChangeLog:

	* include/bits/shared_ptr_atomic.h: Fix typo in comment.

There's no need to check for self-assignment here, it would just add
extra code for an unlikely case. Add a comment saying so.

libstdc++-v3/ChangeLog:

	PR libstdc++/100147
	* include/bits/gslice.h (operator=): Add comment about lack of
	self-assignment check.