A minimal fix to quash an extra ; warning.  I have a more complete
patch for GCC 15.

	DR 1693
	PR c++/113760

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_member_declaration): Only pedwarn about an extra
	semicolon in C++98.

gcc/testsuite/ChangeLog:

	* g++.dg/semicolon-fixits.C: Run in C++98 only.
	* g++.dg/warn/pedantic2.C: Adjust dg-warning.
	* g++.old-deja/g++.jason/parse11.C: Adjust dg-error.
	* g++.dg/DRs/dr1693-1.C: New test.
	* g++.dg/DRs/dr1693-2.C: New test.

Since push2/pop2 requires 16-byte stack alignment, don't use them if the
incoming stack isn't 16-byte aligned.

gcc/

	PR target/113876
	* config/i386/i386.cc (ix86_pro_and_epilogue_can_use_push2pop2):
	Return false if the incoming stack isn't 16-byte aligned.

gcc/testsuite/

	PR target/113876
	* gcc.target/i386/pr113876.c: New test.

OpenMP 5.0 only permits constant expressions for the 'condition' trait
in context selectors; this is relaxed in 5.2 but not implemented. In order
to avoid wrong code, it is now rejected.

Additionally, in Fortran, 'condition' should not accept an integer
expression, which is now ensured. Additionally, as 'device_num' should be
a conforming device number, there is now a check on the value.

	PR middle-end/113904

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_context_selector): Handle splitting of
	OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_context_selector): Handle splitting of
	OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.

gcc/fortran/ChangeLog:

	* trans-openmp.cc (gfc_trans_omp_declare_variant): Handle splitting of
	OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
	* openmp.cc (gfc_match_omp_context_selector): Likewise; rejects
	non-const device_num/condition; improve diagnostic.

gcc/ChangeLog:

	* omp-general.cc (struct omp_ts_info): Update for splitting of
	OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
	* omp-selectors.h (enum omp_tp_type): Replace
	OMP_TRAIT_PROPERTY_EXPR by OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/declare-variant-1.f90: Change 'condition' trait's
	argument from integer to a logical expression.
	* gfortran.dg/gomp/declare-variant-11.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-12.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-13.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-2.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-2a.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-3.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-4.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-6.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-8.f90: Likewise.
	* gfortran.dg/gomp/declare-variant-20.f90: New test.

The current implementation of bytes::calc_crc computes the checksum one
byte at a time which turns out to be quite slow, accounting for 15% of
streaming in time for a modular Hello World.  We have a crc32_unsigned
version that processes 4 bytes at a time which we could use here, but
since we bundle zlib we might as well use its highly optimized crc
routines that can process up to 32 bytes at a time.

So this patch makes us use zlib's crc32 in this hot code path.  This
reduces stream in time for a modular Hello World by around 15% for me
with a release compiler.

gcc/cp/ChangeLog:

	* Make-lang.in (CFLAGS-cp/module.o): Add $(ZLIBINC).
	* module.cc: Include <zlib.h>.
	(bytes::calc_crc): Use crc32 from zlib.
	(bytes_out::set_crc): Use crc32_combine from zlib.

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

Building modular fmtlib triggered two small modules bugs in C++23 and
C++26 mode respectively (due to libstdc++ header differences).

The first is that a TEMPLATE_DECL having DECL_LANG_SPECIFIC doesn't
necessarily imply that its DECL_TEMPLATE_RESULT has DECL_LANG_SPECIFIC.
So in add_specializations we need to use STRIP_TEMPLATE consistently;
this is a follow-up to r12-7187-gdb84f382ae3dc2.

The second is that get_originating_module_decl was ICEing on class-scope
enumerators injected via using-enum.  I suppose we should handle them
like a class-scope entity rather than a non-using-enum enumerator.

gcc/cp/ChangeLog:

	* module.cc (depset::hash::add_specializations): Use
	STRIP_TEMPLATE consistently.
	(get_originating_module_decl): Handle class-scope CONST_DECL.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/friend-6_a.C: New test.
	* g++.dg/modules/using-enum-3_a.C: New test.
	* g++.dg/modules/using-enum-3_b.C: New test.

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

