Roman Kagan [Thu, 2 Jan 2025 15:32:17 +0000 (16:32 +0100)]
libgcc: i386/linux-unwind.h: always rely on sys/ucontext.h
When gcc is built for x86_64-linux-musl target, stack unwinding from
within signal handler stops at the innermost signal frame. The reason
for this behaviro is that the signal trampoline is not accompanied with
appropiate CFI directives, and the fallback path in libgcc to recognize
it by the code sequence is only enabled for glibc except 2.0. The
latter is motivated by the lack of sys/ucontext.h in that glibc version.
Given that all relevant libc-s ship sys/ucontext.h for over a decade,
and that other arches aren't shy of unconditionally using it, follow
suit and remove the preprocessor condition, too.
libgcc/ChangeLog:
* config/i386/linux-unwind.h: Remove preprocessor
condition to enable fallback path for all libc-s.
The result is vsetvl zero, zero, e64, mf2, ta, ma. The previous vsetvl
set vl = 4 but here we wrongly set it to vl = 2. As all the following
vsetvls only ever change the ratio we never recover.
The issue is quite difficult to trigger because we can often
deduce the value of d at runtime. Then very check for the value of
d will be optimized away.
The last known bad commit is r15-3458-g5326306e7d9d36. With that commit
the output is wrong but -fno-schedule-insns makes it correct. From the
next commit on the issue is latent. I still added the PR's test as scan
and run check even if they don't trigger right now. Not sure if the
run test will ever fail but well. I verified that the
patch fixes the issue when applied on top of r15-3458-g5326306e7d9d36.
PR target/115703
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Use max_sew for calculating the
new LMUL.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr115703-run.c: New test.
* gcc.target/riscv/rvv/autovec/pr115703.c: New test.
Tobias Burnus [Tue, 18 Feb 2025 14:48:39 +0000 (15:48 +0100)]
gfortran.dg/gomp/metadirective-3.f90: xfail on offload_nvptx
Currently, 'target' with a nested metadirective creating a 'teams' will
fail with a bogus error ("‘target’ construct with nested ‘teams’ construct
contains directives outside of the ‘teams’ construct").
That's tracked at PR118694 - and, hence, expected.
However, the testcase metadirective-3.f90 triggers this when compiling for
'target offload_nvptx' (otherwise, the code is optimized away). Use xfail to
silence the error as it is known and there is a tracking PR.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/metadirective-3.f90: Add xfail when
compiling for offload_nvptx.
late-combine: Tighten register class check [PR108840]
gcc.target/aarch64/pr108840.c has failed since r15-268-g9dbff9c05520
(which means that I really ought to have looked at it earlier).
The test wants us to fold an SImode AND into all shifts that use it.
This is something that late-combine is supposed to do, but:
(1) the pre-RA pass chickened out because of a register pressure check
(2) the post-RA pass can't handle it, because the shift uses are in
QImode and the sets are in SImode
Both are things that would be good to fix. But (1) is particularly
silly. The constraints on the AND have "rk" for the destination
(so allowing the stack pointer) and "r" for the first source.
Including the stack pointer made the destination seem more permissive
than the source.
The intention was instead to check whether there are any
*allocatable* registers in the destination class that aren't
present in the source.
That's enough for all tests but the last one. The last one still
fails because combine merges the final shift with the move into
the hard return register, giving an arithmetic instruction with
a hard register destination. Pre-RA late-combine currently punts
on those, again due to register pressure concerns. That too is
something I'd like to relax, but not for GCC 15. In the interim,
the best thing seems to be to disable combine for the test.
gcc/
PR rtl-optimization/108840
* late-combine.cc (late_combine::check_register_pressure):
Take only allocatable registers into account when checking
the permissiveness of register classes.
gcc/testsuite/
PR rtl-optimization/108840
* gcc.target/aarch64/pr108840.c: Run at -O2 but disable combine.
Alex Coplan [Tue, 18 Feb 2025 10:48:50 +0000 (10:48 +0000)]
pair-fusion: Tweak wording in dump message [PR118320]
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675978.html
this tweaks the dump messasge added with the fix for PR118320 since it doesn't
just apply to load pairs.
gcc/ChangeLog:
PR rtl-optimization/118320
* pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Tweak wording in dump
message when punting on invalid use arrays.
Richard Biener [Mon, 17 Feb 2025 14:53:11 +0000 (15:53 +0100)]
tree-optimization/98845 - ICE with tail-merging and DCE/DSE disabled
The following shows that tail-merging will make dead SSA defs live
in paths where it wasn't before, possibly introducing UB or as
in this case, uses of abnormals that eventually fail coalescing
later. The fix is to register such defs for stmt comparison.
PR tree-optimization/98845
* tree-ssa-tail-merge.cc (stmt_local_def): Consider a
def with no uses not local.
* gcc.dg/pr98845.c: New testcase.
* gcc.dg/pr81192.c: Adjust.
Pan Li [Sat, 15 Feb 2025 06:33:35 +0000 (14:33 +0800)]
RISC-V: Fix ICE for target attributes has different xlen size
This patch would like to avoid the ICE when the target attribute
specific the xlen different to the cmd. Aka compile with rv64gc
but target attribute with rv32gcv_zbb. For example as blow:
1 │ long foo (long a, long b)
2 │ __attribute__((target("arch=rv32gcv_zbb")));
3 │
4 │ long foo (long a, long b)
5 │ {
6 │ return a + (b * 2);
7 │ }
when compile with rv64gc -O3, it will have ICE similar as below
Consider stage 4, we just report error for the above scenario when
detect the cmd xlen is different to the target attribute during the
target hook TARGET_OPTION_VALID_ATTRIBUTE_P implementation.
PR target/118540
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch):
Report error when cmd xlen is different with target attribute.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr118540-1.c: New test.
* gcc.target/riscv/rvv/base/pr118540-2.c: New test.
Alexandre Oliva [Tue, 18 Feb 2025 02:17:21 +0000 (23:17 -0300)]
[ifcombine] cope with signbit tests of extended values
A compare with zero may be taken as a sign bit test by
fold_truth_andor_for_ifcombine, but the operand may be extended from a
narrower field. If the operand was narrower, the bitsize will reflect
the narrowing conversion, but if it was wider, we'll only know whether
the field is sign- or zero-extended from unsignedp, but we won't know
whether it needed to be extended, because arg will have changed to the
narrower variable when we get to the point in which we can compute the
arg width. If it's sign-extended, we're testing the right bit, but if
it's zero-extended, there isn't any bit we can test.
Instead of punting and leaving the foldable compare to be figured out
by another pass, arrange for the sign bit resulting from the widening
zero-extension to be taken as zero, so that the modified compare will
yield the desired result.
While at that, avoid swapping the right-hand compare operands when
we've already determined that it was a signbit test: it no use to even
try.
for gcc/ChangeLog
PR tree-optimization/118805
* gimple-fold.cc (fold_truth_andor_for_combine): Detect and
cope with zero-extension in signbit tests. Reject swapping
right-compare operands if rsignbit.
Tobias Burnus [Mon, 17 Feb 2025 21:52:34 +0000 (22:52 +0100)]
OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant [PR115271]
On the extension side, it implements OpenMP 6.0's numeric values/ranges for
the adjust_args arguments, including 'omp_num_args'. And it adds parser
support for need_device_addr. It also implements the post-OpenMP-6.0
clarification of OpenMP spec Issue #4443 regarding type(c_ptr) with
dimension being invalid for need_device_ptr.
To be done: Adding full support for need_device_addr (optional, array
descriptor, ...).
On the invalid side, it removed a bogus c_ptr check that went through
all adjust_args without checking for need_device_ptr and the current scope.
And it finally also processes 'declare variant' in an INTERFACE block,
which is part of PR115271, but it does not handle .mod file yet - the
main issue tracked in that PR.
PR fortran/115271
gcc/fortran/ChangeLog:
* gfortran.h (gfc_omp_namelist): Change need_device_ptr to adj_args
union and add more flags.
* openmp.cc (gfc_match_omp_declare_variant,
gfc_resolve_omp_declare): For adjust_args, handle need_device_addr
and numeric values/ranges besides dummy argument names.
(resolve_omp_dispatch): Remove bogus a adjust_args check.
* trans-decl.cc (gfc_handle_omp_declare_variant): New.
(gfc_generate_module_vars, gfc_generate_function_code): Call it.
* trans-openmp.cc (gfc_trans_omp_declare_variant): Handle numeric
values/ranges besides dummy argument names.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/adjust-args-1.f90: Update dg-.* expectations.
* gfortran.dg/gomp/adjust-args-2.f90: Likewise.
* gfortran.dg/gomp/adjust-args-2a.f90: Likewise.
* gfortran.dg/gomp/adjust-args-3.f90: Likewise.
* gfortran.dg/gomp/adjust-args-4.f90: Remove array from c_ptr.
* gfortran.dg/gomp/adjust-args-5.f90: Likewise.
* gfortran.dg/gomp/adjust-args-11.f90: Likewise. Add check that
INTERFACE is now handled in subroutines and in modules.
* gfortran.dg/gomp/adjust-args-13.f90: New test.
* gfortran.dg/gomp/adjust-args-14.f90: New test.
* gfortran.dg/gomp/adjust-args-15.f90: New test.
* gfortran.dg/gomp/declare-variant-21.f90: New test.
Uros Bizjak [Mon, 17 Feb 2025 19:47:14 +0000 (20:47 +0100)]
i386: Simplify PARALLEL RTX scan in ix86_find_all_reg_use
UNSPEC and UNSPEC_VOLATILE never store. Remove unnecessary checks and
simplify RTX scan in ix86_find_all_reg_use to scan only for SET RTX
in the PARALLEL.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_find_all_reg_use):
Scan only for SET RTX in PARALLEL.
Jason Merrill [Sun, 16 Feb 2025 10:00:36 +0000 (11:00 +0100)]
c++: extended temps and statement-exprs [PR118763]
My last patch for 118856 broke the test for 118763 (which my testing didn't
catch, for some reason), because it effectively reverted Jakub's recent fix
(r15-7415) for that bug. It seems we need a new flag to indicate internal
temporaries.
In that patch Jakub wondered if other uses of CLEANUP_EH_ONLY would have the
same issue with jumps out of a statement-expr, and indeed it seems that
maybe_push_temp_cleanup and now set_up_extended_ref_temp have the same
problem. Since maybe_push_temp_cleanup already uses a flag, we can easily
stop setting CLEANUP_EH_ONLY there as well. Since set_up_extended_ref_temp
doesn't, working around this issue there will be more involved.
PR c++/118856
PR c++/118763
gcc/cp/ChangeLog:
* cp-tree.h (TARGET_EXPR_INTERNAL_P): New.
* call.cc (extend_temps_r): Check it instead of CLEANUP_EH_ONLY.
* tree.cc (get_internal_target_expr): Set it instead.
* typeck2.cc (maybe_push_temp_cleanup): Don't set CLEANUP_EH_ONLY.
Richard Biener [Mon, 17 Feb 2025 10:40:01 +0000 (11:40 +0100)]
tree-optimization/118895 - ICE during PRE
When we simplify a NARY during PHI translation we have to make sure
to not inject not available operands into it given that might violate
the valueization hook constraints and we'd pick up invalid
context-sensitive data in further simplification or as in this case
later ICE when we try to insert the expression.
PR tree-optimization/118895
* tree-ssa-sccvn.cc (vn_nary_build_or_lookup_1): Only allow
CSE if we can verify the result is available.
When making warnings trigger a failure in template substitution I
could not find any way to trigger the warning about builtin speculation
not being available on the given target.
Turns out I misread the code -- this warning happens when the
speculation_barrier pattern is not defined.
Here we add an effective target to represent
"__builtin_speculation_safe_value is available on this target" and use
that to adjust our test on SFINAE behaviour accordingly.
N.b. this means that we get extra testing -- not just that things work
on targets which support __builtin_speculation_safe_value, but also that
the behaviour works on targets which don't support it.
Tested with AArch64 native, AArch64 cross compiler, and RISC-V cross
compiler (just running the tests that I've changed).
Ok for trunk?
gcc/testsuite/ChangeLog:
PR target/117991
* g++.dg/template/builtin-speculation-overloads.def: SUCCESS
argument in SPECULATION_ASSERTS now uses a macro `true_def`
instead of the literal `true` for arguments which should work
with `__builtin_speculation_safe_value`.
* g++.dg/template/builtin-speculation-overloads1.C: Define
`true_def` macro on command line to compiler according to the
effective target representing that
`__builtin_speculation_safe_value` does something on this
target.
* g++.dg/template/builtin-speculation-overloads4.C: Likewise.
* lib/target-supports.exp
(check_effective_target_speculation_barrier_defined): New.
Signed-off-by: Matthew Malcomson <mmalcomson@nvidia.com>
Thomas Koenig [Sun, 16 Feb 2025 11:15:40 +0000 (12:15 +0100)]
Avoid shift wider than unsigned HOST_WIDE_INT on unsigned integer exponentiation.
this patch is a variation of Jakub's patch in the PR, which
avoids overflow on the mask used for exponentiation and
fixes unsigned HOST_WIDE_INT. I tried testing this on
a POWER machine, but --with-build-config=bootstrap-ubsan
fails bootstrap there.
gcc/fortran/ChangeLog:
PR fortran/118862
* trans-expr.cc (gfc_conv_cst_int_power): Use functions for
unsigned wide integer.
(gfc_conv_cst_uint_power): Avoid generating the mask if it would
overflow an unsigned HOST_WIDE_INT. Format fixes.
Haochen Jiang [Tue, 11 Feb 2025 03:29:43 +0000 (11:29 +0800)]
i386: Re-alias avx10.2 to 512 bit and deprecate -mno-avx10.2-[256,512]
As mentioned in avx10.1 option deprecate patch, based on the feedback
we got, we would like to re-alias avx10.x to 512 bit.
For -mno- options, also mentioned in the previous patch, it is confusing
what it is disabling when it comes to avx10. So we will only provide
-mno-avx10.x options from AVX10.2, disabling the whole AVX10.x.
gcc/ChangeLog:
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AVX10_1_UNSET): Adjust macro.
(OPTION_MASK_ISA2_AVX10_2_256_UNSET): Removed.
(OPTION_MASK_ISA2_AVX10_2_512_UNSET): Ditto.
(OPTION_MASK_ISA2_AVX10_2_UNSET): New.
(ix86_handle_option): Remove disable part for avx10.2-256.
Rename avx10.2-512 switch case to avx10.2 and adjust disable
part macro.
* common/config/i386/i386-isas.h: Adjust avx10.2 and
avx10.2-512.
* config/i386/driver-i386.cc
(host_detect_local_cpu): Do not append -mno-avx10.x-256
for -march=native.
* config/i386/i386-options.cc
(ix86_valid_target_attribute_inner_p): Adjust avx10.2 and
avx10.2-512.
* config/i386/i386.opt: Reject Negative for mavx10.2-256.
Alias mavx10.2-512 to mavx10.2. Reject Negative for
mavx10.2-512.
* doc/extend.texi: Adjust documentation.
* doc/sourcebuild.texi: Ditto.
Haochen Jiang [Tue, 11 Feb 2025 03:29:34 +0000 (11:29 +0800)]
i386: Deprecate -m[no-]avx10.1 and make -mno-avx10.1-512 to disable the whole AVX10.1
Based on the feedback we got, we would like to re-alias avx10.x to 512
bit in the future. This leaves the current avx10.1 alias to 256 bit
inconsistent. Since it has been there for GCC 14.1 and GCC 14.2,
we decide to deprecate avx10.1 alias. The current proposal is not
adding it back in the future, but it might change if necessary.
For -mno- options, it is confusing what it is disabling when it comes
to avx10. Since there is barely usage enabling AVX10 with 512 bit
then disabling it, we will only provide -mno-avx10.x options in the
future, disabling the whole AVX10.x. If someone really wants to disable
512 bit after enabling it, -mavx10.x-512 -mno-avx10.x -mavx10.x-256 is
the only way to do that since we also do not want to break the usual
expression on -m- options enabling everything mentioned.
However, for avx10.1, since we deprecated avx10.1, there is no reason
we should have -mno-avx10.1. Thus, we need to keep -mno-avx10.1-[256,512].
To avoid confusion, we will make -mno-avx10.1-512 to disable the
whole AVX10.1 set to match the future -mno-avx10.x.
Haochen Jiang [Mon, 10 Feb 2025 08:53:27 +0000 (16:53 +0800)]
i386: Do not check vector size conflict when AVX512 is not explicitly set [PR 118815]
When AVX512 is not explicitly set, we should not take EVEX512 bit into
consideration when checking vector size. It will solve the intrin header
file reporting warnings when compiling with -Wsystem-headers.
However, there is side effect on the usage for '-march=xxx -mavx10.1-256',
where xxx is with AVX512. It will not report warning on vector size for now.
Since it is a rare usage, we will take it.
gcc/ChangeLog:
PR target/118815
* config/i386/i386-options.cc (ix86_option_override_internal):
Do not check vector size conflict when AVX512 is not explicitly
set.
gcc/testsuite/ChangeLog:
PR target/118815
* gcc.target/i386/pr118815.c: New test.
Lulu Cheng [Wed, 12 Feb 2025 06:29:58 +0000 (14:29 +0800)]
LoongArch: Fix the issue of function jump out of range caused by crtbeginS.o [PR118844].
Due to the presence of R_LARCH_B26 in
/usr/lib/gcc/loongarch64-linux-gnu/14/crtbeginS.o, its addressing
range is [PC-128MiB, PC+128MiB-4]. This means that when the code
segment size exceeds 128MB, linking with lld will definitely fail
(ld will not fail because the order of the two is different).
Jakub Jelinek [Sun, 16 Feb 2025 18:19:20 +0000 (11:19 -0700)]
[PR target/118248] Avoid bogus alloca call in RISC-V backend
This is Jakub's patch and Ian's testcase for the slightly vexing fault building
the D runtime with an s390x-x-riscv cross compiler.
The core issue is we're allocating a vector to hold temporary registers
unconditionally, including cases where the vector isn't needed because the loop
isn't going to iterate.
In the cases where the vector isn't needed the length is computed with an
expression (x / y) - 1 where x / y will be zero. The alloca(-1) on the s390
platform triggers a fault. We haven't seen the fault with an x86 cross, but we
can certainly see the bogus value being passed to alloca with a debugger.
Jakub patch just conditionalizes the whole block in a sensible way. So it
looks larger than it really is. I thought it might be better to do a bit of
manual CSE on this code to make it even more obvious, but I think we're
ultimately OK here.
Ian provided the testcase, collapsed down into equivalent C code. Again, it
doesn't fault on an x86-x-riscv, but I can see the incorrect behavior with a
debugger.
And a shout-out to Stefan for providing a docker based reproducer, it really
helped track this down.
PR target/118248
gcc/
* config/riscv/riscv-string.cc (riscv_block_move_straight): Only
allocate REGS buffer if it will be needed.
gcc/testsuite
* gcc.target/riscv/pr118248.c: New test.
Georg-Johann Lay [Fri, 14 Feb 2025 19:22:58 +0000 (20:22 +0100)]
AVR: Don't asm output operations for unused result bytes.
When REG_UNUSED notes indicate that some result bytes are not
used by the following code, then there's no need to asm out them.
The patch uses such notes for the asm out of AND, IOR, XOR, PLUS, MINUS.
gcc/
* config/avr/avr.cc (avr_result_regno_unused_p): New static function.
(avr_out_bitop): Only output result bytes that are used.
(avr_out_plus_1): Same.
Georg-Johann Lay [Sat, 15 Feb 2025 13:35:24 +0000 (14:35 +0100)]
AVR: Diagnose unsupported built-ins in avr_resolve_overloaded_builtin.
This patch executes avr_builtin_supported_p at a later time and in
avr_resolve_overloaded_builtin. This allows for better diagnostics
and avoids lto1 hiccups when a built-in decl is NULL_TREE.
Thomas Koenig [Sun, 16 Feb 2025 11:24:13 +0000 (12:24 +0100)]
Remove double output of attr->save.
In the recent patch for dumping all attributes, there were
duplicates for attr->save, which is output via gfc_code2string
previously. This patch removes that double output.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_attr): Remove double output
of attr->save.
H.J. Lu [Tue, 14 Mar 2023 18:41:51 +0000 (11:41 -0700)]
x86: Properly find the maximum stack slot alignment
Don't assume that stack slots can only be accessed by stack or frame
registers. We first find all registers defined by stack or frame
registers. Then check memory accesses by such registers, including
stack and frame registers.
gcc/
PR target/109780
PR target/109093
* config/i386/i386.cc (ix86_update_stack_alignment): New.
(ix86_find_all_reg_use_1): Likewise.
(ix86_find_all_reg_use): Likewise.
(ix86_find_max_used_stack_alignment): Also check memory accesses
from registers defined by stack or frame registers.
Jakub Jelinek [Sat, 15 Feb 2025 23:45:21 +0000 (16:45 -0700)]
[PR tree-optimization/98028] Use relationship between operands to simplify SUB_OVERFLOW
So this is a fairly old regression, but with all the ranger work that's been
done, it's become easy to resolve.
The basic idea here is to use known relationships between two operands of a
SUB_OVERFLOW IFN to statically compute the overflow state and ultimately allow
turning the IFN into simple arithmetic (or for the tests in this BZ elide the
arithmetic entirely).
The regression example is when the two inputs are known equal. In that case
the subtraction will never overflow. But there's a few other cases we can
handle as well.
a == b -> never overflows
a > b -> never overflows when A and B are unsigned
a >= b -> never overflows when A and B are unsigned
a < b -> always overflows when A and B are unsigned
Bootstrapped and regression tested on x86, and regression tested on the usual
cross platforms.
This is Jakub's version of the vr-values.cc fix rather than Jeff's.
PR tree-optimization/98028
gcc/
* vr-values.cc (check_for_binary_op_overflow): Try to use a known
relationship betwen op0/op1 to statically determine overflow state.
gcc/testsuite
* gcc.dg/tree-ssa/pr98028.c: New test.
Harald Anlauf [Sat, 15 Feb 2025 19:36:15 +0000 (20:36 +0100)]
Fortran: passing of derived type to VALUE,OPTIONAL dummy argument [PR118080]
For scalar OPTIONAL dummy arguments with the VALUE attribute, gfortran
passes a hidden flag to denote presence or absence of the actual argument
for intrinsic types. Extend this treatment to derived type (user-defined
as well as from intrinsic module ISO_C_BINDING).
PR fortran/118080
gcc/fortran/ChangeLog:
* gfortran.texi: Adjust documentation.
* trans-decl.cc (create_function_arglist): Adjust to pass hidden
presence flag also for derived type dummies with VALUE,OPTIONAL
attribute.
* trans-expr.cc (gfc_conv_expr_present): Expect hidden presence
flag also for derived type dummies with VALUE,OPTIONAL attribute.
(conv_cond_temp): Adjust to allow derived types.
(conv_dummy_value): Extend to handle derived type dummies with
VALUE,OPTIONAL attribute.
(gfc_conv_procedure_call): Adjust for actual arguments passed to
derived type dummies with VALUE,OPTIONAL attribute.
* trans-types.cc (gfc_get_function_type): Adjust fndecl for
hidden presence flag.
Jerry DeLisle [Fri, 14 Feb 2025 04:19:56 +0000 (20:19 -0800)]
Fortran: gfortran allows type(C_ptr) in I/O list
Before this patch, gfortran was accepting invalid use of
type(c_ptr) in I/O statements. The fix affects several
existing test cases so no new test case needed.
Existing tests were modified to pass by either using the
transfer function to convert to an acceptable value or
using an assignment to a like type (non-I/O).
PR fortran/117430
gcc/fortran/ChangeLog:
* resolve.cc (resolve_transfer): Change gfc_notify_std to
gfc_error.
gcc/testsuite/ChangeLog:
* gfortran.dg/c_loc_test_17.f90: Use an assignment rather than
PRINT.
* gfortran.dg/c_ptr_tests_10.f03: Use a transfer function.
* gfortran.dg/c_ptr_tests_16.f90: Use an assignment.
* gfortran.dg/c_ptr_tests_9.f03: Use a transfer function.
* gfortran.dg/init_flag_17.f90: Likewise.
* gfortran.dg/pr32601_1.f03: Use an assignment.
Robin Dapp [Sat, 15 Feb 2025 16:21:34 +0000 (09:21 -0700)]
[PATCH] RISC-V: Fix some widen-complicate tests.
this patch adds two bridge patterns for combine in order to fix the
widen-complicate tests that regressed since GCC 14.
They key is to allow combination with a ephemeral binary-operation insn
that widens its first operand. This can subsequently be combined two
a double-widening insn. If the combination doesn't happen we fall back
to the original non-combined two insns. We have been doing the same
thing for multiply-add patterns for a while.
There are still remaining tests of a similar kind that fail. The issue
there is indeed that combine (now) lacks the capability to continue in
cases where there is no apparent local progress but two or three
seemingly no-progress combinations would help us get a better "global" result.
late_combine cannot rescue us here either because it only performs a
propagation if the source can be propagated into all its uses which is
not the case here. What we might need to do is create internal functions
for those widening operations and combine/simplify at gimple-level already.
I have done testing on rv64gcv_zvl512b but on an older local commit.
Curious what the CI has to say about it now.
Regards
Robin
gcc/ChangeLog:
* config/riscv/autovec-opt.md
(*single_widen_first_<any_widen_binop:optab><any_extend:su><mode>):
New combine "bridge" pattern.
Keith Packard [Sat, 15 Feb 2025 16:17:41 +0000 (09:17 -0700)]
[PATCH] rx: allow cmpstrnsi len to be zero
The SCMPU instruction doesn't change the C and Z flags when the
incoming length is zero, which means the insn will produce a
value based upon the existing flag values.
As a quick kludge, adjust these flags to ensure a zero result in this
case.
David Malcolm [Sat, 15 Feb 2025 13:18:19 +0000 (08:18 -0500)]
sarif-replay: handle the 'fixes' property (§3.27.30)
This adds support to sarif-replay to display fix-it hints
stored in GCC's SARIF output.
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Call
handle_fix_object if we see a single-element "fixes" array.
(sarif_replayer::handle_fix_object): New.
(sarif_replayer::handle_artifact_change_object): New.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-1.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-2.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-3.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Sat, 15 Feb 2025 13:15:58 +0000 (08:15 -0500)]
sarif-replay: handle relatedLocations without messages (§3.27.22)
Given the .sarif output from e.g.:
too-many-arguments.c: In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
the underlining of the stray argument (the "42") is captured in
'relatedLocations' (§3.27.22) but previously sarif-replay would not
display this:
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
With this patch sarif-replay handles the relatedLocations element as
a secondary location in libgdiagnostics, and correctly underlines
the "42":
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Treat any
relatedLocations without messages as secondary ranges within the
diagnostic. Doing so requires stashing the notes until after
the diagnostic has been finished, so that relatedLocations can be
walked in one pass.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/unlabelled-secondary-locations.sarif:
New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Sat, 15 Feb 2025 13:13:06 +0000 (08:13 -0500)]
sarif-replay: display annotations as labelled ranges (§3.28.6) [PR118881]
In our .sarif output from e.g.:
bad-binary-op.c: In function ‘test_4’:
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’})
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
the labelled ranges are captured in the 'annotations' property of the
'location' object (§3.28.6).
However sarif-replay emits just:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ^
missing the labelled ranges.
This patch adds support to sarif-replay for the 'annotations' property;
with this patch we emit:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
thus showing the labelled ranges.
Doing so requires adding a new entrypoint to libgdiagnostics:
diagnostic_physical_location_get_file
Given that we haven't yet released a stable version and that
sarif-replay is built together with libgdiagnostics I didn't
bother updating the ABI version.
gcc/ChangeLog:
PR sarif-replay/118881
* doc/libgdiagnostics/topics/physical-locations.rst: Add
diagnostic_physical_location_get_file.
* libgdiagnostics++.h (physical_location::get_file): New wrapper.
(diagnostic::add_location): Likewise.
* libgdiagnostics.cc (diagnostic_manager::get_file_by_name): New.
(diagnostic_physical_location::get_file): New.
(diagnostic_physical_location_get_file): New.
* libgdiagnostics.h (diagnostic_physical_location_get_file): New.
* libgdiagnostics.map (diagnostic_physical_location_get_file): New.
* libsarifreplay.cc (class annotation): New.
(add_any_annotations): New.
(sarif_replayer::handle_result_obj): Collect vectors of
annotations in the calls to handle_location_object and apply them
to "err" and to "note" as appropriate.
(sarif_replayer::handle_thread_flow_location_object): Pass nullptr
for annotations.
(sarif_replayer::handle_location_object): Handle §3.28.6
"annotations" property, using it to populate a new
"out_annotations" param.
gcc/testsuite/ChangeLog:
PR sarif-replay/118881
* sarif-replay.dg/2.1.0-valid/3.28.6-annotations-1.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Nathaniel Shead [Wed, 12 Feb 2025 08:15:22 +0000 (19:15 +1100)]
c++/modules: Don't treat template parameters as TU-local [PR118846]
There are two separate issues making various template parameters behave
as if they were TU-local.
Firstly, the TU-local detection code uses WILDCARD_TYPE_P to check for
types that are not yet concrete; for some reason UNBOUND_CLASS_TEMPLATE
is not on that list. I don't see any particular reason why it shouldn't
be, so this patch adds it; this may solve other latent issues as well.
Secondly, the TEMPLATE_DECL for a type with expressions involving
TEMPLATE_TEMPLATE_PARM_Ps is currently always constrained to internal
linkage, because the result does not have TREE_PUBLIC set. Rather than
messing with TREE_PUBLIC here, I think rather we just should ensure that
we only attempt to constrain visiblity of templates of type, variable,
or function decls.
PR c++/118846
gcc/cp/ChangeLog:
* cp-tree.h (WILDCARD_TYPE_P): Include UNBOUND_CLASS_TEMPLATE.
* decl2.cc (min_vis_expr_r): Don't assume a TEMPLATE_DECL will
be a function or variable.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr118846_a.C: New test.
* g++.dg/modules/pr118846_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jason Merrill [Sat, 15 Feb 2025 09:48:17 +0000 (10:48 +0100)]
c++: NRVO, constexpr, lambda [PR118053]
Here during constant evaluation we encounter a VAR_DECL with DECL_VALUE_EXPR
of the RESULT_DECL, where the latter has been adjusted for
pass-by-invisible-reference. We already had the code to deal with this, we
just need to use it in the non-capture case of DECL_VALUE_EXPR as well.
PR c++/118053
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Generalize
DECL_VALUE_EXPR invisiref handling.
Jonathan Wakely [Thu, 13 Feb 2025 00:26:27 +0000 (00:26 +0000)]
libstdc++: Simplify and comment std::jthread extension [PR100612]
Use a requires-clause on the partial specialization of the
__pmf_expects_stop_token variable template, which is used for the
extension that allows constructing std::jthread with a
pointer-to-member-function that accepts a std::stop_token argument.
Also add a comment referring to the related Bugzilla PR.
Jonathan Wakely [Wed, 12 Feb 2025 19:43:05 +0000 (19:43 +0000)]
libstdc++: Add conditional noexcept to remaining range access functions
Add conditional noexcept to the remaining range access functions that
were not changed in r15-5669-g8692cb10e82e72. This is now being proposed
for C++26 by P3623R0 (not published yet).
libstdc++-v3/ChangeLog:
* include/bits/range_access.h (rbegin, rend, crbegin, crend):
Add conditional noexcept, as per P3623R0.
* testsuite/24_iterators/headers/iterator/range_access.cc: Add
noexcept-specifier to rbegin, rend, crbegin and crend
declarations.
Jonathan Wakely [Wed, 12 Feb 2025 19:52:01 +0000 (19:52 +0000)]
libstdc++: Combine three tests into one
Instead of a test with { target c++11_only } and another with
c++14_only and another with c++17 we can have a single test that uses
{ target c++11 }. This avoids needing to make edits to three very
similar tests.
Also fix the signatures for std::cbegin and std::cend which had the
wrong expression in the trailing-return-type and were missing their
constexpr and conditional noexcept (which were always present even in
C++14). That was wrong in two files, but now only needs to be fixed in
one place!
Thomas Koenig [Sat, 15 Feb 2025 10:38:05 +0000 (11:38 +0100)]
Fix PR 118884, Lapack build failure.
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated symbol
was not set. This led to an apparent type of BT_UNKNOWN, and hence
an error. Fixed as obvoius and simple.
gcc/fortran/ChangeLog:
* frontend-passes.cc (check_externals_procedure): Copy
typespec from old to new symbol.
Thomas Schwinge [Mon, 19 Dec 2022 14:05:53 +0000 (15:05 +0100)]
nvptx: Tag 'gcc/config/nvptx/nvptx.cc:nvptx_record_needed_fndecl' as 'static'
As of Subversion r231013 (Git commit 00e5241831c1227615a45b7bcba29c393671cb3f)
"[PTX] Another libcall patch", only used 'nvptx_record_needed_fndecl' is
locally.
gcc/
* config/nvptx/nvptx.cc (nvptx_record_needed_fndecl): Tag as
'static'.
Andrew Pinski [Thu, 13 Feb 2025 22:10:06 +0000 (14:10 -0800)]
libstdc++: Improve list assumption after constructor [PR118865]
The code example here does:
```
if (begin == end) __builtin_unreachable();
std::list nl(begin, end);
for (auto it = nl.begin(); it != nl.end(); it++)
{
...
}
/* Remove the first element of the list. */
nl.erase(nl.begin());
```
And we get a warning because because we jump threaded the case were we
think the list was empty from the for loop BUT we populated it without
an empty array. So can help the compiler here by adding that after initializing
the list with non empty array, that the list will not be empty either.
This is able to remove the -Wfree-nonheap-object warning in the first reduced
testcase (with the fix for `begin == end` case added) in the PR 118865; the second
reduced testcase has been filed off as PR 118867.
Bootstrapped and tested on x86_64-linux-gnu.
libstdc++-v3/ChangeLog:
PR libstdc++/118865
* include/bits/stl_list.h (_M_initialize_dispatch): Add an
unreachable if the iterator was not empty that the list will
now be not empty.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Georg-Johann Lay [Fri, 14 Feb 2025 17:53:29 +0000 (18:53 +0100)]
AVR: target/118878 - Don't ICE on result from paradoxical reg's alloc.
After register allocation, paradoxical subregs may become something
like r20:SI += r22:SI which doesn't make much sense as assembly code.
Hence avr_out_plus_1() used to ICE on such code. However, paradoxical
subregs appear to be a common optimization device (instead of proper
mode demotion).
PR target/118878
gcc/
* config/avr/avr.cc (avr_out_plus_1): Don't ICE on result of
paradoxical reg's register allocation.
gcc/testsuite/
* gcc.target/avr/torture/pr118878.c: New test.
Thomas Schwinge [Tue, 11 Feb 2025 16:23:28 +0000 (17:23 +0100)]
GCN: Set 'UI_TARGET' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282, PR113331]
In commit 7f1989249e25af6fc0f124452efa24b3796b767a
"[gcn] Set 'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282]", we've copied
the 'UI_NONE' idea from nvptx to GCN.
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch to 'UI_TARGET', allocating a "fake" 'exception_section'.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues. And, this change also
happens to resolve the class of errors identified in GCC PR113331
"AMDGCN: Compilation failure due to duplicate .LEHB<n>/.LEHE<n> symbols".
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch (back) to 'UI_TARGET', implementing some basic support for
'exception_section': discard (via a PTX comment block) whatever GCC writes into
it.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues.
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
Thomas Schwinge [Wed, 12 Feb 2025 23:35:31 +0000 (00:35 +0100)]
nvptx: Sanity-check 'init_frag' state
The 'init_frag' machinery is used by 'nvptx_assemble_integer' (via
'TARGET_ASM_INTEGER'), 'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP'),
'nvptx_output_ascii' (via 'ASM_OUTPUT_ASCII'). But, it's not obvious that
these are called only when that machinery is active (and in a consistent
state), which it only is in 'nvptx_output_aligned_decl' (via
'ASM_OUTPUT_ALIGNED_DECL_COMMON', or 'ASM_OUTPUT_ALIGNED_DECL_LOCAL'), or in
'nvptx_assemble_undefined_decl' (via 'TARGET_ASM_ASSEMBLE_UNDEFINED_DECL'), or
within a region started by 'nvptx_assemble_decl_begin' (via
'nvptx_asm_declare_constant_name' (via 'TARGET_ASM_DECLARE_CONSTANT_NAME'), or
via 'nvptx_declare_object_name' (via 'ASM_DECLARE_OBJECT_NAME')) and ended by
'nvptx_assemble_decl_end' (via 'TARGET_ASM_DECL_END').
And indeed, in a GCC/nvptx offloading configuration, we then find that
'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP') is getting called in inconsistent
'init_frag' state, in 'gcc/varasm.cc', via 'assemble_zeros', from
'output_object_block', to "Move to the object's offset, padding with zeros".
Supposedly, this didn't cause any damage, but we now handle it explicitly.
(..., and the question remains whether such "padding" etc. shouldn't actually
be attempted for targets like nvptx.)
gcc/
* config/nvptx/nvptx.cc (init_frag): New 'bool active' member.
(output_init_frag, nvptx_assemble_value, nvptx_assemble_integer)
(nvptx_output_skip, nvptx_assemble_decl_begin)
(nvptx_assemble_decl_end): Sanity-check its state.
Richard Biener [Fri, 14 Feb 2025 13:48:41 +0000 (14:48 +0100)]
tree-optimization/118852 - wrong code with 502.gcc_r
502.gcc_r when built with -fprofile-generate exposes a SLP discovery
issue where an IV forced live due to early break is not properly
discovered if its latch def is part of a different IVs SSA cycle.
To mitigate this we have to make sure to create an SLP instance
for the original IV. Ideally we'd handle all vect_induction_def
the same but this is left for next stage1.
PR tree-optimization/118852
* tree-vect-slp.cc (vect_analyze_slp): For early-break
forced-live IVs make sure we create an appropriate
entry into the SLP graph.
Jason Merrill [Fri, 14 Feb 2025 09:53:01 +0000 (10:53 +0100)]
c++: extended temp cleanups [PR118856]
A later testcase in PR118856 highlights a preexisting problem with multiple
reference-extended temporaries in a single declaration; if initializing a
later one throws, the cleanup for the earlier one is not in scope yet.
Let's deal with this by keeping a dummy TARGET_EXPR to hold the EH cleanup
until all other initialization is complete. See the comment for various
other considered approaches.
We now avoid extending TARGET_EXPRs with CLEANUP_EH_ONLY set; all such
TARGET_EXPRs were already only internal iterator/flag variables that don't
want to be extended, as they are dead after initialization is complete even
if other temporaries are extended. But some other internal temporaries did
not have the flag set because they don't have TARGET_EXPR_CLEANUP; I
introduce a get_internal_target_expr function to set the flag rather than
directly set the flag (and add a comment) in such places. The places
changed to call get_internal_target_expr either already set the flag, or
have no cleanup at all.
PR c++/118856
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Retain a TARGET_EXPR for
cleanups if something later in initialization throws.
(extend_temps_r): Don't extend eliding or EH-only TARGET_EXPRs.
* cp-tree.h (get_internal_target_expr): Declare.
* tree.cc (get_internal_target_expr): New.
* decl.cc (cp_finish_decomp, expand_static_init): Use it.
* except.cc (build_throw): Likewise.
* init.cc (build_new_1, build_vec_init, build_delete): Likewise.
(build_vec_delete): Likewise.
* typeck2.cc (maybe_push_temp_cleanup): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/eh/ref-temp3.C: New test.
* g++.dg/eh/ref-temp4.C: New test.
Jonathan Wakely [Wed, 12 Feb 2025 18:33:46 +0000 (18:33 +0000)]
libstdc++: Fix more unqualified uses of make_pair
There are some unqualified calls to make_pair in Parallel Mode. Fix
these by just using a qualified call, because it's simpler and I don't
care about this code much.
libstdc++-v3/ChangeLog:
* include/parallel/algobase.h (__mismatch_switch): Qualify calls
to make_pair to avoid ADL.
Jonathan Wakely [Wed, 12 Feb 2025 18:30:21 +0000 (18:30 +0000)]
libstdc++: Fix use of make_pair that used ADL
_Rb_tree::_M_equal_range calls make_pair unqualified, which means it
uses ADL. As the new testcase shows, this can find something other than
std::make_pair. Rather than just changing it to use a qualified call,
remove the use of make_pair entirely. We don't need to deduce any types
here, we know exactly what type of std::pair we want to construct, so do
that explicitly.
libstdc++-v3/ChangeLog:
* include/bits/stl_tree.h (_Rb_tree::_M_equal_range): Replace
unqualified call to make_pair with explicit construction of
std::pair.
* testsuite/23_containers/set/operations/equal_range_adl.cc:
New test.
libstdc++: Conditionally use floating-point fetch_add builtins
- Some hardware has support for floating point atomic fetch_add (and
similar).
- There are existing compilers targetting this hardware that use
libstdc++ -- e.g. NVC++.
- Since the libstdc++ atomic<float>::fetch_add and similar is written
directly as a CAS loop these compilers can not emit optimal code when
seeing such constructs.
- I hope to use __atomic_fetch_add builtins on floating point types
directly in libstdc++ so these compilers can emit better code.
- Clang already handles some floating point types in the
__atomic_fetch_add family of builtins.
- In order to only use this when available, I originally thought I could
check against the resolved versions of the builtin in a manner
something like `__has_builtin(__atomic_fetch_add_<fp-suffix>)`.
I then realised that clang does not expose resolved versions of these
atomic builtins to the user.
From the clang discourse it was suggested we instead use SFINAE (which
clang already supports).
- I have recently pushed a patch for allowing the use of SFINAE on
builtins: r15-6042-g9ed094a817ecaf
Now that patch is committed, this patch does not change what happens
for GCC, while it uses the builtin for codegen with clang.
- I have previously sent a patchset upstream adding the ability to use
__atomic_fetch_add and similar on floating point types.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668754.html
Once that patchset is upstream (plus the automatic linking of
libatomic as Joseph pointed out in the email below
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665408.html )
then current GCC should start to use the builtin branch added in this
patch.
So *currently*, this patch allows external compilers (NVC++ in
particular) to generate better code, and similarly lets clang understand
the operation better since it maps to a known builtin.
I hope that by GCC 16 this patch would also allow GCC to understand the
operation better via mapping to a known builtin.
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (__atomic_fetch_addable): Define
new concept.
(__atomic_impl::__fetch_add_flt): Use new concept to make use of
__atomic_fetch_add when available.
(__atomic_fetch_subtractable, __fetch_sub_flt): Likewise.
(__atomic_add_fetchable, __add_fetch_flt): Likewise.
(__atomic_sub_fetchable, __sub_fetch_flt): Likewise.
Signed-off-by: Matthew Malcomson <mmalcomson@nvidia.com> Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
where the return type of value should be 'int &' since '(val)' is an
expression, not a name, and decltype(auto) performs the type deduction
using the decltype rules.
The problem is that we weren't propagating REF_PARENTHESIZED_P
correctly: the return value of finish_non_static_data_member in this
test was a REFERENCE_REF_P, so we didn't set the flag. We should
use force_paren_expr like below.
PR c++/116379
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) <COMPONENT_REF>: Use force_paren_expr to set
REF_PARENTHESIZED_P.
Jakub Jelinek [Fri, 14 Feb 2025 11:01:13 +0000 (12:01 +0100)]
tree: Fix up the DECL_VALUE_EXPR GC marking [PR118790]
The ggc_set_mark call in gt_value_expr_mark_2 is actually wrong, that
just marks the VAR_DECL itself, but doesn't mark the subtrees of it (type
etc.). So, I think we need to test gcc_marked_p for whether it is marked
or not, if not marked walk the DECL_VALUE_EXPR and then gt_ggc_mx mark
the VAR_DECL that was determined not marked and needs to be marked now.
One option would be to call gt_ggc_mx (t) right after the DECL_VALUE_EXPR
walking, but I'm a little bit worried that the subtree marking could mark
other VAR_DECLs (e.g. seen from DECL_SIZE or TREE_TYPE and the like) and
if they would be DECL_HAS_VALUE_EXPR_P we might not walk their
DECL_VALUE_EXPR anymore later.
So, the patch defers the gt_ggc_mx calls until we've walked all the
DECL_VALUE_EXPRs directly or indirectly connected to already marked
VAR_DECLs.
2025-02-14 Jakub Jelinek <jakub@redhat.com>
PR debug/118790
* tree.cc (struct gt_value_expr_mark_data): New type.
(gt_value_expr_mark_2): Don't call ggc_set_mark, instead check
ggc_marked_p. Treat data as gt_value_expr_mark_data * with pset
in it rather than address of the pset itself and push to be marked
VAR_DECLs into to_mark vec.
(gt_value_expr_mark_1): Change argument from hash_set<tree> *
to gt_value_expr_mark_data * and find pset in it.
(gt_value_expr_mark): Pass to traverse_noresize address of
gt_value_expr_mark_data object rather than hash_table<tree> and
for all entries in the to_mark vector after the traversal call
gt_ggc_mx.
Lulu Cheng [Tue, 10 Dec 2024 12:59:22 +0000 (20:59 +0800)]
LoongArch: Adjust the cost of ADDRESS_REG_REG.
After changing this cost from 1 to 3, the performance of spec2006
401 473 416 465 482 can be improved by about 2% on LA664.
Add option '-maddr-reg-reg-cost='.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Add
option '-maddr-reg-reg-cost='.
* config/loongarch/loongarch-def.cc
(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Initialize
addr_reg_reg_cost to 3.
* config/loongarch/loongarch-opts.cc
(loongarch_target_option_override): If '-maddr-reg-reg-cost='
is not used, set it to the initial value.
* config/loongarch/loongarch-tune.h
(struct loongarch_rtx_cost_data): Add the member
addr_reg_reg_cost and its assignment function to the structure
loongarch_rtx_cost_data.
* config/loongarch/loongarch.cc (loongarch_address_insns):
Use la_addr_reg_reg_cost to set the cost of ADDRESS_REG_REG.
* config/loongarch/loongarch.opt: Regenerate.
* config/loongarch/loongarch.opt.urls: Regenerate.
* doc/invoke.texi: Add description of '-maddr-reg-reg-cost='.
Lulu Cheng [Tue, 11 Feb 2025 12:36:17 +0000 (20:36 +0800)]
LoongArch: After setting the compilation options, update the predefined macros.
PR target/118828
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (loongarch_pragma_target_parse):
Update the predefined macros.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118828.c: New test.
* gcc.target/loongarch/pr118828-2.c: New test.
* gcc.target/loongarch/pr118828-3.c: New test.
* gcc.target/loongarch/pr118828-4.c: New test.
Lulu Cheng [Tue, 11 Feb 2025 12:05:13 +0000 (20:05 +0800)]
LoongArch: Split the function loongarch_cpu_cpp_builtins into two functions.
Split the implementation of the function loongarch_cpu_cpp_builtins into two parts:
1. Macro definitions that do not change (only considering 64-bit architecture)
2. Macro definitions that change with different compilation options.
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (builtin_undef): New macro.
(loongarch_cpu_cpp_builtins): Split to loongarch_update_cpp_builtins
and loongarch_define_unconditional_macros.
(loongarch_def_or_undef): New functions.
(loongarch_define_unconditional_macros): Likewise.
(loongarch_update_cpp_builtins): Likewise.
Richard Biener [Wed, 12 Feb 2025 13:18:06 +0000 (14:18 +0100)]
tree-optimization/90579 - avoid STLF fail by better optimizing
For the testcase in question which uses a fold-left vectorized
reduction of a reverse iterating loop we'd need two forwprop
invocations to first bypass the permute emitted for the reverse
iterating loop and then to decompose the vector load that only
feeds element extracts. The following moves the first transform
to a match.pd pattern and makes sure we fold the element extracts
when the vectorizer emits them so the single forwprop pass can
then pick up the vector load decomposition, avoiding the forwarding
fail that causes.
Moving simplify_bitfield_ref also makes forwprop remove the dead
VEC_PERM_EXPR via the simple-dce it uses - this was also
previously missing.
PR tree-optimization/90579
* tree-ssa-forwprop.cc (simplify_bitfield_ref): Move to
match.pd.
(pass_forwprop::execute): Adjust.
* match.pd (bit_field_ref (vec_perm ...)): New pattern
modeled after simplify_bitfield_ref.
* tree-vect-loop.cc (vect_expand_fold_left): Fold the
element extract stmt, combining it with the vector def.
Nathaniel Shead [Fri, 31 Jan 2025 12:01:15 +0000 (23:01 +1100)]
c++: Clear lambda scope for unattached member template lambdas
In r15-7202 we made lambdas between a template parameter scope and a
class/function/initializer be considered TU-local, in lieu of working
out how to mangle them to the succeeding declaration.
I neglected to clear any existing mangling on the template declaration
however; this means that such lambdas can occasionally get a lambda
scope, and will in general inherit the lambda scope of their
instantiation context (whatever that might be).
This patch ensures that the scope is cleared on the template declaration
as well.
gcc/cp/ChangeLog:
* lambda.cc (record_lambda_scope): Clear mangling scope for
otherwise unattached lambdas in class member templates.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval22.C: Add check that the primary
specialisation of the lambda is TU-local.
Nathaniel Shead [Fri, 31 Jan 2025 10:19:45 +0000 (21:19 +1100)]
c++: Fix mangling of lambas in static member template initializers [PR107741]
My fix for this issue in r15-7147 turns out to not be quite sufficient;
static member templates apparently go down a different code path and
need their own handling.
PR c++/107741
gcc/cp/ChangeLog:
* cp-tree.h (is_static_data_member_initialized_in_class):
Declare new predicate.
* decl2.cc (start_initialized_static_member): Push the
TEMPLATE_DECL when appropriate.
(is_static_data_member_initialized_in_class): New predicate.
(finish_initialized_static_member): Use it.
* lambda.cc (record_lambda_scope): Likewise.
* parser.cc (cp_parser_init_declarator): Start the member decl
early for static members so that lambda scope is set.
(cp_parser_template_declaration_after_parameters): Don't
register in-class initialized static members here.
Robin Dapp [Thu, 13 Feb 2025 23:33:24 +0000 (16:33 -0700)]
RISC-V: Avoid more unsplit insns in const expander [PR118832].
Hi,
in PR118832 we have another instance of the problem already noticed in
PR117878. We sometimes use e.g. expand_simple_binop for vector
operations like shift or and. While this is usually OK, it causes
problems when doing it late, e.g. during LRA.
In particular, we might rematerialize a const_vector during LRA, which
then leaves an insn laying around that cannot be split any more if it
requires a pseudo. Therefore we should only use the split variants
in expand_const_vector.
This patch fixed the issue in the PR and also pre-emptively rewrites two
other spots that might be prone to the same issue.
Regtested on rv64gcv_zvl512b. As the two other cases don't have a test
(so might not even trigger) I unconditionally enabled them for my testsuite
run.
Regards
Robin
PR target/118832
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Expand as
vlmax insn during lra.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr118832.c: New test.
Marek Polacek [Tue, 26 Nov 2024 19:37:21 +0000 (14:37 -0500)]
driver: -fhardened and -z lazy/-z norelro [PR117739]
As the manual states, using "-fhardened -fstack-protector" will produce
a warning because -fhardened wants to enable -fstack-protector-strong,
but it can't since it's been overriden by the weaker -fstack-protector.
-fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same
logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
produce the same warning. But we don't detect this combination, so
this patch fixes it. I also renamed a variable to better reflect its
purpose.
Also don't check warn_hardened in process_command, since it's always
true there.
Also tweak wording in the manual as Jon Wakely suggested on IRC.
PR driver/117739
gcc/ChangeLog:
* doc/invoke.texi: Tweak wording for -Whardened.
* gcc.cc (driver_handle_option): If -z lazy or -z norelro was
specified, don't enable linker hardening.
(process_command): Don't check warn_hardened.
gcc/testsuite/ChangeLog:
* c-c++-common/fhardened-16.c: New test.
* c-c++-common/fhardened-17.c: New test.
* c-c++-common/fhardened-18.c: New test.
* c-c++-common/fhardened-19.c: New test.
* c-c++-common/fhardened-20.c: New test.
* c-c++-common/fhardened-21.c: New test.
Jason Merrill [Wed, 12 Feb 2025 17:47:17 +0000 (18:47 +0100)]
c++: omp declare variant tweak
In r15-6707 I changed this function to use build_stub_object to more simply
produce the right type, but it occurs to me that forward_parm would be even
better, specifically for the diagnostic.
This changes nothing with respect to PR118791.
gcc/cp/ChangeLog:
* decl.cc (omp_declare_variant_finalize_one): Use forward_parm.
projects / thirdparty / gcc.git / log
