Fortran: Fix ICE with use of c_associated.

PR fortran/120049

gcc/fortran/ChangeLog:

* check.cc (gfc_check_c_associated): Modify checks to avoid
ICE and allow use, intrinsic :: iso_c_binding from a separate
module file.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr120049_a.f90: New test.
* gfortran.dg/pr120049_b.f90: New test.

(cherry picked from commit d0571638a6bad932b226ada98b167fa47a47d838)

Daily bump.

Update cpplib es.po

* es.po: Update.

Alpha: Fix base block alignment calculation regression

In determination of base block alignment we only examine a COMPONENT_REF
tree node at hand without ever checking if its ultimate alignment has
been reduced by the combined offset going back to the outermost object.
Consequently cases have been observed where quadword accesses have been
produced for a memory location referring a nested struct member only
aligned to the longword boundary, causing emulation to trigger.

Address this issue by recursing into COMPONENT_REF tree nodes until the
outermost one has been reached, which is supposed to be a MEM_REF one,
accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha:
Also use tree information to get base block alignment") regression.

Bail out and refrain from using tree information for alignment if we end
up at something different or we are unable to calculate the offset at
any point.

gcc/
* config/alpha/alpha.cc
(alpha_get_mem_rtx_alignment_and_offset): Recurse into
COMPONENT_REF nodes.

gcc/testsuite/
* gcc.target/alpha/memcpy-nested-offset-long.c: New file.
* gcc.target/alpha/memcpy-nested-offset-quad.c: New file.

(cherry picked from commit 1dd769b3d0d9251649dcb645d7ed6c4ba2202306)

Daily bump.

c++: unifying specializations of non-primary tmpls [PR120161]

Here unification of P=Wrap<int>::type, A=Wrap<long>::type wrongly
succeeds ever since r14-4112 which made the RECORD_TYPE case of unify
no longer recurse into template arguments for non-primary templates
(since they're a non-deduced context) and so the int/long mismatch that
makes the two types distinct goes unnoticed.

In the case of (comparing specializations of) a non-primary template,
unify should still go on to compare the types directly before returning
success.

PR c++/120161

gcc/cp/ChangeLog:

* pt.cc (unify) <case RECORD_TYPE>: When comparing specializations
of a non-primary template, still perform a type comparison.

gcc/testsuite/ChangeLog:

* g++.dg/template/unify13.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 0c430503f2849ebb20105695b8ad40d43d797c7b)

Update gcc zh_CN.po

* zh_CN.po: Update.

Fix explicit arrays with non-constant size for -fc-prototypes.

gcc/fortran/ChangeLog:

PR fortran/120139
* dump-parse-tree.cc (get_c_type_name): If no constant
size of an array exists, output an asterisk.

(cherry picked from commit 4f9c7b5258f2af89bba8e954c277981d2e2ee1ef)

Do not dump non-interoperable types with -fc-prototypes.

gcc/fortran/ChangeLog:

PR fortran/120107
* dump-parse-tree.cc (write_type): Do not dump non-interoperable
types.

(cherry picked from commit fa0dff8e99e81bc7a3db1dc57d4fc340e0525b1d)

Update cpplib zh_CN.po

* zh_CN.po: Update.

Daily bump.

Update gcc sv.po

* sv.po: Update.

Update cpplib es.po

* es.po: Update.

dwarf2out: Propagate dtprel into the .debug_addr table in resolve_addr_in_expr

For a debugger to display statically-allocated[0] TLS variables the compiler
must communicate information[1] that can be used in conjunction with knowledge
of the runtime enviroment[2] to calculate a location for the variable for
each thread. That need gives rise to dw_loc_dtprel in dwarf2out, a flag tracking
whether the location description is dtprel, or relative to the
"dynamic thread pointer". Location descriptions in the .debug_info section for
TLS variables need to be relocated by the static linker accordingly, and
dw_loc_dtprel controls emission of the needed relocations.

This is further complicated by -gsplit-dwarf. -gsplit-dwarf is designed to allow
as much debugging information as possible to bypass the static linker to improve
linking performance. One of the ways that is done is by introducing a layer of
indirection for relocatable values[3]. That gives rise to addr_index_table which
ultimately results in the .debug_addr section.

While the code handling addr_index_table clearly contemplates the existence of
dtprel entries[4] resolve_addr_in_expr does not, and the result is that when
using -gsplit-dwarf the DWARF for TLS variables contains an address[5] rather
than an offset, and debuggers can't work with that.

This is visible on a trivial example. Compile

```
static __thread int tls_var;

int main(void) {
  tls_var = 42;
  return 0;
}
```

with -g and -g -gsplit-dwarf. Run the program under gdb. When examining the
value of tls_var before and after the assignment, -g behaves as one would
expect but -g -gsplit-dwarf does not. If the user is lucky and the miscalculated
address is not mapped, gdb will print "Cannot access memory at address ...".
If the user is unlucky and the miscalculated address is mapped, gdb will simply
give the wrong value. You can further confirm that the issue is the address
calculation by asking gdb for the address of tls_var and comparing that to what
one would expect.[6]

Thankfully this is trivial to fix by modifying resolve_addr_in_expr to propagate
the dtprel character of the location where necessary. gdb begins working as
expected and the diff in the generated assembly is clear.

```
        .section        .debug_addr,"",@progbits
        .long   0x14
        .value  0x5
        .byte   0x8
        .byte   0
 .Ldebug_addr0:
-       .quad   tls_var
+       .long   tls_var@dtpoff, 0
        .quad   .LFB0
```

[0] Referring to e.g. __thread as statically-allocated vs. e.g. a
    dynamically-allocated pthread_key_create() call.
[1] Generally an offset in a TLS block.
[2] With glibc, provided by libthread_db.so.
[3] Relocatable values are moved to a table in the .debug_addr section, those
    values in .debug_info are replaced with special values that look up indexes
    in that table, and then the static linker elsewhere assigns a single per-CU
    starting index in the .debug_addr section, allowing those special values to
    remain permanently fixed and the resulting data to be ignored by the linker.
[4] ate_kind_rtx_dtprel exists, after all, and new_addr_loc_descr does produce
    it where appropriate.
[5] e.g. an address in the .tbss/.tdata section.
[6] e.g. on x86-64 by examining %fsbase and the offset in the assembly

2025-05-01  Kyle Huey  <me@kylehuey.com>

* dwarf2out.cc (resolve_addr_in_expr): Propagate dtprel into the address
table when appropriate.

c++/modules: Fix handling of -fdeclone-ctor-dtor with explicit instantiations [PR120125]

The attached testcase ICEs in maybe_thunk_body because we haven't
created a node in the cgraph for an imported explicit instantiation yet.

We in fact really shouldn't be emitting calls at all, since an imported
explicit instantiation always exists in the TU we imported it from.  So
this patch adjusts DECL_NOT_REALLY_EXTERN handling to account for this.

PR c++/120125

gcc/cp/ChangeLog:

* module.cc (trees_out::write_function_def): Only set
DECL_NOT_REALLY_EXTERN if the importer might need to emit it.
* optimize.cc (maybe_thunk_body): Don't assume 'fn' has a cgraph
node created.

gcc/testsuite/ChangeLog:

* g++.dg/modules/clone-4_a.C: New test.
* g++.dg/modules/clone-4_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit d787bc4fd372298e9ed5b11cb3050fd3707070f6)

c++: Fix OpenMP support with C++20 modules [PR119864]

In r15-2799-gf1bfba3a9b3f31, a new kind of global constructor was added.
Unfortunately this broke C++20 modules, as both the host and target
constructors were given the same mangled name.  This patch ensures that
only the host constructor gets the module name mangling for now, and
stops forcing the creation of the target constructor even when no such
initialization is required.

PR c++/119864

gcc/cp/ChangeLog:

* decl2.cc (start_objects): Only use module initialized for
host.
(c_parse_final_cleanups): Don't always create an OMP offload
init function in modules.

gcc/testsuite/ChangeLog:

* g++.dg/modules/openmp-1.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 79b7e37ea3fbbc43958190f69f6da3be3d809c9c)

Daily bump.

Do not generate formal arglist from actual if we have already resolved it.

This bug was another case of generating a formal arglist from
an actual one where we should not have done so.  The fix is
straightforward:  If we have resolved the formal arglist, we should
not generare a new one.

OK for trunk and backport?

gcc/fortran/ChangeLog:

PR fortran/120163
* gfortran.h: Add formal_resolved to gfc_symbol.
* resolve.cc (gfc_resolve_formal_arglist): Set it.
(resolve_function): Do not call gfc_get_formal_from_actual_arglist
if we already resolved a formal arglist.
(resolve_call): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/120163
* gfortran.dg/interface_61.f90: New test.

[PATCH] PR modula2/120117: ICE when attempting to obtain the MAX of an aliased set type

The ICE occurred because of a bug in M2GenGCC.mod:FoldBecomes which
attempted to remove the same quadruple twice.  Thereafter cc1gm2
generated an erroneous error type error as PCSymBuild did not skip
an aliased set type.  The type of the const was set incorrectly
(as a set type) rather than the type of the set element.

gcc/m2/ChangeLog:

PR modula2/120117
* gm2-compiler/M2GenGCC.mod (FoldBecomes): Remove the call to
RemoveQuad since this is performed by TypeCheckBecomes.
* gm2-compiler/PCSymBuild.mod (buildConstFunction): Rewrite
header comment.
Check for a set or a type aliased set and appropriately
skip type equivalences and obtain the element type.
* gm2-compiler/SymbolTable.mod (PutConst): Add call to
CheckBreak.

gcc/testsuite/ChangeLog:

PR modula2/120117
* gm2/pim/pass/highbit.mod: New test.
* gm2/pim/pass/highbit2.mod: New test.

(cherry picked from commit bb83283e5c5c55eab7493a58c5e415aa56f5940c)

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

[PATCH] PR modula2/115276: libgm2 wraptime.cc field access all return -1.

This patch provides autoconf tests for each field used in wraptime.cc
referencing struct tm and struct timeval.

libgm2/ChangeLog:

