As I wrote earlier, I was seeing
FAIL: gcc.dg/torture/bitint-24.c   -O0  execution test
FAIL: gcc.dg/torture/bitint-24.c   -O2  execution test
with the ia32 _BitInt enablement patch on i686-linux.  I thought
floatbitintxf.c was miscompiled with -O2 -march=i686 -mtune=generic, but it
turned out to be UB in it.

If a signed _BitInt to be converted to binary floating point has
(after sign extension from possible partial limb to full limb) one or
more most significant limbs equal to all ones and then in the limb below
(the most significant non-~(UBILtype)0 limb) has the most significant limb
cleared, like for 32-bit limbs
0x81582c05U, 0x0a8b01e4U, 0xc1b8b18fU, 0x2aac2a08U, -1U, -1U
then bitint_reduce_prec can't reduce it to that 0x2aac2a08U limb, so
msb is all ones and precision is negative (so it reduced precision from
161 to 192 bits down to 160 bits, in theory could go as low as 129 bits
but that wouldn't change anything on the following behavior).
But still iprec is negative, -160 here.
For that case (i.e. where we are dealing with an negative input), the
code was using 65 - __builtin_clzll (~msb) to compute how many relevant
bits we have from the msb.  Unfortunately that invokes UB for msb all ones.
The right number of relevant bits in that case is 1 though (like for
-2 it is 2 and -4 or -3 3 as already computed) - all we care about from that
is that the most significant bit is set (i.e. the number is negative) and
the bits below that should be supplied from the limbs below.

So, the following patch fixes it by special casing it not to invoke UB.

For msb 0 we already have a special case from before (but that is also
different because msb 0 implies the whole number is 0 given the way
bitint_reduce_prec works - even if we have limbs like ..., 0x80000000U, 0U
the reduction can skip the most significant limb and msb then would be
the one below it), so if iprec > 0, we already don't call __builtin_clzll
on 0.

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

	* soft-fp/bitint.h (FP_FROM_BITINT): If iprec < 0 and msb is all ones,
	just set n to 1 instead of using __builtin_clzll (~msb).

Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ
as broke the gengtype on i686-linux before the libiberty fix is certainly
unexpected.  size_t is there unsigned int, so expected fmt_size_t is
unsigned int (or some other 32-bit type).

The problem was that I was comparing SIZE_MAX against signed maxima,
but SIZE_MAX is unsigned maximum.

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

	* hwint.h (GCC_PRISZ, fmt_size_t): Fix preprocessor conditions,
	instead of comparing SIZE_MAX against INT_MAX and LONG_MAX compare
	it against UINT_MAX and ULONG_MAX.

	PR fortran/113883

gcc/fortran/ChangeLog:

	* trans-array.cc (gfc_trans_deferred_array): Set length to zero,
	avoiding extraneous diagnostics.

gcc/testsuite/ChangeLog:

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

As noted by Joseph, I broke "make gcc.pot" in r14-6057-g12b67d1e13b3cf
by adding an overloaded format API with the format string in a different
position, leading to this failure:

emit_diagnostic_valist used incompatibly as both --keyword=emit_diagnostic_valist:4
--flag=emit_diagnostic_valist:4:gcc-internal-format and --keyword=emit_diagnostic_valist:5
--flag=emit_diagnostic_valist:5:gcc-internal-format

Fix by replacing the overloaded function with one with a different name.

See also r10-6297-g6c8e584430bc5d for previous fixes for this involving
the same function, or r5-6946-g40fecdd62f7d29 and
r5-6959-gdb30e21cbff7b9 for older fixes for similar issues.

gcc/analyzer/ChangeLog:
	* pending-diagnostic.cc (diagnostic_emission_context::warn):
	Update for renaming of emit_diagnostic_valist overload to
	emit_diagnostic_valist_meta.
	(diagnostic_emission_context::inform): Likewise.

gcc/ChangeLog:
	* diagnostic-core.h (emit_diagnostic_valist): Rename overload
	to...
	(emit_diagnostic_valist_meta): ...this.
	* diagnostic.cc (emit_diagnostic_valist): Likewise, to...
	(emit_diagnostic_valist_meta): ...this.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

During tab edits, the pos (position) and bytes_used
Variables were not being set correctly for stream I/O.
Since stream I/O does not have 'real' records, the
format buffer active length must be used instead of
the record length variable.

       PR libgfortran/109358

libgfortran/ChangeLog:

	* io/transfer.c (formatted_transfer_scalar_write): Adjust
	bytes_used and pos variable for stream access.

gcc/testsuite/ChangeLog:

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

A call to `basic_string::clear()` in the std::string move assignment
operator leads to a constexpr error from an access of inactive union
member `_M_local_buf` in the added test (`test_move()`). Changing
`__str._M_local_buf` to `__str._M_use_local_data()` in
`operator=(basic_string&& __str)` fixes this.

	PR libstdc++/113294

libstdc++-v3/ChangeLog:

	* include/bits/basic_string.h (basic_string::operator=): Use
	_M_use_local_data() instead of _M_local_buf on the moved-from
	string.
	* testsuite/21_strings/basic_string/modifiers/constexpr.cc
	(test_move): New test.

Signed-off-by: Paul Keir <paul.keir@uws.ac.uk>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

Jason, this is the patch you proposed for PR113545.  It looks very safe
so I'm posting it here so that it's not forgotten.

	PR c++/113545

gcc/cp/ChangeLog:

	* constexpr.cc (cxx_eval_switch_expr): If the condition doesn't reduce
	to an INTEGER_CST, consider it non-constant.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/constexpr-reinterpret3.C: Remove dg-ice.

lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849]

