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.

Daily bump.

c++/modules: Ensure DECL_FRIEND_CONTEXT is streamed [PR119939]

An instantiated friend function relies on DECL_FRIEND_CONTEXT being set
to be able to recover the template arguments of the class that
instantiated it, despite not being a template itself.  This patch
ensures that this data is streamed even when DECL_CLASS_SCOPE_P is not
true.

PR c++/119939

gcc/cp/ChangeLog:

* module.cc (trees_out::lang_decl_vals): Also stream
lang->u.fn.context when DECL_UNIQUE_FRIEND_P.
(trees_in::lang_decl_vals): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/concept-11_a.H: New test.
* g++.dg/modules/concept-11_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
(cherry picked from commit 1c5cf7cc82d3a2afa5d4fb90049456be408c2a7a)

c++/modules: Find non-exported reachable decls when instantiating friend classes [PR119863]

In r15-9029-geb26b667518c95, we started checking for conflicting
declarations with any reachable decl attached to the same originating
module.  This exposed the issue in the PR, where we would always create
a new type even if a matching type existed in the original module.

This patch reworks lookup_imported_hidden_friend to handle this case
better, by first checking for any reachable decl in the attached module
before looking in the mergeable decl slots.

PR c++/119863

gcc/cp/ChangeLog:

* name-lookup.cc (get_mergeable_namespace_binding): Remove
no-longer-used function.
(lookup_imported_hidden_friend): Also look for hidden imported
decls in an attached decl's module.

gcc/testsuite/ChangeLog:

* g++.dg/modules/tpl-friend-18_a.C: New test.
* g++.dg/modules/tpl-friend-18_b.C: New test.
* g++.dg/modules/tpl-friend-18_c.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
(cherry picked from commit 948ea8766780f7e44f39ccde3f2436ac2fec80da)

Daily bump.

Daily bump.

s390: Allow 5+ argument tail-calls in some -m31 -mzarch special cases [PR119873]

Here is a patch to handle the PARALLEL case too.
I think we can just use rtx_equal_p there, because it will always use
SImode in the EXPR_LIST REGs in that case.

2025-04-25  Jakub Jelinek  <jakub@redhat.com>

PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same register
is passed in call saved register in the PARALLEL case either.

* gcc.target/s390/pr119873-5.c: New test.

(cherry picked from commit 3d156c9e9bdaf351f77e3348b7d0d75e08f65580)

libstdc++: Define __cpp_lib_format_ranges in format header [PR109162]

As P2286R8 and P2585R1 as now fully implemented, we now define
__cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges.
This macro is provided only in <format>.

Uses of internal __glibcxx_format_ranges are also updated.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/version.def (format_ranges): Remove no_stdname and
update value.
* include/bits/version.h: Regenerate.
* src/c++23/std.cc.in: Replace __glibcxx_format_ranges with
__cpp_lib_format_ranges.
* testsuite/std/format/formatter/lwg3944.cc: Likewise.
* testsuite/std/format/parse_ctx.cc: Likewise.
* testsuite/std/format/string.cc: Likewise.
* testsuite/std/format/ranges/feature_test.cc: New test.

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

libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

This patch implements formatter specializations for standard container adaptors
(queue, priority_queue and stack) from P2286R8.

To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the container is formattable, in such case
specializations are unharmful.

As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
 * _CharT is constrained __formatter::__char
 * basic_format_parse_context<_CharT> for parse argument
 * basic_format_context<_Out, _CharT> for format second argument
The standard specifies all above as unconstrained types. In particular
_CharT constrain, allow us to befriend all allowed specializations.

Furthermore the standard specifies these formatters as delegating to
formatter<ranges::ref_view<const? _Container>, charT>, which in turn
delegates to range_formatter. This patch avoids one level of indirection,
and dependency of ranges::ref_view.  This is technically observable if
user specializes formatter<std::ref_view<PD>> where PD is program defined
container, but I do not think this is the case worth extra indirection.