PR modula2/115276
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac (AC_STRUCT_TIMEZONE): Add.
(AC_CHECK_MEMBER): Test for struct tm.tm_year.
(AC_CHECK_MEMBER): Test for struct tm.tm_mon.
(AC_CHECK_MEMBER): Test for struct tm.tm_mday.
(AC_CHECK_MEMBER): Test for struct tm.tm_hour.
(AC_CHECK_MEMBER): Test for struct tm.tm_min.
(AC_CHECK_MEMBER): Test for struct tm.tm_sec.
(AC_CHECK_MEMBER): Test for struct tm.tm_year.
(AC_CHECK_MEMBER): Test for struct tm.tm_yday.
(AC_CHECK_MEMBER): Test for struct tm.tm_wday.
(AC_CHECK_MEMBER): Test for struct tm.tm_isdst.
(AC_CHECK_MEMBER): Test for struct timeval.tv_sec.
(AC_CHECK_MEMBER): Test for struct timeval.tv_sec.
(AC_CHECK_MEMBER): Test for struct timeval.tv_usec.
* libm2iso/wraptime.cc (InitTimeval): Guard against lack
struct timeval and malloc.
(InitTimezone): Guard against lack of struct tm.tm_zone
and malloc.
(KillTimezone): Ditto.
(InitTimeval): Guard against lack of struct timeval
and malloc.
(KillTimeval): Guard against lack of malloc.
(settimeofday): Guard against lack of struct tm.tm_zone.
(GetFractions): Guard against lack of struct timeval.
(localtime_r): Ditto.
(GetYear): Guard against lack of struct tm.
(GetMonth): Ditto.
(GetDay): Ditto.
(GetHour): Ditto.
(GetMinute): Ditto.
(GetSecond): Ditto.
(GetSummerTime): Ditto.
(GetDST): Guards against lack of struct timezone.
(SetTimezone): Ditto.
(SetTimeval): Guard against lack of struct tm.

(cherry picked from commit 419f40af5c5335b84c16e4891377142f12f7577b)

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

[PATCH] PR modula2/119915: Sprintf1 repeats the entire format string if it starts with a directive

This bugfix is for FormatStrings to ensure that in the case of %x, %u the
procedure function PerformFormatString uses Copy rather than Slice to
avoid the case on an upper bound of zero in Slice.  Oddly the %d case
had the correct code.

gcc/m2/ChangeLog:

PR modula2/119915
* gm2-libs/FormatStrings.mod (PerformFormatString): Handle
the %u and %x format specifiers in a similar way to the %d
specifier.  Avoid using Slice and use Copy instead.

gcc/testsuite/ChangeLog:

PR modula2/119915
* gm2/pimlib/run/pass/format2.mod: New test.

(cherry picked from commit 7a4f7a92770db4e739e76a06175454ba38d60b22)

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

[PATCH] PR modula2/119914 No error message generated when passing a Ztype to an unbounded array

This patch detects constants ZType, RType, CType being passed to unbounded
arrays and generates an error message highlighting the formal and
actual parameters in error.

gcc/m2/ChangeLog:

PR modula2/119914
* gm2-compiler/M2Check.mod (checkConstMeta): Add check for
Ztype, Rtype and Ctype and unbounded arrays.
(IsZRCType): New procedure function.
(isZRC): Add comment.
* gm2-compiler/M2Quads.mod:
* gm2-compiler/M2Range.mod (gdbinit): New procedure.
(BreakWhenRangeCreated): Ditto.
(CheckBreak): Ditto.
(InitRange): Call CheckBreak.
(Init): Add gdbhook and initialize interactive watch point.
* gm2-compiler/SymbolTable.def (GetNthParamAnyClosest): New
procedure function.
* gm2-compiler/SymbolTable.mod (BreakSym): Remove constant.
(BreakSym): Add Variable.
(stop): Remove.
(gdbhook): New procedure.
(BreakWhenSymCreated): Ditto.
(CheckBreak): Ditto.
(NewSym): Call CheckBreak.
(Init): Add gdbhook and initialize interactive watch point.
(MakeProcedure): Replace guarded call to stop with CheckBreak.
(GetNthParamChoice): New procedure function.
(GetNthParamOrdered): Ditto.
(GetNthParamAnyClosest): Ditto.
(GetOuterModuleScope): Ditto.

gcc/testsuite/ChangeLog:

PR modula2/119914
* gm2/pim/fail/constintarraybyte.mod: New test.

(cherry picked from commit e9a81addd5b7d018e173fa8d59aafc2f84e41d8b)

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

[PATCH] PR modula2/120188: Use existing test for plugin

This is a cleanup patch which to use the existing plugin test
rather than check the configure build options.

gcc/testsuite/ChangeLog:

PR modula2/120188
* gm2.dg/doc/examples/plugin/fail/doc-examples-plugin-fail.exp:
Remove call to gm2-dg-frontend-configure-check and replace with
tests for whether plugin variables exist.

(cherry picked from commit f1f94e79dbcfa4b33267db27780870ea7810cd21)

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

[PATCH] PR modula2/120188: documented example does not work assignvalue m2plugin

This patch corrects the gm2 command line used in the documentation
to invoke the m2-plugin.  The patch also includes the documentation
example in dejagnu test code with an expect script to check whether
plugins were enabled.

gcc/ChangeLog:

PR modula2/120188
* doc/gm2.texi (Semantic checking): Add -fm2-plugin command line option.

gcc/testsuite/ChangeLog:

PR modula2/120188
* lib/gm2-dg.exp (gm2-dg-frontend-configure-check): New function.
(gm2-dg-runtest): Add -O2 to the option_list.
* gm2.dg/doc/examples/plugin/fail/assignvalue.mod: New test.
* gm2.dg/doc/examples/plugin/fail/doc-examples-plugin-fail.exp: New test.

(cherry picked from commit 9ce4c801e8275fcf0336ae2fb548f6ebb3ca068b)

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

libfortran: Fix up _gfortran_{,m,s}findloc2_s{1,4} [PR120196]

As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many
times in the back case if nothing is found.
For !back, the loops are for (i = 1; i <= extent; i++) so i is in the
body [1, extent] if nothing is found, but for back it is
for (i = extent; i >= 0; i--) so i is in the body [0, extent] and compares
one element before the start of the array.
Note, findloc1_s{1,4} uses
          for (n = len; n > 0; n--, src -= delta * len_array)
for the back loop and
          for (n = 1; n <= len; n++, src += delta * len_array)
for !back.  This patch fixes that.
The testcase fails under valgrind without the libgfortran changes and
succeeds with those.

2025-05-13  Jakub Jelinek  <jakub@redhat.com>

PR libfortran/120196
* m4/ifindloc2.m4 (header1, header2): For back use i > 0 rather than
i >= 0 as for condition.
* generated/findloc2_s1.c: Regenerate.
* generated/findloc2_s4.c: Regenerate.

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

(cherry picked from commit 748a7bc4624e7b000f6fdb93a8cf7da73ff193bb)

libfortran: Fix up _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} [PR120191]

There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the
following testcase shows.
The functions return but then crash in the caller.
Seems that is because buffer overflows, I believe those functions for
if (mask == NULL || *mask) condition being false are supposed to fill in
the result array with all zeros (or allocate it and fill it with zeros).
My understanding is the result array in that case is integer(kind={4,8,16})
and should have the extents the character input array has.
The problem is that it uses * string_len in the extent multiplication:
      extent[n] = GFC_DESCRIPTOR_EXTENT(array,n) * string_len;
and
      extent[n] =
        GFC_DESCRIPTOR_EXTENT(array,n + 1) * string_len;
which is I guess fine and desirable for the extents of the character array,
but not for the extents of the destination array.  Yet the code uses
that extent array for that purpose (and no other purposes).
Here it uses it to set the dimensions for the case where it needs to
allocate (as well as size):
      for (n = 0; n < rank; n++)
        {
          if (n == 0)
            str = 1;
          else
            str = GFC_DESCRIPTOR_STRIDE(retarray,n-1) * extent[n-1];
          GFC_DIMENSION_SET(retarray->dim[n], 0, extent[n] - 1, str);
        }
Here it uses it for bounds checking of the destination:
      if (unlikely (compile_options.bounds_check))
        {
          for (n=0; n < rank; n++)
            {
              index_type ret_extent;

              ret_extent = GFC_DESCRIPTOR_EXTENT(retarray,n);
              if (extent[n] != ret_extent)
                runtime_error ("Incorrect extent in return value of"
                               " MAXLOC intrinsic in dimension %ld:"
                               " is %ld, should be %ld", (long int) n + 1,
                               (long int) ret_extent, (long int) extent[n]);
            }
        }
