These two long-running tests happened to fail for me when
run in parallel (nprocs - 1) compared to a serial run, for
target mmix on my laptop.  The runtime is 3m40s for 3.cc
before this change, and 0.9s afterwards.

	* testsuite/std/time/year_month_day/3.cc (test01): Add ifdeffery to
	limit the tested dates.  For simulators, pass start and end dates
	limiting the tested range to 100000 days, centered on days (0).
	* testsuite/std/time/year_month_day/4.cc: Ditto.

Depending on the libc and filesystem, in cases where posix_fallocate
cannot do an efficient preallocation it may return EINVAL.  In such a
case we should fall back to ftruncate instead.

Apparently, depending on the system the use of posix_fallocate can have
a noticeable speedup over ftruncate in general (depending on the system)
so it probably isn't worth it to use ftruncate in all cases.

	PR c++/100358
	PR c++/115008

gcc/cp/ChangeLog:

	* module.cc (elf_out::create_mapping): Fallback to ftruncate if
	posix_fallocate fails.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

I noticed that in a couple of places we sometimes treat any TYPE_DECL of
lambda type as defining a lambda, which isn't always true since C++20:
in `using T = decltype([]{})`, T is not a lambda-declaration.

	PR c++/106221
	PR c++/110680

gcc/cp/ChangeLog:

	* pt.cc (check_default_tmpl_args): Check this is actually a
	lambda declaration and not just a typedef.
	(push_template_decl): Likewise.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/lambda-uneval19.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

The following testcases ICE because fold_array_ctor_reference in the
RAW_DATA_CST handling just return build_int_cst without actually checking
that if type is non-NULL, TREE_TYPE (val) is uselessly convertible to it.

By falling through the code after it without *suboff += we get everything
we need, the two if conditionals will never be true (we've already
checked that size == BITS_PER_UNIT and so can't be 0, and val will be
INTEGER_CST), but it will do the important fold_ctor_reference call
which will deal with type incompatibilities.

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

	PR tree-optimization/118207
	* gimple-fold.cc (fold_array_ctor_reference): For RAW_DATA_CST,
	just set val to build_int_cst and fall through to the normal
	element handling code instead of returning build_int_cst right away.

	* gcc.dg/pr118207.c: New test.

The test used #include "<generator>", so FAILed everywhere with
fatal error: <generator>: No such file or directory

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

	PR libstdc++/118196
	* testsuite/24_iterators/range_generators/pr118196.cc: Include
	<generator> rather than "<generator>".

gcc:
	* doc/install.texi (Specific) <*-ibm-aix*>: Drop verbose
	references to PTFs for AIX.

This reverts commit 40f243e9.

libstdc++-v3/ChangeLog:

	PR libstdc++/118196
	* include/std/generator (generator::operator=(generator)): Add
	missing 'return *this;'.
	* testsuite/24_iterators/range_generators/pr118196.cc: New test.

This overload requires

  constructible_from<remove_cvref_t<yielded>,
                     const remove_reference_t<yielded>&>

... but then tries to construct remove_cvref_t<yielded> implicitly,
which means it imposes an additional constraint not in the standard.

libstdc++-v3/ChangeLog:

	PR libstdc++/118022
	* include/std/generator
	(_Promise_erased::yield_value(const _Yielded_deref&)): Don't
	implicit-constuct _Yielded_decvref.
	* testsuite/24_iterators/range_generators/pr118022.cc: New test.

We can't vectorize the code into instructions like vslti.w that compare
with immediate_operand, because we miss immediate_operand support for
integer comparisons.