This patch also moves the formattable and it's dependencies to the formatfwd.h,
so it can be used in adapters formatters, without including format header.
The definition of _Iter_for is changed from alias to denoting
back_insert_iterator<basic_string<_CharT>>, to struct with type nested typedef
that points to same type, that is forward declared.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__format::__parsable_with)
(__format::__formattable_with, __format::__formattable_impl)
(__format::__has_debug_format, __format::__const_formattable_range)
(__format::__maybe_const_range, __format::__maybe_const)
(std::formattable): Moved from std/format.
(__format::Iter_for, std::range_formatter): Forward declare.
* include/bits/stl_queue.h (std::formatter): Forward declare.
(std::queue, std::priority_queue): Befriend formatter specializations.
* include/bits/stl_stack.h (std::formatter): Forward declare.
(std::stack): Befriend formatter specializations.
* include/std/format (__format::_Iter_for): Define as struct with
(__format::__parsable_with, __format::__formattable_with)
(__format::__formattable_impl, __format::__has_debug_format)
(_format::__const_formattable_range, __format::__maybe_const_range)
(__format::__maybe_const, std::formattable): Moved to bits/formatfwd.h.
(std::range_formatter): Remove default argument specified in declaration
in bits/formatfwd.h.
* include/std/queue: Include bits/version.h before bits/stl_queue.h.
(formatter<queue<_Tp, _Container, _Compare>, _CharT>)
(formatter<priority_queue<_Tp, _Container, _Compare>, _CharT>): Define.
* include/std/stack: Include bits/version.h before bits/stl_stack.h
(formatter<stack<_Tp, _Container, _Compare>, _CharT>): Define.
* testsuite/std/format/ranges/adaptors.cc: New test.

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

s390: Allow 5+ argument tail-calls in some special cases [PR119873]

protobuf (and therefore firefox too) currently doesn't build on s390*-linux.
The problem is that it uses [[clang::musttail]] attribute heavily, and in
llvm (IMHO llvm bug) [[clang::musttail]] calls with 5+ arguments on
s390*-linux are silently accepted and result in a normal non-tail call.
In GCC we just reject those because the target hook refuses to tail call it
(IMHO the right behavior).
Now, the reason why that happens is as s390_function_ok_for_sibcall attempts
to explain, the 5th argument (assuming normal <= wordsize integer or pointer
arguments, nothing that needs 2+ registers) is passed in %r6 which is not
call clobbered, so we can't do tail call when we'd have to change content
of that register and then caller would assume %r6 content didn't change and
use it again.
In the protobuf case though, the 5th argument is always passed through
from the caller to the musttail callee unmodified, so one can actually
emit just jg tail_called_function or perhaps tweak some registers but
keep %r6 untouched, and in that case I think it is just fine to tail call
it (at least unless the stack slots used for 6+ argument can't be modified
by the callee in the ABI and nothing checks for that).

So, the following patch checks for this special case, where the argument
which uses %r6 is passed in a single register and it is passed default
definition of SSA_NAME of a PARM_DECL with the same DECL_INCOMING_RTL.

It won't really work at -O0 but should work for -O1 and above, at least when
one doesn't really try to modify the parameter conditionally and hope it will
be optimized away in the end.

2025-04-24  Jakub Jelinek  <jakub@redhat.com>
    Stefan Schulze Frielinghaus  <stefansf@gcc.gnu.org>

PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same register
is passed in call saved register.
(s390_function_ok_for_sibcall): Adjust comment.

* gcc.target/s390/pr119873-1.c: New test.
* gcc.target/s390/pr119873-2.c: New test.
* gcc.target/s390/pr119873-3.c: New test.
* gcc.target/s390/pr119873-4.c: New test.

(cherry picked from commit 567684733e0c4f28158e19b72f4e7f660ad81561)

rs6000: Ignore OPTION_MASK_SAVE_TOC_INDIRECT differences in inlining decisions [PR119327]

The following testcase FAILs because the always_inline function can't
be inlined.
The rs6000 backend has similarly to other targets a hook which rejects
inlining which would bring in new ISAs which aren't there in the caller.
And this hook rejects this because of OPTION_MASK_SAVE_TOC_INDIRECT
differences.
This flag is set if explicitly requested or by default depending on
whether the current function looks hot (or at least not cold):
  if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0
      && flag_shrink_wrap_separate
      && optimize_function_for_speed_p (cfun))
    rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT;
The target nodes that are being compared here are actually the default
target node (which was created when cfun was NULL) vs. one that was
created for the always_inline function when it wasn't NULL, so one
doesn't have it, the other does.
In any case, this flag feels like a tuning decision rather than hard
ISA requirement and I see no problems why we couldn't inline
even explicit -msave-toc-indirect function into -mno-save-toc-indirect
or vice versa.
We already ignore OPTION_MASK_P{8,10}_FUSION which are also more
like tuning flags.

2025-04-22  Jakub Jelinek  <jakub@redhat.com>