and here to find out how many retarray elements to actually fill in each
dimension:
  while(1)
    {
      *dest = 0;
      count[0]++;
      dest += dstride[0];
      n = 0;
      while (count[n] == extent[n])
        {
          /* When we get to the end of a dimension, reset it and increment
             the next dimension.  */
          count[n] = 0;
          /* We could precalculate these products, but this is a less
             frequently used path so probably not worth it.  */
          dest -= dstride[n] * extent[n];
Seems maxloc1s.m4 and minloc1s.m4 are the only users of ifunction-s.m4,
so we can change SCALAR_ARRAY_FUNCTION in there without breaking anything
else.

2025-05-13  Jakub Jelinek  <jakub@redhat.com>

PR fortran/120191
* m4/ifunction-s.m4 (SCALAR_ARRAY_FUNCTION): Don't multiply
GFC_DESCRIPTOR_EXTENT(array,) by string_len.
* generated/maxloc1_4_s1.c: Regenerate.
* generated/maxloc1_4_s4.c: Regenerate.
* generated/maxloc1_8_s1.c: Regenerate.
* generated/maxloc1_8_s4.c: Regenerate.
* generated/maxloc1_16_s1.c: Regenerate.
* generated/maxloc1_16_s4.c: Regenerate.
* generated/minloc1_4_s1.c: Regenerate.
* generated/minloc1_4_s4.c: Regenerate.
* generated/minloc1_8_s1.c: Regenerate.
* generated/minloc1_8_s4.c: Regenerate.
* generated/minloc1_16_s1.c: Regenerate.
* generated/minloc1_16_s4.c: Regenerate.

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

(cherry picked from commit 781cfc454b8dc24952fe7f4c5c409296dca505e1)

libfortran: Fix up _gfortran_s{max,min}loc2_{4,8,16}_s{1,4} [PR120191]

I've tried to write a testcase for the BT_CHARACTER maxloc/minloc with named
or unnamed arguments and indeed the just posted patch fixed the arguments
in there in multiple cases to match what the library expects.
But the testcase still fails, due to library problems.

One dealt with in this patch are _gfortran_s{max,min}loc2_{4,8,16}_s{1,4}
functions.  Those are trivial wrappers around
_gfortrani_{max,min}loc2_{4,8,16}_s{1,4} which should call those functions
if the scalar mask is true and just return 0 otherwise.
The two bugs I see there is that the back, len arguments are swapped,
which means that it always acts as back=.true. and for len will use
character length of 1 or 0 instead of the desired one.
The _gfortrani_{max,min}loc2_{4,8,16}_s{1,4} functions have prototypes like
GFC_INTEGER_4
maxloc2_4_s1 (gfc_array_s1 * const restrict array, GFC_LOGICAL_4 back, gfc_charlen_type len)
so back comes before len, ditto for the
GFC_INTEGER_4
smaxloc2_4_s1 (gfc_array_s1 * const restrict array,
               GFC_LOGICAL_4 *mask, GFC_LOGICAL_4 back, gfc_charlen_type len)
The other problem is that it was just testing if (mask).  In my limited
Fortran understanding that means that the optional argument mask was
supplied but nothing about its actual value.  Other scalar mask generated
routines use if (mask == NULL || *mask) as the condition when to call the
non-masked function, i.e. when mask is not supplied (then it should act like
.true. mask) or when it is supplied and evaluates to .true.).

2025-05-13  Jakub Jelinek  <jakub@redhat.com>

PR fortran/120191
* m4/maxloc2s.m4: For smaxloc2 call maxloc2 if mask is NULL or *mask.
Swap back and len arguments.
* m4/minloc2s.m4: Likewise.
* generated/maxloc2_4_s1.c: Regenerate.
* generated/maxloc2_4_s4.c: Regenerate.
* generated/maxloc2_8_s1.c: Regenerate.
* generated/maxloc2_8_s4.c: Regenerate.
* generated/maxloc2_16_s1.c: Regenerate.
* generated/maxloc2_16_s4.c: Regenerate.
* generated/minloc2_4_s1.c: Regenerate.
* generated/minloc2_4_s4.c: Regenerate.
* generated/minloc2_8_s1.c: Regenerate.
* generated/minloc2_8_s4.c: Regenerate.
* generated/minloc2_16_s1.c: Regenerate.
* generated/minloc2_16_s4.c: Regenerate.

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

(cherry picked from commit 482f2192d4ef6af55acae2dc3e0df00b8487cc7d)

fortran: Fix up minloc/maxloc lowering [PR120191]

We need to drop the kind argument from what is passed to the
library, but need to do it not only when one uses the argument name
for it (so kind=4 etc.) but also when one passes all the arguments
to the intrinsics.

The following patch uses what gfc_conv_intrinsic_findloc uses,
which looks more efficient and cleaner, we already set automatic
vars to point to the kind and back actual arguments, so we can just
free/clear expr on the former and set name to "%VAL" on the latter.

And similarly clears dim argument for the BT_CHARACTER case when using
maxloc2/minloc2, again regardless of whether it was named or not.

2025-05-13  Jakub Jelinek  <jakub@redhat.com>
    Daniil Kochergin  <daniil2472s@gmail.com>
    Tobias Burnus  <tburnus@baylibre.com>

PR fortran/120191
* trans-intrinsic.cc (strip_kind_from_actual): Remove.
(gfc_conv_intrinsic_minmaxloc): Don't call strip_kind_from_actual.
Free and clear kind_arg->expr if non-NULL.  Set back_arg->name to
"%VAL" instead of a loop looking for last argument.  Remove actual
variable, use array_arg instead.  Free and clear dim_arg->expr if
non-NULL for BT_CHARACTER cases instead of using a loop.

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

(cherry picked from commit ec249be3c287c6f1dfb328712ac9c39e6fa95eca)

Daily bump.

libstdc++: Remove #warning from <ciso646> for C++17 [PR120187]

Although <ciso646> was removed from C++20, it was not formally
deprecated in C++17. In contrast, <ctgmath>, <cstdalign>, etc. were
formally deprecated in C++17 before being removed in C++20.

Due to the widespread convention of including <ciso646> to detect
implementation-specific macros (such as _GLIBCXX_RELEASE) it causes
quite a lot of noise to issue deprecation warnings in C++17 mode. The
recommendation to include <version> instead does work for recent
compilers, even in C++17 mode, but isn't portable to older compilers
that don't provide <version> yet (e.g. GCC 8).

There are also potential objections to including <version> pre-C++20
when it wasn't defined by the standard. I don't have much sympathy for
this position, because including <ciso646> for implementation-specific
macros wasn't part of the C++17 standard either. It's no more
non-standard to rely on <version> being present and defining those
macros than to rely on <ciso646> defining them, and __has_include can be
used to detect whether <version> is present. However, <ciso646> is being
used in the wild by popular libraries like Abseil and we can't change
versions of those that have already been released.

This removes the #warning in <ciso646> for C++17 mode, so that we only
emit diagnostics for C++20 and later. With this change, including
<ciso646> in C++20 or later gives an error if _GLIBCXX_USE_DEPRECATED is
defined to zero, otherwise a warning if -Wdeprecated is enabled,
otherwise no diagnostic is given.

This also adds "@since C++11 (removed in C++20)" to the Doxygen @file
comments in all the relevant headers.

The test for <ciso646> needs to be updated to no longer expect a warning
for c++17_only. A new test is added to ensure that we get a warning
instead of an error when -D_GLIBCXX_USE_DEPRECATED=0 is not used.

libstdc++-v3/ChangeLog:

PR libstdc++/120187
* include/c_global/ciso646: Only give deprecated warning for
C++20 and later.
* include/c_global/ccomplex: Add @since to Doxygen comment.
* include/c_global/cstdalign: Likewise.
* include/c_global/cstdbool: Likewise.
* include/c_global/ctgmath: Likewise.
* testsuite/18_support/headers/ciso646/macros.cc: Remove
dg-warning for c++17_only effective target.
* testsuite/18_support/headers/ciso646/macros-2.cc: New test.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
(cherry picked from commit af062510f4179aa7b13e632f77593deee8fe29f2)

libstdc++: Restore std::scoped_lock for non-gthreads targets [PR120198]

This was a regression introduced with using version.def to define
feature test macros (r14-3248-g083b7f2833d71d). std::scoped_lock doesn't
need to depend on gthreads and so can be defined unconditionally, even
for freestanding.

libstdc++-v3/ChangeLog:

PR libstdc++/120198
* include/bits/version.def (scoped_lock): Do not depend on
gthreads or hosted.
* include/bits/version.h: Regenerate.
* include/std/mutex (scoped_lock): Update comment.
* testsuite/30_threads/scoped_lock/requirements/typedefs.cc:
Remove dg-require-gthreads and use custom lockable type instead
of std::mutex. Check that typedef is only present for a single
template argument.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
(cherry picked from commit bdd2753f5f021a15a6c4ef02565356985fea1300)

c+: -Wabi false positive [PR120012]

The warning compares the position of a field depending on whether or not the
previous base/field is considered a POD for layout, but failed to consider
whether the previous base/field is empty; layout of an empty base doesn't
consider PODness.

PR c++/120012

gcc/cp/ChangeLog:

* class.cc (check_non_pod_aggregate): Check is_empty_class.

gcc/testsuite/ChangeLog:

* g++.dg/abi/base-defaulted2.C: New test.

(cherry picked from commit b4b4dfbd22e06877052bd4cc4b191d9d138155cf)

Update cpplib es.po

* es.po: Update.

Update gcc sv.po

* sv.po: Update.

libstdc++: Update C++23 status table

This should have been updated for the GCC 15.1 release.

libstdc++-v3/ChangeLog:

* doc/xml/manual/status_cxx2023.xml: Update status of proposals
implemented after GCC 14.2 release.
* doc/html/*: Regenerate.

(cherry picked from commit 203eb116ec60afba61c9fbe6cc4b54310ecda9de)

libstdc++: Fix constraint recursion in std::expected's operator== [PR119714]

This std::expected friend operator== is prone to constraint recursion
after CWG 2369 for the same reason as basic_const_iterator's comparison
operators were before the r15-7757-g4342c50ca84ae5 workaround.  This
patch works around the constraint recursion here in a similar manner,
by making the function parameter of type std::expected dependent in a
trivial way.

PR libstdc++/119714
PR libstdc++/112490

libstdc++-v3/ChangeLog:

* include/std/expected (expected::operator==): Replace
non-dependent std::expected function parameter with a dependent
one of type expected<_Vp, _Er> where _Vp matches _Tp.
* testsuite/20_util/expected/119714.cc: New test.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit 91bc8169edd9038d78f38bd813287d72e6345c26)

libstdc++: Fix availability of std::erase_if(std::flat_foo) [PR119427]

These std::erase_if overloads were wrongly implemented as hidden
friends, visible only via ADL, so erase_if(x) would work but not
std::erase_if(x).

PR libstdc++/119427

libstdc++-v3/ChangeLog:

* include/std/flat_map (_Flat_map_impl::erase_if): Replace
this hidden friend with ...
(_Flat_map_impl::_M_erase_if): ... this member function.
(flat_map): Export _Flat_map_impl::_M_erase_if.
(erase_if(flat_map)): Define.
(flat_multimap): Export _Flat_map_impl::_M_erase_if.
(erase_if(flat_multimap)): Define.
* include/std/flat_set (_Flat_set_impl::erase_if): Replace
with ...
(_Flat_set_impl::_M_erase_if): ... this member function.
(flat_set): Export _Flat_set_impl::_M_erase_if.
(erase_if(flat_set)): Define.
(flat_multiset): Export _Flat_set_impl::_M_erase_if.
(erase_if(flat_multiset)): Define.
* testsuite/23_containers/flat_map/1.cc (test07): New test.
* testsuite/23_containers/flat_multimap/1.cc (test07): New test.
* testsuite/23_containers/flat_multiset/1.cc (test09): New test.
* testsuite/23_containers/flat_set/1.cc (test09): New test.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit aa93272cfd2233858da0792761387cc27f4d5ff3)

libstdc++: Suppress GDB output from new 'skip' commands [PR118260]

I added some gdb.execute('skip -rfu ...') commands to the Python hook
loaded with libstdc++.so but this makes GDB print output like:

Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped when stepping.

This probably aren't interesting to users, so this change suppresses
that output by capturing the output into the gdb.execute return value
(which is then ignored). An exception is thrown if the gdb.execute
command fails, so this doesn't suppress any errors which might be
meaningful to users or libstdc++ developers.

libstdc++-v3/ChangeLog:

PR libstdc++/118260
* python/hook.in: Suppress output from gdb.execute calls to
register skips.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
(cherry picked from commit 31cbac3037b7811bd0df63f4a09aa981b250c4bf)

libstdc++: Update <charconv> rows in C++17 status table

Document that std::to_chars and std::from_chars are complete, mentioning
the libraries used for floating-point types.

libstdc++-v3/ChangeLog:

* doc/xml/manual/status_cxx2017.xml: Update status for
std::to_chars and std::from_chars.
* doc/html/manual/*: Regenerate.

Reviewed-by: Jakub Jelinek <jakub@redhat.com>
Reviewed-by: Björn Schäpers <gcc@hazardy.de>
(cherry picked from commit e0bcedba6132fa5c75cb22b9232dbe72c7b3fea0)

Daily bump.

tree-optimization/120211 - constrain LOOP_VINFO_EARLY_BREAKS_LIVE_IVS more

The PR120089 fix added more PHIs to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS
but not checking that we only add PHIs with a latch argument.  The
following adds this missing check.

PR tree-optimization/120211
* tree-vect-stmts.cc (vect_stmt_relevant_p): Only add PHIs
from the loop header to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS.

* gcc.dg/vect/vect-early-break_135-pr120211.c: New testcase.
* gcc.dg/torture/pr120211-1.c: Likewise.

ipa/120146 - deal with vanished varpool nodes in IPA PTA

I don't understand why they vanish when still refered to, but
lets deal with that in a conservative way.

PR ipa/120146
* tree-ssa-structalias.cc (create_variable_info_for): If
the symtab cannot tell us whether all refs to a variable
are explicit assume they are not.

* g++.dg/ipa/pr120146.C: New testcase.

(cherry picked from commit b38e3a7196d25bc8bcb1fe55da7663745cea9470)

tree-optimization/120143 - ICE with failed early break store move

The early break vectorization store moving was incorrectly trying
to move the pattern stmt instead of the original one which failed
to register and then confused virtual SSA form due to the update
triggered by a degenerate virtual PHI.

PR tree-optimization/120143
* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
Move/update the original stmts, not the pattern stmts which
lack virtual operands and are not in the IL.

* gcc.dg/vect/vect-early-break_135-pr120143.c: New testcase.

(cherry picked from commit da377e7ebf84a05943fb768eaeb7d682dee865fa)

tree-optimization/120089 - force all PHIs live for early-break vect

The following makes sure to even mark unsupported PHIs live when
doing early-break vectorization since otherwise we fail to validate
we can vectorize those and generate wrong code based on the scalar
PHIs which would only work with a vectorization factor of one.

PR tree-optimization/120089
* tree-vect-stmts.cc (vect_stmt_relevant_p): Mark all
PHIs live when not already so and doing early-break
vectorization.
(vect_mark_stmts_to_be_vectorized): Skip virtual PHIs.
* tree-vect-slp.cc (vect_analyze_slp): Robustify handling
of early-break forced IVs.

* gcc.dg/vect/vect-early-break_134-pr120089.c: New testcase.

(cherry picked from commit 9def392a1b63a198d15d972f73b4afc888389d7c)

tree-optimization/120043 - bogus conditional store elimination

The following fixes conditional store elimination to properly
check for conditional stores to readonly memory which we can
obviously not store to unconditionally.  The tree_could_trap_p
predicate used is only considering rvalues and the chosen
approach mimics that of loop store motion.

PR tree-optimization/120043
* tree-ssa-phiopt.cc (cond_store_replacement): Check
whether the store is to readonly memory.

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

(cherry picked from commit 93586e5d51188bf71f4f8fae4ee94ff631740f24)

Fix PR 119928, formal arguments used to wrongly inferred for CLASS.

The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved.  Fixed in the
attached patch.  I think it still makes sense to remove the checks
when the other attributes are present (or PR96073 may come back
in different guise, even if I have to test case at present).
I have also converted the test to a run-time check.

gcc/fortran/ChangeLog:

PR fortran/119928
* interface.cc (gfc_check_dummy_characteristics): Do not issue
error if one dummy symbol has been generated from an actual
argument and the other one has OPTIONAL, INTENT, ALLOCATABLE,
POINTER, TARGET, VALUE, ASYNCHRONOUS or CONTIGUOUS.
(gfc_get_formal_from_actual_arglist): Do nothing if symbol
is a class.

gcc/testsuite/ChangeLog:

PR fortran/119928
* gfortran.dg/interface_60.f90: New test.

Daily bump.

testsuite: Fix pr119131-1.c for targets which emit a psabi warning for vectors of DFP [PR119909]

On PowerPC, there is a psabi warning for argument passing of a DFP vector.
We are not expecting this warning and we get a failure due to it.
Adding -Wno-psabi fixes the testcase.

Committed as obvious after a quick test.

gcc/testsuite/ChangeLog:

PR testsuite/119909
* gcc.dg/torture/pr119131-1.c: Add -Wno-psabi.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
(cherry picked from commit bfb61bf309ed207694a97adabc454bfd0936b269)

Daily bump.

Fortran: parsing issue with DO CONCURRENT;ENDDO on same line [PR120179]

PR fortran/120179

gcc/fortran/ChangeLog:

* match.cc (gfc_match_do): Do not attempt to match end-of-statement
twice.

gcc/testsuite/ChangeLog:

* gfortran.dg/do_concurrent_basic.f90: Extend testcase.

(cherry picked from commit 6ce73ad4370c143a7d1e6a13b1d353db5884213f)

Fortran: array subreferences and components of derived types [PR119986]

PR fortran/119986

gcc/fortran/ChangeLog:

* expr.cc (is_subref_array): When searching for array references,
do not terminate early so that inquiry references to complex
components work.
* primary.cc (gfc_variable_attr): A substring reference can refer
to either a scalar or array character variable.  Adjust search
accordingly.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit fceb6022798b587c9111d0241aaff72602dcd626)

Fix wrong optimization of complex boolean expression

The VRP2 pass turns:

  # prephitmp_3 = PHI <0(4)>
  _1 = prephitmp_3 == 0;
  _5 = stretch_14(D) ^ 1;
  _39 = _1 & _5;
  _40 = _39 | last_20(D);

into

  _5 = stretch_14(D) ^ 1;
  _42 = ~stretch_14(D);
  _39 = _42;
  _40 = last_20(D) | _39;

using the following step:

Folding statement: _1 = prephitmp_3 == 0;
Queued stmt for removal.  Folds to: 1
Folding statement: _5 = stretch_14(D) ^ 1;
Not folded
Folding statement: _39 = _1 & _5;
gimple_simplified to _42 = ~stretch_14(D);
_39 = _42 & 1;
Folded into: _39 = _42;

Folding statement: _40 = _39 | last_20(D);
Folded into: _40 = last_20(D) | _39;

but stretch_14 is a 8-bit boolean so the two forms are not equivalent, that
is to say dropping the "& 1" is wrong.  It's another instance of the issue:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558537.html

Here it's the reverse case: the bitwise NOT (~) is treated as logical by the
machinery in range-op.cc but the bitwise AND (&) is *not* treated as logical
by that of vr-values.cc, leading to the same problematic outcome.

gcc/
* vr-values.cc (simplify_using_ranges::simplify) <BIT_AND_EXPR>:
Do not call simplify_bit_ops_using_ranges for boolean types whose
precision is not 1.

gcc/testsuite/
* gnat.dg/opt106.adb: New test.
* gnat.dg/opt106_pkg1.ads, gnat.dg/opt106_pkg1.adb: New helper.
* gnat.dg/opt106_pkg2.ads, gnat.dg/opt106_pkg2.adb: Likewise.

Daily bump.

fortran: Add testcases for PR120152, PR120153 and PR120158

The following patch adds testcase coverage for the 3 recently fixed
libgfortran PRs.
On trunk before those fixes I'm getting with -m32
FAIL: gfortran.dg/pr120152_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr120152_1.f90   -Os  (test for excess errors)
and with -m64
FAIL: gfortran.dg/pr120152_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr120152_1.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/pr120152_2.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr120152_2.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/pr120153.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr120153.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr120153.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr120153.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr120153.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr120153.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/pr120158.f90   -O0  execution test
FAIL: gfortran.dg/pr120158.f90   -O1  execution test
FAIL: gfortran.dg/pr120158.f90   -O2  execution test
FAIL: gfortran.dg/pr120158.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/pr120158.f90   -O3 -g  execution test
FAIL: gfortran.dg/pr120158.f90   -Os  execution test
On latest trunk everything PASSes.

2025-05-08  Jakub Jelinek  <jakub@redhat.com>

PR libfortran/120152
PR libfortran/120153
PR libfortran/120158
* gfortran.dg/pr120152_1.f90: New test.
* gfortran.dg/pr120152_2.f90: New test.
* gfortran.dg/pr120153.f90: New test.
* gfortran.dg/pr120158.f90: New test.

(cherry picked from commit 66f5f03853035cc917627e7d044bff8ccd9eca3f)

libfortran: Fix up maxval/maxloc for UNSIGNED [PR120158]

When libgfortran is compiled, there are some -Woverflow warnings like
../../../libgfortran/generated/maxloc0_4_m1.c:99:14: warning: unsigned conversion from ‘int’ to ‘GFC_UINTEGER_1’ {aka ‘unsigned char’} changes value from ‘-255’ to ‘1’ [-Woverflow]
   99 |     maxval = -GFC_UINTEGER_1_HUGE;
      |              ^
and those actually point a bug in the maxloc*/maxval* implementation
for UNSIGNED.
The intent of
 #if defined ('atype_inf`)
        result = -atype_inf;
 #else
        result = atype_min;
 #endif
(or similar for maxval) is to initialize the variable with
minimum value of the type, if the type has infinities, then
negative infinity, otherwise the minimum (normalized) value.
atype_min expands for signed integers to say (-GFC_INTEGER_4_HUGE-1)
or for floating point to say -GFC_REAL_8_HUGE.
For UNSIGNED it expands to e.g. -GFC_UINTEGER_4_HUGE, but that is
-0xffffffffU which is 1U, while the minimum value of the type is
0.
Haven't tried to construct testcases for that, but I believe e.g.
maskval could return incorrectly 1 on an array (or masked array)
full of 0s, or maxloc could identify incorrectly the maximum location.

The following patch makes sure atype_min expands to 0 for atype_name
GFC_UINTEGER*.

2025-05-07  Jakub Jelinek  <jakub@redhat.com>

PR libfortran/120158
* m4/iparm.m4 (atype_min): For atype_name starting with
GFC_UINTEGER define to 0.
* generated/maxloc0_16_m1.c: Regenerate.
* generated/maxloc0_16_m2.c: Regenerate.
* generated/maxloc0_16_m4.c: Regenerate.
* generated/maxloc0_16_m8.c: Regenerate.
* generated/maxloc0_16_m16.c: Regenerate.
* generated/maxloc0_4_m1.c: Regenerate.
* generated/maxloc0_4_m2.c: Regenerate.
* generated/maxloc0_4_m4.c: Regenerate.
* generated/maxloc0_4_m8.c: Regenerate.
* generated/maxloc0_4_m16.c: Regenerate.
* generated/maxloc0_8_m1.c: Regenerate.
* generated/maxloc0_8_m2.c: Regenerate.
* generated/maxloc0_8_m4.c: Regenerate.
* generated/maxloc0_8_m8.c: Regenerate.
* generated/maxloc0_8_m16.c: Regenerate.
* generated/maxloc1_16_m1.c: Regenerate.
* generated/maxloc1_16_m2.c: Regenerate.
* generated/maxloc1_16_m4.c: Regenerate.
* generated/maxloc1_16_m8.c: Regenerate.
* generated/maxloc1_16_m16.c: Regenerate.
* generated/maxloc1_4_m1.c: Regenerate.
* generated/maxloc1_4_m2.c: Regenerate.
* generated/maxloc1_4_m4.c: Regenerate.
* generated/maxloc1_4_m8.c: Regenerate.
* generated/maxloc1_4_m16.c: Regenerate.
* generated/maxloc1_8_m1.c: Regenerate.
* generated/maxloc1_8_m2.c: Regenerate.
* generated/maxloc1_8_m4.c: Regenerate.
* generated/maxloc1_8_m8.c: Regenerate.
* generated/maxloc1_8_m16.c: Regenerate.
* generated/maxval_m1.c: Regenerate.
* generated/maxval_m2.c: Regenerate.
* generated/maxval_m4.c: Regenerate.
* generated/maxval_m8.c: Regenerate.
* generated/maxval_m16.c: Regenerate.

(cherry picked from commit 8c73c99b6a8c3a562fef360bc269bd60bab36076)

libfortran: Add 5 missing UNSIGNED symbols [PR120153]

While looking at PR120152, I have noticed that libgfortran.so doesn't
export 5 *m16* symbols I would have expected that should be exported.
This is caused by 2 issues, one filename was forgotten to be added in r15-4124
to i_maxloc1_c (guess because generated/maxloc1_16_i16.c was kept in the
position after generated/maxloc1_8_m16.c and the i -> m difference wasn't
spotted), and one some garbage prefix on HAVE_GFC_UINTEGER_16 macro.

The first two hunks of this patch fix that.
Though, as GCC 15.1 has been released already, we can't add these symbols
to GFORTRAN_15 symbol version as they've never been there, so the patch
adds them to a new GFORTRAN_15.2 symbol version instead.

2025-05-07  Jakub Jelinek  <jakub@redhat.com>

PR libfortran/120153
* Makefile.am (i_maxloc1_c): Add generated/maxloc1_16_m16.c.
* intrinsics/random.c (arandom_m16): Use #ifdef HAVE_GFC_UINTEGER_16
guard rather than #ifdef GFC_HAVE_GFC_UINTEGER_16.
* gfortran.map (GFORTRAN_15): Remove _gfortran_arandom_m16,
_gfortran_maxloc1_16_m16, _gfortran_mmaxloc1_16_m16 and
_gfortran_smaxloc1_16_m16.
(GFORTRAN_15.2): New symbol version, add those 4 symbols to it.
* generated/maxloc1_16_m16.c: New file.
* Makefile.in: Regenerate.

(cherry picked from commit e0c783f31b39a56cbfcc27d84633f9254b5b508d)

libfortran: Readd 15 accidentally removed libgfortran symbols [PR120152]

The r15-4124-gc0002a675a92e76d change seems to have accidentally
dropped 5 sourcefiles from i_maxloc1_c, which resulted in dropping
15 GFORTRAN_8 symbols on x86_64 and 6 on i686.

The following patch adds it back, so that we export those symbols
again, fixing the ABI problem.

2025-05-07  Jakub Jelinek  <jakub@redhat.com>

PR libfortran/120152
* Makefile.am (i_maxloc1_c): Readd generated/maxloc1_4_i8.c,
generated/maxloc1_8_i8.c, generated/maxloc1_16_i8.c,
generated/maxloc1_4_i16.c, generated/maxloc1_8_i16.c.  Move
generated/maxloc1_16_i16.c entry earlier in the list.
* Makefile.in: Regenerated.

(cherry picked from commit 41c8e9b61defb6c616bf35ac9693a52f848afca3)

libcpp: Further fixes for incorrect line numbers in large files [PR120061]

The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switched
to 64-bit location_t and so one actually needs far longer header files
to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
contain (large) testcases in patch form which show on the 14 branch
that the first one used to fail before the PR108900 backport and now
works correctly, while the second one attempts to match the chromium
behavior and it used to pass before the PR108900 backport and now it
FAILs.
The two testcases show rare problematic cases, because
do_include_common -> parse_include -> check_eol -> check_eol_1 ->
cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
triggers there
      /* Allocate the new line_map.  However, if the current map only has a
         single line we can sometimes just increase its column_bits instead. */
      if (line_delta < 0
          || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
          || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits))
          || ( /* We can't reuse the map if the line offset is sufficiently
                  large to cause overflow when computing location_t values.  */
              (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
              >= (((uint64_t) 1)
                  << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
          || range_bits < map->m_range_bits)
        map = linemap_check_ordinary
                (const_cast <line_map *>
                  (linemap_add (set, LC_RENAME,
                                ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
                                ORDINARY_MAP_FILE_NAME (map),
                                to_line)));
and so creates a new ordinary map on the line right after the
(problematic) #include line.
Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
pfile->line_table->highest_location in all 3 tests (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
) is before the decrement the start of the line after the #include line and so
the decrement is really desirable in that case to put highest_location
somewhere on the line where the #include actually is.
But at the same time it is also undesirable, because if we do decrement it,
then linemap_add LC_ENTER called from _cpp_do_file_change will then
  /* Generate a start_location above the current highest_location.
     If possible, make the low range bits be zero.  */
  location_t start_location = set->highest_location + 1;
  unsigned range_bits = 0;
  if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
    range_bits = set->default_range_bits;
  start_location += (1 << range_bits) - 1;
  start_location &=  ~((1 << range_bits) - 1);

  linemap_assert (!LINEMAPS_ORDINARY_USED (set)
                  || (start_location
                      >= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP (set))));
and we can end up with the new LC_ENTER ordinary map having the same
start_location as the preceding LC_RENAME one.
Next thing that happens is computation of included_from:
  if (reason == LC_ENTER)
    {
      if (set->depth == 0)
        map->included_from = 0;
      else
        /* The location of the end of the just-closed map.  */
        map->included_from
          = (((map[0].start_location - 1 - map[-1].start_location)
              & ~((1 << map[-1].m_column_and_range_bits) - 1))
             + map[-1].start_location);
The normal case (e.g. with the testcase included at the start of this comment) is
that map[-1] starts somewhere earlier and so map->included_from computation above
nicely computes location_t which expands to the start of the #include line.
With r14-11679 reverted, for #c11 as well as #c12
map[0].start_location == map[-1].start_location above, and so it is
((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
+ map[-1].start_location,
which happens to be start of the #include line.
For #c11 map[0].start_location is 0x500003a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and
map[0].included_from is set to 0x50000320.
For #c12 map[0].start_location is 0x606c0402 and map[-2].start_location is
0x606c0400 and m_column_and_range_bits is 0 for all 3 maps.
map[0].included_from is set to 0x606c0401.
The last important part is again in linemap_add when doing LC_LEAVE:
      /* (MAP - 1) points to the map we are leaving. The
         map from which (MAP - 1) got included should be the map
         that comes right before MAP in the same file.  */
      from = linemap_included_from_linemap (set, map - 1);

      /* A TO_FILE of NULL is special - we use the natural values.  */
      if (to_file == NULL)
        {
          to_file = ORDINARY_MAP_FILE_NAME (from);
          to_line = SOURCE_LINE (from, from[1].start_location);
          sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from);
        }
Here it wants to compute the right to_line which ought to be the line after
the #include directive.
On the #c11 testcase that doesn't work correctly though, because
map[-1].included_from is 0x50000320, from[0] for that is LC_ENTER with
start_location 0x4080 and m_column_and_range_bits 12 but note that we've
earlier computed map[-1].start_location + (-1 & 0xffffff80) and so only
decreased by 7 bits, so to_line is still on the line with #include and not
after it.  In the #c12 that doesn't happen, all the ordinary maps involved
there had 0 m_column_and_range_bits and so this computes correct line.

Below is a fix for the trunk including testcases using the
location_overflow_plugin hack to simulate the bugs without needing huge
files (in the 14 case it is just 330KB and almost 10MB, but in the 15
case it would need to be far bigger).
The pre- r15-9018 trunk has
FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so  scan-file static_assert[^\n\r]*6[^\n\r]*== 6
and current trunk
FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so  scan-file static_assert[^\n\r]*6[^\n\r]*== 6
FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c -fplugin=./location_overflow_plugin.so  scan-file static_assert[^\n\r]*5[^\n\r]*== 5
and with the patch everything PASSes.
I'll post afterwards a 14 version of the patch.

The patch reverts the r15-9018 change, because it is incorrect,
we really need to decrement it even when crossing ordinary map
boundaries, so that the location is not on the line after the #include
line but somewhere on the #include line.  It also patches two spots
in linemap_add mentioned above to make sure we get correct locations
both in the included_from location_t when doing LC_ENTER (second
line-map.cc hunk) and when doing LC_LEAVE to compute the right to_line
(first line-map.cc hunk), both in presence of an added LC_RENAME
with the same start_location as the following LC_ENTER (i.e. the
problematic cases).
The LC_ENTER hunk is mostly to ensure included_form location_t is
at the start of the #include line (column 0), without it we can
decrease include_from not enough and end up at some random column
in the middle of the line, because it is masking away
map[-1].m_column_and_range_bits bits even when in the end the resulting
include_from location_t will be found in map[-2] map with perhaps
different m_column_and_range_bits.  That alone doesn't fix the bug
though.
The more important is the LC_LEAVE hunk and the problem there is
caused by linemap_line_start not actually doing
    r = set->highest_line + (line_delta << map->m_column_and_range_bits);
when adding a new map (the LC_RENAME one because we need to switch to
different number of directly encoded ranges, or columns, etc.).
So, in the original PR108900 case that
  to_line = SOURCE_LINE (from, from[1].start_location);
doesn't do the right thing, from there is the last < 0x50000000 map
with m_column_and_range_bits 12, from[1] is the first one above it
and map[-1].included_from is the correct location of column 0 on
the #include line, but as the new LC_RENAME map has been created without
actually increasing highest_location to be on the new line (we've just
set to_line of the new LC_RENAME map to the correct line),
  to_line = SOURCE_LINE (from, from[1].start_location);
stays on the same source line.  I've tried to just replace that with
  to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1;
i.e. just find out the #include line from map[-1].included_from and
add 1 to it, unfortunately that breaks the
c-c++-common/cpp/line-4.c
test where we expect to stay on the same 0 line for LC_LEAVE from
<command line> and gcc.dg/cpp/trad/Wunused.c, gcc.dg/cpp/trad/builtins.c
and c-c++-common/analyzer/named-constants-via-macros-traditional.c tests
all with -traditional-cpp preprocessing where to_line is also off-by-one
from the expected one.
So, this patch instead conditionalizes it, uses the
  to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1;
way only if from[1] is a LC_RENAME map (rather than the usual
LC_ENTER one), that should limit it to the problematic cases of when
parse_include peeked after EOL and had to create LC_RENAME map with
the same start_location as the LC_ENTER after it.

Some further justification for the LC_ENTER hunk, using the
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682774.html testcase
(old is 14 before r14-11679, vanilla current 14 and new with the 14 patch)
I get
$ /usr/src/gcc-14/obj/gcc/cc1.old -quiet -std=c23 pr116047.c -nostdinc
In file included from pr116047-1.h:327677:21,
                 from pr116047.c:4:
pr116047-2.h:1:1: error: unknown type name ‘a’
    1 | a b c;
      | ^
pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
    1 | a b c;
      |     ^
pr116047-1.h:327677:1: error: static assertion failed: ""
327677 | #include "pr116047-2.h"
       | ^~~~~~~~~~~~~
$ /usr/src/gcc-14/obj/gcc/cc1.vanilla -quiet -std=c23 pr116047.c -nostdinc
In file included from pr116047-1.h:327678,
                 from pr116047.c:4:
pr116047-2.h:1:1: error: unknown type name ‘a’
    1 | a b c;
      | ^
pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
    1 | a b c;
      |     ^
$ /usr/src/gcc-14/obj/gcc/cc1.new -quiet -std=c23 pr116047.c -nostdinc
In file included from pr116047-1.h:327677,
                 from pr116047.c:4:
pr116047-2.h:1:1: error: unknown type name ‘a’
    1 | a b c;
      | ^
pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
    1 | a b c;
      |     ^

pr116047-1.h has on lines 327677+327678:
 #include "pr116047-2.h"
 static_assert (__LINE__ == 327678, "");
so the static_assert failure is something that was dealt mainly in the
LC_LEAVE hunk and files.cc reversion, but please have a look at the
In file included from lines.
14.2 emits correct line (#include "pr116047-2.h" is indeed on line
327677) but some random column in there (which is not normally printed
for smaller headers; 21 is the . before extension in the filename).
Current trunk emits incorrect line (327678 instead of 327677, clearly
it didn't decrement).
And the patched compiler emits the right line with no column, as would
be printed if I remove e.g. 300000 newlines from the file.

2025-05-07  Jakub Jelinek  <jakub@redhat.com>

PR preprocessor/108900
PR preprocessor/116047
PR preprocessor/120061
* files.cc (_cpp_stack_file): Revert 2025-03-28 change.
* line-map.cc (linemap_add): Use
SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; instead of
SOURCE_LINE (from, from[1].start_location); to compute to_line
for LC_LEAVE.  For LC_ENTER included_from computation, look at
map[-2] or even lower if map[-1] has the same start_location as
map[0].

* gcc.dg/plugin/plugin.exp: Add location-overflow-test-pr116047.c
and location-overflow-test-pr120061.c.
* gcc.dg/plugin/location_overflow_plugin.cc (plugin_init): Don't error
on unknown values, instead just break.  Handle 0x4fHHHHHH arguments
differently.
* gcc.dg/plugin/location-overflow-test-pr116047.c: New test.
* gcc.dg/plugin/location-overflow-test-pr116047-1.h: New test.
* gcc.dg/plugin/location-overflow-test-pr116047-2.h: New test.
* gcc.dg/plugin/location-overflow-test-pr120061.c: New test.
* gcc.dg/plugin/location-overflow-test-pr120061-1.h: New test.
* gcc.dg/plugin/location-overflow-test-pr120061-2.h: New test.

(cherry picked from commit edf745dc519ddbfef127e2789bf11bfbacd300b7)

Daily bump.

libstdc++: Add missing export for std::is_layout_compatible_v [PR120159]

libstdc++-v3/ChangeLog:

PR libstdc++/120159
* src/c++23/std.cc.in (is_layout_compatible_v): Export.

(cherry picked from commit 8a1f3615c01cdbf5b2d37448c8bb09a96d5e3330)

c++: C++17/20 class layout divergence [PR120012]

C++20 made a class with only explicitly defaulted constructors no longer
aggregate, and this wrongly affected whether the class is considered "POD
for layout purposes" under the ABI.

Conveniently, we already have check_non_pod_aggregate to diagnose cases
where this makes a difference, due to PR103681 around a C++14 aggregate
change.

This backport is the same code change as the trunk version, but since
-fabi-version=21 cannot be selected, the fix is not available, only the
warning, so the first testcase is different.

PR c++/120012

gcc/cp/ChangeLog:

* cp-tree.h (struct lang_type): Add non_aggregate_pod.
(CLASSTYPE_NON_AGGREGATE_POD): New.
* class.cc (check_bases_and_members): Set it.
(check_non_pod_aggregate): Diagnose it.

gcc/testsuite/ChangeLog:

* g++.dg/abi/base-defaulted1.C: New test.
* g++.dg/abi/base-defaulted1a.C: New test.

(cherry picked from commit e6e3b0772ed40cc65a544bbe744ece62d8b9713e)

c++: let plain -Wabi warn about future changes

c_common_post_options limits flag_abi_version and flag_abi_compat_version to
actual ABI version numbers, but let's not do that for warn_abi_version; we
might want to add a warning relative to a future ABI version that isn't
available in the current release, such backporting the PR120012 warning.

Also allow plain -Wabi to include such a warning without complaining that
it's useless.

Also warn about an unsupported -fabi-version argument.

gcc/c-family/ChangeLog:

* c-opts.cc (c_common_post_options): Let plain -Wabi warn
about changes in a future version.

(cherry picked from commit 11e62bc6d9f8109a98facd1f90d4602869eb12e7)

ipa: Do not emit info about temporary clones to ipa-clones dump (PR119852)

As described in PR 119852, the output of -fdump-ipa-clones can contain
"(null)" as the suffix/reason for cloning when we need to create a
clone to hold the original function during recursive inlining.  Such
clone is never output and so should not be part of the dump output
either.

gcc/ChangeLog:

2025-04-23  Martin Jambor  <mjambor@suse.cz>

PR ipa/119852
* cgraphclones.cc (dump_callgraph_transformation): Document the
function.  Do not dump if suffix is NULL.

gcc/testsuite/ChangeLog:

2025-04-23  Martin Jambor  <mjambor@suse.cz>

PR ipa/119852
* gcc.dg/ipa/pr119852.c: New test.

(cherry picked from commit fb5829a01651d427a63a12c44ecc8baa47dbfc83)

Document option -fdump-ipa-clones

I have noticed that the option -fdump-ipa-clones is not documented
although there are users who depend on it.  This patch adds the
missing documentation along with the description of the information it
dumps and the format it uses.

I am never quite sure which of the texinfo mark-ups is the most
appropriate in which situation, I'll of course incorporate any
feedback on this as well as the general wording of the text.

After we settle on a version, I'd like to backport the documentation
also at least to GCC 15, 14 and 13.

Is it perhaps OK for master and the branches or what would better be
changed?

Thanks,

Martin

gcc/ChangeLog:

2025-04-23  Martin Jambor  <mjambor@suse.cz>

* doc/invoke.texi (Developer Options): Document -fdump-ipa-clones.

(cherry picked from commit 6ecc2fee06bdd60da0e9b3fe6660b553dbdca3ca)

libstdc++: Fix width computation for the chrono formatting [PR120114]

Use `__unicode::_field_width` to compute the field width of the output when writting
the formatted output for std::chrono::types. This applies both to characters copied
from format string, and one produced by localized formatting.

We also use _Str_sink::view() instead of get(), which avoids copying the content of
the buffer to std::string in case of small output.

PR libstdc++/120114

libstdc++-v3/ChangeLog:

* include/bits/chrono_io.h (__formatter_chrono::_M_format): Use __field_width.
* testsuite/std/time/format/pr120114.cc: New test.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
(cherry picked from commit 52f6ab55051ff43fd1b40ff06d9501043f8ba844)

Daily bump.

Allow IPA_CP to handle UNDEFINED as VARYING.

When applying a bitmask to reflect ranges, it is sometimes deferred and
this can result in an UNDEFINED result.  IPA is not expecting this, and
add a check for it, and convert to VARYING if encountered.

PR tree-optimization/120048
gcc/
* ipa-cp.cc (ipcp_store_vr_results): Check for UNDEFINED.

gcc/testsuite/
* gcc.dg/pr120048.c: New.

libstdc++: Add missing feature-test macro in <memory>

Per version.syn#2, <memory> is required to define
__cpp_lib_addressof_constexpr as 201603L.

Bootstrapped and tested on aarch64-linux-gnu.

Signed-off-by: Dhruv Chawla <dhruvc@nvidia.com>
libstdc++-v3/ChangeLog:
* include/std/memory: Define __glibcxx_want_addressof_constexpr.
* testsuite/20_util/headers/memory/version.cc: Test for macro
value.

(cherry picked from commit 0e65fef8717f404cf9c85bff51bf87d534f87828)

libstdc++: Remove unnecessary dg-prune-output from tests

There are no errors matching this pattern in these tests (only in the
deque/48101_neg.cc and vector/48101_neg.cc tests).

libstdc++-v3/ChangeLog:

* testsuite/23_containers/forward_list/48101_neg.cc: Remove
dg-prune-output that doesn't match anything.
* testsuite/23_containers/list/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/set/48101_neg.cc: Likewise.

(cherry picked from commit 8396c80be153b5207d992b7ea6dd4fdb536ce973)

libstdc++: fix possible undefined atomic lock-free type aliases in module std

When building for 'i386-*' targets, all basic types are 'sometimes lock-free'
and thus std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are
not declared. In the header <atomic>, they are placed in preprocessor
condition __cpp_lib_atomic_lock_free_type_aliases. In module std, they should
be the same.

libstdc++-v3/ChangeLog:

* src/c++23/std.cc.in (atomic_signed_lock_free): Guard with
preprocessor check for __cpp_lib_atomic_lock_free_type_aliases.
(atomic_unsigned_lock_free): Likewise.

(cherry picked from commit 466c80a885ccbd5186cd57b0785cf38b8cf2ff2f)

gimple-fold: Fix fold_truth_andor_for_ifcombine [PR120074]

The following testcase ICEs because of a mismatch between wide_int
precision, in particular lr_and_mask has 32-bit precision while sign has
16-bit.

decode_field_reference ensures that {ll,lr,rl,rr}_and_mask has
{ll,lr,rl,rr}_bitsize precision, so the
        ll_and_mask |= sign;
and
        rl_and_mask |= sign;
and
        ll_and_mask &= sign;
and
        rl_and_mask &= sign;
cases should work right, sign has in those cases {ll,rl}_bitsize
precision.  The problem is that nothing until much later guarantees
that ll_bitsize == lr_bitsize or rl_bitsize == rr_bitsize.
In the testcase there is
((b ^ a) & 3) < 0
where a is 16-bit and b is 32-bit, so it is the lsignbit handling,
and because of the xor the xor operand is moved to the *r_and_mask, so
with ll_and_mask being 16-bit 3 and lr_and_mask being 32-bit 3.

Now, either b in the above case would be INTEGER_CST, in that case
if rr_arg was also INTEGER_CST we'd use the l_const && r_const case
and try to handle it, or we'd run into (though much later)
      if (ll_bitsize != lr_bitsize || rl_bitsize != rr_bitsize
...
        return 0;

One possibility is dealing with a different precision using wide_int::from.

Another option used in this patch as it is safest is
+         if (ll_bitsize != lr_bitsize)
+           return 0;
          if (!lr_and_mask.get_precision ())
            lr_and_mask = sign;
          else
            lr_and_mask &= sign;
and similarly in the other hunk, i.e. punt if there is a mismatch
early.

And yet another option would be to compute
the sign
      wide_int sign = wi::mask (ll_bitsize - 1, true, ll_bitsize);
      /* If ll_arg is zero-extended and we're testing the sign bit, we know
         what the result should be.  Shifting the sign bit out of sign will get
         us to mask the entire field out, yielding zero, i.e., the sign bit of
         the zero-extended value.  We know the masked value is being compared
         with zero, so the compare will get us the result we're looking
         for: TRUE if EQ_EXPR, FALSE if NE_EXPR.  */
      if (lsignbit > ll_bitsize && ll_unsignedp)
        sign <<= 1;
once again for the lr_and_mask and rr_and_mask cases using rl_bitsize.

As we just return 0; anyway unless l_const && r_const, if l_const & r_const
are false it doesn't really matter what is chosen, but for the const
cases it matters and I'm not sure what is right.  So the second option
might be safest.

2025-05-06  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/120074
* gimple-fold.cc (fold_truth_andor_for_ifcombine): For
lsignbit && l_xor case, punt if ll_bitsize != lr_bitsize.  Similarly
for rsignbit && r_xor case, punt if rl_bitsize != rr_bitsize.
Formatting fix.

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

(cherry picked from commit 81475602c3dd57ff6987e5f902814e8e3a0a0dde)

libgomp: Update SVE test

Fix udr-sve.c target test that to check for the correct results based on the
OpenMP clauses used.  The test was first written with a misunderstood
functionality of the reduction clause.

Tested with aarch64-linux-gnu. OK for trunk?

libgomp/ChangeLog:

* testsuite/libgomp.c-target/aarch64/udr-sve.c: Fix test.

Daily bump.

ipa/120006 - wrong code with IPA PTA

When PTA gets support for special-handling more builtins in
find_func_aliases the corresponding code in find_func_clobbers
needs updating as well since for unhandled cases it assumes
the former will populate ESCAPED accordingly.  The following
fixes a few omissions, the testcase runs into the missing strdup
handling.  I believe the more advanced handling using modref
results and fnspecs opened a larger gap, the proper fix is to
merge both functions, gating the clobber/use part on a parameter
to avoid diverging.

PR ipa/120006
* tree-ssa-structalias.cc (find_func_clobbers): Handle
strdup, strndup, realloc, index, strchr, strrchr, memchr,
strstr, strpbrk builtins like find_func_aliases does.

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

(cherry picked from commit a85b89e26b1f50997701eb428c2dd71668f216ff)

ipa/119973 - IPA PTA issue with global initializers

For global initializers with IPA PTA we initialize them from the
IPA reference data but that lacks references to the constant pool.
The following conservatively considers the whole initializer.

PR ipa/119973
* tree-ssa-structalias.cc (create_variable_info_for):
Build constraints from DECL_INITIAL directly rather than
the IPA reference list which is incomplete.

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

(cherry picked from commit 7a16ef443b13fff9537baa533597836c57131262)

Ada: Fix assertion failure on Finalizable aspect for tagged record type

This is a (benign) assertion failure on the mainline for the new Finalizable
aspect put on a tagged record type when not all the primitives are declared.
This compiles and runs on the 15 branch because assertions are disabled.

gcc/ada/
PR ada/120104
* exp_ch3.adb (Expand_Freeze_Record_Type): For a controlled tagged
type, freeze only the controlled primitives that are present.

gcc/testsuite/
* gnat.dg/specs/finalizable1.ads: New test.

Daily bump.

Daily bump.

Fortran: fix procedure pointer handling with -fcheck=pointer [PR102900]

PR fortran/102900

gcc/fortran/ChangeLog:

* trans-decl.cc (gfc_generate_function_code): Use sym->result
when generating fake result decl for functions returning
allocatable or pointer results.
* trans-expr.cc (gfc_conv_procedure_call): When checking the
pointer status of an actual argument passed to a non-allocatable,
non-pointer dummy which is of type CLASS, do not check the
class container of the actual if it is just a procedure pointer.
(gfc_trans_pointer_assignment): Fix treatment of assignment to
NULL of a procedure pointer.

gcc/testsuite/ChangeLog:

* gfortran.dg/proc_ptr_52.f90: Add -fcheck=pointer to options.
* gfortran.dg/proc_ptr_57.f90: New test.

(cherry picked from commit cc8d86ee4680d56eefeb76a8f2f752282e2631e3)

Daily bump.

c: Fix up RAW_DATA_CST handling in check_constexpr_init [PR120057]

The pr120057-1.c testcase is incorrectly rejected since
 r15-4377 (and for a while it also ICEd after the error), i.e.
the optimization of large C initializers using RAW_DATA_CST.
Similarly, the embed-18.c testcase is incorrectly rejected since
the embed support has been introduced and RAW_DATA_CST used for that.

The callers of check_constexpr_init (store_init_value and
output_init_element) compute int_const_expr as
      int_const_expr = (TREE_CODE (init) == INTEGER_CST
                        && !TREE_OVERFLOW (init)
                        && INTEGRAL_TYPE_P (TREE_TYPE (init)));
but that is only passed through down to check_constexpr_init.
I think tweaking those 2 callers to also allow RAW_DATA_CST for
int_const_expr when check_constexpr_init needs top special case it
no matter what would be larger, so the patch just changes
check_constexpr_init to deal with RAW_DATA_CST in the initializers.
For TYPE_UNSIGNED char precision integral types RAW_DATA_CST is
always valid, for !TYPE_UNSIGNED we need to check for 128-255 values
being turned into negative ones.

2025-05-02  Jakub Jelinek  <jakub@redhat.com>

PR c/120057
* c-typeck.cc (check_constexpr_init): Handle RAW_DATA_CST.

* gcc.dg/cpp/embed-18.c: New test.
* gcc.dg/pr120057-1.c: New test.
* gcc.dg/pr120057-2.c: New test.

(cherry picked from commit e81f2f4855876c5d85ab9870c5a150ee1a59ee73)

libsanitizer: Fix build with glibc 2.42

The termio structure will be removed from glibc 2.42.  It has
been deprecated since the late 80s/early 90s.

Cherry-picked from LLVM commit 59978b21ad9c65276ee8e14f26759691b8a65763
("[sanitizer_common] Remove interceptors for deprecated struct termio
(#137403)").

Co-Authored-By: Tom Stellard <tstellar@redhat.com>
libsanitizer/

* sanitizer_common/sanitizer_common_interceptors_ioctl.inc: Cherry
picked from LLVM commit 59978b21ad9c65276ee8e14f26759691b8a65763.
* sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise.
* sanitizer_common/sanitizer_platform_limits_posix.h: Likewise.

Daily bump.

c++/modules: Ensure deduction guides for imported types are reachable [PR120023]

In the linked PR, because the deduction guides depend on an imported
type, we never walk the type and so never call add_deduction_guides.
This patch ensures that we make bindings for deduction guides if we saw
any deduction guide at all.

PR c++/120023

gcc/cp/ChangeLog:

* module.cc (depset::hash::find_dependencies): Also call
add_deduction_guides when walking one.

gcc/testsuite/ChangeLog:

* g++.dg/modules/dguide-7_a.C: New test.
* g++.dg/modules/dguide-7_b.C: New test.
* g++.dg/modules/dguide-7_c.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit fb4583566afdee50aad12e1219610813b44bdff4)

c++/modules: Fix imported CNTTPs being considered non-constant [PR119938]

When importing a CNTTP object, since r15-3031-g0b7904e274fbd6 we
shortcut the processing of the generated NTTP so that we don't attempt
to recursively load pendings.  However, due to an oversight we do not
properly set TREE_CONSTANT or DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P
on the decl, which confuses later processing.  This patch ensures that
this happens correctly.

PR c++/119938

gcc/cp/ChangeLog:

* pt.cc (get_template_parm_object): When !check_init, add assert
that expr really is constant and mark decl as such.

gcc/testsuite/ChangeLog:

* g++.dg/modules/tpl-nttp-2_a.H: New test.
* g++.dg/modules/tpl-nttp-2_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit d613678c94f06809656e56b37f314501b37a5ddd)

c++/modules: Catch exposures of TU-local values through inline references [PR119996]

In r15-9136-g0210bedf481a9f we started erroring for inline variables
that exposed TU-local entities in their definition, as such variables
would need to have their definitions emitted in importers but would not
know about the TU-local entities they referenced.

A case we mised was potentially-constant references, which disable
streaming of their definitions in make_dependency so as to comply with
[expr.const] p9.2.  This meant that we didn't see the definition
referencing a TU-local entity, leading to nonsensical results.

PR c++/119551
PR c++/119996

gcc/cp/ChangeLog:

* module.cc (depset::hash::make_dependency): Also mark inline
variables referencing TU-local values as exposures here.
(depset::hash::finalize_dependencies): Add error message for
inline variables.

gcc/testsuite/ChangeLog:

* g++.dg/modules/internal-13.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 22ccaded63e96e5a42f4e3676dbbb57aa05b36f9)

Daily bump.

Update gcc .po files

* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po,
ja.po, ka.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po,
zh_CN.po, zh_TW.po: Update.

Always reflect lower bits from mask in subranges.

During intersection, we expand the subranges to exclude the lower values
from a bitmask with trailing zeros.  This leads to inconsistant evaluations
and in this case of this PR, that lead to an infinite cycle.

Always expand the lower subranges in set_range_from_bitmask instead.

PR tree-optimization/119712
gcc/
* value-range.cc (range_bitmask::adjust_range): Delete.
(irange::set_range_from_bitmask): Integrate adjust_range.
(irange::update_bitmask): Do nothing if bitmask doesnt change.
(irange:intersect_bitmask): Do not call adjust_range. Exit if there
is no second bitmask.
* value-range.h (adjust_range): Remove prototype.

gcc/testsuite/
* gcc.dg/pr119712.c: New.
* gcc.dg/pr83072-2.c: Adjust.
* gcc.dg/tree-ssa/phi-opt-value-5.c: Adjust.
* gcc.dg/tree-ssa/vrp122.c: Adjust

testsuite: Force -mcmodel=small for gcc.target/aarch64/pr115258.c

The test implicitly assumed the default code model and so failed
for -mcmodel=tiny.

gcc/testsuite/
* gcc.target/aarch64/pr115258.c: Add -mcmodel=small.

(cherry picked from commit 3584aab37f54bcd220c7061568af777e37f4f6ed)

c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]

In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration

  template<int N>
  template<class T>
  friend class A<N>::B;

where the scope A<N> remains dependent after instantiation.  But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing

  g<[]{}>::template fn

since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.

This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)

PR c++/119981
PR c++/119378

gcc/cp/ChangeLog:

* pt.cc (tsubst) <case UNBOUND_CLASS_TEMPLATE>: Substitute
into template parameter list first.  When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.

gcc/testsuite/ChangeLog:

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

Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 05ea8baf6ff96c77a9a2467d5c45b1ed575fca92)

Fix GNAT build failure for x86/FreeBSD

gcc/ada/
PR ada/112958
* Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific
version of s-dorepr.adb.
* libgnat/s-dorepr__freebsd.adb: New file.

AVR: fxload_<mode>_libgcc: Use REG_ prefix.

gcc/
* config/avr/avr.md (fxload_<mode>_libgcc): Use REG_ prefix for
magix register numbers (aligns with trunk).

AVR: target/119989 - Add missing clobbers to xload_<mode>_libgcc.

libgcc's __xload_1...4 is clobbering Z (and also R21 is some cases),
but avr.md had clobbers of respective GPRs only up to reload.
Outcome was that code reading from the same __memx address twice
could be wrong.  This patch adds respective clobbers.

      Forward-port from 2025-04-30 r14-11703
      PR target/119989
gcc/
* config/avr/avr.md (xload_<mode>_libgcc): Clobber R21, Z.

gcc/testsuite/
* gcc.target/avr/torture/pr119989.h: New file.
* gcc.target/avr/torture/pr119989-memx-1.c: New test.
* gcc.target/avr/torture/pr119989-memx-2.c: New test.
* gcc.target/avr/torture/pr119989-memx-3.c: New test.
* gcc.target/avr/torture/pr119989-memx-4.c: New test.
* gcc.target/avr/torture/pr119989-flashx-1.c: New test.
* gcc.target/avr/torture/pr119989-flashx-2.c: New test.
* gcc.target/avr/torture/pr119989-flashx-3.c: New test.
* gcc.target/avr/torture/pr119989-flashx-4.c: New test.

(cherry picked from commit 1ca1c1fc3b58ae5e1d3db4f5a2014132fe69f82a)

Fix compilation failure on FreeBSD

[changelog]
PR ada/112958
* init.c (__gnat_error_handler) [__FreeBSD__]: Fix typo.

libstdc++: [_GLIBCXX_INLINE_VERSION] Fix tests failures

Adapt testsuite v3_target_compile to strip version namespace from compiler
output so that dg-error and dg-warning directives do not need to consider it.

Avoid a aligned_storage check as behavior has been fixed only when using
gnu-versioned-namespace as it is an abi breaking change.

libstdc++-v3/ChangeLog:

* testsuite/lib/libstdc++.exp (v3_target_compile): Strip version namespace
from compiler output.
* testsuite/20_util/aligned_storage/value.cc [_GLIBCXX_INLINE_VERSION]:
Avoid align_msa check.
* testsuite/20_util/function/cons/70692.cc: Remove now useless __8 namespace
pattern.
* testsuite/23_containers/map/48101_neg.cc: Likewise.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.

Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit 8709d6a17830c8a9f48cb3ac6dfc6af76f2e1e81)