gcc/ChangeLog:

	* config/loongarch/lasx.md (vec_cmp<mode><mode256_i>): Remove.
	(vec_cmpu<ILASX:mode><mode256_i>): Remove.
	* config/loongarch/loongarch.cc (loongarch_expand_lsx_cmp):
	Ensure vector comparison instructions support CMP_OP1.
	* config/loongarch/lsx.md (vec_cmp<mode><mode_i>): Remove.
	(vec_cmpu<ILSX:mode><mode_i>): Remove.
	* config/loongarch/simd.md (ALLVEC, allmode_i): New mode iterators.
	(vec_cmp<mode><allmode_i>): New define_expand.
	(vec_cmpu<mode><allmode_i>): Likewise.

gcc/testsuite/ChangeLog:

	* gcc.target/loongarch/vector/lasx/lasx-vcond-3.c: New test.

2024-12-26  John David Anglin  <danglin@gcc.gnu.org>

gcc/ChangeLog:

	PR target/118050
	* timevar.cc (get_time): Only use CLOCK_MONOTONIC if
	'_POSIX_TIMERS > 0 && defined(_POSIX_MONOTONIC_CLOCK)'.
	Otherise, use CLOCK_REALTIME.

gcc:
	* doc/gm2.texi (Dialect): Move PM4 link to https.

We hardly ever emit code using machine instructions for aligned memory
accesses for block move and clear operation and the reason for this
appears to be that suboptimal alignment is often passed by the caller
and then we only try to find a better alignment by checking pseudo
register pointer alignment information, and from observation it's most
often only set for stack frame references.

This code originates from before Tree SSA days and we can do better
nowadays, by looking up the original tree node associated with a MEM
RTL, so implement this approach, factoring out repeating code from
`alpha_expand_block_move' and `alpha_expand_block_clear' to a new
function.

In some cases howewer tree information is not available while pointer
alignment is, such as with the case concerned with PR target/115459,
where we have:

(gdb) pr orig_src
(mem:BLK (plus:DI (reg/f:DI 65 virtual-stack-vars [ lock.206_2 ])
        (const_int 8368 [0x20b0])) [8  S18 A8])
(gdb) pr orig_dst
(mem/j/c:BLK (plus:DI (reg/f:DI 65 virtual-stack-vars [ lock.206_2 ])
        (const_int 8208 [0x2010])) [8 MEM[(struct gnat__debug_pools__print_info_stdout__internal__L_18__B1182b__S1183b___PAD *)_339].F[1 ...]{lb: 1 sz: 1}+0 S18 A128])
(gdb)

