EienMiku [Sat, 1 Aug 2026 06:37:47 +0000 (14:37 +0800)]
c++: Add missing "to" in reflection diagnostic
The diagnostic for applying ^^ to a local entity with an intervening
lambda expression reads "cannot be applied a local entity"; add the
missing "to", matching the phrasing of the other diagnostics in
get_reflection.
gcc/cp/ChangeLog:
* reflect.cc (get_reflection): Add missing "to" in diagnostic.
Marek Polacek [Fri, 31 Jul 2026 15:57:14 +0000 (11:57 -0400)]
c++/reflection: ICE with &template [:members_of():] [PR124794]
Given
struct C { template <class T> void f(T); };
we handle "&template [:^^C::f:]" correctly because the spliced
expression is
BASELINK<OVERLOAD<TEMPLATE_DECL f>>, binfo C>
which is fine: we have an OVERLOAD around the TEMPLATE_DECL and
lookup_member wrapped the whole thing in a BASELINK. But when
we're splicing members_of(^^C, ac)[0], we ended up with
OVERLOAD<TEMPLATE_DECL f>>
and then go down the wrong path in cp_parser_splice_expression.
splice already correctly adds the missing OVERLOAD but it also
needs to (maybe) add a BASELINK.
This patch also adjusts baselink_for_fns to gain a parameter
controlling if we want to ignore currently_open_derived_class.
It matters when we're in a member function of a class derived
from C and the object argument of the -> is a different derived class,
as exercised in splice17.C: pd->[:g1:] (42); in D2::mfn. There, if
we didn't ignore currently_open_derived_class, the BASELINK would
use D2 as the access_binfo, which is wrong because it has no
derivation relationship to the object type (here D1). With this
patch access_binfo will be C, which is what members_of gave us.
PR c++/124794
gcc/cp/ChangeLog:
* cp-tree.h (baselink_for_fns): Adjust declaration.
* parser.cc (cp_parser_reflect_expression): Adjust the call to
baselink_for_fns.
* reflect.cc (splice): Call baselink_for_fns.
* semantics.cc (baselink_for_fns): Add a bool parameter. If
it's true, ignore currently_open_derived_class.
[expr.reflect] says that a reflection of a pack-index-expressions
is ill-formed. But that applies to the ^^id-expression production,
not ^^type-id, in which a pack-index-specifier (for types) can be
used. So it's wrong for get_reflection to check PACK_INDEX_P, it
should only reject PACK_INDEX_EXPR.
I don't think that currently we can get there with a PACK_INDEX_EXPR
though: for a pack-index-expression Xs...[0] cp_parser_reflection_name
will consume Xs and then immediately call get_reflection which gives
an error. But leaving the PACK_INDEX_EXPR check in doesn't seem like
a bad idea.
PR c++/126546
gcc/cp/ChangeLog:
* reflect.cc (get_reflection): Check PACK_INDEX_EXPR instead of
PACK_INDEX_P.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/pack-index1.C: Accept a reflection of a
pack-index-specifier. Reject a reflection of a
pack-index-expression.
* g++.dg/reflect/pack-index2.C: New test.
James K. Lowden [Mon, 3 Aug 2026 20:48:30 +0000 (16:48 -0400)]
cobol: Ignore comments in strings.
Change the file reader to recognize string constants, and not treat
the sequence "*>" as an inline comment if it appears in a
string. Credit to George Neill for the patch.
gcc/cobol/ChangeLog:
* lexio.cc (skip_quoted_literal): New function.
(remove_inline_comment): Use new function.
These changes add expanded diagnostics to error locations not addressed
in the original patch. This is done by using a new helper function that
saves the error message information for namelist related errors in a
buffer and keeping a status bit in the st_parameter_dt structure.
PR libfortran/118793
libgfortran/ChangeLog:
* io/io.h (NML_ERR_MSG_LEN): New macro.
(st_parameter_dt): Add nml_err_pending bit.
(gfc_unit): Add nml_err_msg.
* io/list_read.c (nml_error): New function.
(eat_separator): Use new function
(convert_integer): Likewise.
(convert_unsigned): Likewise.
(parse_repeat): Likewise. Save the position where the repeat
count starts and report it.
(read_logical): Likewise.
(read_integer): Likewise.
(parse_real): Likewise.
(read_complex): Likewise.
(read_real): Likewise.
(check_type): Likewise.
(list_formatted_read_scalar): Likewise.
(read_character): Likewise. Save the initial position of the value
(nml_read_obj): Unwind to nml_err_ret on a deferred error.
(namelist_read): Store deferred errors in the unit's nml_err_msg
buffer.
gcc/testsuite/ChangeLog:
* gfortran.dg/namelist_101.f90: Fix dg-do directive typo and
check the expanded diagnostic.
* gfortran.dg/namelist_104.f90: New test.
Jeff Law [Mon, 3 Aug 2026 20:48:05 +0000 (14:48 -0600)]
[committed] Fix recent msp430-elf regressions
I didn't actually bisect this, but I strongly suspect this relates to the
recent set INSN_CODE before calling insn_cost.
An obscure corner case I didn't even know existed. Inside combine we can
create nop moves which look something like (set (pc) (pc)). That would have
triggered an early out in msp430_insn_cost. After the combine change those
insns use NOOP_MOVE_INSN_CODE via special hackery in combine rather than the -1
for an unrecognized insn.
So rather than early exit from msp430_insn_code, we try to call get_attr_length
of that noop move which of course fails and triggers all kinds of testsuite
regressions.
While I considered checking earlier in the call stack, msp430 seems to be the
only port affected, so I put it down in there. Built and regression tested
where it fixes the recent regressions and causes no new regressions. Pushing
to the trunk.
gcc/
* config/msp430/msp430.cc (msp430_insn_cost): Handle insns with
NOOP_MOVE_INSN_CODE.
James K. Lowden [Mon, 3 Aug 2026 19:24:44 +0000 (15:24 -0400)]
cobol: Remove TITLE token.
TITLE was never part of ISO COBOL and is no longer mentioned in the
IBM manual. Removed it from the token list, where it was not used, and
from the lexer, where it caused errors.
gcc/cobol/ChangeLog:
* cdf.y: Update tokens.
* parse.y: Remove TITLE token.
* scan.l: Remove scanning for TITLE.
* token_names.h: Remove TITLE from token set.
James K. Lowden [Mon, 3 Aug 2026 18:06:08 +0000 (14:06 -0400)]
cobol: Avoid internal compiler error in generated lexer.
For some inputs the lexer returned: input buffer overflow, can't
enlarge buffer because scanner uses REJECT. In fact REJECT is not
used, but the message can be engendered by variable-length patterns if
they match very long input.
Use the flex input() and unput() to read the stream in advance of
pattern-matching, and restore it before the lexer continues.
gcc/cobol/ChangeLog:
* scan.l: Remove pattern that potentially matches until EOF.
* scan_ante.h (skip_string): Recast in terms of input/unput.
(yyinput): Declare function.
(yyunput): Declare function.
(is_refmod): Recast in terms of input/unput.
Robert Dubner [Mon, 3 Aug 2026 17:26:27 +0000 (13:26 -0400)]
cobol: Repairs to structure creation. [PR119461]
This PR is over a year old. The original observation that the record
layout was done in odd ways has been addressed in the intervening
months; these changes finalize those repairs. Some recursive references
(where a structure contains a pointer to structures like itself) have
been repaired (instead of using a placeholding "char *").
The use of ULONGLONG (a synonym for long_long_unsigned_type_node)
has been replaced with UINT64 (for uint64_type_node) in order to reduce
possible ambiguity.
PR cobol/119461
gcc/cobol/ChangeLog:
* genapi.cc (array_of_long_long): Renamed array_of_uint64().
(array_of_uint64): Likewise.
(parser_compile_ecs): Use array_of_uint64().
(parser_compile_dcls): Likewise.
(parser_file_add): Likewise.
(gg_array_of_file_pointers): Use new cblc_file_pp_type_node;
* gengen.cc (gg_get_structure_type_decl): Moved to structs.cc and
renamed.
* gengen.h (ULONGLONG): #define removed and replaced with UINT64.
(UINT64): Likewise.
(gg_get_structure_type_decl): Declaration removed.
* structs.cc (create_structure_type): New function.
(get_structure_type_decl): Renamed version of
gg_get_structure_type_decl().
(create_cblc_field_t): Cleaned up structure creation.
(create_referlet_t): Likewise.
(create_refer_t): Likewise.
(create_our_type_nodes): Likewise.
* structs.h (GTY): New declaration for cblc_file_pp_type_node;
* symbols.h (enum cbl_ctype_t): Removed.
Excluding an interval is now expressible, and excluding zero is just
the [-0.0, +0.0] case of it, so say so.
For some stupid historical reason which I can't remember, the irange
and prange nonzero_p() predicates returns true only for ~[0,0], so
even [5,5] returns false. When we want to test whether a range
contains a zero, we usually use the contains_p() idiom. I think this
is idotic, but perhaps there is a reason for it.
I've implemented the frange version the same way, with the wrinkle
that the constructor for ~[-0.0, +0.0] includes the possibility of
+-NAN, which means that nonzero_p() must ignore the NAN bits,
otherwise anything but a strict ~[-0.0, +0.0] +-NAN would return
false. For example, this:
x = frange(0.0, VR_ANTI_RANGE);
x.clear_nan();
x.nonzero_p(); <-- would return false
Tested on ppc64le Linux: regstrap and LAPACK. Surprisingly there are
no changes to generated output in my Fortran files, presumably because
intersect/union are enough to fold inequalities away, and also because
there are no callers to nonzero_p() for frange. Every nonzero_p()
call is guarded by prange or irange checks, but it's nice to
implement these since they are pure virtuals from the base vrange
class.
gcc/ChangeLog:
* value-range.cc (frange::set_nonzero): Implement.
(frange::nonzero_p): Implement.
(range_tests_excluding): Test set_nonzero and nonzero_p.
Reshma Roy [Thu, 30 Jul 2026 06:49:08 +0000 (12:19 +0530)]
match: Fix incorrect identification of POPCOUNT pattern [PR126466]
This fixes r17-489-g8ca1e887847e2f, which added a third 32-bit
Hacker's Delight popcount matcher. Its predicate checked
compare_tree_int (@5, 0x0F0F0F0F) twice and never validated the
final outer AND constant (@7), so any mask was accepted once the
earlier constants matched.
Require compare_tree_int (@7, 0x0000003F) so only the intended
popcount idiom is folded to IFN_POPCOUNT.
gcc/ChangeLog:
PR tree-optimization/126466
* match.pd: Fix incorrect POPCOUNT identification in the third
32-bit Hacker's Delight matcher.
Jakub Jelinek [Mon, 3 Aug 2026 09:26:11 +0000 (11:26 +0200)]
mips: Fix up creation of MD builtins with 0 arguments [PR126484]
For MIPS_SI_FTYPE_VOID and MIPS_USI_FTYPE_VOID which are meant
for functions which return (SImode) int or unsigned int and have
(void) arguments the MIPS backend creates those using
case MIPS_SI_FTYPE_VOID: types[(int) type] = build_function_type_list (intSI_type_node, void_type_node, NULL_TREE); break;
case MIPS_USI_FTYPE_VOID: types[(int) type] = build_function_type_list (unsigned_intSI_type_node, void_type_node, NULL_TREE); break;
That is wrong, because functions which don't take any arguments
(i.e. (void) or C23/C++ ()) should be using void_list_node as
TYPE_ARG_TYPES, not a TREE_LIST with void_type_node TREE_VALUE
and TREE_CHAIN being that void_list_node. Although void_list_node
also has TREE_VALUE of void_type_node, various places in the C++
FE as well as in the middle-end rely on void_list_node to be unique,
compare it using pointer comparison.
The following testcase strangely happens to compile fine when compiled
in C, but fails in C++ (which reports wrong number of arguments due
to this bug).
The following simple patch just arranges those 0 argument functions
to have the MIPS_*_FTYPE_VOID enumerators be named as before, but
in the build_function_type_list call omit that ", void_type_node" part,
so it creates correct 0 arguments FUNCTION_TYPE.
2026-08-03 Jakub Jelinek <jakub@redhat.com>
PR target/126484
* config/mips/mips-ftypes.def (MIPS_SI_FTYPE_VOID,
MIPS_USI_FTYPE_VOID): Use DEF_MIPS_FTYPE with 0 as
first argument rather than 1 and leave out ", VOID" from
second argument.
* config/mips/mips.cc (MIPS_FTYPE_NAME0): Define.
(MIPS_FTYPE_ATYPES0): Define.
testsuite/g++: force the serial PSTL backend in xtreme-header-8.C
xtreme-header-8.C is the only xtreme-header test that builds a named
module, so [basic.link]/17 applies to it and exposing a TU-local entity
is ill-formed. libstdc++ selects the PSTL backend from
__has_include(<tbb/tbb.h>), so on a machine with oneTBB installed
<execution> pulls third-party headers into the module purview. oneTBB
names namespace-scope statics and constants from inline member functions
of externally linked classes, which GCC correctly rejects, and the test
fails for reasons that have nothing to do with libstdc++ or the modules
implementation.
The failure dates back to r15-6379-g0c2ae3843261 ("c++/modules: Ignore
TU-local entities where necessary"), which added the test. The exposure
diagnostic already existed then, so the test has failed on a host with
oneTBB installed since the day it landed. That commit message does note
the hazard, "unfortunately the system headers on some
targets declare TU-local entities", but the third-party headers reached
through <execution> were not considered.
_GLIBCXX_USE_TBB_PAR_BACKEND is a documented user-overridable knob, and
libstdc++ already suppresses the TBB backend the same way for module std
(r15-5366-g7db55c0ba1ba). Define it to 0 so the test exercises what it
is meant to exercise regardless of what happens to be installed on the
test machine.
Tested on aarch64-none-linux-gnu.
gcc/testsuite/ChangeLog:
* g++.dg/modules/xtreme-header-8.C: Select the serial PSTL
backend.
[frange] Represent the inverse of a constant range
We've been throwing away the VR_ANTI_RANGE flag when setting a range,
and quietly turning it into VARYING. This patch allows setting the
inverse of a range:
frange::set (TYPE, MIN, MAX, VR_ANTI_RANGE)
This allows us to represent x != C, which is very useful for
representing non-zero.
Excluding a point is two sub-ranges:
[-INF, prev (C)] U [next (C), +INF]
range-op-float has in fact been asking for this all along.
operator_not_equal::op1_range hands us r.set (type, tmp, tmp,
VR_ANTI_RANGE) on the true edge, and operator_equal::op1_range does
the same on the false edge. They needed no changes; frange simply had
nowhere to put the answer.
Nothing here is special-cased. C == 0.0 excludes both zeros for free,
because prev (0.0) is the largest negative denormal and next (0.0) the
smallest positive one.
With this patch we finally come to parity with DOM floating point
threading, at least when it comes to the LAPACK package, which I've
taken as representative of floating point intensive code.
Tested on ppc64le Linux: regstrap, LAPACK, GSL, etc. I also
benchmarked threading counts and VRP folds, as per the last commit in
this series.
gcc/ChangeLog:
* value-range.h (class frange): Declare set_excluding.
* value-range.cc (frange::set_excluding): New.
(frange::set): Assert KIND is VR_RANGE or VR_ANTI_RANGE and that the
endpoints are not NAN. Turn a VR_ANTI_RANGE into the two sub-ranges
that exclude the point.
(frange_float_excluding, range_tests_excluding): New.
(range_tests_floats): Call range_tests_excluding.
* value-range-storage.cc (frange_storage::get_frange): Return early
for VR_VARYING, like irange_storage::get_irange.
Raise MAX_PAIRS from 1 to 2, enabling sub-ranges. This will allow us
to represent non-zero and other inequalities in a follow-up patch.
I tested how many sub-ranges would give us the most bang for the buck,
by allowing 10 sub-ranges, and seeing how many we created and used.
Even though 1 sub-range caught 91.29% of what we encountered in real
life (well, in a corpus of Fortran files from the LAPACK package), we
couldn't represent non-zero, which caused DOM to get a bunch of cases
we missed. With 2 subranges, we caught 99.63% of ranges generated,
and anything past this was useless, cause we either didn't generate
them in real life, or there was no change in generated code by having
more sub-ranges. For instance, from 3631 files, going from 2 to 3
sub-ranges caused code generation changes in 4 files (all rotmg*).
Going past 3, produced zero effect.
I also benchmarked LAPACK and the GSL package for jump threading
changes as well as VRP constant propagation. For LAPACK, we got 0.31%
more jump threading opportunities, and for GSL 1.10%. For VRP it was
the opposite, LAPACK got 0.48% more constants propagated, whereas GSL
got a mere 0.26% boost.
This may not seem like much, but just being able to represent the
inverse of a constant (e.g. nonzero) closes the gap with the DOM
internal tables. With this work, we get 100% of what DOM threading
was getting with its internal tables for the LAPACK corpus. We nuked
58 of the regressions, and I believe this will fix a few PRs we had
open for nonzero folding, as well as some signed zero missed
optimizations.
Oh, and with this patch we cause code generation differences in 2.2%
of LAPACK, and 5.48% of GSL files. I didn't dig into any of these,
but it seems other passes benefit as well. Either way, we needed a
way to represent != 0.0, which seemed like a big limitation in the
initial frange implementation, and was causing me to lose sleep in my
self-imposed break from hacking.
Tested on ppc64le: regstrap, LAPACK, GSL.
gcc/ChangeLog:
* value-range.h (class frange): Raise MAX_PAIRS to 2.
* value-range.cc: Include value-range-storage.h.
(real_from_str, range_tests_sub_ranges, range_tests_sub_ranges_nan)
(range_tests_sub_ranges_zero, range_tests_sub_ranges_storage): New.
(range_tests_floats): Call them, and adjust the disjoint-union test.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/vrp-float-15.c: New test.
* gcc.dg/tree-ssa/vrp-float-16.c: New test.
* gcc.dg/tree-ssa/vrp-float-17.c: New test.
shuffle_slide_patterns did not verify that the endpoints of a combined
slideup+slidedown sequence actually correspond to OP0's and OP1's
expected positions, allowing a non-monotonic shuffle mask to be
accepted as a valid slide pattern. This produced wrong code at -O0
for masks such as { 7, 0, 7, 0 } on a 4-element vector, as reported
in PR target/126411.
This patch checks that d->perm[0] and d->perm[vlen - 1] correspond
to the expected OP0/OP1 boundary positions (vlen - slideup_cnt and
2 * vlen - 1 - slideup_cnt respectively), and rejects the pattern
otherwise. need_slideup_p is also added to the existing second-pivot
rejection check.
PR target/126411
gcc/ChangeLog:
* config/riscv/riscv-v.cc (shuffle_slide_patterns): Check that
the sequence endpoints correspond to OP0's and OP1's expected
positions and also reject a second pivot when need_slideup_p is set.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/bug126411.c: New test.
Suggested-by: Raphael M Zinsly <raphael.zinsly@oss.qualcomm.com> Signed-off-by: Souradipto Das <souradiptodas6@gmail.com>
Robert Dubner [Sun, 2 Aug 2026 19:28:50 +0000 (15:28 -0400)]
cobol: Make pointer to stash location file-static. [PR126391]
COBOL variable assignments can have ON SIZE ERROR clauses. When an error
occurs and there is such a clause, the original destination value is
not changed. Since the discovery of an error happens near the end, I
chose to create a data stash for the original value; when an error is
detected, the starting value is restored from the stash.
The stash area is created using malloc, but never freed. It gets
realloced as necessary when subsequently needed. (This avoids repeated
malloc/free calls during execution.)
My mistake: I created the pointer to that area as an automatic variable
on the stack, but assigned it to a static tree. The mistake manifested
here as a temporary variable with the function context as
stored-char-length, but then later showing up with a context of prog,
leading to the ICE, because automatic variables have to have the correct
function context.
The fix was to give that variable a name and give it file-static scope.
PR cobol/126391
gcc/cobol/ChangeLog:
* move.cc (move_helper): static tree stash has file-static scope.
SSE math is disabled with -mno-sse2. Since sse-init-v2df-1.c requires
SSE math, compile sse-init-v2df-1.c with -mfpmath=sse so that SSE math
is enabled with "-mno-sse2"
* gcc.target/i386/sse-init-v2df-1.c: Compile with -mfpmath=sse.
Andrea Pinski [Sat, 1 Aug 2026 23:17:25 +0000 (16:17 -0700)]
phiopt: Factor loads, reject if the pointer types are not compatiable [PR126571]
In some cases (different address space and/or function pointers) pointers are considered
non-compatible. This means creating a phi with non-compatible pointers will fail.
This takes the easy way out and rejecting this case. This could be refined to support
the only case where address spaces are different but that case will show up much less
than the address space being different so it is not worth the trouble right now.
Pushed as obvious after bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/126571
gcc/ChangeLog:
* tree-ssa-phiopt.cc (factor_out_conditional_load): Reject
when the pointer types are not compatible when creating a phi.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr126571-1.c: New test.
* gcc.target/i386/pr126571-1.c: New test.
Signed-off-by: Andrea Pinski <andrew.pinski@oss.qualcomm.com>
Thomas Koenig [Sat, 1 Aug 2026 17:03:38 +0000 (19:03 +0200)]
Fix undefined variable warning in ASSOCIATE.
This patch fixes unused warnings in ASSOCIATE constructs by setting
value_used and value_set attributes based on the associate names.
This is placed after resolution of the code. To get to the association
list, an extra argument to gfc_resolve was needed.
gcc/fortran/ChangeLog:
PR fortran/126558
* gfortran.h (gfc_resolve): Add optional argument for
an association list.
* resolve.cc (mark_assoc_used): New function.
(gfc_resolve): Use it.
gcc/testsuite/ChangeLog:
PR fortran/126558
* gfortran.dg/warn_undefined_vars_10.f90: New test.
Thomas Koenig [Sat, 1 Aug 2026 08:47:27 +0000 (10:47 +0200)]
Inline MATMUL(TRANSPOSE(A),B) for rank 1 B.
This patch implements inlining MATMUL(TRANSPOSE(A),B). For ordering
of the loops, this is an unpleasant problem because of the dependence
of c(i) on the previous iteration, but gcc was able to fully unroll
the loops at least for small sizes, and the version in the patch generated
better code.
gcc/fortran/ChangeLog:
* frontend-passes.cc (enum matrix_case): Add case A2TB1.
(matmul_lhs_realloc): Add condition for reallocation and
size checks.
(inline_matmul_assign): Handle A2TB1.
Roger Sayle [Sat, 1 Aug 2026 16:51:02 +0000 (17:51 +0100)]
x86 SSE: Improved vector initialization/construction.
This patch is a reorganization of x86's vector initialization (vec_init)
functionality to generate more efficient implementations in most/many
cases. Previously, for most (128-bit and 256-bit) vectors types,
i386-expand.cc made use of "concat" recursion to divide-and-conquor;
splitting each vector into upper and lower halves, initializing them,
then concatenating the results together. Simple and orthogonal, but
alas inefficient. This idiom is unable to take advantage of SSE's
zero extension semantics, shuffle/permutation instructions, byte-level
shifts, element insertion instructions nor vector-mode logic operations.
Unfortunately the reality is that these ISAs are irregular, as are the
patterns provided by the backend expose their instructions (which are
often available in one mode but not another).
The patch below recognizes/accepts these asymmetries, and provides
"custom" vector initialization functions for most 128-bit and 256-bit
vector modes. There are too many optimization/improvements to list
them all, but some examples are given below:
v4si f1(int x, int y) { return (v4si){x,y,0,0}; }
Before with -O2:
f1_old: movd %edi, %xmm0
movd %esi, %xmm1
punpckldq %xmm1, %xmm0
movq %xmm0, %xmm0
ret
After with -O2:
f1_new: movd %edi, %xmm0
movd %esi, %xmm1
punpckldq %xmm1, %xmm0
ret
v4si f2(int x) { return (v4si){0,x,x,0}; }
Before with -O2:
f2_old: movd %edi, %xmm2
pxor %xmm0, %xmm0
movd %edi, %xmm1
punpckldq %xmm2, %xmm0
punpcklqdq %xmm1, %xmm0
ret
f2_new: movd %edi, %xmm0
shufps $65, %xmm0, %xmm0
ret
After with -O2 -mavx2:
f4_new: movzbl %dil, %eax
vmovd %eax, %xmm0
vpinsrb $9, %edi, %xmm0, %xmm0
ret
Unfortunately, despite all of the goodness there remains one testsuite
regression: avx512vl-concatv4si-1.c whose f2 function currently expects
3 instructions before the return:
which actually contains our two optimal instructions, but between
combine, simplify-rtx and sse.md's define_insn_and_splits, we fail
to notice that the remaining operations (converting V2SI to V4SI)
are a no-op. I beg the reviewers'/maintainers' indulgence to allow
this to fail for the time being, to be solved in a follow-up patch.
This current patch is large enough already, and this remaining quirk
needs to be resolved outside the RTL expansion pass, in the later
RTL optimizers (where it is currently a missed optimization).
2026-08-01 Roger Sayle <roger@nextmovesoftware.com>
Hongtao Liu <hongtao.liu@intel.com>
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_vector_init_one_nonzero):
Improved implementations for V2DI, V2DF, V4SI, V4SF, V4DI and V4DF
modes. Return false for V2SI and V2SF modes if the one non-zero
element isn't the first/lowest. Improved implementations for V8HI,
V16QI, V2HI and V8QI modes.
(nonzero_int_const_count): New helper function to count the
number of non-zero integer constants in a given array.
(nonzero_float_const_count): Likewise for SFmode floats.
(nonzero_double_const_count): Likewise for DFmode doubles.
(ix86_expand_vector_init_insert): New function to initialize a
V4SI, V8HI or V16QI vector using a sequence of pinsr[bwd] insns.
(onevar_perm_p): New local helper function.
(twovar_perm_p): Likewise.
(ix86_expand_vector_init_v2di): New mode-specific function.
(ix86_expand_vector_init_v2df): Likewise.
(ix86_expand_vector_init_v4si): Likewise.
(ix86_expand_vector_init_v4sf): Likewise.
(ix86_expand_vector_init_v8hi): Likewise.
(ix86_expand_vector_init_v16qi): Likewise.
(ix86_expand_vector_init_v4di): Likewise.
(ix86_expand_vector_init_v4df): Likewise.
(ix86_expand_vector_init_v8si): Likewise.
(ix86_expand_vector_init_v8sf): Likewise.
(ix86_expand_vector_init_general): Call the above custom helper
functions for the relevant modes.
* config/i386/sse.md (*vec_interleave_lowv4si_sse): New pattern
for (V4SImode) unpcklps on TARGET_SSE but not TARGET_SSE2.
Robert Dubner [Sat, 1 Aug 2026 11:48:37 +0000 (07:48 -0400)]
cobol: Refactor the gmath.cc "int256" structure.
The int256 structure is used for doing fixed-point arithmetic. This
rewrite incorporates "int rdigits" into the structure, so that the number
of digits to the right of the decimal point is carried as part of the
structure instead of being carried by external logic.
gcc/cobol/ChangeLog:
* copybook.h (_COPYBOOK_H): #include <sys/types.h> for macOS.
* lexio.h (struct filespan_t): Mollify cppcheck with a const variable.
* parse.y: Adjust a dbgmsg() call.
* util.cc (cobol_filename): Likewise.
Jakub Jelinek [Sat, 1 Aug 2026 09:46:49 +0000 (11:46 +0200)]
Get rid of ? true : false and simplify ? false : true
Last night I've noticed in match.pd various places like
cmp == EQ_EXPR ? true : false
and
cmp == EQ_EXPR ? false : true
I don't think that is useful, neither for readers nor for code formatting.
Sure, x ? true : false is not always equivalent to just x, but if it is
passed to a bool argument or sets a bool variable or if x is actually
a comparison in C++, it is exactly the same.
I think using just cmp == EQ_EXPR and cmp != EQ_EXPR is better.
2026-08-01 Jakub Jelinek <jakub@redhat.com>
* ipa-polymorphic-call.cc (csftc_abort_walking_p): Remove useless
"? true : false".
* tree-ssa-loop-im.cc (ref_indep_loop_p): Likewise.
* match.pd (X ==/!= !X is false/true): Replace "? false : true"
with negation of the condition.
(((C << x) & D) != 0): Likewise.
(fold_sign_changed_comparison and fold_widened_comparison): Likewise.
Remove useless "? true : false".
(if the second operand is NaN, the result is constant): Replace
"? false : true" with negation of the condition.
(__builtin_ctz (x) >= C -> (x & ((1 << C) - 1)) == 0): Likewise.
Remove useless "? true : false".
(__builtin_ctz (x) == C -> (x & ((1 << (C + 1)) - 1)) == (1 << C)):
Replace "? false : true" with negation of the condition.
(__builtin_ffs (X) == 0 -> X == 0): Remove useless "? true : false".
(__builtin_ffs (X) > 6 -> X != 0 && (X & 63) == 0): Likewise.
Replace "? false : true" with negation of the condition.
* gimple-pretty-print.cc (dump_phi_nodes): Use !(flags & TDF_GIMPLE)
instead of (flags & TDF_GIMPLE) ? false : true.
gcc/fortran/
* expr.cc (gfc_check_init_expr): Remove useless "? true : false".
(gfc_expr_check_typed): Replace "? false : true" with negation of the
condition.
* parse.cc (gfc_find_state): Likewise.
* resolve.cc (impure_stmt_fcn): Likewise.
* arith.cc (gfc_check_character_range): Remove useless
"? true : false".
* array.cc (is_constant_element): Likewise.
* decl.cc (gfc_verify_c_interop): Likewise.
* interface.cc (gfc_check_dummy_characteristics): Likewise.
* io.cc (check_open_constraints): Likewise.
(check_close_constraints): Likewise.
(check_io_constraints): Likewise.
gcc/jit/
* jit-recording.cc (recording::context::set_bool_option): Remove
useless "? true : false".
Reviewed-by: Andrea Pinski <andrew.pinski@oss.qualcomm.com>
Jakub Jelinek [Sat, 1 Aug 2026 09:44:55 +0000 (11:44 +0200)]
c++: Rename metafns_called to state_dependent
On Thu, Jul 30, 2026 at 10:29:23AM -0400, Jason Merrill wrote:
> OK, though we might rename metafns_called to something like state_dependent
> and mention EH in its comment. That can be a trunk-only followup.
Here it is.
2026-08-01 Jakub Jelinek <jakub@redhat.com>
* constexpr.cc (class constexpr_global_ctx): Rename metafns_called
to state_dependent, expand comment about constexpr EH.
(constexpr_global_ctx::constexpr_global_ctx ()): Rename
metafns_called to state_dependent.
(cxx_eval_cxa_builtin_fn): Likewise.
(cxx_eval_call_expression): Likewise.
Pan Li [Thu, 30 Jul 2026 07:36:36 +0000 (15:36 +0800)]
RISC-V: Add test cases for vwaddu.vv reg overlap
Add test cases for register group overlap, please
note it is not overlap as much as possible.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u16-m1.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u16-m2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u16-m4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u16-mf2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u16-mf4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u32-m1.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u32-m2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u32-m4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u32-mf2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u8-m1.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u8-m2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u8-m4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u8-mf2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u8-mf4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwaddu_vv-u8-mf8.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pan Li [Thu, 30 Jul 2026 07:36:21 +0000 (15:36 +0800)]
RISC-V: Add test cases for vwadd.vv reg overlap
Add test cases for register group overlap, please
note it is not overlap as much as possible.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/group_overlap/group_overlap.h:
Add test helper macros.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i16-m1.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i16-m2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i16-m4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i16-mf2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i16-mf4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i32-m1.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i32-m2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i32-m4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i32-mf2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i8-m1.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i8-m2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i8-m4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i8-mf2.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i8-mf4.c: New test.
* gcc.target/riscv/rvv/autovec/group_overlap/vwadd_vv-i8-mf8.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tomasz Kamiński [Sat, 1 Aug 2026 07:08:15 +0000 (09:08 +0200)]
libstdc++: Disable "-Winvalid-specialization" for g++ coroutine tests.
These test define specializations for libstdc++ std::coroutine_handle
definition, that is marked [[_Clang::__no_specializations]] since r17-2853-gb90df55625eb40.
Andrea Pinski [Fri, 24 Jul 2026 19:49:54 +0000 (12:49 -0700)]
gimple-fold: fix follow_outer_ssa_edges for undefined overflow cases [PR126313]
ifcombine uses match and match will use in some cases the global
range causing wrong code as the range of the ssa name might be based
on the outer condition.
The case in the bug report is:
```
# RANGE [irange] int [0, 255] MASK 0xff VALUE 0x0
_2 = (int) a.0_1;
if (_2 > 1)
goto <bb 4>; [59.00%]
else
goto <bb 3>; [41.00%]
<bb 3> [local count: 440234144]:
# RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0
_8 = (int) a.0_1;
if (_2 > _8)
goto <bb 4>; [50.00%]
else
goto <bb 5>; [50.00%]
```
So this was `(_2 <= 1 && _2 <= _8) ? goto 5 else; goto 4;`
This starts by combnining `_2 <= 1 && _2 <= _8` into `_2 <= min(1, _8)`.
But since _8 has a range of [0,1], match invokes the pattern that was added
in r14-868-gb06cfb62229f to giving `_2 <= (_8 & 1)` and then since _8 has a
range of [0,1], that expression simpifies into `_2 < _8` which is wrong.
as _2 is the same as _8. So we end up with not taking the condition any more.
The problem comes follow_outer_ssa_edges is used to save off the global range
but we return early if the variable had a type where overflow is undefined as we
can't temporary rewrite it. So the fix is to swap around the saving the off
the global range before returning early.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/126313
gcc/ChangeLog:
* gimple-fold.cc (follow_outer_ssa_edges): Swap around returning
for undefined overflow and saving off the global range.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr126313.c: New test.
Signed-off-by: Andrea Pinski <andrew.pinski@oss.qualcomm.com>
Jason Merrill [Fri, 31 Jul 2026 17:45:48 +0000 (13:45 -0400)]
c++: early DMI parsing and {} [PR126481]
Here I thought that only name lookup and use of 'this' could change in a
complete class context, but this testcase demonstrates that an init-list
also needs deferred parsing.
PR c++/126481
gcc/cp/ChangeLog:
* parser.cc (cp_parser_early_parsing_nsdmi): Also defer {}.
Eric Botcazou [Fri, 31 Jul 2026 18:18:15 +0000 (20:18 +0200)]
Ada: Fix bogus error for 'Value invoked on function call and -gnatVa
This happens when the function takes an In Out or Out parameter, so only in
Ada 2012 and later. The mechanism used to implement the validity check for
the call, required by -gnatVa, inserts the copy-out statement incorrectly.
gcc/ada/
PR ada/126379
* exp_ch6.adb (Insert_Post_Call_Actions): Also deal with attribute
references as parent node.
gcc/testsuite/
* gnat.dg/validity_check3.adb: New test.
Patrick Palka [Fri, 31 Jul 2026 18:56:29 +0000 (14:56 -0400)]
libstdc++: Optimize ranges::distance for segmented iterators [PR123211]
For segmented iterators, ranges::distance is equivalent to the sum of
ranges::distance of each of its segments.
PR libstdc++/123211
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__distance_fn::operator()): For
the non-sized-sentinel overload, recursively handle segmented
iterators via __for_each_segment.
Patrick Palka [Fri, 31 Jul 2026 18:54:12 +0000 (14:54 -0400)]
libstdc++: Introduce segmented iterator concept and traversal
This patch defines a new utility function std::__for_each_segment for
iterating over "segmented" iterators, i.e. iterators for ranges composed
of sub-ranges. Such iterators must provide a static member function
_S_for_each_segment implementing traversal over their segments via a
callback function. This patch implements such traversal for iterators
of std::deque, ranges::join_view and ranges::concat_view.
PR libstdc++/123211
libstdc++-v3/ChangeLog:
* include/bits/stl_deque.h (_Deque_iterator::_S_for_each_segment):
Define.
(_Deque_iterator::_S_enable_for_each_segment): Define.
* include/bits/stl_iterator_base_funcs.h: Include <bits/move.h>.
(__for_each_segment): Define.
* include/bits/stl_iterator_base_types.h: Include
<ext/type_traits.h> in C++98 mode.
(__enable_for_each_segment): Define.
(__segmented_iterator): Define in C++20.
* include/debug/safe_iterator.h
(_Safe_iterator::_S_for_each_segment): Define.
(_Safe_iterator::_S_enable_for_each_segment): Define.
* include/std/ranges (join_view::_Iterator::_Iterator): New
constructor taking both an inner and outer iterator.
(join_view::_Iterator::_S_for_each_segment): Define.
(join_view::_Iterator::_S_enable_for_each_segment): Define.
(concat_view::_Iterator::_S_for_each_segment): Define.
(concat_view::_Iterator::_S_enable_for_each_segment): Define.
* testsuite/23_containers/deque/for_each_segment.cc: New test.
* testsuite/std/ranges/adaptors/join/for_each_segment.cc: New test.
* testsuite/std/ranges/concat/for_each_segment.cc: New test.
Patrick Palka [Fri, 31 Jul 2026 18:11:42 +0000 (14:11 -0400)]
libstdc++: Implement LWG 4440 feature-test macros added to <iosfwd>
Note __cpp_lib_char8_t doesn't use the <bits/version.h> mechanism, it's
defined in c++config and thus provided by all headers by default.
libstdc++-v3/ChangeLog:
* include/std/iosfwd: Provide feature-test macros
__cpp_lib_spanstream and __cpp_lib_syncbuf.
* testsuite/27_io/headers/iosfwd/synopsis.cc: Verify values
of these FTMs.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Patrick Palka [Fri, 31 Jul 2026 18:11:38 +0000 (14:11 -0400)]
libstdc++: Implement LWG 4301 changes to condition_variable{_any}
* include/std/condition_variable (condition_variable::wait_until):
Take timeout parameter by value as per LWG 4301.
(condition_variable::wait_for): Likewise.
(condition_variable::__wait_until_impl): Likewise.
(condition_variable_any::wait_until): Likewise.
(condition_variable_any::wait_for): Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Paul Thomas [Fri, 24 Jul 2026 14:05:46 +0000 (15:05 +0100)]
Fortran: Auto deallocate coarrays, allocated in team blocks [PR126205]
Gfortran was not compliant with F2018(11.1.5.2), which requires that
coarrays that are allocated within a team block are deallocated immediately
before END TEAM.
This the fourth variant of the patch; the main differences being whether
the code is located on resolve.cc, split between resolve.cc and
trans-stmt.cc or, as here, split between parse.cc, match.cc and st.cc.
The main attraction of the latter scheme is that coarray.cc and
resolve.cc do the main job of preparing the code for translation.
The team context is tracked using a vector of team namespaces, which is
pushed at CHANGE TEAM and popped at END TEAM. The allocate expressions
are stashed in a vector hash_map, keyed on the namespace. The allocate
expressions are stored while the ALLOCATE statments are being matched.
They are then recovered before end in parse_change_team and sent off
for automatic deallocation in st.cc(deallocate_allocated_coarrays.
The use of st.cc for functions generating chunks of code is a pointer
to something that I have been eyeing for a long time, which is to
extract all such functions from class.cc and resolve.cc so that they
can be refactored to use common chunks. This, however, is for another
time!
2026-07-24 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/126205
* gfortran.h: Add prototype for deallocate_allocated_coarrays.
hash_map team_allocated_coarrays, vector team_context_stack and
prototype for get_current_team_context.
* match.cc (gfc_match_allocate): Capture allocate expressions
of allocatable coarrays and stash in team_allocated_coarrays.
* parse.cc (parse_change_team): Push team context. When end is
seen, create the code to deallocate allocated coarrays in this
context, using deallocate_allocated_coarrays.
* st.cc (get_guarded_dealloc): Generate code to produce
IF (ALLOCATED (expr)) DEALLOCATE (expr).
(deallocate_allocated_coarrays): Modify the final array ref of
the allocate expressions and call get_guarded_dealloc.
gcc/testsuite/
PR fortran/126205
* gfortran.dg/coarray/team_allocated_coarrays.f90: New test.
Andrea Pinski [Fri, 31 Jul 2026 04:06:31 +0000 (21:06 -0700)]
match: Fix min/max patterns for `((signed)a) < 0` [PR126458]
In r16-4585-ga4e033fb51d566, I accidently used the wrong type
to form SIGNED_TYPE_MIN. This was ok most of the time except
if the two types differ only by one precision. When they diff
by one precision, we would incorrectly detect the wrong thing
and think it should be a min/max. This fixes the problem
by using the precision of the constant (0) rather then the final
type.
Pushed as obvious after a bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/126458
gcc/ChangeLog:
* match.pd (min/max detection): Fix precision of
the signed type min.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr126458-1.c: New test.
Signed-off-by: Andrea Pinski <andrew.pinski@oss.qualcomm.com>
Tomasz Kamiński [Fri, 31 Jul 2026 14:52:09 +0000 (16:52 +0200)]
libstdc++: Reject user-defined specializations for coroutine_handle.
The P0912R5, "Merge Coroutines TS into C++20 working draft" that
introduced them already included made specializing coroutine_handle
ill-formed, no diagnostic required.
This is QoI improvment, that produces diagnostic in such situation
by decaroting base template with [[_Clang::__no_specializations]].
libstdc++-v3/ChangeLog:
* include/std/coroutine: Ignore -Winvalid-specialization in file.
(std::coroutine_handle): Add clang::no_specializations attribute.
* testsuite/18_support/coroutines/specializations_neg.cc: New test.
Tomasz Kamiński [Wed, 29 Jul 2026 10:14:39 +0000 (12:14 +0200)]
libstdc++: Reject user-defined specializations for allocator traits.
Marks allocator_traits primary tempalte with [[_Clang::__no_specializations]]
attribute in C++23 or later.
This is QoI improvement for C++23 P2652R2, "Disallow User Specialization
of allocator_traits", that makes such cases ill-formed, but does not
require diagnostic.
Jonathan Wakely [Wed, 29 Jul 2026 18:04:37 +0000 (19:04 +0100)]
libstdc++: Make chrono::parse accept out-of-range values that aren't needed [PR126364]
When parsing a time with %R or %T we should ignore out of range hours
and minutes if the type being parsed doesn't need them, e.g. when
parsing a chrono::year_month_day from "2026-07-29 99:99:99" we do not
set failbit, and should continue parsing after the invalid hours and
minutes.
Because we were short circuiting as soon as we saw "99" (in either
field) we didn't parse to the end of the %R or %T field, and then could
set failbit if there were any subsequent characters or flags to parse.
The fix is to only short-circuit when setting failbit, and continue
parsing otherwise.
With this change, we no longer hit the 'break' when __read_unsigned(2)
returns -1 (e.g. because the input was non-numeric) unless we're
parsing a type that needs the %R or %T value. But that's OK, because
__read_unsigned sets failbit when it returns -1 and so the next
__read_chr or __read_unsigned will fail without extracting more
characters, and we'll break there instead. So there's no change in
observable behaviour for non-numeric inputs, only for out-of-range
numeric inputs.
libstdc++-v3/ChangeLog:
PR libstdc++/126364
* include/bits/chrono_io.h (_Parser::operator()) <R>: Only break
early when setting failbit.
* testsuite/std/time/parse/126364.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Muhammad Kamran [Thu, 30 Jul 2026 17:34:19 +0000 (18:34 +0100)]
libgcc: aarch64: Do not use .previous after build attributes
.aeabi_subsection selects the current AArch64 build-attribute
subsection, not the current ELF section. The following .previous
therefore does not return from the build-attribute subsection. In
aarch64-asm.h it instead switches back to .note.GNU-stack, which was the
previous ELF section after emitting the non-executable stack note.
Remove the .previous from the build-attribute marking path. Keep it in
the GNU_PROPERTY path, where it matches the explicit switch to
.note.gnu.property.
libgcc/ChangeLog:
* config/aarch64/aarch64-asm.h (FEATURE_1_AND_MARK): Do not emit
.previous after AArch64 build attributes.
c++: ICE on on systems without mmap support [PR124806]
On systems without mmap support, cc1plus can crash when finishing module
output after earlier errors prevented elf_out::begin from running. In
that case elf_out::end attempts to fill in the ELF header even though
hdr.buffer was never initialized.
gcc/cp/ChangeLog:
PR c++/124806
* module.cc (elf_out::began): New data member.
(elf_out::begin): Set it after successful initialization.
(elf_out::end): Do not finalize output that never began.
Jakub Jelinek [Fri, 31 Jul 2026 07:11:08 +0000 (09:11 +0200)]
match.pd: Fix 2 further problems with narrow shift count types [PR126504]
This is the same problem as in just fixed PR126476, we have patterns
which simplify something involving a shift to comparison of the shift
count against a compile time determined value.
Like in PR126476, if the shift count has a very narrow type like
unsigned _BitInt(4) in the example and we want to compare it against
something that doesn't fit into that type (like 20), then we miscompile
it as comparison against something else (like 4), even when actually
it just means that for no valid value the original will ever be true
(resp. false), depending on what comparison it is.
Now, why we have 4 very similar simplifiers is weird, sure, the first
two changed in the last PR were one left shift and one right shift
and in both cases powers of two, but here we have two others which
look very similar, especially the last one to the first one.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/126504
* match.pd ((CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)):
If cand isn't representable in TREE_TYPE (@1), simplify to
cmp == NE_EXPR.
(((1 << n) & M) != 0 -> n == log2 (M)): Don't simplify if
log2 doesn't fit into TREE_TYPE (@0).
Jakub Jelinek [Fri, 31 Jul 2026 07:07:26 +0000 (09:07 +0200)]
bitintlower: Fix up handle_plus_minus [PR126503]
The following testcase is miscompiled on aarch64 (but not on x86_64).
The difference is that x86_64/i686 define optabs that make it use IFN_UADDC
and IFN_USUBC, those are then used both in the loop and to perform the
most significant limb, so
# _6 = PHI <0(2), _7(3)>
# _9 = PHI <0(2), _10(3)>
_8 = VIEW_CONVERT_EXPR<unsigned long[5]>(a)[_6];
_11 = .USUBC (0, _8, _9);
_12 = IMAGPART_EXPR <_11>;
_13 = REALPART_EXPR <_11>;
VIEW_CONVERT_EXPR<unsigned long[7]>(<retval>)[_6] = _13;
_14 = _6 + 1;
_15 = VIEW_CONVERT_EXPR<unsigned long[5]>(a)[_14];
_16 = .USUBC (0, _15, _12);
_10 = IMAGPART_EXPR <_16>;
_17 = REALPART_EXPR <_16>;
VIEW_CONVERT_EXPR<unsigned long[7]>(<retval>)[_14] = _17;
_7 = _6 + 2;
if (_7 != 4)
in the loop and
_18 = MEM <unsigned long> [(_BitInt(257) *)&a + 32B];
_19 = (<unnamed-signed:1>) _18;
_20 = (<unnamed-unsigned:1>) _19;
_21 = (unsigned long) _20;
_22 = .USUBC (0, _21, _10);
_23 = IMAGPART_EXPR <_22>;
_24 = REALPART_EXPR <_22>;
_25 = (<unnamed-signed:1>) _24;
_26 = (unsigned long) _25;
MEM <unsigned long> [(unsigned _BitInt(400) *)&<retval> + 32B] = _26;
...
after the loop. Now, on targets which don't support the optab, we instead
use
# _6 = PHI <0(2), _7(3)>
# _9 = PHI <0(2), _10(3)>
_8 = VIEW_CONVERT_EXPR<unsigned long[6]>(a)[_6];
_11 = .SUB_OVERFLOW (0, _8);
_13 = REALPART_EXPR <_11>;
_14 = IMAGPART_EXPR <_11>;
_15 = .SUB_OVERFLOW (_13, _9);
_16 = IMAGPART_EXPR <_15>;
_12 = _14 + _16;
_17 = REALPART_EXPR <_15>;
VIEW_CONVERT_EXPR<unsigned long[8]>(<retval>)[_6] = _17;
_18 = _6 + 1;
_19 = VIEW_CONVERT_EXPR<unsigned long[6]>(a)[_18];
_20 = .SUB_OVERFLOW (0, _19);
_21 = REALPART_EXPR <_20>;
_22 = IMAGPART_EXPR <_20>;
_23 = .SUB_OVERFLOW (_21, _12);
_24 = IMAGPART_EXPR <_23>;
_10 = _22 + _24;
_25 = REALPART_EXPR <_23>;
VIEW_CONVERT_EXPR<unsigned long[8]>(<retval>)[_18] = _25;
_7 = _6 + 2;
if (_7 != 4)
in the loop (i.e. instead of one .USUBC 2 .SUB_OVERFLOW) and then
after the loop for the most significant limb
_26 = MEM <unsigned long> [(_BitInt(257) *)&a + 32B];
_27 = (<unnamed-signed:1>) _26;
_28 = (<unnamed-signed:1>) _10;
_29 = 0 - _27;
_30 = _29 - _28;
_31 = (unsigned long) _30;
MEM <unsigned long> [(unsigned _BitInt(400) *)&<retval> + 32B] = _31;
Now, the last thing is what is wrong. We need to do two subtractions
(or after folding one negation and one subtraction), and while in the
original operation signed overflow is indeed undefined, it just means
that the two operations together don't overflow, but one of them can.
In this testcase (in foo function) on aarch64, _26 is 1 (the most
significant bit of 257-bit negative value) and _10 is also 1 (borrow
from within the loop). When we perform this computation in signed 1-bit
precision, we have 0 - -1 (overflow) and -1 - -1 (another overflow).
The RTL emitted for this then results in miscompilation, but we really
shouldn't introduce UB into the IL for something that didn't have UB
originally.
So, the following patch forces use of unsigned type for these and casts
to the signed one only at the end.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/126503
* gimple-lower-bitint.cc (bitint_large_huge::handle_plus_minus): If
IFN_ADDC/IFN_SUBC can't be used and rhs1_type is not the limb type
and is signed, perform both additions or both subtractions in
unsigned type for the rhs1_type and cast to rhs1_type at the end.
Jakub Jelinek [Fri, 31 Jul 2026 07:05:50 +0000 (09:05 +0200)]
gimplify: Allow declarations in recalculate_side_effects [PR126497]
The following testcase ICEs, because we decide to fold a comparison
into just one of its operands, we call recalculate_side_effects on that
and ICE on the assertion that it isn't called on anything unexpected
(here PARM_DECL).
Already some time ago we had to add an exception for SSA_NAME for the
same reason.
The tcc_declaration case is slightly different, TREE_SIDE_EFFECTS is
sometimes present on those if they are TREE_THIS_VOLATILE, but it is
something the FE should take care of when creating those decls, not
a business of the gimplifier.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR middle-end/126497
* gimplify.cc (recalculate_side_effects): Return for
tcc_declaration.
* gcc.dg/bitint-141.c: New test.
Reviewed-by: Andrea Pinski <andrew.pinski@oss.qualcomm.com>
Jakub Jelinek [Fri, 31 Jul 2026 07:03:05 +0000 (09:03 +0200)]
match.pd: Fix (a & b) == (a ^ b) -> !(a | b) simplification [PR126490]
The following testcase is miscompiled.
We have 2 different simplifications
(a & b) ^ (a == b) -> !(a | b)
(a & b) == (a ^ b) -> !(a | b)
where both a and b are truth_valued_p. That doesn't mean they have
boolean type, it means that either they have integral type with one bit
precision (boolean, unsigned or signed) or they are result of comparisons
etc.
Now, because both a and b appear as operands of the same &, they necessarily
have the same or uselessly compatible type. For the first case, the a == b
comparison necessarily has to have the same type too and so type is the same
type as well.
For the second case that is not the case, e.g. in the problematic
testcase both a and b are unsigned _BitInt(1) while == has int type, but
it could very well be also that a and b are results of comparisons etc.
and have int type.
Now, the comment properly uses ! for the replacement, but the replacement
of the simplification actually uses bit_not, so ~. ~ is fine for 1-bit
precision, but not for wider ones.
The following patch differentiates between the case when a and b have
1-bit precision type, then it ensures ~ is done in that type and only
then it is converted to type, while for other cases it does ^ 1 instead.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/126490
* match.pd ((a & b) == (a ^ b) -> !(a | b)): If @0 has
integral one bit precision type, use (convert:type ...) around the
bit_not just in case the comparison has a different result type
from the type of its operands. Otherwise do that too but with
bit_not replaced with bit_xor with one of the appropriate type.
Jakub Jelinek [Fri, 31 Jul 2026 06:58:27 +0000 (08:58 +0200)]
c++: Don't cache calls which rethrow etc. [PR126508]
The first 3 testcase below are miscompiled, we happily cache
calls during constant evaluation which don't depend just on their
arguments, but also on the current exceptions (uncaught or caught).
If we decide to cache such functions and then try to evaluate them
with different uncaught/caught exceptions (or none), we can get wrong
results.
We already don't cache calls which allocate and don't free all heap
allocations, or free some heap allocations they haven't allocated,
or which call (right now any) metafunctions, or have exited through
exception, or aren't constant.
This patch just adds the rethrow/__builtin_uncaught_exceptions/
__builtin_current_exception calls to the set of non-cacheable operations
(to be precise, e.g. rethrow would be safe to cache if we can prove
that the current exception was always thrown from within that function,
ditto __builtin_current_exception, but it is hard to figure out).
The last testcase attempts to check if we don't need something similar
also for __builtin_eh_ptr_adjust_ref, but the call to foo for some reason
isn't cached and so I don't have a proof we need to handle it too.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR c++/126508
* constexpr.cc (cxx_eval_cxa_builtin_fn): Avoid caching
calls which rethrow or call __builtin_uncaught_exceptions
or __builtin_current_exception.
* g++.dg/cpp26/constexpr-eh20.C: New test.
* g++.dg/cpp26/constexpr-eh21.C: New test.
* g++.dg/cpp26/constexpr-eh22.C: New test.
* g++.dg/cpp26/constexpr-eh23.C: New test.
Jakub Jelinek [Fri, 31 Jul 2026 06:56:03 +0000 (08:56 +0200)]
range-op-float: Fix up inf handling in other reverse ops [PR126464]
On Thu, Jul 30, 2026 at 09:31:17AM +0200, Richard Biener wrote:
> > The following testcase is miscompiled since my r16-1108 change.
> > The problem is if we handle a reverse of a narrowing float to float cast
> > (in the example there are double -> float and long double -> double
> > cast) and the lhs range is [-inf, -inf] or [+inf, +inf] (note, regardless
> > of whether some NaNs are allowed or not, so not necessarily
> > lhs.known_isinf ()), then handling that range in the wider type also
> > as [-inf, -inf] or [+inf, +inf] is wrong, e.g. for the double -> float
> > conversion, [-inf, -0x0.ffffff8p+128] double range could map to just
> > that [-inf, -inf]. We have already float_widen_lhs_range function
> > but that just extends the range by +/-1ulp or 0.5ulp if the bounds
> > are finite. If the range isn't singleton (except for optional NaN),
> > then the minimum (or maximum) finite is already in the range, so this just
> > extends the case where they are singleton.
> > I don't know how to portably figure out that 0x0.ffffff8p+128 for
> > double -> float (especially when in float_widen_lhs_range we don't know
> > yet the wider type), so the patch just uses the +/-1ulp extension (i.e.
> > [-inf, min_finite] or [+inf, max_finite] case.
On a second thought, this actually isn't specific to just reverse of
narrowing float to float casts, it is a problem for any other reverse binary
ops too.
E.g. the following testcase is miscompiled at -O2 since r13-3926-gd4c2f1d376da
(but works with -O0). The lhs of the addition is [-inf, -inf], one of its
operand is [-1e304, -1e300] and we think the other operand has to be
[-inf, -inf]. That is obviously wrong, even much larger operands can result
in -inf, anything below -DBL_MAX + -1e300 where x + -1e300 doesn't round to
-DBL_MAX or higher but to -inf.
So, the following patch just widens lb of +inf and ub of -inf by 1ulp for
all callers (and thus doesn't need the also_inf argument.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/126464
* range-op-float.cc (float_widen_lhs_range): Remove also_inf
argument, replace its uses as if it was always true.
(operator_cast::op1_range): Don't pass third argument to
float_widen_lhs_range.
Jakub Jelinek [Fri, 31 Jul 2026 06:53:52 +0000 (08:53 +0200)]
match.pd: Fix up ((C << A) & D) != 0 simplification [PR126476]
This simplification for power of two @1 and @2 folds to false (resp.
to true for the == version) if @1 is larger than @2 (in unsigned
comparison), because @1 & @2 is known to be zero (i.e. for shift count 0)
and for shift count larger than that it will be zero too, either because
@1 << @0 is even larger, or if @0 is too large @1 << @0 overflows to zero.
This is the case of e.g. ((4 << x) & 2) != 0, which is always false.
Now, this PR is about a different problem, if @1 is smaller than @2, say
((1 << x) & 256) != 0, but x has a very narrow type, say unsigned _BitInt(3),
then the largest possible value of x is 7 and ((1 << 7) & 256) is
still 0, 1 << 7 is 128 and so still smaller than 256.
So, if c1 - c2 doesn't fit into the shift count type
(resp. for the other case c2 - c1), it will be also always false (resp.
true).
Trying to improve it and using range of x (aka @0) is not needed,
this simplification folds it into @0 != (c1 - c2) and so will be folded
later. Just the case where c1 - c2 overflows is problematic because
we've lost the details (unless we'd promote both operands or something).
Another possible way to do this would be build_int_cst and check for
the overflow flags, but I think this is shorter.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/126476
* match.pd (((C << A) & D) != 0 -> A == 0,
((C << A) & D) == 0 -> A != 0): Fold to false/true if
c1 - c2 resp. c2 - c1 doesn't fit into TREE_TYPE (@0).
Jakub Jelinek [Fri, 31 Jul 2026 06:47:54 +0000 (08:47 +0200)]
c++: Fix up check_return_expr for expansion stmts [PR126420]
The first testcase below is rejected because of a deduction failure,
the second testcase ICEs.
The first testcase is IFNDR according to
https://eel.is/c++draft/temp.res.general#6.2
- no valid specialization, ignoring static_assert-declarations that
fail, can be generated for the compound-statement of an
expansion-statement and there is no instantiation of it,
so rejecting it is fine and accepting it silently too.
But we ICE on the second testcase and that is a problem,
we set current_function_returns_value = 1 in check_return_expr
when the return value is dependent, and then don't instantiate it,
and as it is the only return from the function, when we try to expand
it we try to create dependent RESULT_DECL etc. for it and ICE.
The following patch just defers what check_return_expr normally
does in expansion statement bodies. For expansion statement not
within a template check_return_expr will be called again when
we try to instantiate the body (if at all), similarly for partial
specialization we don't try to find out if the expansion stmt
has constant number of iterations at that point and will invoke
check_return_expr again during the final instantiation.
2026-07-30 Jakub Jelinek <jakub@redhat.com>
PR c++/126420
PR c++/126423
* typeck.cc (check_return_expr): If in_expansion_stmt, goto
dependent before even setting current_function_returns_value.
* pt.cc (tsubst_stmt): Temporarily set in_expansion_stmt around
partial instantiation of expansion statement body.
* g++.dg/cpp26/expansion-stmt43.C: New test.
* g++.dg/cpp26/expansion-stmt44.C: New test.
Jakub Jelinek [Fri, 31 Jul 2026 06:37:18 +0000 (08:37 +0200)]
c++: Improve diagnostics for nullptr_t/info [PR126343]
We currently print std::nullptr_t or std::meta::info in diagnostics
when seeing a NULLPTR_TYPE or META_TYPE, when they aren't type aliases
(or when they are exactly those type aliases).
I think that isn't a bad idea, the aliases is what users usually
use for those. There are 2 problems with this though.
We print
decltype(nullptr)
and
decltype(nullptr) const volatile
exactly the same, both as std::nullptr_t, so the qualifiers are lost.
And, e.g. in case of a static assertion failure when people want to find
out why some reflections aren't equal we can print
note: the comparison reduces to '(^^std::meta::info == ^^std::meta:info)'
and the user then has no idea what is going on. Is it because one of
those is a type alias (which one), or because of cv-qual differences,
or both?
The following patch prints the aliases in normal %qT etc. printing,
if cv qualified prints qualifications after them (so e.g.
'std::nullptr_t const' or 'std::meta::info volatile').
And, when printing a reflection expression, it differentiates even
between the type alias case and non-alias, so for non-aliases prints
'decltype(nullptr)' or 'decltype(^^int) const volatile' etc.
2026-07-31 Jakub Jelinek <jakub@redhat.com>
PR c++/126343
* error.cc (dump_type) <case NULLPTR_TYPE>: Call
pp_c_type_qualifier_list.
(dump_type) <case META_TYPE>: Likewise.
(dump_expr) <case REFLECT_EXPR>: For REFLECT_EXPR on
non-typedef META_TYPE or NULLPTR_TYPE print
decltype(^^int) or decltype(nullptr).
Patrick Palka [Fri, 31 Jul 2026 01:18:38 +0000 (21:18 -0400)]
c++: resolvedness of resolve_nondeduced_context result [PR126406]
In r16-5967-gbae0ed69e1862a we removed the mark_used call from
resolve_nondeduced_context under the rationale that it should be
the caller's responsiblity to mark_used.
Removing the call however now means that resolve_nondeduced_context
could return a specialization whose type is not yet fully resolved
(i.e. has an uninstantiated noexcept or undeduced return type), and
callers that immediately inspect TREE_TYPE of the result (such as
standard_conversion and build_conditional_expr) now misbehave.
In light of such callers, this patch reverts r16-5967; it's not
necessary to fix PR119343 because after r16-6276 convert_to_void
now properly propagates an error_mark_node result from
resolve_nondeduced_context.
James K. Lowden [Thu, 30 Jul 2026 22:41:05 +0000 (18:41 -0400)]
cobol: New warning to allow REDEFINES anywhere in data item definition.
The new warning -Wredefines-first (an error by default) allows the
user to reduce the error to a warning, or suppress it. Suppression is
automatic with -dialect mf.
This is a wrong-code problem starting with the recent check_initializer
simplification (r17-1661). I thought the fix would be to bring some of
those dropped conditions back, but now I think the change just uncovered
a latent bug.
Since r17-1661, when initializing 'm' of type 'M[2]' we no longer call
build_aggr_init_full_exprs in check_initializer; instead, we go on to
store_init_value -> split_nonconstant_init. There we arrive with:
which so far seems OK. The type is an array so split_nonconstant_init_1
delegates to build_vec_init and returns true which, as the comment says,
should mean that "the whole of the value was initialized by the generated
statements". This is inaccurate: since try_const and do_static_init are
both true in build_vec_init, we have split out the constant initializer
(the {.a={.p=&empty.str}, .b={.p=&empty.str}} part) into DECL_INITIAL:
so we have both dynamic and static initializers. But since
split_nonconstant_init_1 returns bool, it's not ready to signal this case
to split_nonconstant_init, which then does:
and then overwrites DECL_INITIAL (dest). So we've lost a half of the
initializer and got wrong-code as the result.
This patch fixes it by not throwing away the DECL_INITIAL that
build_vec_init set for us. I suppose another approach would be
to somehow change split_nonconstant_init_1/ARRAY_TYPE to follow
the element pruning/add_stmt like the rest of the function, but that
seems more complicated.
PR c++/126335
gcc/cp/ChangeLog:
* typeck2.cc (split_nonconstant_init): Assert that DECL_INITIAL
is initially null. Don't clear DECL_INITIAL if build_vec_init
set it. Only clear TREE_READONLY if CODE has side-effects.
AArch64: Relax regexps in tests to let them pass with -fweb
The -fweb option changes the way that GCC allocates
registers. -fweb is not enabled by default, so we
have never previously noticed that some AArch64 tests
have unreasonably strict expectations about register
allocation. This patch relaxes those expectations.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/ffs.c: Relax test expectations.
* gcc.target/aarch64/frecpe_1.c: As above.
* gcc.target/aarch64/frecpe_2.c: As above.
Eric Botcazou [Thu, 30 Jul 2026 16:29:51 +0000 (18:29 +0200)]
Ada: Fix bogus error for 'Unrestricted_Access of overloaded subprogram
This plugs an old loophole in Analyze_Attribute for the handling of the
GNAT specific Unrestricted_Access attribute.
gcc/ada/
PR ada/126482
* sem_attr.adb (Analyze_Attribute): Treat Unrestricted_Access like
[Unchecked_]Access when it comes to the overloading of the prefix.
Jason Merrill [Wed, 29 Jul 2026 18:04:24 +0000 (14:04 -0400)]
c++: anonymous namespace in module partition [PR126209]
Here since r16-4484 we include all namespaces in the current purview in a
module, even if the namespace comes from another partition. That breaks for
an anonymous namespace, which is local to the TU (and added to the
definition of TU-local entity by P2996 Reflection); here _c ended up
representing the anonymous namespace from _a separately from the same one
passed along from _b, leading to an ICE trying to import them into the same
slot in _d. I tried just adding namespaces to is_tu_local_entity, but that
broke other things, so for 16.2 let's handle them here.
PR c++/126209
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_namespace_entities): Don't
force out anonymous namespaces.
gcc/testsuite/ChangeLog:
* g++.dg/modules/anon-5_a.C: New test.
* g++.dg/modules/anon-5_b.C: New test.
* g++.dg/modules/anon-5_c.C: New test.
* g++.dg/modules/anon-5_d.C: New test.
[frange] Store sub-ranges in a variable-length trailing array.
frange_storage held a fixed frange_pair m_pairs[MAX_PAIRS], so every
cached range reserved space for MAX_PAIRS sub-ranges even though the
large majority hold one. Mirror irange_storage: a trailing frange_pair
array that alloc () sizes to the range's actual num_pairs ().
Tested on ppc64le Linux. The usual regstrap, LAPACK, Fortran assembly
checks for no functional changes apply.
gcc/ChangeLog:
* value-range-storage.h (class frange_storage): Replace the fixed
m_pairs[MAX_PAIRS] with a variable-length trailing array and an
m_max_ranges capacity; declare size and the constructor.
* value-range-storage.cc (frange_storage::size): New.
(frange_storage::alloc): Allocate size (r) bytes.
(frange_storage::frange_storage): New; record m_max_ranges.
(frange_storage::fits_p): Check m_max_ranges.
Replace the single-interval union_ with a sub-range aware one.
Like the intersect rewrite, do this ahead of raising MAX_PAIRS. It is
still 1, so set_pairs collapses the result back to a single range. No
functional change.
Tested on ppc64le: regstrap, LAPACK, no changes on a corpus of Fortran
files.
gcc/ChangeLog:
* value-range.cc (frange::union_): Merge both operands' sub-ranges
via set_pairs instead of widening to the hull.
Richard Biener [Thu, 30 Jul 2026 12:27:59 +0000 (14:27 +0200)]
Deal with all vector defs in vectorizable_live_operation
After no longer requiring copies for existing vector defs we
have to deal with them. vectorizable_live_operation computes
an insert location based on them, so insert on region entry
if required.
* tree-vect-loop.cc (vectorizable_live_operation): Insert
on entry when the vector def is a default def or a constant.
Eikansh Gupta [Wed, 3 Jun 2026 10:16:29 +0000 (15:46 +0530)]
MATCH: Simplify zero/sign extension bit operations [PR122848]
Fold bitwise operations involving zero and sign extensions from the same
low-precision value. The AND case folds to the zero extension, and the
OR case folds to the sign extension.
Eikansh Gupta [Wed, 17 Jun 2026 04:28:16 +0000 (09:58 +0530)]
MATCH: fold signbit comparison and conditional negate to copysign [PR109843]
Fold (signbit (x) cmp1 0) cmp (signbit (y) cmp2 0) ? y : -y
to copysign (y, +-x). The result keeps the magnitude of Y and takes its
sign from X (or -X). Emitted as IFN_COPYSIGN when the target supports it.
PR tree-optimization/109843
gcc/ChangeLog:
* match.pd ((signbit (x) cmp 0) cmp (signbit (y) cmp 0) ? y : -y):
New simplification to copysign (y, +-x).
Bohan Lei [Thu, 23 Jul 2026 01:36:30 +0000 (09:36 +0800)]
RISC-V: Add intrinsic support for Zvabd
This commit adds intrinsic support for Zvabd. The original vwabad
machine description pattern would cause an ICE when emitting the
intrinsic because operand 0 and operand 2 are different pseudos,
and operand 2 has a constraint of "0", while operand 0 is marked as
read-write "+". The vwmacc-like pattern is now used to support correct
intrinsic generation and to better reflect the semantics. Pan Li's new
overlap constraint is used according to Robin's review comments of v2.
Prior to this change, the vectorizer estimated unrealistically high
costs for some scalar code: a cost was charged for each narrowing
conversion, even though those conversions are effectively free as
part of the associated stores. Consequently, the vectorizer could
decide to vectorize code that should not have been vectorized.
Scalar costs are inevitably somewhat overestimated in the case of
byte order reversals that should cause GCC to generate a 'rev'
instruction, because the vectorizer estimates costs independently of
the store-merging pass that discovers such reversals in scalar code.
When predicated tails are enabled for basic block SLP, the scalar cost
of reversals can be overestimated by so much that they are vectorized.
That will not happen after this change is applied.
The AArch64 backend now uses a new vectorizer function,
vect_is_truncating_store, to tell whether a given stmt truncates the
input of a store. This function is analogous to an existing
function, vect_is_extending_load, which tells whether a given stmt
extends the result of a load. The two functions are called in
roughly the same places, to help with the accuracy of costing scalar
and vector stmts.
A truncating assignment that has multiple uses should not be in an
SLP tree being costed, but it seems convenient to use single_imm_use
anyway (and it fits the expected/desired case we need to identify).
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_detect_scalar_stmt_subtype):
Call the new vect_is_truncating_store function and return 0 if
vect_is_truncating_store returns true.
(aarch64_sve_adjust_stmt_cost): Call vect_is_truncating_store
and assign 0 to stmt_cost if vect_is_truncating_store returns
true.
* tree-vectorizer.h (vect_is_truncating_store): New function
analogous to vect_is_extending_load.
Richard Biener [Wed, 29 Jul 2026 12:26:42 +0000 (14:26 +0200)]
Avoid SSA copies from vect_add_slp_permutation
In the past we needed a stmt_vec_info for all vector defs. Not
anymore.
* tree-vect-slp.cc (vect_add_slp_permutation): We no longer
need a copy when the extraction is readily available.
(vect_schedule_slp_node): Handle default defs or constants
in vector defs.
Fortran support for init,set,shutdown OpenACC directives
This patch adds parsing and libgomp runtime calls for these directives,
sharing the existing implementation with runtime API calls. It also
includes support for the device_type and device_num clauses in the
Fortran front-end.
For the device_type clause, the current implementation limits usage to
accepting only a single clause per directive. While the OpenACC
specification states that device_type should modify the device for
subsequent clauses inside other directives or constructs, supporting
this behavior requires a larger refactoring and may be addressed in
the future.
The set directive does not yet support the default_async clause, as
further discussion is needed to agree on its semantics and libgomp
implementation.
gcc/ChangeLog:
* builtin-types.def (BT_FN_VOID_INT_INT): New definition.
* omp-builtins.def (BUILT_IN_GOACC_INIT): New builtin for
init directive.
(BUILT_IN_GOACC_SHUTDOWN): New builtin for shutdown directive.
(BUILT_IN_GOACC_SET_DEVICE): New builtin for set directive.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_clauses): Dump OpenACC DEVICE_TYPE
and DEVICE_NUM clauses.
(show_omp_node): Handle INIT, SHUTDOWN, and SET directives.
(show_code_node): Likewise.
* frontend-passes.cc (gfc_code_walker): Walk device_num_expr for
INIT, SHUTDOWN, and SET directives.
* gfortran.h (enum gfc_statement): Add ST_OACC_INIT,
ST_OACC_SHUTDOWN, and ST_OACC_SET.
(gfc_omp_clauses): Add device_num_expr and oacc_device_type
fields.
(enum gfc_exec_op): Add EXEC_OACC_INIT, EXEC_OACC_SHUTDOWN, and
EXEC_OACC_SET.
* match.h (gfc_match_oacc_init): Declare.
(gfc_match_oacc_shutdown): Likewise.
(gfc_match_oacc_set): Likewise.
* openmp.cc (gfc_free_omp_clauses): Free device_num_expr.
(match_oacc_device_type_kind): New helper to parse OpenACC
device_type arguments.
(match_oacc_device_type): New helper to match the OpenACC
DEVICE_TYPE clause.
(enum omp_mask2): Add OMP_CLAUSE_DEVICE_NUM.
(gfc_match_omp_clauses): Match OpenACC DEVICE_TYPE and
DEVICE_NUM clauses.
(OACC_INIT_CLAUSES): New clause mask.
(OACC_SHUTDOWN_CLAUSES): Likewise.
(OACC_SET_CLAUSES): Likewise.
(gfc_match_oacc_init): New matcher.
(gfc_match_oacc_shutdown): Likewise.
(gfc_match_oacc_set): Likewise.
(resolve_omp_clauses): Resolve DEVICE_NUM; require at least one
of DEVICE_TYPE and DEVICE_NUM on SET.
(oacc_code_to_statement): Map new exec ops to statement codes.
(gfc_resolve_oacc_directive): Resolve INIT, SET, and SHUTDOWN
directives.
* parse.cc (decode_oacc_directive): Recognize init, set, and
shutdown directives.
(next_statement): Treat INIT, SET, and SHUTDOWN as executable
statements.
(gfc_ascii_statement): Add ASCII names for new directives.
(is_oacc): Recognize new exec ops.
* resolve.cc (gfc_resolve_blocks): Resolve INIT, SET, and
SHUTDOWN directives.
* st.cc (gfc_free_statement): Free clauses for new directives.
* trans-openmp.cc (gfc_trans_omp_clauses): Assert that
DEVICE_NUM and DEVICE_TYPE do not appear on construct clauses.
(gfc_trans_oacc_executable_directive): Lower INIT, SHUTDOWN, and
SET to GOACC builtins.
(gfc_trans_oacc_directive): Dispatch new directives.
* trans.cc (trans_code): Dispatch new directives.
* types.def (BT_FN_VOID_INT_INT): New definition.
libgomp/ChangeLog:
* libgomp.map (GOACC_2.5): Export GOACC_init, GOACC_shutdown, and
GOACC_set_device.
* libgomp_g.h (GOACC_init): Declare.
(GOACC_shutdown): Likewise.
(GOACC_set_device): Likewise.
* oacc-init.c (GOACC_DIRECTIVE_DEVICE_MASK): New macro for
supported device types.
(acc_init_1): Accept explicit device number argument.
(acc_shutdown_1): Shut down a single device or all devices of a
type.
(goacc_attach_host_thread_to_device): Whitespace fix.
(GOACC_init): New entry point for init directive.
(GOACC_shutdown): New entry point for shutdown directive.
(GOACC_set_device): New entry point for set directive.
(acc_init): Pass default device number to acc_init_1.
(acc_shutdown): Pass default device number to acc_shutdown_1.
(acc_set_device_num): Whitespace fix.
(goacc_restore_bind): Whitespace fix.
(goacc_lazy_initialize): Pass default device number to acc_init_1.
* testsuite/libgomp.oacc-fortran/init-1.f90: New test.
* testsuite/libgomp.oacc-fortran/lib-1-directives.f90: New test.
* testsuite/libgomp.oacc-fortran/lib-4-directives.f90: New test.
* testsuite/libgomp.oacc-fortran/lib-5-directives.f90: New test.
* testsuite/libgomp.oacc-fortran/lib-5-init.f90: New test.
* testsuite/libgomp.oacc-fortran/set-1.f90: New test.
* testsuite/libgomp.oacc-fortran/shutdown-1.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/goacc/acc-init-1.f90: New test.
* gfortran.dg/goacc/acc-init-clauses-1.f90: New test.
* gfortran.dg/goacc/acc-set-1.f90: New test.
* gfortran.dg/goacc/acc-set-clauses-1.f90: New test.
* gfortran.dg/goacc/acc-shutdown-1.f90: New test.
* gfortran.dg/goacc/acc-shutdown-clauses-1.f90: New test.
* gfortran.dg/goacc/uninit-if-clause.f95: Test INIT with
uninitialized IF clause.
* gfortran.dg/goacc/update-if_present-2.f90: Update expected
errors now that INIT and SHUTDOWN are recognized.
Signed-off-by: Sebastian Galindo <sebastian.galindo143@gmail.com> Co-authored-by: Thomas Schwinge <tschwinge@baylibre.com>
projects / thirdparty / gcc.git / log