Daily bump.

aarch64: Fix CFA offsets in non-initial stack probes [PR119610]

PR119610 is about incorrect CFI output for a stack probe when that
probe is not the initial allocation.  The main aarch64 stack probe
function, aarch64_allocate_and_probe_stack_space, implicitly assumed
that the incoming stack pointer pointed to the top of the frame,
and thus held the CFA.

aarch64_save_callee_saves and aarch64_restore_callee_saves use a
parameter called bytes_below_sp to track how far the stack pointer
is above the base of the static frame.  This patch does the same
thing for aarch64_allocate_and_probe_stack_space.

Also, I noticed that the SVE path was attaching the first CFA note
to the wrong instruction: it was attaching the note to the calculation
of the stack size, rather than to the r11<-sp copy.

gcc/
PR target/119610
* config/aarch64/aarch64.cc (aarch64_allocate_and_probe_stack_space):
Add a bytes_below_sp parameter and use it to calculate the CFA
offsets.  Attach the first SVE CFA note to the move into the
associated temporary register.
(aarch64_allocate_and_probe_stack_space): Update calls accordingly.
Start out with bytes_per_sp set to the frame size and decrement
it after each allocation.

gcc/testsuite/
PR target/119610
* g++.dg/torture/pr119610.C: New test.
* g++.target/aarch64/sve/pr119610-sve.C: Likewise.

(cherry picked from commit fa61afef18a8566d1907a5ae0e7754e1eac207d9)

Remove other processors from X86_TUNE_DEST_FALSE_DEP_FOR_GLC except GLC

Since the tune if only for GLC(sapphirerapids and alderlake-P).

gcc/ChangeLog:

* config/i386/x86-tune.def (X86_TUNE_DEST_FALSE_DEP_FOR_GLC):
Remove other processor except for GLC since this one is only
for GLC.

(cherry picked from commit 1ad6e171b126a82f38b1e8cbfd207f1d91c58a59)

Daily bump.