PR target/119327
* config/rs6000/rs6000.cc (rs6000_can_inline_p): Ignore also
OPTION_MASK_SAVE_TOC_INDIRECT differences.

* g++.dg/opt/pr119327.C: New test.

(cherry picked from commit 4b62cf555b5446cb02fc471519cf1afa09e1a108)

Adjust gcc_release for id href web transformations

We now have some script which transforms e.g.
<h2 id="15.1">GCC 15.1</h2>
line in gcc-15/changes.html to
<h2 id="15.1"><a href="#15.1">GCC 15.1</a></h2>

This unfortunately breaks the gcc_release script, which looks for
GCC 15.1 appearing in gennews after optional blanks from the start of
the line in the NEWS file, which is no longer the case, there is
[129]GCC 15.1
or something like that with an URL later on
 129. https://gcc.gnu.org/gcc-15/changes.html#15.1

The following patch handles this.

2025-04-25  Jakub Jelinek  <jakub@redhat.com>

* gcc_release: Allow optional \[[0-9]+\] before GCC major.minor
in the NEWS file.

(cherry picked from commit fef3a3c8b5d35c7a8eeae67f95a264a90120dd29)

Bump BASE-VER

2025-04-25  Jakub Jelinek  <jakub@redhat.com>

* BASE-VER: Set to 15.1.1.

Update ChangeLog and version files for release

Update gennews for GCC 15.

2025-04-25  Jakub Jelinek  <jakub@redhat.com>

* gennews (files): Add files for GCC 15.

(cherry picked from commit 865d0f23d2ba08b3b6df6066e7dc5e807a14f5fa)

Daily bump.

opts.cc: Use opts rather than opts_set for validating -fipa-reorder-for-locality

This ensures -fno-ipa-reorder-for-locality doesn't complain with an explicit
-flto-partition=.

Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
* opts.cc (validate_ipa_reorder_locality_lto_partition): Check opts
instead of opts_set for x_flag_ipa_reorder_for_locality.
(finish_options): Update call site.

(cherry picked from commit fbf8443961f484ed7fb7e953206af1ee60558a24)

opts.cc Simplify handling of explicit -flto-partition= and -fipa-reorder-for-locality

The handling of an explicit -flto-partition= and -fipa-reorder-for-locality
should be simpler.  No need to have a new default option.  We can use opts_set
to check if -flto-partition is explicitly set and use that information in the
error handling.
Remove -flto-partition=default and update accordingly.

Bootstrapped and tested on aarch64-none-linux-gnu.

Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
gcc/

* common.opt (LTO_PARTITION_DEFAULT): Delete.
(flto-partition=): Change default back to balanced.
* flag-types.h (lto_partition_model): Remove LTO_PARTITION_DEFAULT.
* opts.cc (validate_ipa_reorder_locality_lto_partition):
Check opts_set->x_flag_lto_partition instead of LTO_PARTITION_DEFAULT.
(finish_options): Remove handling of LTO_PARTITION_DEFAULT.

gcc/testsuite/

* gcc.dg/completion-2.c: Remove check for default.

(cherry picked from commit 040f94d1f63c3607a2f3faf5c329c3b2b6bf7d1e)

Regenerate gcc.pot

* gcc.pot: Regenerate.

Fortran: Fix checking for IMPURE in DO CONCURRENT.

PR fortran/119836

gcc/fortran/ChangeLog:

* resolve.cc (check_pure_function): Fix checking for
an impure subprogram within a DO CONCURRENT construct.
(pure_subroutine): Ditto.

gcc/testsuite/ChangeLog:

* gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
dg-error test.
* gfortran.dg/pr119836_1.f90: New test.
* gfortran.dg/pr119836_2.f90: New test.
* gfortran.dg/pr119836_3.f90: New test.
* gfortran.dg/pr119836_4.f90: New test.

(cherry picked from commit f9ea46d946887a05d7ecbca5aeeb99fd868f6e70)

Update gcc sv.po

* sv.po: Update.

testsuite: AMDGCN test for vect-early-break_38.c as well to consistent architecture [PR119286]

I had missed this one during the AMDGCN test failures.

Like vect-early-break_18.c this test is also scalaring the
loads and thus leading to unexpected vectorization for this
testcase.

gcc/testsuite/ChangeLog:

PR target/119286
* gcc.dg/vect/vect-early-break_38.c: Force -march=gfx908 for amdgcn.

(cherry picked from commit 50a747215e45783de4fd64e47d0851f07d3a44df)

