The range adaptor perfect forwarding simplification mechanism is currently
only enabled for trivially copyable bound arguments, to prevent undesirable
copies of complex objects. But "trivially copyable" is the wrong property
to check for here, since a move-only type with a trivial move constructor
is considered trivially copyable, and after P2492R2 we can't assume copy
constructibility of the bound arguments. This patch makes the mechanism
more specifically check for trivial copy constructibility instead so
that it's properly disabled for move-only bound arguments.
PR libstdc++/118413
libstdc++-v3/ChangeLog:
* include/std/ranges (views::__adaptor::_Partial): Adjust
constraints on the "simple" partial specializations to require
is_trivially_copy_constructible_v instead of
is_trivially_copyable_v.
* testsuite/std/ranges/adaptors/adjacent_transform/1.cc (test04):
Extend P2494R2 test.
* testsuite/std/ranges/adaptors/transform.cc (test09): Likewise.
Andrew Pinski [Tue, 28 Jan 2025 20:00:06 +0000 (12:00 -0800)]
split-path: Small fix for poor_ifcvt_pred (tsvc s258) [PR118505]
After r15-3436-gb2b20b277988ab, poor_ifcvt_pred returns false for
the case where the statement could trap but in this case trapping
instructions cannot be made unconditional so it is a poor ifcvt.
This fixes a small preformance regression with TSVC s258 at
`-O3 -ftrapping-math` on aarch64 where ifcvt would not happen
and we would still have a branch.
On a specific aarch64, we go from 0.145s down to 0.118s.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR tree-optimization/118505
* gimple-ssa-split-paths.cc (poor_ifcvt_pred): Return
true for trapping statements.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Tue, 28 Jan 2025 20:20:25 +0000 (12:20 -0800)]
split-path: CALL_EXPR can't show up in gimple_assign
While working on split path, I noticed that poor_ifcvt_candidate_code
would check for CALL_EXPR but that can't show up in gimple_assign
so this removes that check.
This could be a very very small compile time improvement.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* gimple-ssa-split-paths.cc (poor_ifcvt_candidate_code): Remove CALL_EXPR handling.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Martin Jambor [Wed, 29 Jan 2025 09:51:08 +0000 (10:51 +0100)]
tree-ssa-dce: Avoid creating invalid BBs with no outgoing edge (PR117892)
Zhendong Su and Michal Jireš found out that our gimple DSE pass can,
under fairly specific conditions, remove a noreturn call which then
leaves behind a "normal" BB with no successor edges which following
passes do not expect. This patch simply tells the pass to leave such
calls alone even when they otherwise appear to be dead.
Interestingly, our CFG verifier does not report this. I'll put on my
todo list to add a test for it in the next stage 1.
Pan Li [Thu, 23 Jan 2025 06:28:39 +0000 (14:28 +0800)]
RISC-V: Fix incorrect code gen for scalar signed SAT_TRUNC [PR117688]
This patch would like to fix the wroing code generation for the scalar
signed SAT_TRUNC. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure we have the correct value before ALU like add. The gen_lowpart
will generate something like lbu which has all zero for highest bits.
For example, when 0xff7f(-129 for HImode) trunc to QImode, we actually
want compare -129 to -128, but if there is no sign extend like lbu, we will
compare 0xff7f to 0xffffffffffffff80(assum Xmode is DImode). Thus, we have
to sign extend 0xff(Qmode) to 0xffffffffffffff7f(assume Xmode is DImode)
before compare in Xmode.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
PR target/117688
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_sstrunc): Leverage the helper
riscv_extend_to_xmode_reg with SIGN_EXTEND.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr117688.h: Add test helper macros.
* gcc.target/riscv/pr117688-trunc-run-1-s16-to-s8.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s32-to-s16.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s32-to-s8.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s64-to-s16.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s64-to-s32.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s64-to-s8.c: New test.
Pan Li [Thu, 23 Jan 2025 04:14:43 +0000 (12:14 +0800)]
RISC-V: Fix incorrect code gen for scalar signed SAT_SUB [PR117688]
This patch would like to fix the wroing code generation for the scalar
signed SAT_SUB. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure we have the correct value before ALU like sub. The gen_lowpart
will generate something like lbu which has all zero for highest bits.
For example, when 0xff(-1 for QImode) sub 0x1(1 for QImode), we actually
want to -1 - 1 = -2, but if there is no sign extend like lbu, we will get
0xff - 1 = 0xfe which is incorrect. Thus, we have to sign extend 0xff(Qmode)
to 0xffffffffffffffff(assume XImode is DImode) before sub in Xmode.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
PR target/117688
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_sssub): Leverage the helper
riscv_extend_to_xmode_reg with SIGN_EXTEND.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr117688.h: Add test helper macro.
* gcc.target/riscv/pr117688-sub-run-1-s16.c: New test.
* gcc.target/riscv/pr117688-sub-run-1-s32.c: New test.
* gcc.target/riscv/pr117688-sub-run-1-s64.c: New test.
* gcc.target/riscv/pr117688-sub-run-1-s8.c: New test.
Pan Li [Thu, 23 Jan 2025 04:08:17 +0000 (12:08 +0800)]
RISC-V: Fix incorrect code gen for scalar signed SAT_ADD [PR117688]
This patch would like to fix the wroing code generation for the scalar
signed SAT_ADD. The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode. Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure we have the correct value before ALU like add. The gen_lowpart
will generate something like lbu which has all zero for highest bits.
For example, when 0xff(-1 for QImode) plus 0x2(1 for QImode), we actually
want to -1 + 2 = 1, but if there is no sign extend like lbu, we will get
0xff + 2 = 0x101 which is incorrect. Thus, we have to sign extend 0xff(Qmode)
to 0xffffffffffffffff(assume XImode is DImode) before plus in Xmode.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
PR target/117688
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_ssadd): Leverage the helper
riscv_extend_to_xmode_reg with SIGN_EXTEND.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr117688-add-run-1-s16.c: New test.
* gcc.target/riscv/pr117688-add-run-1-s32.c: New test.
* gcc.target/riscv/pr117688-add-run-1-s64.c: New test.
* gcc.target/riscv/pr117688-add-run-1-s8.c: New test.
* gcc.target/riscv/pr117688.h: New test.
Pan Li [Mon, 27 Jan 2025 03:01:08 +0000 (11:01 +0800)]
RISC-V: Refactor SAT_* operand rtx extend to reg help func [NFC]
This patch would like to refactor the helper function of the SAT_*
scalar. The helper function will convert the define_pattern ops
to the xmode reg for the underlying code-gen. This patch add
new parameter for ZERO_EXTEND or SIGN_EXTEND if the input is const_int
or the mode is non-Xmode.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_gen_zero_extend_rtx): Rename from ...
(riscv_extend_to_xmode_reg): Rename to and add rtx_code for
zero/sign extend if non-Xmode.
(riscv_expand_usadd): Leverage the renamed function with ZERO_EXTEND.
(riscv_expand_ussub): Ditto.
Richard Biener [Wed, 29 Jan 2025 07:58:39 +0000 (08:58 +0100)]
middle-end/118684 - fix fallout of wrong stack local alignment fix
When we expand BIT_FIELD_REF <x_2(D), 8, 8> we can end up creating
a stack local, running into the fix. But get_object_alignment
will return 8 for any SSA_NAME because that's not an "object" we
handle. Deal with handled components on registers by singling out
SSA_NAME bases, using their type alignment instead of
get_object_alignment (I considered "robustifying" get_object_alignment,
but decided not to at this point).
This fixes an ICE on gcc.dg/pr41123.c on arm as reported by the CI.
PR middle-end/118684
* expr.cc (expand_expr_real_1): When creating a stack local
during expansion of a handled component, when the base is
a SSA_NAME use its type alignment and avoid calling
get_object_alignment.
Jakub Jelinek [Wed, 29 Jan 2025 08:32:04 +0000 (09:32 +0100)]
c++: Return false from __is_bounded_array for zero-sized arrays [PR118655]
This is basically Marek's PR114479 r14-9759 __is_array fix applied to
__is_bounded_array as well. Similarly to that trait, when not using
the builtin it returned false for zero sized arrays but when using
the builtin it returns true.
Harald Anlauf [Tue, 28 Jan 2025 20:21:40 +0000 (21:21 +0100)]
Fortran: fix passing of component ref to assumed-rank dummy [PR118683]
While the fix for pr117774 addressed the passing of an inquiry reference
to an assumed-rank dummy, it missed the similar case of passing a component
reference. The newer testcase gfortran.dg/pr81978.f90 uncovered this
latent issue with a UBSAN instrumented compiler.
PR fortran/118683
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): The bounds update for
passing to assumed-rank dummies shall also handle component
references besides inquiry references.
Jason Merrill [Tue, 28 Jan 2025 18:11:50 +0000 (13:11 -0500)]
c++: constexpr VEC_INIT_EXPR [PR118285]
cxx_eval_vec_init_1 was doing the wrong thing for an array of
self-referential class type; just evaluating the TARGET_EXPR initializer
creates a new object that refers to the TARGET_EXPR_SLOT, if we want it to
refer properly to the initialization target we need to provide it.
PR c++/118285
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_vec_init_1): Build INIT_EXPR for
initializing a class.
Jason Merrill [Mon, 27 Jan 2025 23:30:18 +0000 (18:30 -0500)]
c++: init-list opt and lvalue initializers [PR118673]
When fn returns {extension}, the ArrayRef in the initializer_list is
constructed to point to 'extension', the variable with static storage
duration. The optimization was copying extension's value into a temporary
array and constructing the ArrayRef to point to that temporary copy instead,
resulting in a dangling pointer. So suppress this optimization if the
element constructor takes a reference and the initializer is a non-mergeable
lvalue.
Richard Earnshaw [Tue, 28 Jan 2025 16:14:35 +0000 (16:14 +0000)]
arm: libgcc: make -spec=sync-*.specs compatible with LTO [PR118642]
The arm-none-eabi port provides some alternative implementations of
__sync_synchronize for different implementations of the architecture.
These can be selected using one of -specs=sync-{none,dmb,cp15dmb}.specs.
These specs fragments fail, however, when LTO is used because they
unconditionally add a --defsym=__sync_synchronize=<implementation> to
the linker arguments and that fails if libgcc is not added to the list
of libraries.
Fix this by only adding the defsym if libgcc will be passed to the
linker.
libgcc/
PR target/118642
* config/arm/sync-none.specs (link): Only add the defsym if
libgcc will be used.
* config/arm/sync-dmb.specs: Likewise.
* config/arm/sync-cp15dmb.specs: Likewise.
Richard Biener [Tue, 28 Jan 2025 15:20:30 +0000 (16:20 +0100)]
middle-end/118684 - wrongly aligned stack local during expansion
The following fixes a not properly aligned stack temporary created
during RTL expansion of a MEM_REF that we handle as a BIT_FIELD_REF
whose base was allocated to a register but which was originally
aligned to allow a larger load not trapping. While probably UB
in C the vectorizer creates aligned accesses that might overread
a (static) allocation because it is then known not to trap.
PR middle-end/118684
* expr.cc (expand_expr_real_1): When expanding a reference
based on a register and we end up needing a MEM make sure
that's aligned as the original reference required.
David Malcolm [Tue, 28 Jan 2025 15:36:53 +0000 (10:36 -0500)]
sarif output: escape braces in messages [PR118675]
gcc/ChangeLog:
PR other/118675
* diagnostic-format-sarif.cc: Define INCLUDE_STRING.
(escape_braces): New.
(set_string_property_escaping_braces): New.
(sarif_builder::make_message_object): Escape braces in the "text"
property.
(sarif_builder::make_message_object_for_diagram): Likewise, and
for the "markdown" property.
(sarif_builder::make_multiformat_message_string): Likewise for the
"text" property.
(xelftest::test_message_with_braces): New.
(selftest::diagnostic_format_sarif_cc_tests): Call it.
gcc/testsuite/ChangeLog:
PR other/118675
* gcc.dg/sarif-output/bad-binary-op.py: Update expected output for
escaping of braces in message text.
* gcc.dg/sarif-output/missing-semicolon.py: Likewise.
* gcc.dg/sarif-output/multiple-outputs.py: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
vect: Fix permutation counting in VLA-friendly path [PR117270]
vectorizable_slp_permutation_1 has two ways of generating the
permutations: one that looks for repeating patterns and one that
calculates the permutation index for every output element individually.
The former works for VLA and VLS whereas the latter only works for VLS.
There are two justifications for using the repeating code for VLS:
it gives more testing coverage, and it should reduce the analysis
overhead for common cases. This PR kind-of demonstrates both:
the VLS coverage was showing a bug in the analysis shortcut.
The bug seems to go back to g:ab7e60cec1a6, which added the
repeating_p path. It generated N copies of the permutation vector
in the repeating case, but didn't multiply the number of permutation
instructions for costing purposes by N. So we seem to have been
undercounting ncopies>1 permutations all this time...
The problem became more visible with g:8157f3f2d211, which extended
the repeating code to handle more cases.
In the patch, I think noutputs is in practice always a multiple
of unpack_factor, but it seemed more future-proof to handle the
general case.
gcc/
PR tree-optimization/117270
* tree-vect-slp.cc (vectorizable_slp_permutation_1): Make nperms
account for the number of times that each permutation will be used
during transformation.
Patrick Palka [Tue, 28 Jan 2025 14:27:02 +0000 (09:27 -0500)]
c++: friend vs inherited guide confusion [PR117855]
We recently started using the lang_decl_fn::context field to track
inheritedness of a deduction guide (for C++23 inherited CTAD). This
new overloading of the field accidentally made DECL_FRIEND_CONTEXT
return non-NULL for inherited guides, which breaks the below testcase
during overload resolution with an inherited guide.
This patch fixes this by refining DECL_FRIEND_CONTEXT appropriately.
Richard Earnshaw [Mon, 27 Jan 2025 13:52:05 +0000 (13:52 +0000)]
arm: libbacktrace: Check if the compiler supports __sync atomics
Older versions of the Arm architecture lack support for __sync
operations directly in hardware and require calls into appropriate
operating-system hooks. But such hooks obviously don't exist in a
freestanding environment.
Consquently, it is incorrect to assume during configure that such
functions will exist and we need a configure-time check to determine
whether or not these routines will work.
libbacktrace:
* configure.ac: Always check if the compiler supports __sync
operations.
* configure: Regenerated.
[PR118663][LRA]: Change secondary memory mode only if there are regs holding the changed mode
My recent patch for PR118067 changes the secondary memory mode if
all regs of the pseudo reg class are prohibited in the secondary mode.
But the patch does not check a special case when the
corresponding target hook returns this mode although there are no hard
regs of pseudo class holding value of the mode at all. This results
in given PR and this patch fixes it.
Richard Biener [Tue, 28 Jan 2025 11:28:14 +0000 (12:28 +0100)]
tree-optimization/117424 - invalid LIM of trapping ref
The following addresses a bug in tree_could_trap_p leading to
hoisting of a possibly trapping, because of out-of-bound, access.
We only ensured the first accessed byte is within a decl there,
the patch makes sure the whole base of the reference is within it.
This is pessimistic if a handled component would then subset to
a sub-object within the decl but upcasting of a decl to larger
types should be uncommon, questionable, and wrong without
-fno-strict-aliasing.
The testcase is a bit fragile, but I could not devise a (portable)
way to ensure an out-of-bound access to a decl would fault.
PR tree-optimization/117424
* tree-eh.cc (tree_could_trap_p): Verify the base is
fully contained within a decl.
Thomas Schwinge [Tue, 14 Jan 2025 11:58:08 +0000 (12:58 +0100)]
Clarify 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P' in 'gcc/tree-pretty-print.cc:dump_omp_clause'
In commit b7e20480630e3eeb9eed8b3941da3b3f0c22c969
"openmp: Relax handling of implicit map vs. existing device mappings",
'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P' was added next to 'OMP_CLAUSE_MAP_IMPLICIT'
with comment: "NOTE: this is different than OMP_CLAUSE_MAP_IMPLICIT". However,
dumping it as '[implicit]' doesn't exactly help for telling the two apart; make
that '[runtime_implicit]'. Also, prepend a space character, similar to how
we're doing with other such attributes.
Jakub Jelinek [Tue, 28 Jan 2025 09:14:05 +0000 (10:14 +0100)]
combine: Fix up make_extraction [PR118638]
The following testcase is miscompiled at -Os on x86_64-linux.
The problem is during make_compound_operation of
(ashiftrt:SI (ashift:SI (mult:SI (reg:SI 107 [ a_5 ])
(const_int 3 [0x3]))
(const_int 31 [0x1f]))
(const_int 31 [0x1f]))
where it incorrectly returns
(mult:SI (sign_extract:SI (reg:SI 107 [ a_5 ])
(const_int 2 [0x2])
(const_int 0 [0]))
(const_int 3 [0x3]))
which isn't obviously true, the former returns either 0 or -1 depending
on the least significant bit of the multiplication,
the latter returns either 0 or -3 depending on the second least significant
bit of the multiplication argument.
The bug has been introduced in PR96998 r11-4563, which added handling of x
* (2^N) similar to x << N. In the above case, pos is 0 and len is 1,
sign extracting a single least significant bit of the multiplication.
As 3 is not a power of 2, shift_amt is -1.
But IN_RANGE (-1, 1, 1 - 1) is still true, because the basic requirement of
IN_RANGE that LOWER is not greater than UPPER is violated.
The intention of using 1 as LOWER is to avoid matching multiplication by 1,
that really shouldn't appear in the IL. But to avoid violating IN_RANGE
requirement, we need to verify that len is at least 2.
I've added this len > 1 check to the inner if rather than outer because I
think for GCC 16 we should add a further optimization.
In the particular case of 1 least significant bit sign extraction from
multiplication by 3, we could actually say it is equivalent to
(sign_extract:SI (reg:SI 107 [ a_5 ])
(const_int 1 [0x2])
(const_int 0 [0]))
That is because 3 is an odd number and multiplication by 2 will yield the
least significant bit 0 (we are sign extracting just one) and so the
multiplication doesn't change anything on the outcome.
More generally, even for larger len, multiplication by C which is
(1 << X) + 1 where X is >= len should be optimizable just to extraction
of the multiplicand's least significant len bits.
2025-01-28 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/118638
* combine.cc (make_extraction): Only optimize (mult x 2^n) if len is
larger than 1.
Add tests for implied copy of variables in reduction clause.
The OpenACC reduction clause on compute construct implies a copy clause
for each reduction variable [1]. This patch adds tests to check if the
implied copy is being generated. The check covers various types and
operators as described in the specification.
[1] OpenACC 2.7 Specification section 2.5.13
gcc/testsuite/ChangeLog:
* c-c++-common/goacc/implied-copy-1.c: New test.
* c-c++-common/goacc/implied-copy-2.c: New test.
* g++.dg/goacc/implied-copy.C: New test.
* gcc.dg/goacc/implied-copy.c: New test.
* gfortran.dg/goacc/implied-copy-1.f90: New test.
* gfortran.dg/goacc/implied-copy-2.f90: New test.
Jakub Jelinek [Tue, 28 Jan 2025 08:31:27 +0000 (09:31 +0100)]
c: For array element type drop qualifiers but keep other properties of the element type [PR116357]
In the following testcase we error on the first case because it is
trying to construct an array from overaligned type, but if there are
qualifiers, we accept it silently (unlike in C++ which diagnoses all 3).
The problem is that grokdeclarator if TYPE_QUALS (element_type) is
non-zero just uses TYPE_MAIN_VARIANT; that loses not just the qualifiers
but also attributes, alignment etc.
The following patch uses c_build_qualified_type with TYPE_UNQUALIFIED instead,
which will be in the common case the same as TYPE_MAIN_VARIANT if the
checks are satisfied for it, but if not, will look up different unqualified
type or even create it if there is none.
2025-01-28 Jakub Jelinek <jakub@redhat.com>
PR c/116357
* c-decl.cc (grokdeclarator): Use c_build_qualified_type with
TYPE_UNQUALIFIED instead of TYPE_MAIN_VARIANT.
Jeff Law [Tue, 28 Jan 2025 04:25:39 +0000 (21:25 -0700)]
[PR target/114085] Fix H8 constraint issue which led to ICE
Nowhere near the top of my list, but a quick looksie Sunday led to an easy to
fix backend bug. It's not a regression, but given its the H8 backend I think
we've safely got a degree of freedom here.
The H8 has a constraint "U" which allowed both a subset of MEMs and REGs, so it
wasn't marked as a memory constraint. LRA doesn't really handle this well -- a
pseudo which didn't get a hard reg was replaced by its MEM. The stack slot
doesn't fit the limited addressing forms available and LRA didn't know it just
needed to reload the address into a reg.
Fixed by removing REG from the "U" constraint, turning "U" into a memory
constraint and adjusting a few patterns to allow "rU" instead of "U".
We don't really support C++ on the H8 and as a result libstdc++ won't build.
Interestingly enough that also keeps the C++ tests from working, even for a
compile-only test. So no testcase. Though I did check the reduced and
original test manually and ran it through my tester without any regressions.
PR target/114085
gcc/
* config/h8300/constraints.md (U): No longer accept REGs.
* config/h8300/logical.md (andqi3_2): Use "rU" rather than "U".
(andqi3_2_clobber_flags, andqi3_1, <code>qi3_1): Likewise.
* config/h8300/testcompare.md (tst_extzv_1_n): Likewise.
Jason Merrill [Mon, 27 Jan 2025 17:04:13 +0000 (12:04 -0500)]
c++: only strip conversions for deduction [PR118632]
In r15-2761 I changed unify to always strip IMPLICIT_CONV_EXPR from PARM.
In this testcase that leads to comparing nullptr to (int*)0, and failing
because they aren't the same. Let's only strip conversions if we're
actually going to try to deduce template arguments.
While we're at it, let's move this after the early exits.
And with this adjustment we can remove the workaround for mangle57.C.
PR c++/118632
gcc/cp/ChangeLog:
* pt.cc (unify): Only strip conversion if deducible_expression.
Vineet Gupta [Fri, 24 Jan 2025 21:56:28 +0000 (13:56 -0800)]
RISC-V: Add another test for FRM elimination bug [PR118646]
The issue is same as PR118103 and fixed by commit 55d288d4ff53
("RISC-V: Make FRM as global register [PR118103]").
Essentially FRM save/restore were getting eliminated because FRM reg
semantics were not being modelled correctly.
In this case it showed up as SPEC2017 527.cam4 runtime aborts in
glibc:round_away() due to non-canonical rounding mode showing up,
"leaking" earlier in the call chain because such rounding mode
save/restore was getting eliminated.
PR target/118646
gcc/testsuite/ChangeLog:
* gfortran.target/riscv/rvv/pr118646.f90 (New Test).
Simon Martin [Wed, 22 Jan 2025 15:19:47 +0000 (16:19 +0100)]
c++: Don't prune constant capture proxies only used in array dimensions [PR114292]
We currently ICE upon the following valid (under -Wno-vla) code
=== cut here ===
void f(int c) {
constexpr int r = 4;
[&](auto) { int t[r * c]; }(0);
}
=== cut here ===
When parsing the lambda body, and more specifically the multiplication,
we mark the lambda as LAMBDA_EXPR_CAPTURE_OPTIMIZED, which indicates to
prune_lambda_captures that it might be possible to optimize out some
captures.
The problem is that prune_lambda_captures then misses the use of the r
capture (because neither walk_tree_1 nor cp_walk_subtrees walks the
dimensions of array types - here "r * c"), hence believes the capture
can be pruned... and we trip on an assert when instantiating the lambda.
This patch changes cp_walk_subtrees so that (1) when walking a
DECL_EXPR, it also walks the DECL's type, and (2) when walking an
INTEGER_TYPE, it also walks its TYPE_{MIN,MAX}_VALUE. Note that #2 makes
a <case INTEGER_TYPE> redundant in for_each_template_parm_r, and removes
it.
PR c++/114292
gcc/cp/ChangeLog:
* pt.cc (for_each_template_parm_r) <INTEGER_TYPE>: Remove case
now handled by cp_walk_subtrees.
* tree.cc (cp_walk_subtrees): Walk the type of DECL_EXPR
declarations, as well as the TYPE_{MIN,MAX}_VALUE of
INTEGER_TYPEs.
Robin Dapp [Thu, 17 Oct 2024 16:39:16 +0000 (18:39 +0200)]
RISC-V: Disable two-source permutes for now [PR117173].
After testing on the BPI (4.2% improvement for x264 input 1, 4.4% for
input 2) and the discussion in PR117173 I figured it's best to disable
the two-source permutes by default for now.
The patch adds a parameter "riscv-two-source-permutes" which restores
the old behavior.
PR target/117173
gcc/ChangeLog:
* config/riscv/riscv-v.cc (shuffle_generic_patterns): Only
support single-source permutes by default.
* config/riscv/riscv.opt: New param "riscv-two-source-permutes".
gcc/testsuite/ChangeLog:
* gcc.dg/fold-perm-2.c: Run with two-source permutes.
* gcc.dg/pr54346.c: Ditto.
Harald Anlauf [Sun, 26 Jan 2025 21:56:57 +0000 (22:56 +0100)]
Fortran: fix bogus diagnostics on renamed interface import [PR110993]
PR fortran/110993
gcc/fortran/ChangeLog:
* frontend-passes.cc (check_externals_procedure): Do not compare
interfaces of a non-bind(C) procedure against a bind(C) global one.
(check_against_globals): Use local name from rename-on-use in the
search for interfaces.
c++: Use mapped reads and writes when munmap and msync are available
Module support is broken when MAPPED_READING and MAPPED_WRITING
are defined to 0. This causes internal compiler errors in the
permissive-error-1.C and permissive-error-2.C tests.
HP-UX 11.11 doesn't define _POSIX_MAPPED_FILES but it does have
munmap and msync. Testing indicates support is sufficient for
c++ modules, so use checks for these functions instead of
_POSIX_MAPPED_FILES check.
2025-01-27 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
PR c++/116524
* configure.ac: Check for munmap and msync.
* configure: Regenerate.
* config.in: Regenerate.
gcc/cp/ChangeLog:
* module.cc: Test HAVE_MUNMAP and HAVE_MSYNC instead of
_POSIX_MAPPED_FILES > 0.
Jakub Jelinek [Mon, 27 Jan 2025 16:17:17 +0000 (17:17 +0100)]
c++: Handle CWG2867 even in namespace scope structured bindings in header modules [PR115769]
The following patch implements the module streaming of the new
STATIC_INIT_DECOMP_BASE_P and STATIC_INIT_DECOMP_NONBASE_P flags. As I think
namespace scope structured bindings in the header modules will be pretty rare,
I've tried to stream something extra only when they actually appear, in that
case it streams extra INTEGER_CSTs which mark end of
STATIC_INIT_DECOMP_*BASE_P (0), start of STATIC_INIT_DECOMP_BASE_P for
static_aggregates (1), start of STATIC_INIT_DECOMP_NONBASE_P for
static_aggregates (2) and ditto for tls_aggregates (3 and 4).
The patch also copies with just small tweaks the testcases from the
namespace scope structured binding CWG2867 patch.
2025-01-27 Jakub Jelinek <jakub@redhat.com>
PR c++/115769
gcc/cp/
* module.cc (module_state::write_inits): Verify
STATIC_INIT_DECOMP_{,NON}BASE_P flags and stream changes in those
out.
(module_state::read_inits): Stream those flags in.
gcc/testsuite/
* g++.dg/modules/dr2867-1_a.H: New test.
* g++.dg/modules/dr2867-1_b.C: New test.
* g++.dg/modules/dr2867-2_a.H: New test.
* g++.dg/modules/dr2867-2_b.C: New test.
* g++.dg/modules/dr2867-3_a.H: New test.
* g++.dg/modules/dr2867-3_b.C: New test.
* g++.dg/modules/dr2867-4_a.H: New test.
* g++.dg/modules/dr2867-4_b.C: New test.
Jakub Jelinek [Mon, 27 Jan 2025 15:45:56 +0000 (16:45 +0100)]
c++: Implement for namespace statics CWG 2867 - Order of initialization for structured bindings [PR115769]
The following patch adds CWG 2867 support for namespace locals.
Those vars are just pushed into {static,tls}_aggregates chain, then
pruned from those lists, separated by priority and finally emitted into
the corresponding dynamic initialization functions.
The patch adds two flags used on the TREE_LIST nodes in those lists,
one marks the structured binding base variable and/or associated ref
extended temps, another marks the vars initialized using get methods.
The flags are preserved across the pruning, for splitting into by priority
all associated decls of a structured binding using tuple* are forced
into the same priority as the first one, and finally when actually emitting
code, CLEANUP_POINT_EXPRs are disabled in the base initializer(s) and
code from the bases and non-bases together is wrapped into a single
CLEANUP_POINT_EXPR.
2025-01-27 Jakub Jelinek <jakub@redhat.com>
PR c++/115769
gcc/cp/
* cp-tree.h (STATIC_INIT_DECOMP_BASE_P): Define.
(STATIC_INIT_DECOMP_NONBASE_P): Define.
* decl.cc (cp_finish_decl): Mark nodes in {static,tls}_aggregates
emitted for namespace scope structured bindings with
STATIC_INIT_DECOMP_{,NON}BASE_P flags when needed.
* decl2.cc (decomp_handle_one_var, decomp_finalize_var_list): New
functions.
(emit_partial_init_fini_fn): Use them.
(prune_vars_needing_no_initialization): Assert
STATIC_INIT_DECOMP_*BASE_P is not set on DECL_EXTERNAL vars to be
pruned out.
(partition_vars_for_init_fini): Use same priority for
consecutive STATIC_INIT_DECOMP_*BASE_P vars and propagate
those flags to new TREE_LISTs when possible. Formatting fix.
(handle_tls_init): Use decomp_handle_one_var and
decomp_finalize_var_list functions.
gcc/testsuite/
* g++.dg/DRs/dr2867-5.C: New test.
* g++.dg/DRs/dr2867-6.C: New test.
* g++.dg/DRs/dr2867-7.C: New test.
* g++.dg/DRs/dr2867-8.C: New test.
but since r106 is used we wrongly materialize it using a subreg:
modifying insn i3 10: r106:V4QI=r109:V4SI#0
which of course does not work for modes with more than one component,
specifically vector and complex modes.
PR rtl-optimization/118662
* combine.cc (try_combine): When re-materializing a load
from an extended reg by a lowpart subreg make sure we're
not dealing with vector or complex modes.
Richard Biener [Mon, 27 Jan 2025 10:28:47 +0000 (11:28 +0100)]
middle-end/118643 - ICE with out-of-bound decl access
When RTL expansion of an out-of-bound access of a register falls
back to a BIT_FIELD_REF we have to ensure that's valid. The
following avoids negative offsets by expanding through a stack
temporary.
PR middle-end/118643
* expr.cc (expand_expr_real_1): Avoid falling back to BIT_FIELD_REF
expansion for negative offset.
Richard Biener [Thu, 23 Jan 2025 12:10:17 +0000 (13:10 +0100)]
tree-optimization/112859 - bogus loop distribution
When we get a zero distance vector we still have to check for the
situation of a common inner loop with zero distance. But we can
still allow a zero distance for the loop we distribute
(gcc.dg/tree-ssa/ldist-33.c is such a case). This is because
zero distances in non-outermost loops are a misrepresentation
of dependence by dependence analysis.
Note that test coverage of loop distribution of loop nests is
very low.
PR tree-optimization/112859
PR tree-optimization/115347
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): For a zero
distance vector still make sure to not have an inner
loop with zero distance.
* gcc.dg/torture/pr112859.c: New testcase.
* gcc.dg/torture/pr115347.c: Likewise.
Paul Thomas [Mon, 27 Jan 2025 09:55:26 +0000 (09:55 +0000)]
Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640]
2025-01-27 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/118640
* resolve.cc (generate_component_assignments): Make sure that
the rhs temporary does not pick up the optional attribute from
the lhs.
gcc/testsuite/
PR fortran/118640
* gfortran.dg/pr118640.f90: New test.
Jakub Jelinek [Mon, 27 Jan 2025 09:22:28 +0000 (10:22 +0100)]
match.pd: Canonicalize unsigned division by power of two into right shift [PR118637]
We already do this canonicalization in
simplify_using_ranges::simplify_div_or_mod_using_ranges, but that means
that it is not done at -O1 or when vrp is otherwise disabled, and that
it can be done too late in some cases when e.g. the r8-2064
"X / C1 op C2 into a simple range test." optimization triggers first.
Note, for unsigned modulo we already have
(simplify
(mod @0 (convert? (power_of_two_cand@1 @2)))
(if ((TYPE_UNSIGNED (type) || tree_expr_nonnegative_p (@0))
...
optimization which duplicates what
simplify_using_ranges::simplify_div_or_mod_using_ranges
does in case ranges aren't needed.
For GCC 16 I think we should improve the niters pattern recognition
and handle even what r8-2064 comes with, after all as I've tried to show
in the PR the user could have written it that way.
I've guarded this optimization on #if GIMPLE just in case this would stand
in any way to the various divmult etc. simplification, guess that can be
lifted for GCC 16 too. In the modulo case we also handle
unsigned % (power_of_two << n), but not really sure if we could do that
for the division, because unsigned / (power_of_two << n) is not simple
unsigned >> (log2 (power_of_two) + n), one can shift the bit out and then
it becomes just 0.
2025-01-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118637
* match.pd: Canonicalize unsigned division by power of two to
right shift.
The FakeStack flag is not zeroed out when can_store_by_pieces()
returns false. Over time, this causes FakeStack::Allocate() to perform
the maximum number of loop iterations, significantly slowing down the
instrumented program.
trying to combine definition of r11 in:
40: a1:SI=frm:SI
into:
42: frm:SI=a1:SI
instruction becomes a no-op:
(set (reg:SI 69 frm)
(reg:SI 69 frm))
original cost = 4 + 4 (weighted: 8.000000), replacement cost = 2147483647; keeping replacement
rescanning insn with uid = 42.
updating insn 42 in-place
verify found no changes in insn with uid = 42.
deleting insn 40
For example we have code as blow:
9 │ int test_exampe () {
10 │ test ();
11 │
12 │ size_t vl = 4;
13 │ vfloat16m1_t va = __riscv_vle16_v_f16m1(a, vl);
14 │ va = __riscv_vfnmadd_vv_f16m1_rm(va, va, va, __RISCV_FRM_RDN, vl);
15 │ va = __riscv_vfmsac_vv_f16m1(va, va, va, vl);
16 │
17 │ __riscv_vse16_v_f16m1(b, va, vl);
18 │
19 │ return 0;
20 │ }
it will be compiled to:
53 │ main:
54 │ addi sp,sp,-16
55 │ sd ra,8(sp)
56 │ call initialize
57 │ lui a6,%hi(b)
58 │ lui a2,%hi(a)
59 │ addi a3,a6,%lo(b)
60 │ addi a2,a2,%lo(a)
61 │ li a4,4
62 │ .L8:
63 │ fsrmi 2
64 │ vsetvli a5,a4,e16,m1,ta,ma
65 │ vle16.v v1,0(a2)
66 │ slli a1,a5,1
67 │ subw a4,a4,a5
68 │ add a2,a2,a1
69 │ vfnmadd.vv v1,v1,v1
>> The fsrm a0 insn is deleted by late-combine <<
70 │ vfmsub.vv v1,v1,v1
71 │ vse16.v v1,0(a3)
72 │ add a3,a3,a1
73 │ bgt a4,zero,.L8
74 │ lh a4,%lo(b)(a6)
75 │ li a5,-20480
76 │ addi a5,a5,-1382
77 │ bne a4,a5,.L14
78 │ ld ra,8(sp)
79 │ li a0,0
80 │ addi sp,sp,16
81 │ jr ra
This patch would like to add the FRM register to the global_regs as it
is a cooperatively-managed global register. And then the fsrm insn will
not be eliminated by late-combine. The related spec17 cam4 failure may
also caused by this issue too.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
PR target/118103
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_conditional_register_usage): Add
the FRM as the global_regs.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr118103-1.c: New test.
* gcc.target/riscv/rvv/base/pr118103-run-1.c: New test.
Gaius Mulley [Sat, 25 Jan 2025 20:30:02 +0000 (20:30 +0000)]
[PR modula2/118010, modula2/118183] Rebuild bootstrap tools with lseek fix
This patch rebuilds the bootstrap tools mc and pge incorporating the fix to
libc.lseek. The tool mc is changed to omit INCLUDE_MEMORY from
checkGccConfigSystem. The pge tool on rebuild now requires
--gcc-config-system to pick up the system.h containing INCLUDE_MEMORY.
After rebuild all local INCLUDE_MEMORY definitions disappear.
Harald Anlauf [Sat, 25 Jan 2025 18:59:56 +0000 (19:59 +0100)]
Fortran: fix issues with variables in BLOCK DATA [PR58857]
PR fortran/58857
gcc/fortran/ChangeLog:
* class.cc (gfc_find_derived_vtab): Declare some frontend generated
variables and procedures (_vtab, _copy, _deallocate) as artificial.
(find_intrinsic_vtab): Likewise.
* trans-decl.cc (check_block_data_decls): New helper function.
(gfc_generate_block_data): Use it to emit warnings for variables
declared in a BLOCK DATA program unit but not in a COMMON block.
gcc/testsuite/ChangeLog:
* gfortran.dg/uncommon_block_data_2.f90: New test.
Andi Kleen [Thu, 26 Dec 2024 04:21:58 +0000 (20:21 -0800)]
Move ferror out of hot loop of file cache
glibc ferror is surprisingly expensive. Move it out of the hot loop
of finding lines by setting a flag after the actual IO operations.
gcc/ChangeLog:
PR preprocessor/118168
* input.cc (file_cache_slot::m_error): New field.
(file_cache_slot::create): Clear m_error.
(file_cache_slot::file_cache_slot): Clear m_error.
(file_cache_slot::read_data): Set m_error on error.
(file_cache_slot::get_next_line): Use m_error instead of ferror.
This patch fixes calls to lseek from m2 sources. The new data
type SYSTEM.COFF_T is used instead of SYSTEM.CCSIZE_T.
gcc/m2/ChangeLog:
PR modula2/118010
* gm2-libs-log/FileSystem.mod (doModeChange): Replace
LONGINT with COFF_T.
(SetPos): Use COFF_T for the return value and offset type
when calling lseek.
* gm2-libs/FIO.mod (SetPositionFromBeginning): Convert pos
to COFF_T.
(SetPositionFromEnd): Ditto.
* mc-boot/GFIO.cc: Rebuild.
* mc-boot/Glibc.h: Ditto.
* pge-boot/GFIO.cc: Ditto.
* pge-boot/Glibc.h: Ditto.
Simon Martin [Sat, 25 Jan 2025 17:09:23 +0000 (18:09 +0100)]
c++: Reinstate check for uninitialized bases with c++ <= 17 [PR118239]
We currently accept this code with c++ <= 17 even though it's invalid
since the base is not initialized (we properly reject it with c++ >= 20)
=== cut here ===
struct NoMut1 { int a, b; };
struct NoMut3 : NoMut1 {
constexpr NoMut3(int a, int b) {}
};
void mutable_subobjects() {
constexpr NoMut3 nm3(1, 2);
}
=== cut here ===
This is a fallout of r0-118700-gc2b3ec18a494e3, that ignores all fields
with DECL_ARTIFICIAL in cx_check_missing_mem_inits, including those that
represent base classes, and need to be checked.
This patch makes sure that we only skip fields that have DECL_ARTIFICIAL
if they don't have DECL_FIELD_IS_BASE.
PR c++/118239
gcc/cp/ChangeLog:
* constexpr.cc (cx_check_missing_mem_inits): Don't skip fields
with DECL_FIELD_IS_BASE.
Jeff Law [Sat, 25 Jan 2025 16:42:19 +0000 (09:42 -0700)]
[RISC-V][PR target/116256] Improve handling of single bit constants
So under the umbrella of pr116256 (P3 regression) I've been exploring removal
of the mvconst_internal pattern. Not surprisingly, that's going to cause all
kinds of undesirable fallout. While I can kind of see a path forward for that
work, it's going to require some combine work that I don't think we want to
tackle in the context of gcc-15.
Essentially without mvconst_internal we'll have fully exposed constant
synthesis prior to combine. Remember that combine has limits on what
combinations it will perform based on how many instructions are in the source
sequence. If we need 2+ instructions to synthesize the constant, those eat
into our budget.
In a world without mvconst_internal we'd need to either improve combine to
handle 5 insns cases (which do show up in the testsuite) or we need to
significantly improve how combine handles REG_EQUAL notes. 5 insn combinations
sound like insanity to me. So I'd tend to lean towards the latter, though
that's going to need some refactoring and diving into note redistribution
(ugh!).
In the mean time we can start limiting mvconst_internal. For the remaining
case in pr116256 we have this code in combine:
Note a couple things. First insn 8 will be split shortly after combine and
will need the constant 2048. But that's obviously exposed late. Second (of
course) is the mvconst_internal pattern at insn 10. After split1 we'll have:
> (insn 16 5 17 2 (set (reg:DI 144) (const_int 4096 [0x1000])) "j.c":152:11 -1
> (nil))
> (insn 17 16 18 2 (set (reg:DI 143)
> (plus:DI (reg:DI 144)
> (const_int -2048 [0xfffffffffffff800]))) "j.c":152:11 -1
> (expr_list:REG_EQUAL (const_int 2048 [0x800])
> (nil)))
> (insn 18 17 19 2 (set (reg:V2048HF 138 [ _5 ])
> (if_then_else:V2048HF (unspec:V2048BI [ (const_vector:V2048BI [
> (const_int 1 [0x1]) repeated x2048
> ])
> (reg:DI 143)
> (const_int 2 [0x2]) repeated x3
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> ] UNSPEC_VPREDICATE)
> (vec_duplicate:V2048HF (reg:HF 142 [ x ]))
> (unspec:V2048HF [ (reg:DI 0 zero)
> ] UNSPEC_VUNDEF))) "j.c":152:11 -1
> (nil))
> (insn 19 18 20 2 (set (reg:DI 145)
> (const_int 4096 [0x1000])) "j.c":152:11 -1
> (nil))
> (insn 20 19 11 2 (set (reg:DI 139)
> (plus:DI (reg:DI 145)
> (const_int -2048 [0xfffffffffffff800]))) "j.c":152:11 -1
> (expr_list:REG_EQUAL (const_int 2048 [0x800])
> (nil)))
> (insn 11 20 0 2 (set (mem:V2048HF (reg/f:DI 141 [ in ]) [1 MEM <vector(2048) _Float16> [(_Float16 *)in_7(D)]+0 S4096 A128])
> (if_then_else:V2048HF (unspec:V2048BI [
> (const_vector:V2048BI [
> (const_int 1 [0x1]) repeated x2048
> ])
> (reg:DI 139) (const_int 2 [0x2]) repeated x3
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> ] UNSPEC_VPREDICATE)
> (reg:V2048HF 138 [ _5 ])
> (unspec:V2048HF [ (reg:DI 0 zero)
> ] UNSPEC_VUNDEF))) "j.c":152:11 3843 {*pred_movv2048hf}
> (expr_list:REG_DEAD (reg/f:DI 141 [ in ])
> (expr_list:REG_DEAD (reg:DI 0 zero) (expr_list:REG_DEAD (reg:SI 66 vl)
> (expr_list:REG_DEAD (reg:SI 67 vtype)
> (expr_list:REG_DEAD (reg:V2048HF 138 [ _5 ])
> (expr_list:REG_DEAD (reg:DI 139)
> (nil))))))))
Note the synthesis of 2048 appears twice. I seriously considered adding a
local cprop pass at this point. That could be done with a bit of work. It
didn't look too bad -- the biggest problem is cprop isn't designed to run once
we've left cfglayout. But we could probably finesse that by not allowing it to
change jumps if we've left cfglayout or converting it to do the more complex
jump fixups.
You might ask why the post-reload optimizers don't help since this at least
looks like a case where they could. After LRA the RTL looks like:
Note the re-use of a5 for the constant synthesis steps. That's going to spoil
any chance of reload_cse saving us. That re-use also gets in the way of vsetvl
elimination and we ultimately get this code:
> foo10:
> li a5,4096
> addi a5,a5,-2048
> vsetvli zero,a5,e16,m8,ta,ma
> vfmv.v.f v8,fa0
> li a5,4096
> addi a5,a5,-2048
> vsetvli zero,a5,e16,m8,ta,ma
> vse16.v v8,0(a0)
> ret
The regression is we have the obviously redundant vsetvl. The additional copy
of the synthesis is undesirable as well.
If we filter out single bit constants from mvconst_internal we trivially fix
that regression. The only fallout is a class of saturation tests which want to
test against 0x80000000. Under the hood this is a minor codegen issue
interacting badly with combine's deliberate rejection of simplification of
extensions of constants. Rather than constructing the SImode constant, then
zero extending the result we can just generate the constant we actually want
directly in DImode.
The net is we fix the regression, don't introduce any obvious new regressions
and slightly reduce our dependence on mvconst_internal. All good in my book.
Obviously I'll wait for pre-commit CI to render a verdict.
PR target/116256
gcc/
* config/riscv/riscv.md (mvconst_internal): Reject single bit
constants.
* config/riscv/riscv.cc (riscv_gen_zero_extend_rtx): Improve
handling constants.
Jakub Jelinek [Sat, 25 Jan 2025 09:15:24 +0000 (10:15 +0100)]
c++: Only destruct elts of array for new expression if exception is thrown during the initialization [PR117827]
The following testcase r12-6328, because the elements of the array
are destructed twice, once when the callee encounters delete[] p;
and then second time when the exception is thrown.
The array elts should be only destructed if exception is thrown from
one of the constructors during the build_vec_init emitted code in case of
new expressions, but when the new expression completes, it is IMO
responsibility of user code to delete[] it when it is no longer needed.
So, the following patch uses the cleanup_flags argument to build_vec_init
to get notified of the flags that need to be changed when the expression
is complete and build_disable_temp_cleanup to do the changes.
2025-01-25 Jakub Jelinek <jakub@redhat.com>
PR c++/117827
* init.cc (build_new_1): Pass address of a make_tree_vector ()
initialized gc tree vector to build_vec_init and append
build_disable_temp_cleanup to init_expr from it.
This patch corrects a typo in the definition of lseek in libc.
The second offset parameter should have been declared as COFF_T.
No errors are seen when bootstrapping using -Werror=odr
-Werror=lto-type-mismatch.
gcc/m2/ChangeLog:
PR modula2/118010
* gm2-compiler/P2SymBuild.mod (Debug): Comment out unused
procedure.
* gm2-libs/libc.def (lseek): Declare second parameter offset
as COFF_T.
Nathaniel Shead [Sun, 5 Jan 2025 12:01:44 +0000 (23:01 +1100)]
c++/modules: Treat unattached lambdas as TU-local [PR116568]
This fixes ICEs where unattached lambdas at class scope (for instance,
in member template instantiations) are streamed. This is only possible
in header units, as in named modules attempting to stream such lambdas
will be an error.
PR c++/116568
gcc/cp/ChangeLog:
* module.cc (trees_out::get_merge_kind): Treat all lambdas
without a mangling scope as un-mergeable.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-8.h: New test.
* g++.dg/modules/lambda-8_a.H: New test.
* g++.dg/modules/lambda-8_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Sun, 5 Jan 2025 12:45:05 +0000 (23:45 +1100)]
c++/modules: Diagnose TU-local lambdas, give mangling scope to lambdas in concepts
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
properly set for most lambdas we can use it to detect lambdas that are
TU-local.
CWG2988 suggests that lambdas in concept definitions should not be
considered TU-local, since they are always unevaluated and should never
be emitted. This patch gives these lambdas a mangling scope (though it
will never be actually used in name mangling).
PR c++/116568
gcc/cp/ChangeLog:
* cp-tree.h (finish_concept_definition): Adjust parameters.
(start_concept_definition): Declare.
* module.cc (depset::hash::is_tu_local_entity): Use
LAMBDA_EXPR_EXTRA_SCOPE to detect TU-local lambdas.
* parser.cc (cp_parser_concept_definition): Start a lambda scope
for concept definitions.
* pt.cc (tsubst_lambda_expr): Namespace-scope lambdas may now
have extra scope.
(finish_concept_definition): Split into...
(start_concept_definition): ...this new function.
gcc/testsuite/ChangeLog:
* g++.dg/modules/internal-4_b.C: Remove XFAIL, add lambda alias
testcase.
* g++.dg/modules/lambda-9.h: New test.
* g++.dg/modules/lambda-9_a.H: New test.
* g++.dg/modules/lambda-9_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Thu, 23 Jan 2025 08:22:04 +0000 (19:22 +1100)]
c++: Fix mangling of otherwise unattached class-scope lambdas [PR118245]
This is a step closer to implementing the suggested changes for
https://github.com/itanium-cxx-abi/cxx-abi/pull/85. Most lambdas
defined within a class should have an extra scope of that class so that
uses across different TUs are properly merged by the linker. This also
needs to happen during template instantiation.
While I was working on this I found some other cases where the mangling
of lambdas was incorrect and causing issues, notably the testcase
lambda-ctx3.C which currently emits the same mangling for the base class
and member lambdas, causing mysterious assembler errors since r14-9232.
One notable case not handled either here or in the ABI is what is
supposed to happen with such unattached lambdas declared in member
templates; see lambda-uneval22. I believe that by the C++ standard,
such lambdas should also dedup across TUs, but this isn't currently
implemented, and it's not clear exactly how such lambdas should mangle.
Since this should only affect usage of lambdas in unevaluated contexts
(a C++20 feature) this patch does not add an ABI flag to control this
behaviour.
PR c++/118245
gcc/cp/ChangeLog:
* cp-tree.h (LAMBDA_EXPR_EXTRA_SCOPE): Adjust comment.
* parser.cc (cp_parser_class_head): Start (and do not finish)
lambda scope for all valid types.
(cp_parser_class_specifier): Finish lambda scope after parsing
members instead.
* pt.cc (instantiate_class_template): Add lambda scoping.
gcc/testsuite/ChangeLog:
* g++.dg/abi/lambda-ctx3.C: New test.
* g++.dg/cpp2a/lambda-uneval22.C: New test.
* g++.dg/cpp2a/lambda-uneval23.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Gaius Mulley [Sat, 25 Jan 2025 00:05:48 +0000 (00:05 +0000)]
PR modula2/118589 Opaque type fields are visible outside implementation module
This patch fixes a bug shown when a variable declared as an opaque type is
dereferenced outside the declaration module. The fix also improves error
recovery. In the error cases it ensures that an error symbol is created
and the appropriate virtual token is assigned. Finally there is a new
testsuite directory gm2.dg which contains tests to check against expected
error messages.
gcc/m2/ChangeLog:
PR modula2/118589
* gm2-compiler/M2MetaError.mod (symDesc): Add opaque type
description.
* gm2-compiler/M2Quads.mod (BuildDesignatorPointerError): New
procedure.
(BuildDesignatorPointer): Reimplement.
* gm2-compiler/P3Build.bnf (SubDesignator): Tidy up error message.
Use MetaErrorT2 rather than WriteForma1 and use the token pos from
the quad stack.
gcc/testsuite/ChangeLog:
PR modula2/118589
* lib/gm2-dg.exp (gm2.exp): load_lib.
* gm2.dg/pim/fail/badopaque.mod: New test.
* gm2.dg/pim/fail/badopaque2.mod: New test.
* gm2.dg/pim/fail/dg-pim-fail.exp: New test.
* gm2.dg/pim/fail/opaquedefs.def: New test.
* gm2.dg/pim/fail/opaquedefs.mod: New test.
Andrew Carlotti [Fri, 24 Jan 2025 11:00:41 +0000 (11:00 +0000)]
aarch64: Add +cpa feature flag
This doesn't enable anything within the compiler, but this allows the
flag to be passed the assembler. There also doesn't appear to be a
kernel cpuinfo name yet.
Andrew Carlotti [Thu, 9 Jan 2025 19:33:25 +0000 (19:33 +0000)]
aarch64: Make AARCH64_FL_CRYPTO always unset
This feature flag bit only exists to support the +crypto alias. Outside
of option processing this bit needs to be set or unset consistently.
This patch goes with the latter option.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc: Assert that CRYPTO
bit is not set.
* config/aarch64/aarch64-feature-deps.h
(info<FEAT>.explicit_on): Unset CRYPTO bit.
(cpu_##CORE_IDENT): Ditto.
Andrew Carlotti [Mon, 11 Nov 2024 12:20:25 +0000 (12:20 +0000)]
aarch64: Rewrite architecture strings for assembler
Add infrastructure to allow rewriting the architecture strings passed to
the assembler (either as -march options or .arch directives). There was
already canonicalisation everywhere except for an -march driver option
passed directly to the compiler; this patch applies the same
canonicalisation there as well.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_get_arch_string_for_assembler): New.
(aarch64_rewrite_march): New.
(aarch64_rewrite_selected_cpu): Call new function.
* config/aarch64/aarch64-elf.h (ASM_SPEC): Remove identity mapping.
* config/aarch64/aarch64-protos.h
(aarch64_get_arch_string_for_assembler): New.
* config/aarch64/aarch64.cc
(aarch64_declare_function_name): Call new function.
(aarch64_start_file): Ditto.
* config/aarch64/aarch64.h
(EXTRA_SPEC_FUNCTIONS): Use new macro name.
(MCPU_TO_MARCH_SPEC): Rename to...
(MARCH_REWRITE_SPEC): ...this, and extend the spec rule.
(aarch64_rewrite_march): New declaration.
(MCPU_TO_MARCH_SPEC_FUNCTIONS): Rename to...
(AARCH64_BASE_SPEC_FUNCTIONS): ...this, and add new function.
(ASM_CPU_SPEC): Use new macro name.
Andrew Carlotti [Thu, 23 Jan 2025 17:08:17 +0000 (17:08 +0000)]
aarch64: Move arch/cpu parsing to aarch64-common.cc
Aside from moving the functions, the only changes are to make them
non-static, and to use the existing info arrays within aarch64-common.cc
instead of the info arrays remaining in aarch64.cc.
It seems odd that we add "native" to the list for -march but not for
-mcpu. This is probably a bug, but for now we'll preserve the existing
behaviour.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_print_hint_candidates): New helper function.
(aarch64_print_hint_for_core_or_arch): Inline into callers.
(aarch64_print_hint_for_core): Inline callee and use new helper.
(aarch64_print_hint_for_arch): Ditto.
(aarch64_print_hint_for_extensions): Use new helper.
Andrew Carlotti [Wed, 8 Jan 2025 22:58:05 +0000 (22:58 +0000)]
aarch64: Rename info structs in aarch64-common.cc
Also add a (currently unused) processor field to aarch64_processor_info,
and change name from "" to NULL for the terminating array entries.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(struct aarch64_option_extension): Rename to..
(struct aarch64_extension_info): ...this.
(all_extensions): Update type name.
(struct arch_to_arch_name): Rename to...
(struct aarch64_arch_info): ...this, and rename name field.
(all_architectures): Update type names, and move before...
(struct processor_name_to_arch): ...this. Rename to...
(struct aarch64_processor_info): ...this, rename name field and
add cpu field.
(all_cores): Update type name, and set new field.
(aarch64_parse_extension): Update names.
(aarch64_get_all_extension_candidates): Ditto.
(aarch64_rewrite_selected_cpu): Ditto.
Andrew Carlotti [Wed, 8 Jan 2025 20:06:09 +0000 (20:06 +0000)]
aarch64: Replace duplicate cpu enums
Replace `enum aarch64_processor` and `enum target_cpus` with
`enum aarch64_cpu`, and prefix the entries with `AARCH64_CPU_`.
Also rename aarch64_none to aarch64_no_cpu.
gcc/ChangeLog:
* config/aarch64/aarch64-opts.h
(enum aarch64_processor): Rename to...
(enum aarch64_cpu): ...this, and rename the entries.
* config/aarch64/aarch64.cc
(aarch64_type): Rename type and initial value.
(struct processor): Rename member types.
(all_architectures): Rename enum members.
(all_cores): Ditto.
(aarch64_get_tune_cpu): Rename type and enum member.
* config/aarch64/aarch64.h (enum target_cpus): Remove.
(TARGET_CPU_DEFAULT): Rename default value.
(aarch64_tune): Rename type.
* config/aarch64/aarch64.opt:
(selected_tune): Rename type and default value.
Andrew Carlotti [Wed, 8 Jan 2025 18:29:27 +0000 (18:29 +0000)]
aarch64: Improve mcpu/march conflict check
Features from a cpu or base architecture that were explicitly disabled
by a +nofeat option were being incorrectly added back in before checking
for conflicts between -mcpu and -march options. This patch instead
compares the returned feature masks directly.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_override_options): Compare
returned feature masks directly.
[PR118497][IRA]: Fix calculation of cost of assigning callee-saved hard reg
Assembler code generated by GCC for PR118497 contains unnecessary
move insn. This happened as IRA assigns AX reg to a pseudo which
should be in BX reg later for a call. The pseudo did not get BX as
LRA decided that it requires to save BX although BX will be saved
anyway. The patch fixes the cost calculation. Usage of hard reg
nrefs from regstat or DF will result in numerous failures as such
nrefs include artificial reg refs. Therefore we add a calculation of
hard reg nrefs in IRA. Also we change regexp used for scanning the
assembler in test vartrack-1.c as with the patch LRA assigns
callee-saved hard reg BP instead of another callee-saved hard reg BX
expected by the test.
gcc/ChangeLog:
PR target/118497
* ira-int.h (target_ira_int): Add x_ira_hard_regno_nrefs.
(ira_hard_regno_nrefs): New macro.
* ira.cc (setup_hard_regno_aclass): Remove unused code. Modify
the comment.
(setup_hard_regno_nrefs): New function.
(ira): Call it.
* ira-color.cc (calculate_saved_nregs): Check
ira_hard_regno_nrefs.
gcc/testsuite/ChangeLog:
PR target/118497
* gcc.target/i386/pr118497.c: New.
* gcc.target/i386/vartrack-1.c: Modify the regexp.
Marek Polacek [Mon, 25 Nov 2024 14:45:13 +0000 (09:45 -0500)]
c++: ICE with nested anonymous union [PR117153]
In a template, for
union {
union {
T d;
};
};
build_anon_union_vars crates a malformed COMPONENT_REF: we have no
DECL_NAME for the nested anon union so we create something like "object.".
Most of the front end doesn't seem to care, but if such a tree gets to
potential_constant_expression, it can cause a crash.
We can use FIELD directly for the COMPONENT_REF's member. tsubst_stmt
should build up a proper one in:
if (VAR_P (decl) && !DECL_NAME (decl)
&& ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
/* Anonymous aggregates are a special case. */
finish_anon_union (decl);
PR c++/117153
gcc/cp/ChangeLog:
* decl2.cc (build_anon_union_vars): Use FIELD for the second operand
of a COMPONENT_REF.
gcc/testsuite/ChangeLog:
* g++.dg/other/anon-union6.C: New test.
* g++.dg/other/anon-union7.C: New test.
yxj-github-437 [Thu, 16 Jan 2025 00:36:15 +0000 (08:36 +0800)]
c++/modules: Fix linkage checks for exported using-decls
This patch attempts to fix an error when build module std. The reason for
the error is __builtin_va_list (aka struct __va_list) has internal linkage.
so mark this builtin type as TREE_PUBLIC to make struct __va_list has
external linkage.
g++ -fmodules -std=c++23 -fsearch-include-path bits/std.cc -c
std.cc:3642:14:error: exporting ‘typedef __gnuc_va_list va_list’ that does not have external linkage
3642 | using std::va_list;
| ^~~~~~~
<built-in>: note: ‘struct __va_list’ declared here with internal linkage
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_build_builtin_va_list): Mark
__builtin_va_list as TREE_PUBLIC.
* config/arm/arm.cc (arm_build_builtin_va_list): Likewise.
David Malcolm [Fri, 24 Jan 2025 15:20:16 +0000 (10:20 -0500)]
jit: fix for write_reproducer [PR117886]
The original generated .c reproducer for PR jit/117886 did not compile,
with:
main.c: In function ‘create_code’:
main.c:600:9: error: initialization of ‘gcc_jit_rvalue *’ from incompatible pointer type ‘gcc_jit_lvalue *’ [-Wincompatible-pointer-types]
600 | local__1,
| ^~~~~~~~
The issue is that recording::ctor::write_reproducer was missing
creation of casts to gcc_jit_rvalue * for
gcc_jit_context_new_array_constructor and
gcc_jit_context_new_struct_constructor.
Fixed thusly.
gcc/jit/ChangeLog:
PR jit/117886
* jit-recording.cc (reproducer::get_identifier_as_rvalue): Handle
null memento.
(reproducer::get_identifier_as_lvalue): Likewise.
(reproducer::get_identifier_as_type): Likewise.
(recording::ctor::write_reproducer): Use get_identifier_as_rvalue
rather than get_identifier when writing out gcc_jit_rvalue *
expressions.
David Malcolm [Fri, 24 Jan 2025 15:20:11 +0000 (10:20 -0500)]
sarif-replay: respect prefix and suffix during installation [PR117670]
gcc/ChangeLog:
PR sarif-replay/117670
* Makefile.in (SARIF_REPLAY_INSTALL_NAME): New.
(install-libgdiagnostics): Use it,and exeext, rather than just
sarif-replay.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
r15-491-gc290e6a0b7a9de fixed a latent issue with dr_analyze_innermost
and dr_may_alias where not properly analyzed DRs would yield an invalid
answer. This caused some missed optimizations in case there is not
actually any evolution in the not analyzed base part. The following
recovers this by only handling base parts which reference SSA vars
as index in the conservative way.
The gfortran.dg/vect/vect-8.f90 testcase is difficult to deal with,
so the following merely bumps the maximum number of expected vectorized loops
for both aarch64 and x86-64.
PR tree-optimization/116010
* tree-data-ref.cc (contains_ssa_ref_p_1): New function.
(contains_ssa_ref_p): Likewise.
(dr_may_alias_p): Avoid treating unanalyzed base parts without
SSA reference conservatively.
Merge new optabs with the existing implementations for signbit and
isinf.
gcc/ChangeLog:
* config/s390/s390.h (S390_TDC_POSITIVE_ZERO): Remove.
(S390_TDC_NEGATIVE_ZERO): Remove.
(S390_TDC_POSITIVE_NORMALIZED_BFP_NUMBER): Remove.
(S390_TDC_NEGATIVE_NORMALIZED_BFP_NUMBER): Remove.
(S390_TDC_POSITIVE_DENORMALIZED_BFP_NUMBER): Remove.
(S390_TDC_NEGATIVE_DENORMALIZED_BFP_NUMBER): Remove.
(S390_TDC_POSITIVE_INFINITY): Remove.
(S390_TDC_NEGATIVE_INFINITY): Remove.
(S390_TDC_POSITIVE_QUIET_NAN): Remove.
(S390_TDC_NEGATIVE_QUIET_NAN): Remove.
(S390_TDC_POSITIVE_SIGNALING_NAN): Remove.
(S390_TDC_NEGATIVE_SIGNALING_NAN): Remove.
(S390_TDC_POSITIVE_DENORMALIZED_DFP_NUMBER): Remove.
(S390_TDC_NEGATIVE_DENORMALIZED_DFP_NUMBER): Remove.
(S390_TDC_POSITIVE_NORMALIZED_DFP_NUMBER): Remove.
(S390_TDC_NEGATIVE_NORMALIZED_DFP_NUMBER): Remove.
(S390_TDC_SIGNBIT_SET): Remove.
(S390_TDC_INFINITY): Remove.
* config/s390/s390.md (signbit<mode>2<tf_fpr>): Merge this one
(isinf<mode>2<tf_fpr>): and this one into
(<TDC_CLASS:tdc_insn><mode>2<tf_fpr>): new expander.
(isnormal<mode>2<tf_fpr>): New BFP expander.
(isnormal<mode>2): New DFP expander.
* config/s390/vector.md (signbittf2_vr): Merge this one
(isinftf2_vr): and this one into
(<tdc_insn>tf2_vr): new expander.
(signbittf2): Merge this one
(isinftf2): and this one into
(<tdc_insn>tf2): new expander.
gcc/testsuite/ChangeLog:
* gcc.target/s390/isfinite-isinf-isnormal-signbit-1.c: New test.
* gcc.target/s390/isfinite-isinf-isnormal-signbit-2.c: New test.
* gcc.target/s390/isfinite-isinf-isnormal-signbit-3.c: New test.
* gcc.target/s390/isfinite-isinf-isnormal-signbit.h: New test.
Richard Biener [Fri, 24 Jan 2025 08:13:17 +0000 (09:13 +0100)]
tree-optimization/118634 - improve cunroll dump
We no longer subtract the estimated eliminated number of instructions
from the estimated size after unrolling we print - this is a bit
confusing when comparing dumps to previous releases. The following
changes the dump from
Estimated size after unrolling: 42
to
Estimated size after unrolling: 42-12
for the testcase in the PR.
PR tree-optimization/118634
* tree-ssa-loop-ivcanon.cc (try_unroll_loop_completely):
Dump the number of estimated eliminated insns.
Saurabh Jha [Tue, 21 Jan 2025 15:59:39 +0000 (15:59 +0000)]
Fix command flags for SVE2 faminmax
Earlier, we were gating SVE2 faminmax behind sve+faminmax. This was
incorrect and this patch changes it so that it is gated behind
sve2+faminmax.
gcc/ChangeLog:
* config/aarch64/aarch64-sve2.md:
(*aarch64_pred_faminmax_fused): Fix to use the correct flags.
* config/aarch64/aarch64.h
(TARGET_SVE_FAMINMAX): Remove.
* config/aarch64/iterators.md: Fix iterators so that famax and
famin use correct flags.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/faminmax_1.c: Fix test to use the
correct flags.
* gcc.target/aarch64/sve/faminmax_2.c: Fix test to use the
correct flags.
* gcc.target/aarch64/sve/faminmax_3.c: New test.
Alexandre Oliva [Fri, 24 Jan 2025 02:23:16 +0000 (23:23 -0300)]
[ifcombine] check for more zero-extension cases [PR118572]
When comparing a signed narrow variable with a wider constant that has
the bit corresponding to the variable's sign bit set, we would check
that the constant is a sign-extension from that sign bit, and conclude
that the compare fails if it isn't.
When the signed variable is masked without getting the [lr]l_signbit
variable set, or when the sign bit itself is masked out, we know the
sign-extension bits from the extended variable are going to be zero,
so the constant will only compare equal if it is a zero- rather than
sign-extension from the narrow variable's precision, therefore, check
that it satisfies this property, and yield a false compare result
otherwise.
for gcc/ChangeLog
PR tree-optimization/118572
* gimple-fold.cc (fold_truth_andor_for_ifcombine): Compare as
unsigned the variables whose extension bits are masked out.