showing no tree information and the alignment of 8 only for `orig_src',
while indeed REGNO_POINTER_ALIGN returns 128 for pseudo 65.  So retain
the old approach and return the largest alignment determined and its
associated offset.

Add test cases accordingly and remove XFAILs from memclr-a2-o1-c9-ptr.c
now that it does get aligned code produced now.

	gcc/
	* config/alpha/alpha.cc
	(alpha_get_mem_rtx_alignment_and_offset): New function.
	(alpha_expand_block_move, alpha_expand_block_clear): Use it for
	alignment retrieval.

	gcc/testsuite/
	* gcc.target/alpha/memclr-a2-o1-c9-ptr.c: Remove XFAILs.
	* gcc.target/alpha/memcpy-di-aligned.c: New file.
	* gcc.target/alpha/memcpy-di-unaligned.c: New file.
	* gcc.target/alpha/memcpy-di-unaligned-dst.c: New file.
	* gcc.target/alpha/memcpy-di-unaligned-src.c: New file.

Correct the offset adjustment made in the multi-word unaligned access
helpers such that it is actually used by the unaligned load and store
instructions, fixing a bug introduced with commit 1eb356b9 ("alpha
gprel optimizations")[1] back in 2001, which replaced address changes
made directly according to the argument of the MEM expression passed
with one made according to an address previously extracted from said MEM
expression.  The address is however incorrectly extracted from said MEM
before an adjustment has been made to it for the offset supplied.

This bug is usually covered by the fact that our block move and clear
operations are hardly ever provided with correct block alignment data
and we also usually fail to fetch that information from the MEM supplied
(although PR target/115459 shows it does happen sometimes).  Instead the
bit alignment of 8 is usually conservatively used, meaning that a zero
offset is passed to `alpha_expand_unaligned_store_words' and then code
has been written such that neither `alpha_expand_unaligned_load_words'
nor `alpha_expand_unaligned_store_words' cannot ever be called with
nonzero offset from `alpha_expand_block_move'.

The only situation where `alpha_expand_unaligned_store_words' can be
called with nonzero offset is from `alpha_expand_block_clear' with a BWX
target for a misaligned block that has been embedded in a data object of
a higher alignment such that there is a small unaligned prefix our code
decides to handle so as to align further stores.

For instance it happens when a block clear is called for a block of 9
bytes embedded at offset 1 in a structure aligned to a 2-byte word, as
illustrated by the test case included.  Now this test case does not work
without the change that comes next applied, because the backend cannot
see the word alignment of the struct and uses the bit alignment of 8
instead.

Should this change be swapped with the next one incorrect code such as:

	stb $31,1($16)
	lda $3,1($16)
	ldq_u $2,8($16)
	ldq_u $1,1($16)
	mskqh $2,$3,$2
	stq_u $2,8($16)
	mskql $1,$3,$1
	stq_u $1,1($16)

would be produced, where the unadjusted offsets of 1/8 can be seen with
the LDQ_U/STQ_U operations along with byte masks calculated accordingly
rather than the expected offsets of 2/9.  As a result the byte at the
offset of 9 fails to get cleared.  In these circumstances this would
also show as execution failures with the memclr.c test:

FAIL: gcc.c-torture/execute/memclr.c   -O1  execution test
FAIL: gcc.c-torture/execute/memclr.c   -Os  execution test

-- not at `-O0' though, as the higher alignment cannot be retrieved in
that case, and then not at `-O2' or higher optimization levels either,
because then we choose to open-code this block clear instead:

	ldbu $1,0($16)
	stw $31,8($16)
	stq $1,0($16)

avoiding the bug in `alpha_expand_unaligned_store_words'.

I am leaving the pattern match test case XFAIL-ed here for documentation
purposes and it will be un-XFAIL-ed along with the fix to retrieve the
correct alignment.  The run test is of course never expected to fail.

References:

[1] <https://inbox.sourceware.org/gcc-patches/20010909020708.A29152@twiddle.net/>

	gcc/
	* config/alpha/alpha.cc (alpha_expand_unaligned_load_words):
	Move address extraction until after the MEM referred has been
	adjusted for the offset supplied.
	(alpha_expand_unaligned_store_words): Likewise.

	gcc/testsuite/
	* gcc.target/alpha/memclr-a2-o1-c9-ptr.c: New file.
	* gcc.target/alpha/memclr-a2-o1-c9-run.c: New file.