It turns out that with modules we can call mangle_decl recursively
which is bad because the global mangling state isn't recursion aware.
The recursion happens from write_closure_type_name, which calls
lambda_function, which performs name lookup, which can trigger lazy
loading, which can call maybe_clone_body for a newly loaded cdtor, which
can inspect DECL_ASSEMBLER_NAME, which enters mangling.  This was
observed when using fmtlib as a module with trunk and it leads to a
bogus "mangling conflicts with a previous mangle error" followed by an
ICE from cdtor_comdat_group due to a mangling mismatch.

This patch fixes this by sidestepping lazy loading when performing the
op() lookup in lambda_function, so that we don't accidentally end up
entering mangling recursively.  This should be safe since the lazy load
should still get triggered by some other name lookup.

In passing it was noticed that lazy loading can get excessively recursive
ultimately due to the name lookups performed from check_local_shadow,
which may trigger lazy loading, which cause us to instantiate/clone
things, which end up calling check_local_shadow.  This patch mitigates
this by implementating an optimization suggested by Jason:

> I think we shouldn't bother with check_local_shadow in a clone or
> instantiation, only when actually parsing.

This reduces the maximum depth of lazy loading recursion for a simple
modular Hello World from ~115 to ~12.

gcc/cp/ChangeLog:

	* lambda.cc (lambda_function): Call get_class_binding_direct
	instead of lookup_member to sidestep lazy loading.
	* name-lookup.cc (check_local_shadow): Punt if we're in a
	function context that's not actual parsing.

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

	PR fortran/113866

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): When passing an optional
	dummy argument to an optional dummy argument of a bind(c) procedure
	and the dummy argument is passed via a CFI descriptor, no special
	presence check and passing of a default NULL pointer is needed.

gcc/testsuite/ChangeLog:

	* gfortran.dg/bind_c_optional-2.f90: New test.

If register_specialization finds a previous declaration and throws the new
one away, we shouldn't still add the new one to
DECL_TEMPLATE_SPECIALIZATIONS.

	PR c++/113612

gcc/cp/ChangeLog:

	* pt.cc (process_partial_specialization): Return early
	on redeclaration.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/var-templ85.C: New test.

gcc/ChangeLog:

	PR target/113742
	* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix
	recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/pr113742.c: New test.

On the heels of r14-8903, this patch adds further complain parameters
so that we don't emit "invalid use of incomplete type" from inside
a concept.

	PR c++/112436

gcc/cp/ChangeLog:

	* except.cc (expand_start_catch_block): Pass tf_warning_or_error to
	is_admissible_throw_operand_or_catch_parameter.
	(build_throw): Pass complain to
	is_admissible_throw_operand_or_catch_parameter.
	(complete_ptr_ref_or_void_ptr_p): Add a tsubst_flags_t parameter.  Use
	it.  Return bool.  Call complete_type_or_maybe_complain instead of
	complete_type_or_else.
	(is_admissible_throw_operand_or_catch_parameter): Add a tsubst_flags_t
	parameter.  Use it.  Guard error calls.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-pr112436.C: New test.

The SLP permute optimization rewrite fixed this.

	PR tree-optimization/113896
	* g++.dg/torture/pr113896.C: New testcase.

The recent enhancement to discover constant array indices by range
info used by get_ref_base_and_extent doesn't work when the outermost
component reference is to a bitfield because we track the running
offset in the reference ops as bytes.  The following does as
ao_ref_init_from_vn_reference and recovers that manually, tracking
the offset for the purpose of discovering the constant array index
in bits instead.

	PR tree-optimization/113895
	* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Track
	offset to discover constant array indices in bits, handle
	COMPONENT_REF to bitfields.

	* gcc.dg/torture/pr113895-1.c: New testcase.

As it turned out, my patch to complete the libgm2 autoconf macros works
on both Linux/sparc64 and Linux/x86_64, but breaks Solaris bootstrap:

/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_gettimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:148:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
  148 |   return gettimeofday (tv, tz);
      |                        ^~
      |                        |
      |                        void*