Daily bump.

aarch64: Define __ARM_FEATURE_FAMINMAX

We implemented FAMINMAX ACLE support but failed to define the
associated feature macro.

gcc/
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Define
__ARM_FEATURE_FAMINMAX.

gcc/testsuite/
* gcc.target/aarch64/pragma_cpp_predefs_4.c: Test
__ARM_FEATURE_FAMINMAX.

(cherry picked from commit a544a9c5bbfce013ab020f82acd2470d610fb3c8)

Revert "libstdc++: Optimize std::projected<I, std::identity>" [PR119888]

This non-standard optimization breaks real-world code that expects the
result of std::projected to always (be a class type and) have a value_type
member, which isn't true for e.g. I=int*, so revert it for now.

PR libstdc++/119888

This reverts commit 51761c50f843d5be4e24172535e4524b5072f24c.

aarch64: Update FP8 dependencies for -mcpu=olympus

We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the
FP8FMA and FP8DOT4 features aren't implied by FP8FMA.  The intent is for
-mcpu=olympus to support all of them.
Fix the definition to include the relevant sub-features explicitly.

Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
gcc/

* config/aarch64/aarch64-cores.def (olympus): Add fp8fma, fp8dot4
explicitly.

(cherry picked from commit 5d5e8e87a42af8c0d962fa16dc9835fb71778250)

testsuite: XFAIL predcom-8.c on aarch64 [PR118407]

gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
in the PR trail.  The fix didn't make it into GCC 15, so this patch
XFAILs the test instead.

Other targets might benefit from an XFAIL too, but people who work on
those targets would be better placed to know the right conditions.

gcc/testsuite/
PR tree-optimization/118407
* gcc.dg/tree-ssa/predcom-8.c: Add XFAIL for aarch64.

cobol: Restrict COBOL to supported Linux arches [PR119217]

The COBOL frontend is currently built on all x86_64 and aarch64 hosts
although the code contains some Linux/glibc specifics that break the build
e.g. on Solaris/amd64.

Tested on Linux/x86_64 and Solaris/amd64.

2025-03-17  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

PR cobol/119217
* configure.ac: Restrict cobol to aarch64-*-linux*,
x86_64-*-linux*.
Fix indentation.
* configure: Regenerate.

(cherry picked from commit 6390fc86995fbd5239497cb9e1797a3af51d3936)

libstdc++: Update baseline symbols for m68k-linux

* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.

(cherry picked from commit f9cfb3735cf301c4b943d9ed1cd8b887e11d6be5)

libstdc++: Update baseline symbols for riscv64-linux

* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.

(cherry picked from commit 89259795a5a6e637144c7054e7c09c5182d1df56)

Document locality partitioning params in invoke.texi

Filip Kastl pointed out that contrib/check-params-in-docs.py complains
about params not documented in invoke.texi, so this patch adds the short
explanation from params.opt for these to the invoke.texi section.
Thanks for the reminder.

Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
gcc/

* doc/invoke.texi (lto-partition-locality-frequency-cutoff,
lto-partition-locality-size-cutoff, lto-max-locality-partition):
Document.

(cherry picked from commit b7fb18dcf79476aa30ed2ad6cc2eaeab1f266107)

libstdc++: Update Linux/sparc64 baselines for GCC 15.1

The Linux/sparc64 libstdc++ baselines haven't been updated for years.
This patch fixes that.

Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.

2025-04-21  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

libstdc++-v3:
* config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: Regenerate.
* config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt: Likewise.

(cherry picked from commit 496b2ed86c41f50adac99e15c0d1a7c2d5428eba)

libstdc++: Update Solaris baselines for GCC 15.1

This patch updates the Solaris libstdc++ baselines for GCC 15.1.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the
gcc-15 branch and trunk.

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

libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

(cherry picked from commit 0c8f5e9f7a3cf5cb853ae485796021653ef4be7c)

libstdc++: Update baseline_symbols.txt for {x86_64,i486,powerpc64le,s390x,aarch64}-linux

We forgot to update these timely, sorry for that, the following patch
updates them from the 15.1-rc1 builds in Fedora.

2025-04-22  Jakub Jelinek  <jakub@redhat.com>

* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.

(cherry picked from commit cbd0d8e76a9403096907c179d2be6c163fb50414)

testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:

FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5:
error: implicit declaration of function '__sigsetjmp'; did you mean
'sigsetjmp'? [-Wimplicit-function-declaration]