handle_cast handles the simple way all narrowing large/huge bitint to
large/huge bitint conversions and also such widening conversions if we can
assume that the most significant limb is processed using constant index
and both lhs and rhs have same number of limbs.
But, the condition whether we can rely on the most significant limb
being processed using constant index is incorrect.
For m_upwards_2limb it was correct (m_upwards_2limb then is the number
of limbs handled by the loop, so if lhs_type has larger precision than
that, it is handled with constant index), similarly if m_var_msb is set
(on left shifts), it is never handled with constant idx.  But in other
cases, like right shifts or non-equality comparisons, or bitquery operations
which operate from most significant to least significant limb, all those
can handle even the most significant limb in a loop when lhs_type has
precision which is a multiple of limb_prec.

So, the following patch punts on the optimization in that case and goes for
the conditionals in the loop for that case.

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

	PR tree-optimization/113849
	* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use
	fast path for widening casts where !m_upwards_2limb and lhs_type
	has precision which is a multiple of limb_prec.

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

The C and C++ FEs when parsing attributes already canonicalize them
(i.e. if they start with __ and end with __ substrings, we remove those).
lookup_attribute already verifies in gcc_assert that the first character
of name is not an underscore, and even lookup_scoped_attribute_spec doesn't
attempt to canonicalize the namespace it is passed.  But for some historic
reason it was canonicalizing the name argument, which misbehaves when
an attribute starts with ____ and ends with ____.
I believe it is just wrong to try to canonicalize
lookup_scope_attribute_spec name attribute, it should have been
canonicalized already, in other spots where it is called it is already
canonicalized before.

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

	PR c++/113674
	* attribs.cc (extract_attribute_substring): Remove.
	(lookup_scoped_attribute_spec): Don't call it.

	* c-c++-common/Wattributes-3.c: New test.

This patch depends on the libiberty/vprintf-support.c change.

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

	* gengtype.cc (adjust_field_rtx_def): Use HOST_SIZE_T_PRINT_UNSIGNED
	and cast to fmt_size_t instead of %lu and cast to unsigned long.

As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt
enablement patch this testcase FAILs on ia32, there is nothing vectorized in
there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted.

The following patch instead prunes it.

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

	* gcc.dg/pr113693.c: Guard _BitInt(837) use with
	__BITINT_MAXWIDTH__ >= 837.  Use dg-prune-output instead of
	dg-message for dbgcnt message.

