Christophe Lyon [Thu, 9 Oct 2025 14:09:26 +0000 (14:09 +0000)]
arm: [MVE] Fix operands order in vbicq_f [PR122223]
The operands of the floating-point version of vbicq were swapped, this
patch fixes this.
For this backport the testcase needs an adjustment: the code is less
optimized than with gcc-15, so we still generate the 0.0f constant and
a vbic instruction. We actually check that the 0.0f constant is in
the right vbic parameter.
Due to some quirks in crtstuff.c, attribute "retain" requires
some features that avr doesn't implement -- even though it
doesnt't even use crtstuff. This patch works around that.
PR target/122516
gcc/
* config/avr/elf.h (SUPPORTS_SHF_GNU_RETAIN): Define if
HAVE_GAS_SHF_GNU_RETAIN.
AVR: AVR-SD: Put a valid opcode prior to gs() table in .subsection 1.
On functional safety devices (AVR-SD), each executed instruction must
be followed by a valid opcode. This is because instruction fetch and
decode for the next instruction runs while the 2-stage pipeline is
executing the current instruction.
There is only one case where avr-gcc generates code interspersed with
data, which is when a switch/case table is generated for a function
with a "section" attribute and AVR_HAVE_JMP_CALL. In that case, the
table with the gs() code label addresses is put in .subsection 1 so
that it belongs to the section as specified by the "section" attribute.
gcc/
* config/avr/avr.cc (avr_output_addr_vec): Output
a valid opcode prior to the first gs() label provided:
- The code is compiled for an arch that has AVR-SD mcus, and
- the function has a "section" attribute, and
- the function has a gs() label addresses switch/case table.
AVR: target/122527 -- Don't use __load_N to load from __flash1.
This patch fixes a case where a 3 byte or 4 byte load from __flash1
uses __load_3/4 to read the value, which is wrong.
This only occured when the device has ELPM but not ELPMx (avr31).
PR target/122527
gcc/
* config/avr/avr.cc (avr_load_libgcc_p): Return false if
the address-space is not ADDR_SPACE_FLASH.
(avr_out_lpm_no_lpmx [addr=REG]): Handle sizes of 3 and 4 bytes.
Guo Jie [Wed, 29 Oct 2025 08:38:54 +0000 (16:38 +0800)]
LoongArch: Standard instruction template fnmam4 correction
The current implementation of the fnmam4 instruction template requires
the third source operand to be assigned the same hard register as the
target operand, but the constraint is not documented in the instruction
manual or standard template definitions. The current constraint will
generate additional data dependencies and extra instructions.
LIU Hao [Sat, 25 Oct 2025 09:19:34 +0000 (17:19 +0800)]
x86-64: Use `movsxd` to perform SI-to-DI extension in Intel syntax
Although there's no possibility of ambiguity, Intel manual says the mnemonic
for DWORD-to-QWORD sign-extension operation should be MOVSXD. Some assemblers
(GNU AS, NASM) also overload MOVSX, but some others don't accept MOVSX (LLVM,
MASM, YASM in NASM mode) and require MOVSXD.
This mnemonic was introduced in r0-34259-g123bf9e3f4056d in 2001, and has not
been updated ever since.
gcc/ChangeLog:
PR target/119079
* config/i386/i386.md: Use `movsxd` to perform SI-to-DI extension in Intel
syntax.
Harald Anlauf [Thu, 9 Oct 2025 16:43:22 +0000 (18:43 +0200)]
Fortran: fix "unstable" interfaces of external procedures [PR122206]
In the testcase repeated invocations of a function showed an apparently
unstable interface. This was caused by trying to guess an (inappropriate)
interface of the external procedure after processing of the procedure
arguments in gfc_conv_procedure_call. The mis-guessed interface showed up
in subsequent uses of the procedure symbol in gfc_conv_procedure_call. The
solution is to check for an existing interface of an external procedure
before trying to wildly guess based on just the actual arguments.
PR fortran/122206
gcc/fortran/ChangeLog:
* trans-types.cc (gfc_get_function_type): Do not clobber an
existing procedure interface.
Haochen Jiang [Tue, 21 Oct 2025 03:21:45 +0000 (11:21 +0800)]
i386: Correct cpu codename value for unknown model number
There are several changes for features enabled on cpus. r16-1666 disabled
CLDEMOTE on clients. r16-2224 removed Key locker since Panther Lake and
Clearwater forest. r16-4436 disabled PREFETCHI on Panther Lake.
The patches caused the current return guess value not aligned for
host_detect_local_cpu meeting the unknown model number. Correct the
logic according to the features enabled.
This patch will also backport to GCC14 and GCC15.
gcc/ChangeLog:
* config/i386/driver-i386.cc (host_detect_local_cpu): Correct
the logic for unknown model number cpu guess value.
The insn failed to match the pattern (aarch64-sve2.md):
;; Predicated binary operations with no reverse form, merging with zero.
;; At present we don't generate these patterns via a cond_* optab,
;; so there's no correctness requirement to handle merging with an
;; independent value.
(define_insn_and_rewrite "*cond_<sve_int_op><mode>_z"
[(set (match_operand:SVE_FULL_I 0 "register_operand")
(unspec:SVE_FULL_I
[(match_operand:<VPRED> 1 "register_operand")
(unspec:SVE_FULL_I
[(match_operand 5)
(unspec:SVE_FULL_I
[(match_operand:SVE_FULL_I 2 "register_operand")
(match_operand:SVE_FULL_I 3 "register_operand")]
SVE2_COND_INT_BINARY_NOREV)]
UNSPEC_PRED_X)
(match_operand:SVE_FULL_I 4 "aarch64_simd_imm_zero")]
UNSPEC_SEL))]
"TARGET_SVE2"
{@ [ cons: =0 , 1 , 2 , 3 ]
[ &w , Upl , 0 , w ] movprfx\t%0.<Vetype>, %1/z, %0.<Vetype>\;<sve_int_op>\t%0.<Vetype>, %1/m, %0.<Vetype>, %3.<Vetype>
[ &w , Upl , w , w ] movprfx\t%0.<Vetype>, %1/z, %2.<Vetype>\;<sve_int_op>\t%0.<Vetype>, %1/m, %0.<Vetype>, %3.<Vetype>
}
"&& !CONSTANT_P (operands[5])"
{
operands[5] = CONSTM1_RTX (<VPRED>mode);
}
[(set_attr "movprfx" "yes")]
)
because operands[3] and operands[4] were both expanded into the same register
operand containing a zero vector by define_expand "@cond_<sve_int_op><mode>".
This patch fixes the ICE by making a case distinction in
function_expander::use_cond_insn that uses add_fixed_operand if
fallback_arg == CONST0_RTX (mode), and otherwise add_input_operand (which was
previously the default and allowed the expansion of the zero-vector
fallback_arg to a register operand).
The patch was bootstrapped and tested on aarch64-linux-gnu, no regression.
OK for trunk?
Alex Coplan pointed out in the bugzilla ticket that this ICE goes back
to GCC 10. Shall we backport?
Signed-off-by: Jennifer Schmitz <jschmitz@nvidia.com>
Co-authored by: Richard Sandiford <rdsandiford@googlemail.com>
gcc/
PR target/121599
* config/aarch64/aarch64-sve-builtins.cc
(function_expander::use_cond_insn): Use add_fixed_operand if
fallback_arg == CONST0_RTX (mode).
gcc/testsuite/
PR target/121599
* gcc.target/aarch64/sve2/pr121599.c: New test.
David Malcolm [Wed, 19 Feb 2025 14:46:43 +0000 (09:46 -0500)]
input: give file_cache_slot its own copy of the file path [PR118919]
input.cc's file_cache was borrowing copies of the file name.
This could lead to use-after-free when writing out sarif output
from Fortran, which frees its filenames before the sarif output
is fully written out.
Fix by taking a copy in file_cache_slot.
gcc/ChangeLog:
PR other/118919
* input.cc (file_cache_slot::m_file_path): Make non-const.
(file_cache_slot::evict): Free m_file_path.
(file_cache_slot::create): Store a copy of file_path if non-null.
(file_cache_slot::~file_cache_slot): Free m_file_path.
David Malcolm [Wed, 19 Feb 2025 14:44:46 +0000 (09:44 -0500)]
analyzer: handle more IFN_UBSAN_* as no-ops [PR118300]
Previously the analyzer treated IFN_UBSAN_BOUNDS as a no-op, but
the other IFN_UBSAN_* were unrecognized and conservatively treated
as having arbitrary behavior.
Treat IFN_UBSAN_NULL and IFN_UBSAN_PTR also as no-ops, which should
make -fanalyzer behave better with -fsanitize=undefined.
gcc/analyzer/ChangeLog:
PR analyzer/118300
* kf.cc (class kf_ubsan_bounds): Replace this with...
(class kf_ubsan_noop): ...this.
(register_sanitizer_builtins): Use it to handle IFN_UBSAN_NULL,
IFN_UBSAN_BOUNDS, and IFN_UBSAN_PTR as nop-ops.
(register_known_functions): Drop handling of IFN_UBSAN_BOUNDS
here, as it's now handled by register_sanitizer_builtins above.
gcc/testsuite/ChangeLog:
PR analyzer/118300
* gcc.dg/analyzer/ubsan-pr118300.c: New test.
Eric Botcazou [Mon, 20 Oct 2025 09:21:21 +0000 (11:21 +0200)]
Ada: Fix spurious warning for renaming of component of VFA record
This is a regression present on the mainline and all active branches: the
compiler gives a spurious "is not referenced" warning for the renaming of
a component of a Volatile_Full_Access record.
gcc/ada/
PR ada/107536
* exp_ch2.adb (Expand_Renaming): Mark the entity as referenced.
gcc/testsuite/
* gnat.dg/renaming18.adb: New test.
Alex Coplan [Mon, 13 Oct 2025 13:41:09 +0000 (13:41 +0000)]
aarch64, testsuite: Add -fchecking to test options [PR121772]
I noticed while testing a backport of the PR121772 fix to GCC 13 that
the test wasn't triggering the ICE as expected with the unpatched
compiler.
This turned out to be because the ICE is a checking ICE, and we
configure by default with --enable-checking=release on the branches.
Additionally, I hadn't noticed when doing the backports to 15 and 14
since there we still ICE later on in emit_move_insn even if we don't
catch the invalid gimple with checking.
I'm not too sure why the 13 branch doesn't see the emit_move_insn ICE,
but it's somewhat irrelevant - the important thing is that adding
-fchecking to the options makes the test fail as expected with an
unpatched compiler (i.e. with a gimple checking failure), even on
release branches.
I considered applying this patch to just the release branches, but
figured that trunk will at some point itself become a release branch, so
it seems to make most sense just to apply it everywhere.
I've checked that the test still passes with this patch, and still fails
if I revert the PR121772 fix.
gcc/testsuite/ChangeLog:
PR tree-optimization/121772
* gcc.target/aarch64/torture/pr121772.c: Add -fchecking to
dg-options.
Jason Merrill [Tue, 14 Oct 2025 20:27:57 +0000 (23:27 +0300)]
c++: pointer to auto member function [PR120757]
Here r13-1210 correctly changed &A<int>::foo to not be considered
type-dependent, but tsubst_expr of the OFFSET_REF got confused trying to
tsubst a type that involved auto. Fixed by getting the type from the
member rather than tsubst.
PR c++/120757
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) [OFFSET_REF]: Don't tsubst the type.
Jakub Jelinek [Thu, 9 Oct 2025 16:06:39 +0000 (18:06 +0200)]
gimplify: Fix up side-effect handling in 2nd __builtin_c[lt]zg argument [PR122188]
The patch from yesterday made me think about side-effects in the second
argument of __builtin_c[lt]zg. When we change
__builtin_c[lt]zg (x, y)
when y is not INTEGER_CST into
x ? __builtin_c[lt]zg (x) : y
with evaluating x only once, we omit the side-effects in y unless x is not
0. That looks undesirable, we should evaluate side-effects in y
unconditionally.
2025-10-09 Jakub Jelinek <jakub@redhat.com>
PR c/122188
* c-gimplify.cc (c_gimplify_expr): Also gimplify the second operand
before the COND_EXPR and use in COND_EXPR result of gimplification.
Jakub Jelinek [Wed, 8 Oct 2025 07:58:41 +0000 (09:58 +0200)]
gimplify: Fix up __builtin_c[lt]zg gimplification [PR122188]
The following testcase ICEs during gimplification.
The problem is that save_expr sometimes doesn't create a SAVE_EXPR but
returns the original complex tree (COND_EXPR) and the code then uses that
tree in 2 different spots without unsharing. As this is done during
gimplification it wasn't unshared when whole body is unshared and because
gimplification is destructive, the first time we gimplify it we destruct it
and second time we try to gimplify it we ICE on it.
Now, we could replace one a use with unshare_expr (a), but because this
is a gimplification hook, I think easier than trying to create a save_expr
is just gimplify the argument, then we know it is is_gimple_val and so
something without side-effects and can safely use it twice. That argument
would be the first thing to gimplify after return GS_OK anyway, so it
doesn't change argument sequencing etc.
2025-10-08 Jakub Jelinek <jakub@redhat.com>
PR c/122188
* c-gimplify.cc (c_gimplify_expr): Gimplify CALL_EXPR_ARG (*expr_p, 0)
instead of calling save_expr on it.
Jakub Jelinek [Sat, 4 Oct 2025 15:06:16 +0000 (17:06 +0200)]
widening_mul: Reset flow sensitive info in maybe_optimize_guarding_check [PR122104]
In PR95852 I've added an optimization where next to just pattern
recognizing r = x * y; r / x != y or r = x * y; r / x == y
as .MUL_OVERFLOW or negation thereof it also recognizes
r = x * y; x && (r / x != y) or r = x * y; !x || (r / x == y)
by optimizing the guarding condition to always true/false.
The problem with that is that some value ranges recorded for
the SSA_NAMEs in the formerly conditional, now unconditional
basic block can be invalid.
This patch fixes it by calling reset_flow_sensitive_info_in_bb
if we optimize the guarding condition.
2025-10-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/122104
* tree-ssa-math-opts.cc (maybe_optimize_guarding_check): Call
reset_flow_sensitive_info_in_bb on bb when optimizing out the
guarding condition.
Jakub Jelinek [Thu, 18 Sep 2025 14:41:32 +0000 (16:41 +0200)]
openmp: Fix up ICE in lower_omp_regimplify_operands_p [PR121977]
The following testcase ICEs in functions called from
lower_omp_regimplify_operands_p, because maybe_lookup_decl returns
NULL for this (on the outer taskloop context) when regimplifying the
taskloop pre body. If it isn't found in current context, we should
look in outer ones.
2025-09-18 Jakub Jelinek <jakub@redhat.com>
PR c++/121977
* omp-low.cc (lower_omp_regimplify_operands_p): If maybe_lookup_decl
returns NULL, use maybe_lookup_decl_in_outer_ctx as fallback.
Jakub Jelinek [Wed, 10 Sep 2025 10:34:50 +0000 (12:34 +0200)]
bitint: Fix up lowering optimization of .*_OVERFLOW ifns [PR121828]
THe lowering of .{ADD,SUB,MUL}_OVERFLOW ifns is optimized, so that we don't
in the common cases uselessly don't create a large _Complex _BitInt
temporary with the first (real) part being the result and second (imag) part
just being a huge 0 or 1, although we still do that if it can't be done.
The optimizable_arith_overflow function checks when that is possible, like
whether the ifn result is used at most twice, once in REALPART_EXPR and once
in IMAGPART_EXPR in the same bb, etc. For IMAGPART_EXPR it then checks
if it has a single use which is a cast to some integral non-bitint type
(usually bool or int etc.). The final check is whether that cast stmt
appears after the REALPART_EXPR (the usual case), in that case it is
optimizable, otherwise it is not (because the lowering for optimizable
ifns of this kind is done at the location of the REALPART_EXPR and it
tweaks the IMAGPART_EXPR cast location at that point, so otherwise it
would be set after use.
Now, we also have an optimization for the REALPART_EXPR lhs being used
in a single stmt - store in the same bb, in that case we don't have to
store the real part result in a temporary but it can go directly into
memory.
Except that nothing checks for the IMAGPART_EXPR cast being before or after
the store in this case, so the following testcase ICEs because we have
a use before a def stmt.
In bar (the function handled right already before this patch) we have
_6 = .SUB_OVERFLOW (y_4(D), x_5(D));
_1 = REALPART_EXPR <_6>;
_2 = IMAGPART_EXPR <_6>;
a = _1;
_3 = (int) _2;
baz (_3);
before the lowering, so we can just store the limbs of the .SUB_OVERFLOW
into the limbs of a variable and while doing that compute the value we
eventually store into _3 instead of the former a = _1; stmt.
In foo we have
_5 = .SUB_OVERFLOW (y_3(D), x_4(D));
_1 = REALPART_EXPR <_5>;
_2 = IMAGPART_EXPR <_5>;
t_6 = (int) _2;
baz (t_6);
a = _1;
and we can't do that because the lowering would be at the a = _1; stmt
and would try to set t_6 to the overflow flag at that point. We don't
need to punt completely and mark _5 as _Complex _BitInt VAR_DECL though
in this case, all we need is not merge the a = _1; store with the
.SUB_OVERFLOW and REALPART_EXPR/IMAGPART_EXPR lowering. So, add _1
to m_names and lower the first 3 stmts at the _1 = REALPART_EXPR <_5>;
location, optimizable_arith_overflow returned non-zero and so the
cast after IMAGPART_EXPR was after it and then a = _1; will copy from
the temporary VAR_DECL to memory.
2025-09-10 Jakub Jelinek <jakub@redhat.com>
PR middle-end/121828
* gimple-lower-bitint.cc (gimple_lower_bitint): For REALPART_EXPR
consumed by store in the same bb and with REALPART_EXPR from
optimizable_arith_overflow, don't add REALPART_EXPR lhs to
the m_names bitmap only if the cast from IMAGPART_EXPR doesn't
appear in between the REALPART_EXPR and the store.
Jakub Jelinek [Mon, 8 Sep 2025 09:49:58 +0000 (11:49 +0200)]
libstdc++: Fix up <ext/pointer.h> [PR121827]
During the tests mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692482.html
(but dunno why I haven't noticed it back in August but only when testing
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/694527.html )
I've noticed two ext header problems.
One is that #include <ext/pointer.h> got broken with the r13-3037-g18f176d0b25591e28 change and since then is no longer
self-contained, as it includes iosfwd only if _GLIBCXX_HOSTED is defined
but doesn't actually include bits/c++config.h to make sure it is defined,
then includes a bunch of headers which do include bits/c++config.h and
finally uses in #if _GLIBCXX_HOSTED guarded code what is declared in iosfwd.
The other problem is that ext/cast.h is also not a self-contained header,
but that one has
/** @file ext/cast.h
* This is an internal header file, included by other library headers.
* Do not attempt to use it directly. @headername{ext/pointer.h}
*/
comment, so I think we just shouldn't include it in extc++.h and let
ext/pointer.h include it.
2025-09-08 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/121827
* include/precompiled/extc++.h: Don't include ext/cast.h which is an
internal header.
* include/ext/pointer.h: Include bits/c++config.h before
#if _GLIBCXX_HOSTED.
Jakub Jelinek [Fri, 5 Sep 2025 08:59:42 +0000 (10:59 +0200)]
testsuite, powerpc, v2: Fix vsx-vectorize-* after alignment peeling [PR118567]
On Tue, Jul 01, 2025 at 02:50:40PM -0500, Segher Boessenkool wrote:
> No tests become good tests without effort. And tests that are not good
> tests require constant maintenance!
Here are two patches, either just the first one or both can be used
and both were tested on powerpc64le-linux.
The second one adds further 8 tests, which are dg-do run which #include
the former tests, don't do any dump tests and just define the checking/main
for those.
2025-09-05 Jakub Jelinek <jakub@redhat.com>
PR testsuite/118567
* gcc.target/powerpc/vsx-vectorize-9.c: New test.
* gcc.target/powerpc/vsx-vectorize-10.c: New test.
* gcc.target/powerpc/vsx-vectorize-11.c: New test.
* gcc.target/powerpc/vsx-vectorize-12.c: New test.
* gcc.target/powerpc/vsx-vectorize-13.c: New test.
* gcc.target/powerpc/vsx-vectorize-14.c: New test.
* gcc.target/powerpc/vsx-vectorize-15.c: New test.
* gcc.target/powerpc/vsx-vectorize-16.c: New test.
Jakub Jelinek [Fri, 5 Sep 2025 08:54:53 +0000 (10:54 +0200)]
testsuite, powerpc, v2: Fix vsx-vectorize-* after alignment peeling [PR118567]
On Tue, Jul 01, 2025 at 02:50:40PM -0500, Segher Boessenkool wrote:
> No tests become good tests without effort. And tests that are not good
> tests require constant maintenance!
Here are two patches, either just the first one or both can be used
and both were tested on powerpc64le-linux.
The first one removes all the checking etc. stuff from the testcases,
as they are just dg-do compile, for the vectorize dump checks all we
care about are the vectorized loops they want to test.
2025-09-05 Jakub Jelinek <jakub@redhat.com>
PR testsuite/118567
* gcc.target/powerpc/vsx-vectorize-1.c: Remove includes, checking
part of main1 and main.
* gcc.target/powerpc/vsx-vectorize-2.c: Remove includes, replace
bar definition with declaration, remove main.
* gcc.target/powerpc/vsx-vectorize-3.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-4.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-5.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-6.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-7.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-8.c: Likewise.
Jakub Jelinek [Mon, 25 Aug 2025 22:28:10 +0000 (00:28 +0200)]
omp-expand: Initialize fd->loop.n2 if needed for the zero iter case [PR121453]
When expand_omp_for_init_counts is called from expand_omp_for_generic,
zero_iter1_bb is NULL and the code always creates a new bb in which it
clears fd->loop.n2 var (if it is a var), because it can dominate code
with lastprivate guards that use the var.
When called from other places, zero_iter1_bb is non-NULL and so we don't
insert the clearing (and can't, because the same bb is used also for the
non-zero iterations exit and in that case we need to preserve the iteration
count). Clearing is also not necessary when e.g. outermost collapsed
loop has constant non-zero number of iterations, in that case we initialize the
var to something already earlier. The following patch makes sure to clear
it if it hasn't been initialized yet before the first check for zero iterations.
2025-08-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/121453
* omp-expand.cc (expand_omp_for_init_counts): Clear fd->loop.n2
before first zero count check if zero_iter1_bb is non-NULL upon
entry and fd->loop.n2 has not been written yet.
Richard Biener [Tue, 5 Aug 2025 06:59:18 +0000 (08:59 +0200)]
tree-optimization/121370 - avoid UB in building a CHREC
When there is obvious UB involved in the process of re-associating
a series of IV increments to build up a CHREC, fail. This catches
a few degenerate cases where SCEV introduces UB with its inherent
re-associating of IV increments.
Richard Biener [Mon, 14 Jul 2025 12:09:28 +0000 (14:09 +0200)]
tree-optimization/121059 - fixup loop mask query
When we opportunistically mask an operand of a AND with an already
available loop mask we need to query that set with the correct number
of masks we expect.
PR tree-optimization/121059
* tree-vect-stmts.cc (vectorizable_operation): Query
scalar_cond_masked_set with the correct number of masks.
Richard Biener [Mon, 7 Jul 2025 07:56:50 +0000 (09:56 +0200)]
tree-optimization/120817 - bogus DSE of .MASK_STORE
DSE used ao_ref_init_from_ptr_and_size for .MASK_STORE but
alias-analysis will use the specified size to disambiguate
against smaller objects. For .MASK_STORE we instead have to
make the access size unspecified but we can still constrain
the access extent based on the maximum size possible.
PR tree-optimization/120817
* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Use
ao_ref_init_from_ptr_and_range with unknown size for
.MASK_STORE and .MASK_LEN_STORE.
Richard Biener [Mon, 7 Jul 2025 13:13:38 +0000 (15:13 +0200)]
tree-optimization/120358 - bogus PTA with structure access
When we compute the constraint for something like
MEM[(const struct QStringView &)&tok2 + 32] we go and compute
what (const struct QStringView &)&tok2 + 32 points to and then
add subvariables to its dereference that possibly fall in the
range of the access according to the original refs size. In
doing that we disregarded that the subvariable the starting
address points to might not be aligned to it and thus the
access might start at any point within that variable. The following
conservatively adjusts the pruning of adjacent sub-variables to
honor this.
PR tree-optimization/120358
* tree-ssa-structalias.cc (get_constraint_for_1): Adjust
pruning of sub-variables according to the imprecise
known start offset.
Richard Biener [Fri, 30 May 2025 12:11:47 +0000 (14:11 +0200)]
tree-optimization/120357 - ICE with early break vectorization
When doing early break vectorization of a loop with a conditional
reduction the epilog creation code is confused as to before which exit
to insert the conditional reduction induction IV update. The
following make sure this is done before the main IV exit.
PR tree-optimization/120357
* tree-vect-loop.cc (vect_create_epilog_for_reduction): Create
the conditional reduction induction IV increment before the
main IV exit.
* gcc.dg/vect/vect-early-break_136-pr120357.c: New testcase.
AVR: target/122187 - Don't clobber recog_data.operand[] in insn out.
avr.cc::avr_out_extr() and avr.cc::avr_out_extr_not()
changed xop for output, which spoiled the operand for
the next invokation, running into an assertion.
This patch makes a local copy of the operands.
PR target/122187
gcc/
* config/avr/avr.cc (avr_out_extr, avr_out_extr_not):
Make a local copy of the passed rtx[] operands.
gcc/testsuite/
* gcc.target/avr/torture/pr122187.c: New test.
Patrick Palka [Sat, 20 Sep 2025 14:45:22 +0000 (10:45 -0400)]
c++: find_template_parameters and NTTPs [PR121981]
Here the normal form of the two immediately-declared D<<placeholder>, V>
constraints is the same, so we rightfully share the normal form between
them. We first compute the normal form from the context of auto deduction
for W in which case the placeholder has level 2 where the set of
in-scope template parameters has depth 2 (a dummy level is added from
normalize_placeholder_type_constraints).
Naturally the atomic constraint only depends on the template parameter
V of depth 1 index 0. The depth 2 of current_template_parms however
means that find_template_parameters when it sees V within the atomic
constraint will recurse into its TREE_TYPE, an auto of level 2, and mark
the atomic constraint as also depending on the template parameter of
depth 2 index 0, which is clearly wrong. Later during constraint
checking for B we ICE within the satisfaction cache since we lack two
levels of template arguments supposedly needed by the cached atomic
constraint.
I think when find_template_parameters sees an NTTP, it doesn't need to
walk its TREE_TYPE because NTTP substitution is done obliviously with
respect to its type -- only the corresponding NTTP argument matters,
not other template arguments possibly used within its type. This is
most clearly true for (unconstrained) auto NTTPs as in the testcase, but
also true for other NTTPs. Doing so fixes the testcase because we no
longer record any depth 2 when walking V within the atomic constraint.
PR c++/121981
gcc/cp/ChangeLog:
* pt.cc (any_template_parm_r) <case TEMPLATE_TYPE_PARM>:
Don't walk TREE_TYPE.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-placeholder15.C: New test.
Steve Baird [Wed, 7 Feb 2024 21:52:58 +0000 (13:52 -0800)]
ada: Error in determining accumulator subtype for a reduction expression
There was an earlier bug in determining the accumulator subtype for a
reduction expression in the case where the reducer subprogram is overloaded.
The fix for that bug introduced a recently-discovered
regression. Redo accumulator subtype computation in order to address
this regression while preserving the benefits of the earlier fix.
gcc/ada/
PR ada/113536
* exp_attr.adb: Move computation of Accum_Typ entirely into the
function Build_Stat.
Alex Coplan [Tue, 9 Sep 2025 11:57:14 +0000 (12:57 +0100)]
match.pd: Add missing type check to reduc(ctor) pattern [PR121772]
In this PR we have a reduction of a vector constructor, where the
type of the constructor is int16x8_t and the elements are int16x4_t;
i.e. it is representing a concatenation of two vectors.
This triggers a match.pd pattern which looks like it was written to
handle reductions of vector constructors where the elements of the ctor
are scalars, not vectors. There is no type check to enforce this
property, which leads to the pattern replacing a reduction to scalar
with an int16x4_t vector in this case, which of course is a type error,
leading to an invalid GIMPLE ICE.
This patch adds a type check to the pattern, only going ahead with the
transformation if the element type of the ctor matches that of the
reduction.
gcc/ChangeLog:
PR tree-optimization/121772
* match.pd: Add type check to reduc(ctor) pattern.
gcc/testsuite/ChangeLog:
PR tree-optimization/121772
* gcc.target/aarch64/torture/pr121772.c: New test.
Patrick Palka [Wed, 24 Sep 2025 02:41:26 +0000 (22:41 -0400)]
libstdc++/testsuite: Unpoison 'u' on s390x in names.cc test
This is the s390 counterpart to r11-7364-gd0453cf5c68b6a, and fixes the
following names.cc failure caused by a use of a poisoned identifier.
If we look at the corresponding upstream header[1] it's clear that the
problematic identifier is 'u'.
In file included from /usr/include/linux/types.h:5,
from /usr/include/linux/sched/types.h:5,
from /usr/include/bits/sched.h:61,
from /usr/include/sched.h:43,
from /usr/include/pthread.h:22,
from /usr/include/c++/14/s390x-redhat-linux/bits/gthr-default.h:35,
from /usr/include/c++/14/s390x-redhat-linux/bits/gthr.h:157,
from /usr/include/c++/14/ext/atomicity.h:35,
from /usr/include/c++/14/bits/ios_base.h:39,
from /usr/include/c++/14/streambuf:43,
from /usr/include/c++/14/bits/streambuf_iterator.h:35,
from /usr/include/c++/14/iterator:66,
from /usr/include/c++/14/s390x-redhat-linux/bits/stdc++.h:54,
from /root/rpmbuild/BUILD/gcc-14.3.1-20250617/libstdc++-v3/testsuite/17_intro/names.cc:384:
/usr/include/asm/types.h:24: error: expected unqualified-id before '[' token
/usr/include/asm/types.h:24: error: expected ')' before '[' token
/root/rpmbuild/BUILD/gcc-14.3.1-20250617/libstdc++-v3/testsuite/17_intro/names.cc:101: note: to match this '('
compiler exited with status 1
FAIL: 17_intro/names.cc -std=gnu++98 (test for excess errors)
Excess errors:
/usr/include/asm/types.h:24: error: expected unqualified-id before '[' token
/usr/include/asm/types.h:24: error: expected ')' before '[' token
Patrick Palka [Wed, 17 Sep 2025 01:00:50 +0000 (21:00 -0400)]
libstdc++: Explicitly pass -Wsystem-headers in tests that need it
When running libstdc++ tests using an installed gcc (as opposed to an
in-tree gcc), we naturally use system stdlib headers instead of the
in-tree headers. But warnings from within system headers are suppressed
by default, so tests that check for such warnings spuriously fail in such
a setup. This patch makes us compile such tests with -Wsystem-headers so
that they consistently pass.
projects / thirdparty / gcc.git / log