__sigsetjmp is a Linux/glibc implementation detail.  Other tests just
use sigsetjmp directly, so this patch follows suit.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, and x86_64-apple-darwin24.4.0.

2025-04-22  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

gcc/testsuite:
* gcc.misc-tests/gcov-31.c (run_pending_traps): Use sigsetjmp
instead of __sigsetjmp.

(cherry picked from commit ab41f146cf077b89cff8d86e2f698ed0fabd12d9)

Daily bump.

Daily bump.

Daily bump.

Daily bump.

tree-optimization/119858 - type mismatch with POINTER_PLUS

The recent PFA early-break vectorization fix left us with a POINTER_PLUS
and non-sizetype offset.

PR tree-optimization/119858
* tree-vect-loop.cc (vectorizable_live_operation): Convert
pointer offset to sizetype.

LoongArch: Change {dg-do-what-default} save and restore logical.

The set of {dg-do-what-default} to 'run' may lead some test hang
during make check.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/loongarch-vector.exp: Change
{dg-do-what-default} save and restore logical.

(cherry picked from commit dd982198656d914a4958bf86356a4c996c728b9d)

Daily bump.

libstdc++: Update status tables to refer to GCC 15 not mainline

libstdc++-v3/ChangeLog:

* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxx2023.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.

Set DEV-PHASE to prerelease.

2025-04-17  Jakub Jelinek  <jakub@redhat.com>

* DEV-PHASE: Set to prerelease.

libgomp: Don't test ompx::allocator::gnu_pinned_mem on non-linux targets.

The libgomp.c/alloc-pinned*.c test have
/* { dg-skip-if "Pinning not implemented on this host" { ! *-*-linux-gnu* } } */
so they are only run on Linux targets right now.  Duplicating the tests or
reworking them into headers looked like too much work for me right now this
late in stage4, so I've just #ifdefed the uses at least for now.

2025-04-17  Jakub Jelinek  <jakub@redhat.com>

PR libgomp/119849
* testsuite/libgomp.c++/allocator-1.C (test_inequality, main): Guard
ompx::allocator::gnu_pinned_mem uses with #ifdef __gnu_linux__.
* testsuite/libgomp.c++/allocator-2.C (main): Likewise.

libstdc++: Fixed signed comparision in _M_parse_fill_and_align [PR119840]

Explicitly cast elements of __not_fill to _CharT. Only '{' and ':'
are used as `__not_fill`, so they are never negative.

PR libstdc++/119840

libstdc++-v3/ChangeLog:

* include/std/format (_M_parse_fill_and_align): Cast elements of
__not_fill to _CharT.

middle-end: fix masking for partial vectors and early break [PR119351]

The following testcase shows an incorrect masked codegen:

#define N 512
#define START 1
#define END 505

int x[N] __attribute__((aligned(32)));

int __attribute__((noipa))
foo (void)
{
  int z = 0;
  for (unsigned int i = START; i < END; ++i)
    {
      z++;
      if (x[i] > 0)
        continue;

      return z;
    }
  return -1;
}

notice how there's a continue there instead of a break.  This means we generate
a control flow where success stays within the loop iteration:

  mask_patt_9.12_46 = vect__1.11_45 > { 0, 0, 0, 0 };
  vec_mask_and_47 = mask_patt_9.12_46 & loop_mask_41;
  if (vec_mask_and_47 == { -1, -1, -1, -1 })
    goto <bb 4>; [41.48%]
  else
    goto <bb 15>; [58.52%]

However when loop_mask_41 is a partial mask this comparison can lead to an
incorrect match.  In this case the mask is:

  # loop_mask_41 = PHI <next_mask_63(6), { 0, -1, -1, -1 }(2)>

due to peeling for alignment with masking and compiling with
-msve-vector-bits=128.

At codegen time we generate:

ptrue   p15.s, vl4
ptrue   p7.b, vl1
not     p7.b, p15/z, p7.b
.L5:
ld1w    z29.s, p7/z, [x1, x0, lsl 2]
cmpgt   p7.s, p7/z, z29.s, #0
not     p7.b, p15/z, p7.b
ptest   p15, p7.b
b.none  .L2
...<early exit>...