When writing the HOST_SIZE_T_PRINT_UNSIGNED incremental patch,
my first bootstrap failed on i686-linux.  That is because I've also had
@@ -1344,8 +1344,10 @@ adjust_field_rtx_def (type_p t, options_
            }

          subfields = create_field (subfields, t,
-                                   xasprintf (".fld[%lu].%s",
-                                              (unsigned long) aindex,
+                                   xasprintf (".fld["
+                                              HOST_SIZE_T_PRINT_UNSIGNED
+                                              "].%s",
+                                              (fmt_size_t) aindex,
                                               subname));
          subfields->opt = nodot;
          if (t == note_union_tp)
hunk in gengtype.cc.  While sprintf obviously can print in this case %llu
with fmt_size_t being unsigned long long (that is another bug I'll fix
incrementally), seems libiberty_vprintf_buffer_size
can't deal with that, it ignores h, hh, l, ll and L modifiers and
unconditionally, estimates 30 chars as upper bounds for integers (that is
fine) and then uses (void) va_arg (ap, int); to skip over the argument
regardless if it was %d, %ld, %lld, %hd, %hhd etc.
Now, on x86_64 that happens to work fine probably for all of those,
on ia32 for everything but %lld, because it then skips just one half
of the long long argument; now as there is %s after it, it will try to
compute strlen not from the pointer argument corresponding to %s, but
from the most significant half of the previous long long argument.

So, the following patch attempts not to completely ignore the modifiers,
but figure out from them whether to va_arg an int (used for h and hh as
well), or long, or long long, or size_t, or ptrdiff_t - added support for
z and t there, plus for Windows I64.  And also %Lf etc. for long double.

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

	* vprintf-support.c (libiberty_vprintf_buffer_size): Handle
	properly l, ll, z, t or on _WIN32 I64 modifiers for diouxX
	and L modifier for fFgGeE.

Each major release is not binary compatible with the previous.

	PR d/113667

libphobos/ChangeLog:

	* configure: Regenerate.
	* configure.ac (libtool_VERSION): Update to 5:0:0.

The cause of the ICE was that TYPE_DECLs were only being generated for
structs with members, not opaque structs.

	PR d/113125

gcc/d/ChangeLog:

	* types.cc (TypeVisitor::visit (TypeStruct *)): Generate TYPE_DECL and
	apply UDAs to opaque struct declarations.

gcc/testsuite/ChangeLog:

	* gdc.dg/imports/pr113125.d: New test.
	* gdc.dg/pr113125.d: New test.

D front-end changes:

	- Import latest fixes from dmd v2.107.0.

D runtime changes:

	- Import latest fixes from druntime v2.107.0.

Included in the merge are the fix for PR113772, and new testsuite
directives to enable fixing PR104739.

	PR d/113772

gcc/d/ChangeLog:

	* dmd/MERGE: Merge upstream dmd 11240a9663.
	* d-builtins.cc (build_frontend_type): Update for new front-end
	interface.
	* types.cc (same_type_p): Likewise.

libphobos/ChangeLog:

	* libdruntime/MERGE: Merge upstream druntime 11240a9663.

When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed directly to the function that runs dtors.

When instead dealing with caller running destructors, two temporaries
were being generated, one explicit temporary generated by the D
front-end, and another implicitly by the code generator.  This has been
reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to
bind it to the implicit slot created for the TARGET_EXPR, as that has
the shorter lifetime of the two.

	PR d/113758

gcc/d/ChangeLog:

	* d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee
	destorys its arguments.
	* decl.cc (DeclVisitor::visit (VarDeclaration *)): Set
	SET_DECL_VALUE_EXPR on the temporary variable to make it a placeholder
	for the TARGET_EXPR_SLOT.

gcc/testsuite/ChangeLog:

	* gdc.dg/torture/pr113758.d: New test.

BUILD_INFO is currently a byproduct of checking makeinfo
presence/version.  INSTALL_INFO used to be defined similarly, but was
removed in 2000 (!) by commit 17db6582
(svn r38141).

In order to save build time, our CI overrides MAKEINFO=echo, which
works when invoking 'make all' but not for 'make install' in case some
info files need an update.

I noticed this while testing a patch posted on the gcc-patches list,
leading to an error at 'make install' time after updating tm.texi (the
build reported 'new text' in tm.texi and stopped).  This is because
'install' depends on 'install-info', which depends on
$(DESTDIR)$(infodir)/gccint.info (among others).

As discussed, it is better to detect this problem during 'make all'
rather than 'make install', and we still want to detect it even if
makeinfo is not available.

This patch makes configure set BUILD_INFO=no-info in case makeinfo is
missing/too old, which effectively makes the build rules no-ops
(x$(BUILD_INFO) != xinfo), and updates Makefile.in so that 'info'
dependencies are still checked.

2024-02-10  Christophe Lyon  <christophe.lyon@linaro.org>

	gcc/
	* Makefile.in: Add no-info dependency.
	* configure.ac: Set BUILD_INFO=no-info if makeinfo is not
	available.
	* configure: Regenerate.

The initial heap trampoline implementation was targeting 64b
platforms.  As the PR demonstrates this creates an issue where it
is expected that the same symbols are exported for 32 and 64b.

Rather than conditionalize the exports and code-gen on x86_64,
this patch provides a basic implementation of the IA32 trampoline.

This also avoids potential user confusion, when a 32b target has
64b multilibs, and vice versa; which is the case for Darwin.

	PR target/113855

gcc/ChangeLog:

	* config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
	available to all sub-targets.
	* config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
	* config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete.

libgcc/ChangeLog:

	* config.host: Add trampoline support to x?86-linux.
	* config/i386/heap-trampoline.c (trampoline_insns): Provide
	a variant for IA32.
	(union ix86_trampoline): Likewise.
	(__gcc_nested_func_ptr_created): Implement a basic trampoline
	for IA32.

Two libgomp tests XPASS on Solaris (any non-Linux target actually) since
their introduction:

XPASS: libgomp.c/alloc-pinned-1.c execution test
XPASS: libgomp.c/alloc-pinned-2.c execution test

The problem is that the test just prints

OS unsupported

and exits successfully, while the test is XFAILed:

/* { dg-xfail-run-if "Pinning not implemented on this host" { ! *-*-linux-gnu } } */

Fixed by aborting immediately after the message above in the non-Linux
case.

Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.

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

	libgomp:
	PR testsuite/113448
	* testsuite/libgomp.c/alloc-pinned-1.c [!__linux__] (CHECK_SIZE):
	Call abort.
	* testsuite/libgomp.c/alloc-pinned-2.c [!__linux__] (CHECK_SIZE):
	Likewise.

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.