In file included from /usr/include/sys/select.h:27,
                 from /usr/include/sys/types.h:665,
                 from /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:35:
/usr/include/sys/time.h:444:18: note:   initializing argument 1 of 'int gettimeofday(timeval*, void*)'
  444 | int gettimeofday(struct timeval *_RESTRICT_KYWD, void *_RESTRICT_KYWD);
      |                  ^
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_settimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:165:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
  165 |   return settimeofday (tv, tz);
      |                        ^~
      |                        |
      |                        void*
/usr/include/sys/time.h:431:18: note: initializing argument 1 of 'int
settimeofday(timeval*, void*)'
  431 | int settimeofday(struct timeval *, void *);
      |                  ^~~~~~~~~~~~~~~~

This happens because on Linux only HAVE_[GS]ETTIMEOFDAY is defined,
while Solaris has both that and HAVE_STRUCT_TIMEZONE, selecting
different implementations.

Fixed by casting tv to struct timeval *.

I thought about changing the signatures instead to take a struct timeval
* instead, but that seemed risky given that there's a
HAVE_STRUCT_TIMEVAL, so would probably break other targets.

Bootstrapped without regressions on i386-pc-solaris2.11,
sparc-sun-solaris2.11, and x86_64-pc-linux-gnu.

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

	libgm2:
	* libm2iso/wraptime.cc [HAVE_STRUCT_TIMEZONE && HAVE_GETTIMEOFDAY]
	(EXPORT(gettimeofday)): Cast tv to struct timeval *.
	[HAVE_STRUCT_TIMEZONE && HAVE_SETTIMEOFDAY]
	(EXPORT(settimeofday)): Likewise.

	PR tree-optimization/113831
	* tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Fix
	typo in comment.

The following adjusts move_early_exit_stmts to track the last seen
VUSE instead of getting it from the last store which could be a PHI
where gimple_vuse doesn't work.

	PR tree-optimization/113902
	* tree-vect-loop.cc (move_early_exit_stmts): Track
	last_seen_vuse for VUSE updating.

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

When doing early break vectorization we should treat the final iteration as
possibly being partial.  This so that when we calculate the vector loop upper
bounds we take into account that final iteration could have done some work.

The attached testcase shows that if we don't then cunroll may unroll the loop an
if the upper bound is wrong we lose a vector iteration.

This is similar to how we adjust the scalar loop bounds for the PEELED case.

gcc/ChangeLog:

	PR tree-optimization/113734
	* tree-vect-loop.cc (vect_transform_loop): Treat the final iteration of
	an early break loop as partial.

gcc/testsuite/ChangeLog:

	PR tree-optimization/113734
	* gcc.dg/vect/vect-early-break_117-pr113734.c: New test.

When __has_feature was introduced for GCC 14, I included the feature
cxx_constexpr_string_builtins, since of the relevant string builtins
that GCC implements, it seems to support constexpr evaluation of those
builtins.

However, as the PR shows, GCC doesn't implement the full list of
builtins in the clang documentation.  After enumerating the builtins,
the clang docs [1] say:

> Support for constant expression evaluation for the above builtins can
> be detected with __has_feature(cxx_constexpr_string_builtins).

and a strict reading of this would suggest we can't really support
constexpr evaluation of a builtin if we don't implement the builtin in
the first place.

So the conservatively correct thing to do seems to be to stop
advertising the feature altogether to avoid failing to build code which
assumes the presence of this feature implies the presence of all the
builtins listed in the clang documentation.

[1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins

gcc/cp/ChangeLog:

	PR c++/113658
	* cp-objcp-common.cc (cp_feature_table): Remove entry for
	cxx_constexpr_string_builtins.

gcc/testsuite/ChangeLog:

	PR c++/113658
	* g++.dg/ext/has-feature2.C: New test.

The following fixes a missing add to the accumulated offset when
adjusting an ARRAY_REF op for value-ranges applied to by
get_ref_base_and_extent.

	PR tree-optimization/113898
	* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Add
	missing accumulated off adjustment.

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

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.