By inference it appears to me that the same fix for PR target/115459
needs to be applied to the block clear operation that has been done for
block move, as implemented by commit ccfe7151 ("[alpha] adjust MEM
alignment for block move [PR115459]").

	gcc/
	PR target/115459
	* config/alpha/alpha.cc (alpha_expand_block_clear): Adjust MEM
	to match inferred alignment.

Remove code duplication in the part of `alpha_expand_block_clear' that
handles any aligned trailing part of the block, observing that the two
legs of code only differ by the machine mode and that we already take
the same approach with handling any unaligned prefix earlier on.  No
functional change, just code shuffling.

	gcc/
	* config/alpha/alpha.cc (alpha_expand_block_clear): Fold two
	legs of a conditional together.

Eliminate a redundant bitwise inclusive OR operation on the insertion of
constant zero into a bit-field, improving code produced at `-O2' from an
output sequence such as:

	mov $31,$3				# Redundant!
	ldq_u $1,7($16)
	insqh $3,$16,$3				# Redundant!
	ldq_u $2,0($16)
	mskqh $1,$16,$1
	mskql $2,$16,$2
	bis $1,$3,$1				# Redundant!
	stq_u $1,7($16)
	stq_u $2,0($16)
	ret $31,($26),1

to:

	ldq_u $2,7($16)
	ldq_u $1,0($16)
	mskqh $2,$16,$2
	stq_u $2,7($16)
	mskql $1,$16,$1
	stq_u $1,0($16)
	ret $31,($26),1

for a quadword unaligned store operation.  As shown in the example this
only triggers for the high-part store (and therefore only for 2-byte,
4-byte, and 8-byte stores), because `insXl' insns are fully expressed in
terms of RTL and therefore the insertion of zero is eliminated in later
RTL passes, however corresponding `insXh' insns are unspecs only, making
them impossible to see through.

We can get this optimal right from expand though, given that our handler
for "insvmisaligndi", i.e. `alpha_expand_unaligned_store', has explicit
provisions for `const0_rtx' source.

	gcc/
	* config/alpha/alpha.md (insvmisaligndi): Use "reg_or_0_operand"
	rather than "register_operand" for operand 3.

	gcc/testsuite/
	* gcc.target/alpha/stlx0.c: New file.
	* gcc.target/alpha/stqx0.c: New file.
	* gcc.target/alpha/stwx0.c: New file.
	* gcc.target/alpha/stwx0-bwx.c: New file.

Expand coverage for unaligned memory stores, for the "insvmisalignM"
patterns, for 2-byte, 4-byte, and 8-byte scalars, across byte alignments
of 1, 2, 4 and byte misalignments within from 0 up to 7 (there's some
redundancy there for the sake of simplicity of the test case), making
sure all data is written and no data is changed outside the area meant
to be written.

The test case has turned invaluable in verifying changes to the Alpha
backend, but functionality covered is generic, so I have concluded this
test qualifies for generic verification and does not have to be limited
to the Alpha-specific subset of the testsuite.

	gcc/testsuite/
	* gcc.c-torture/execute/misalign.c: New file.

Expand coverage for `__builtin_memset' for the special case of clearing
a block, primarily for "setmemM" block set pattern, though with smaller
sizes open-coded sequences may be produced instead.

This verifies block sizes in bytes from 1 to 64 across byte alignments
of 1, 2, 4, 8 and byte misalignments within from 0 up to 7 (there's some
redundancy there for the sake of simplicity of the test case), making
sure all the intended area is cleared and no data is changed outside it.

These choice of the ranges for the parameters has come from the Alpha
backend, whose "setmemM" pattern has various corner cases related to
base alignment and the misalignment within.

The test case has turned invaluable in verifying changes to the Alpha
backend, but functionality covered is generic, so I have concluded this
test qualifies for generic verification and does not have to be limited
to the Alpha-specific subset of the testsuite.

Just as with `__builtin_memcpy' tests this code turned out to require
quite a lot of time to compile, although a bit less than the former.

Example compilation times with reasonably fast POWER9@2.166GHz at `-O2'
optimization and GCC built at `-O2' for various targets:

mips-linux-gnu:        19s
vax-netbsdelf:         27s
alphaev56-linux-gnu:   30s
alpha-linux-gnu:       31s
powerpc64le-linux-gnu: 47s

With GCC built at `-O0':

alphaev56-linux-gnu: 2m59s
alpha-linux-gnu:     3m06s

I have therefore set the timeout factor accordingly so as to take slower
test hosts into account.

	gcc/testsuite/
	* gcc.c-torture/execute/memclr.c: New file.

Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the
Alpha testsuite as several targets already do.  Add `-Og -g' and `-Oz'
as well via ADDITIONAL_TORTURE_OPTIONS to expand coverage.  Adjust test
options across individual test cases accordingly where required.

Discard base-2.c, cix-2.c, and max-2.c test cases as they merely are
optimization variants of base-1.c, cix-1.c, and max-1.c respectively,
run at `-O2' rather than the default level (`-O0'), now covered by the
framework with the latter ones in a generic way.

Old test results:

		=== gcc Summary ===

# of expected passes		44

vs new ones:
		=== gcc Summary ===

# of expected passes		364
# of unsupported tests		5

	gcc/testsuite/
	* gcc.target/alpha/alpha.exp: Use `gcc-dg-runtest' rather than
	`dg-runtest'.  Add `-Og -g' and `-Oz' variants via
	ADDITIONAL_TORTURE_OPTIONS.
	* gcc.target/alpha/20000715-1.c: Adjust test options
	accordingly.
	* gcc.target/alpha/20011018-1.c: Likewise.
	* gcc.target/alpha/980217-1.c: Likewise.
	* gcc.target/alpha/asm-1.c: Likewise.
	* gcc.target/alpha/pr105209.c: Likewise.
	* gcc.target/alpha/pr106966.c: Likewise.
	* gcc.target/alpha/pr115297.c: Likewise.
	* gcc.target/alpha/pr115526.c: Likewise.
	* gcc.target/alpha/pr19518.c: Likewise.
	* gcc.target/alpha/pr22093.c: Likewise.
	* gcc.target/alpha/pr24178.c: Likewise.
	* gcc.target/alpha/pr39740.c: Likewise.
	* gcc.target/alpha/pr42113.c: Likewise.
	* gcc.target/alpha/pr42269-1.c: Likewise.
	* gcc.target/alpha/pr42448-1.c: Likewise.
	* gcc.target/alpha/pr42448-2.c: Likewise.
	* gcc.target/alpha/pr42774.c: Likewise.
	* gcc.target/alpha/pr61586.c: Likewise.
	* gcc.target/alpha/pr66140.c: Likewise.
	* gcc.target/alpha/pr83628-1.c: Likewise.
	* gcc.target/alpha/pr83628-2.c: Likewise.
	* gcc.target/alpha/pr83628-3.c: Likewise.
	* gcc.target/alpha/pr86984.c: Likewise.
	* gcc.target/alpha/sqrt.c: Likewise.
	* gcc.target/alpha/base-2.c: Remove file.
	* gcc.target/alpha/cix-2.c: Remove file.
	* gcc.target/alpha/max-2.c: Remove file.

The hook changes the allocno class to either FP_REGS or GR_REGS depending on
the mode of the register. This results in better register allocation overall,
fewer spills and reduced codesize - particularly in SPEC2017 lbm.

gcc/ChangeLog:

	* config/loongarch/loongarch.cc
	(loongarch_ira_change_pseudo_allocno_class): New function.
	(TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Define macro.

It seems that tokens_buff_new() has always been allocating the virtual
location buffer 4 times larger than intended, and now that location_t is
64-bit, it is 8 times larger. Fixed.

libcpp/ChangeLog:

	* macro.cc (tokens_buff_new): Fix length argument to XNEWVEC.

Running tests in parallel on my 4.5y+ old laptop made this
test time out: the test itself runs in 9m20s, the timeout
being 10 minutes with the 2x factor.  That's a bit too close.

This commit does to the base test a similar change as was
done for gcc.dg/torture/inline-mem-cpy-1.c in commit
r14-8188-g6eca0d23b7ea84; or IOW cut it down a factor of 7
(r14-8188 was by a factor of 11).

	* gcc.dg/memcmp-1.c: Pass -DRUN_FRACTION=7 when testing in a simulator.

Without this, after r15-6415-g586477d67bf2e3, you'll see,
for targets where int32_t is a typedef of long int (beware
of artificially broken lines):

/x/gcc/libgfortran/caf/single.c: In function '_gfortran_caf_get_by_ct':
/x/gcc/libgfortran/caf/single.c:2943:56: error: passing argument 2 of '\
(accessor_hash_table + (sizetype)((unsigned int)getter_index * 12))->ac\
cessor' from incompatible pointer type [-Wincompatible-pointer-types]
 2943 |   accessor_hash_table[getter_index].accessor (dst_ptr, &free_bu\
ffer, src_ptr,
      |                                                        ^~~~~~~~\
~~~~
      |                                                        |
      |                                                        int *
/x/gcc/libgfortran/caf/single.c:2943:56: note: expected 'int32_t *' {ak\
a 'long int *'} but argument is of type 'int *'

libgfortran:
	* caf/single.c (_gfortran_caf_get_by_ct): Correct type of free_buffer
	to int32_t.

Commit r15-6408 overlooked the case of passing NULL without MOLD argument
to a derived type pointer dummy argument without specified intent.  Since
it is prohibited to modify the dummy argument, we treat it as if intent(in)
were specified and suppress copying back of the pointer address.

	PR fortran/118179

gcc/fortran/ChangeLog:

	* trans-expr.cc (conv_null_actual): Suppress copying back of
	pointer address for unspecified intent.

gcc/testsuite/ChangeLog:

	* gfortran.dg/null_actual_7.f90: Extend testcase to also cover
	scalar variants with pointer or allocatable dummy with or without
	specified intent.

gcc/testsuite/ChangeLog:

	PR fortran/107635

	* gfortran.dg/coarray_lib_comm_1.f90: Use less complicated
	pattern, because all we need is the right count.

'make tags' currently fails for libcc1 with this:
 *** No rule to make target `marshall-c.hh', needed by `tags-am'.  Stop.

The problem is that while marshall-c.hh has been removed via
r12-454-g25d1a6ecdc443f, it's still part of the libcc1_la_SOURCES
variable, hence the 'tags' target has a dependency on it.

This patch simply removes the marshall_c_source variable, that should be
empty.

libcc1/ChangeLog:

	* Makefile.am: Remove reference to deleted marshall-c.h.
	* Makefile.in: Regenerate.

2024-12-23  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran/ChangeLog

	PR fortran/116254
	* trans-array.cc (gfc_trans_create_temp_array): Make sure that
	transformational intrinsics of class objects that change rank,
	most particularly spread, go through the correct code path. Re-
	factor so that changes to the dtype are done on the temporary
	before the class data of the result points to it.

	PR fortran/118059
	* trans-expr.cc (arrayfunc_assign_needs_temporary): Character
	array function expressions assigned to an unlimited polymorphic
	variable require a temporary.

Recently two test cases for PR118149 have been added.
While pr118149-2.c works well for AArch64, pr118149.c fails
because the expected optimization in forwprop4 cannot be applied
as SLP vectorization does not happen.
This patch fixes this issue by disabling the check on AArch64.

gcc/testsuite/ChangeLog:

	* gcc.dg/tree-ssa/pr118149.c: Disable for AArch64.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

ChangeLog:

	* MAINTAINERS: Add myself to write after approval.

gcc:
	* doc/invoke.texi (HPPA Options): Remove references
	to HP-UX 8 and HP-UX 9.

Fix identifier names to be too similar to Modula-2 keywords and causing
warnings coming from Modula-2's own libraries.

m2/m2log/InOut.mod:51:18: note: In implementation module ‘InOut’:
either the identifier has the same name as a keyword or alternatively a
keyword has the wrong case (‘IN’ and ‘in’)
   51 |    in, out: File ;

m2/m2log/InOut.mod:51:18: note: the symbol name ‘in’ is legal as an
identifier, however as such it might cause confusion and is considered
bad programming practice

gcc/gm2:
	* gm2-libs-log/InOut.mod: Fix bad identifier warning.

Signed-off-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>

gcc/fortran/ChangeLog:

	* check.cc (gfc_check_random_seed): Clear gmp variables returned by
	gfc_array_size.
	* expr.cc (gfc_check_pointer_assign): Likewise.