Here the basic blocks are rotated and a not is generated.
But the generated not is unmasked (or predicated over an ALL true mask in this
case).  This has the unintended side-effect of flipping the results of the
inactive lanes (which were zero'd by the cmpgt) into -1.  Which then incorrectly
causes us to not take the branch to .L2.

This is happening because we're not comparing against the right value for the
forall case.  This patch gets rid of the forall case by rewriting the
if(all(mask)) into if (!all(mask)) which is the same as if (any(~mask)) by
negating the masks and flipping the branches.

1. For unmasked loops we simply reduce the ~mask.
2. For masked loops we reduce (~mask & loop_mask) which is the same as
   doing (mask & loop_mask) ^ loop_mask.

For the above we now generate:

.L5:
        ld1w    z28.s, p7/z, [x1, x0, lsl 2]
        cmple   p7.s, p7/z, z28.s, #0
        ptest   p15, p7.b
        b.none  .L2

This fixes gromacs with > 1 OpenMP threads and improves performance.

gcc/ChangeLog:

PR tree-optimization/119351
* tree-vect-stmts.cc (vectorizable_early_exit): Mask both operands of
the gcond for partial masking support.

gcc/testsuite/ChangeLog:

PR tree-optimization/119351
* gcc.target/aarch64/sve/pr119351.c: New test.
* gcc.target/aarch64/sve/pr119351_run.c: New test.

libstdc++: Do not use 'not' alternative token in <format>

This fixes:
FAIL: 17_intro/headers/c++1998/operator_names.cc  -std=gnu++23 (test for excess errors)
FAIL: 17_intro/headers/c++1998/operator_names.cc  -std=gnu++26 (test for excess errors)

The purpose of 'not defined<format_kind<R>>' is to be ill-formed (as
required by [format.range.fmtkind]) and to give an error that includes
the string "not defined<format_kind<R>>". That was intended to tell you
that format_kind<R> is not defined, just like it says!

But user code can use -fno-operator-names so we can't use 'not' here,
and "! defined" in the diagnostic doesn't seem as user-friendly. It also
raises questions about whether it was intended to be the preprocessor
token 'defined' (it's not) or where 'defined' is defined (it's not).

Replace it with __primary_template_not_defined<format_kind<R>> and a
comment, which seems to give a fairly clear diagnostic with both GCC and
Clang. The diagnostic now looks like:

.../include/c++/15.0.1/format:5165:7: error: use of 'std::format_kind<int>' before deduction of 'auto'
 5165 |       format_kind<_Rg> // you can specialize this for non-const input ranges
      |       ^~~~~~~~~~~~~~~~
.../include/c++/15.0.1/format:5164:35: error: '__primary_template_not_defined' was not declared in this scope
 5164 |     __primary_template_not_defined(
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
 5165 |       format_kind<_Rg> // you can specialize this for non-const input ranges
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 5166 |     );
      |     ~

libstdc++-v3/ChangeLog:

* include/std/format (format_kind): Do not use 'not'
alternative token to make the primary template ill-formed. Use
the undeclared identifier __primary_template_not_defined and a
comment that will appear in diagnostics.
* testsuite/std/format/ranges/format_kind_neg.cc: New test.

s390: Use match_scratch instead of scratch in define_split [PR119834]

The following testcase ICEs since r15-1579 (addition of late combiner),
because *clrmem_short can't be split.
The problem is that the define_insn uses
   (use (match_operand 1 "nonmemory_operand" "n,a,a,a"))
   (use (match_operand 2 "immediate_operand" "X,R,X,X"))
   (clobber (match_scratch:P 3 "=X,X,X,&a"))
and define_split assumed that if operands[1] is const_int_operand,
match_scratch will be always scratch, and it will be reg only if
it was the last alternative where operands[1] is a reg.
The pattern doesn't guarantee it though, of course RA will not try to
uselessly assign a reg there if it is not needed, but during RA
on the testcase below we match the last alternative, but then comes
late combiner and propagates const_int 3 into operands[1].  And that
matches fine, match_scratch matches either scratch or reg and the constraint
in that case is X for the first variant, so still just fine.  But we won't
split that because the splitters only expect scratch.

The following patch fixes it by using match_scratch instead of scratch,
so that it accepts either.

2025-04-17  Jakub Jelinek  <jakub@redhat.com>

PR target/119834
* config/s390/s390.md (define_split after *cpymem_short): Use
(clobber (match_scratch N)) instead of (clobber (scratch)).  Use
(match_dup 4) and operands[4] instead of (match_dup 3) and operands[3]
in the last of those.
(define_split after *clrmem_short): Use (clobber (match_scratch N))
instead of (clobber (scratch)).
(define_split after *cmpmem_short): Likewise.

* g++.target/s390/pr119834.C: New test.