This is, in effect, a reapplication of de2bc6a7367aca2eecc925ebb64cfb86998d89f3
fixing the compile-time hog in var-tracking due to calling simplify_rtx
on the two arms of the rotation before detecting the ROTATE.
That is not necessary.
simplify-rtx can transform (X << C1) | (X >> C2) into ROTATE (X, C1) when
C1 + C2 == mode-width. But the transformation is also valid for PLUS and XOR.
Indeed GIMPLE can also do the fold. Let's teach RTL to do it too.
The motivating testcase for this is in AArch64 intrinsics:
uint64x2_t G2(uint64x2_t a, uint64x2_t b) {
uint64x2_t c = veorq_u64(a, b);
return veorq_u64(vaddq_u64(c, c), vshrq_n_u64(c, 63));
}
which I was hoping to fold to a single XAR (a ROTATE+XOR instruction) but
GCC was failing to detect the rotate operation for two reasons:
1) The combination of the two arms of the expression is done under XOR rather
than IOR that simplify-rtx currently supports.
2) The ASHIFT operation is actually a (PLUS X X) operation and thus is not
detected as the LHS of the two arms we require.
The patch fixes both issues. The analysis of the two arms of the rotation
expression is factored out into a common helper simplify_rotate_op which is
then used in the PLUS, XOR, IOR cases in simplify_binary_operation_1.
The check-assembly testcase for this is added in the following patch because
it needs some extra AArch64 backend work, but I've added self-tests in this
patch to validate the transformation.
Bootstrapped and tested on aarch64-none-linux-gnu
Signed-off-by: Kyrylo Tkachov <ktachov@nvidia.com>
PR target/117048
* simplify-rtx.cc (extract_ashift_operands_p): Define.
(simplify_rotate_op): Likewise.
(simplify_context::simplify_binary_operation_1): Use the above in
the PLUS, IOR, XOR cases.
(test_vector_rotate): Define.
(test_vector_ops): Use the above.
Andrew MacLeod [Sat, 2 Nov 2024 14:26:24 +0000 (10:26 -0400)]
Don't call invert on VARYING.
When all cases go to one label and resul in a VARYING value, we can't
invert that value to remove all values from the default case. Simply
check for this case and set the default to UNDEFINED.
PR tree-optimization/117398
gcc/
* gimple-range-edge.cc (gimple_outgoing_range::calc_switch_ranges):
Check for VARYING and don't call invert () on it.
As Yuta Mukai pointed out, the manual wrongly said that LS64 is
enabled by default for Armv8.7-A and above, and for Armv9.2-A
and above. LS64 is not mandatory at any architecture level
(and the code correctly implemented that).
I think this was a leftover from an early version of the spec.
gcc/
* doc/invoke.texi: Fix documentation of LS64 so that it's
not implied by Armv8.7-A or Armv9.2-A.
Jakub Jelinek [Mon, 4 Nov 2024 11:29:01 +0000 (12:29 +0100)]
libstdc++: Fix up 117406.cc test [PR117406]
Christophe mentioned in bugzilla that the test FAILs on aarch64,
I'm not including <climits> and use INT_MAX.
Apparently during my testing I got it because the test preinclude
-include bits/stdc++.h
and that includes <climits>, dunno why that didn't happen on aarch64.
In any case, either I can add #include <climits>, or because the
test already has #include <limits> I've changed uses of INT_MAX
with std::numeric_limits<int>::max(), that should be the same thing.
But if you prefer
#include <climits>
I can surely add that instead.
2024-11-04 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/117406
* testsuite/26_numerics/headers/cmath/117406.cc: Use
std::numeric_limits<int>::max() instead of INT_MAX.
Richard Biener [Thu, 31 Oct 2024 10:51:16 +0000 (11:51 +0100)]
Preserve ->move_dr behavior when adjusting epilogue info
When update_epilogue_loop_vinfo relates the shared loop DRs with
the epilogue stmts and infos it should not fiddle with how
pattern recognition applied move_dr.
* tree-vect-loop.cc (update_epilogue_loop_vinfo): A DRs
main stmt vinfo dr_aux should refer to a pattern stmt
which is how move_dr sets this up. We shouldn't undo this.
Richard Biener [Thu, 31 Oct 2024 08:55:35 +0000 (09:55 +0100)]
Move updated versioning threshold compute
The following moves computing the combined main + epilogue loop
versioning threshold until we figured the epilogues to use rather
than incrementally updating it with the chance to joust candidates
after the fact.
* tree-vect-loop.cc (vect_analyze_loop): Move lowest_th
compute until after epilogue_vinfos is final.
Kyrylo Tkachov [Thu, 17 Oct 2024 13:39:57 +0000 (06:39 -0700)]
simplify-rtx: Simplify ROTATE:HI (X:HI, 8) into BSWAP:HI (X)
With recent patch to improve detection of vector rotates at RTL level
combine now tries matching a V8HImode rotate by 8 in the example in the
testcase. We can teach AArch64 to emit a REV16 instruction for such a rotate
but really this operation corresponds to the RTL code BSWAP, for which we
already have the right patterns. BSWAP is arguably a simpler representation
than ROTATE here because it has only one operand, so let's teach simplify-rtx
to generate it.
With this patch the testcase now generates the simplest form:
.L2:
ldr q31, [x1, x0]
rev16 v31.16b, v31.16b
str q31, [x0, x2]
add x0, x0, 16
cmp x0, 2048
bne .L2
IMO ideally the bswap detection would have been done during vectorisation
time and used the expanders for that, but teaching simplify-rtx to do this
transformation is fairly straightforward and, unlike at tree level, we have
the native RTL BSWAP code. This change is not enough to generate the
equivalent sequence in SVE, but that is something that should be tackled
separately.
Bootstrapped and tested on aarch64-none-linux-gnu.
Kyrylo Tkachov [Tue, 22 Oct 2024 14:52:36 +0000 (07:52 -0700)]
aarch64: Emit XAR for vector rotates where possible
We can make use of the integrated rotate step of the XAR instruction
to implement most vector integer rotates, as long we zero out one
of the input registers for it. This allows for a lower-latency sequence
than the fallback SHL+USRA, especially when we can hoist the zeroing operation
away from loops and hot parts. This should be safe to do for 64-bit vectors
as well even though the XAR instructions operate on 128-bit values, as the
bottom 64-bit results is later accessed through the right subregs.
This strategy is used whenever we have XAR instructions, the logic
in aarch64_emit_opt_vec_rotate is adjusted to resort to
expand_rotate_as_vec_perm only when it's expected to generate a single REV*
instruction or when XAR instructions are not present.
With this patch we can gerate for the input:
v4si
G1 (v4si r)
{
return (r >> 23) | (r << 9);
}
v8qi
G2 (v8qi r)
{
return (r << 3) | (r >> 5);
}
the assembly for +sve2:
G1:
movi v31.4s, 0
xar z0.s, z0.s, z31.s, #23
ret
G2:
movi v31.4s, 0
xar z0.b, z0.b, z31.b, #5
ret
instead of the current:
G1:
shl v31.4s, v0.4s, 9
usra v31.4s, v0.4s, 23
mov v0.16b, v31.16b
ret
G2:
shl v31.8b, v0.8b, 3
usra v31.8b, v0.8b, 5
mov v0.8b, v31.8b
ret
Bootstrapped and tested on aarch64-none-linux-gnu.
Kyrylo Tkachov [Wed, 16 Oct 2024 11:10:08 +0000 (04:10 -0700)]
aarch64: Optimize vector rotates as vector permutes where possible
Some vector rotate operations can be implemented in a single instruction
rather than using the fallback SHL+USRA sequence.
In particular, when the rotate amount is half the bitwidth of the element
we can use a REV64,REV32,REV16 instruction.
More generally, rotates by a byte amount can be implented using vector
permutes.
This patch adds such a generic routine in expmed.cc called
expand_rotate_as_vec_perm that calculates the required permute indices
and uses the expand_vec_perm_const interface.
On aarch64 this ends up generating the single-instruction sequences above
where possible and can use LDR+TBL sequences too, which are a good choice.
With help from Richard, the routine should be VLA-safe.
However, the only use of expand_rotate_as_vec_perm introduced in this patch
is in aarch64-specific code that for now only handles fixed-width modes.
A runtime aarch64 test is added to ensure the permute indices are not messed
up.
Bootstrapped and tested on aarch64-none-linux-gnu.
Kyrylo Tkachov [Tue, 15 Oct 2024 13:33:11 +0000 (06:33 -0700)]
PR 117048: aarch64: Add define_insn_and_split for vector ROTATE
The ultimate goal in this PR is to match the XAR pattern that is represented
as a (ROTATE (XOR X Y) VCST) from the ACLE intrinsics code in the testcase.
The first blocker for this was the missing recognition of ROTATE in
simplify-rtx, which is fixed in the previous patch.
The next problem is that once the ROTATE has been matched from the shifts
and orr/xor/plus, it will try to match it in an insn before trying to combine
the XOR into it. But as we don't have a backend pattern for a vector ROTATE
this recog fails and combine does not try the followup XOR+ROTATE combination
which would have succeeded.
This patch solves that by introducing a sort of "scaffolding" pattern for
vector ROTATE, which allows it to be combined into the XAR.
If it fails to be combined into anything the splitter will break it back
down into the SHL+USRA sequence that it would have emitted.
By having this splitter we can special-case some rotate amounts in the future
to emit more specialised instructions e.g. from the REV* family.
This can be done if the ROTATE is not combined into something else.
This optimisation is done in the next patch in the series.
Bootstrapped and tested on aarch64-none-linux-gnu.
Kyrylo Tkachov [Tue, 22 Oct 2024 10:27:47 +0000 (03:27 -0700)]
aarch64: Use canonical RTL representation for SVE2 XAR and extend it to fixed-width modes
The MD pattern for the XAR instruction in SVE2 is currently expressed with
non-canonical RTL by using a ROTATERT code with a constant rotate amount.
Fix it by using the left ROTATE code. This necessitates splitting out the
expander separately to translate the immediate coming from the intrinsic
from a right-rotate to a left-rotate immediate.
Additionally, as the SVE2 XAR instruction is unpredicated and can handle all
element sizes from .b to .d, it is a good fit for implementing the XOR+ROTATE
operation for Advanced SIMD modes where the TARGET_SHA3 cannot be used
(that can only handle V2DImode operands). Therefore let's extend the accepted
modes of the SVE2 patternt to include the Advanced SIMD integer modes.
This leads to some tests for the svxar* intrinsics to fail because they now
simplify to a plain EOR when the rotate amount is the width of the element.
This simplification is desirable (EOR instructions have better or equal
throughput than XAR, and they are non-destructive of their input) so the
tests are adjusted.
For V2DImode XAR operations we should prefer the Advanced SIMD version when
it is available (TARGET_SHA3) because it is non-destructive, so restrict the
SVE2 pattern accordingly. Tests are added to confirm this.
Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for mainline?
* config/aarch64/iterators.md (SVE_ASIMD_FULL_I): New mode iterator.
* config/aarch64/aarch64-sve2.md (@aarch64_sve2_xar<mode>):
Use SVE_ASIMD_FULL_I modes. Use ROTATE code for the rotate step.
Adjust output logic.
* config/aarch64/aarch64-sve-builtins-sve2.cc (svxar_impl): Define.
(svxar): Use the above.
gcc/testsuite/
* gcc.target/aarch64/xar_neon_modes.c: New test.
* gcc.target/aarch64/xar_v2di_nonsve.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/xar_s16.c: Scan for EOR rather than
XAR.
* gcc.target/aarch64/sve2/acle/asm/xar_s32.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/xar_s64.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/xar_s8.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/xar_u16.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/xar_u32.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/xar_u64.c: Likewise.
* gcc.target/aarch64/sve2/acle/asm/xar_u8.c: Likewise.
simplify-rtx can transform (X << C1) | (X >> C2) into ROTATE (X, C1) when
C1 + C2 == mode-width. But the transformation is also valid for PLUS and XOR.
Indeed GIMPLE can also do the fold. Let's teach RTL to do it too.
The motivating testcase for this is in AArch64 intrinsics:
uint64x2_t G2(uint64x2_t a, uint64x2_t b) {
uint64x2_t c = veorq_u64(a, b);
return veorq_u64(vaddq_u64(c, c), vshrq_n_u64(c, 63));
}
which I was hoping to fold to a single XAR (a ROTATE+XOR instruction) but
GCC was failing to detect the rotate operation for two reasons:
1) The combination of the two arms of the expression is done under XOR rather
than IOR that simplify-rtx currently supports.
2) The ASHIFT operation is actually a (PLUS X X) operation and thus is not
detected as the LHS of the two arms we require.
The patch fixes both issues. The analysis of the two arms of the rotation
expression is factored out into a common helper simplify_rotate which is
then used in the PLUS, XOR, IOR cases in simplify_binary_operation_1.
The check-assembly testcase for this is added in the following patch because
it needs some extra AArch64 backend work, but I've added self-tests in this
patch to validate the transformation.
Bootstrapped and tested on aarch64-none-linux-gnu
Signed-off-by: Kyrylo Tkachov <ktachov@nvidia.com>
PR target/117048
* simplify-rtx.cc (extract_ashift_operands_p): Define.
(simplify_rotate_op): Likewise.
(simplify_context::simplify_binary_operation_1): Use the above in
the PLUS, IOR, XOR cases.
(test_vector_rotate): Define.
(test_vector_ops): Use the above.
Andrew Pinski [Sun, 3 Nov 2024 06:34:00 +0000 (23:34 -0700)]
docs: Document that __builtin_assoc_barrier also can be used for FMAs [PR115023]
I noticed that __builtin_assoc_barrier makes a differnce for FMAs formation
but it was not documented. This adds that documentation even with a small example.
Build the HTML documents to make sure everything looks correct.
gcc/ChangeLog:
PR middle-end/115023
* doc/extend.texi (__builtin_assoc_barrier): Document ffp-contract=fast
and FMA usage.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
There are a couple of things wrong with this pattern which
I missed during the review. First each nop_convert should
be nop_convert1 or nop_convert2.
Second is we need to the minus in the same type as the minus
was originally so we don't introduce extra undefined behavior
(signed integer overflow). And we need a convert into the new
type too.
pr117363-1.c tests not introducing extra undefined behavior.
pr117363-2.c tests the casting to the correct final type, ldist
introduces the cond_expr here.
Bootstraped and tested on x86_64-linux-gnu.
PR tree-optimization/117363
gcc/ChangeLog:
* match.pd (`a != 0 ? a - 1 : 0`): Fix type handling
and nop_convert handling.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr117363-1.c: New test.
* gcc.dg/torture/pr117363-2.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Paul Thomas [Sun, 3 Nov 2024 18:02:16 +0000 (18:02 +0000)]
Fortran: Fix associate_69.f90 that fails on some platforms [PR115700]
2024-11-03 Paul Thomas <pault@gcc.gnu.org>
gcc/testsuite/
PR fortran/115700
* gfortran.dg/associate_69.f90: Remove the test that produces a
variable string length because the optimized count depends on
the platform. This is tested in associate_70.f90.
Thomas Koenig [Tue, 29 Oct 2024 20:08:59 +0000 (21:08 +0100)]
Add UMASKR and UMASKL intrinsics.
gcc/fortran/ChangeLog:
* check.cc (gfc_check_mask): Handle BT_INSIGNED.
* gfortran.h (enum gfc_isym_id): Add GFC_ISYM_UMASKL and
GFC_ISYM_UMASKR.
* gfortran.texi: List UMASKL and UMASKR, remove unsigned future
unsigned arguments for MASKL and MASKR.
* intrinsic.cc (add_functions): Add UMASKL and UMASKR.
* intrinsic.h (gfc_simplify_umaskl): New function.
(gfc_simplify_umaskr): New function.
(gfc_resolve_umasklr): New function.
* intrinsic.texi: Document UMASKL and UMASKR.
* iresolve.cc (gfc_resolve_umasklr): New function.
* simplify.cc (gfc_simplify_umaskr): New function.
(gfc_simplify_umaskl): New function.
Jakub Jelinek [Sat, 2 Nov 2024 17:48:54 +0000 (18:48 +0100)]
libstdc++: Fix up std::{,b}float16_t std::{ilogb,l{,l}r{ound,int}} [PR117406]
These overloads incorrectly cast the result of the float __builtin_*
to _Float or __gnu_cxx::__bfloat16_t. For std::ilogb that changes
behavior for the INT_MAX return because that isn't representable in
either of the floating point formats, for the others it is I think
just a very inefficient hop from int/long/long long to std::{,b}float16_t
and back. I mean for the round/rint cases, either the argument is small
and then the return value should be representable in the floating point
format too, or it is too large that the argument is already integral
and then it should just return the argument with the round trips.
Too large value is unspecified unlike ilogb.
2024-11-02 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/117406
* include/c_global/cmath (std::ilogb(_Float16), std::llrint(_Float16),
std::llround(_Float16), std::lrint(_Float16), std::lround(_Float16)):
Don't cast __builtin_* return to _Float16.
(std::ilogb(__gnu_cxx::__bfloat16_t),
std::llrint(__gnu_cxx::__bfloat16_t),
std::llround(__gnu_cxx::__bfloat16_t),
std::lrint(__gnu_cxx::__bfloat16_t),
std::lround(__gnu_cxx::__bfloat16_t)): Don't cast __builtin_* return to
__gnu_cxx::__bfloat16_t.
* testsuite/26_numerics/headers/cmath/117406.cc: New test.
Jakub Jelinek [Sat, 2 Nov 2024 17:47:27 +0000 (18:47 +0100)]
gimplify: Fix up RAW_DATA_CST related ICE [PR117384]
Apparently tree_output_constant_def doesn't strictly guarantee that the
returned VAR_DECL will have the same or uselessly convertible type as
the type of the constant passed to it, compare_constants says:
/* For arrays, check that mode, size and storage order match. */
/* For record and union constructors, require exact type equality. */
The older use of tree_output_constant_def in gimplify.cc was already
handling this right:
ctor = tree_output_constant_def (ctor);
if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
but the spot I've added for RAW_DATA_CST missed this.
So, the following patch adds that.
2024-11-02 Jakub Jelinek <jakub@redhat.com>
PR middle-end/117384
* gimplify.cc (gimplify_init_ctor_eval): Add VIEW_CONVERT_EXPR around
rctor if it doesn't have expected type.
Nathaniel Shead [Thu, 31 Oct 2024 09:05:16 +0000 (20:05 +1100)]
c++/modules: Propagate TYPE_CANONICAL for partial specialisations [PR113814]
In some cases, when we go to import a partial specialisation there might
already be an incomplete implicit instantiation in the specialisation
table. This causes ICEs described in the linked PR as we now have two
separate matching specialisations for this same arguments with different
TYPE_CANONICAL.
We already support multiple specialisations with the same args however,
as they may be differently constrained. So we can solve this by simply
ensuring that the TYPE_CANONICAL of the new partial specialisation
matches the existing specialisation.
* g++.dg/modules/partial-6.h: New test.
* g++.dg/modules/partial-6_a.H: New test.
* g++.dg/modules/partial-6_b.H: New test.
* g++.dg/modules/partial-6_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Co-authored-by: Jason Merrill <jason@redhat.com>
In cases like the linked PR we sometimes get mutually recursive
dependencies that both rely on the other to have been streamed as part
of their merge key information. In the linked PR, this causes an ICE.
The root cause is that 'sort_cluster' is not correctly ordering the
dependencies; both the element_t specialisation and the
reverse_adaptor::first function decl depend on each other, but by
streaming element_t first it ends up trying to stream itself recursively
as part of calculating its own merge key, which apart from the checking
ICE will also cause issues on stream-in, as the merge key will not
properly stream.
There is a comment already in 'sort_cluster' describing this issue, but
it says:
Finding the single cluster entry dep is very tricky and
expensive. Let's just not do that. It's harmless in this case
anyway.
However in this case it was not harmless: it's just somewhat luck that
the sorting happened to work for the existing cases in the testsuite.
This patch solves the issue by noting any declarations that rely on deps
first seen within their own merge key. This declaration gets marked as
an "entry" dep; any of these deps that end up recursively referring back
to that entry dep as part of their own merge key do not.
Then within sort_cluster we can ensure that the entry dep is written to
be streamed first of its cluster; this will ensure that any other deps
are just emitted as back-references, and the mergeable dep itself will
structurally decompose.
PR c++/116317
gcc/cp/ChangeLog:
* module.cc
(depset::DB_MAYBE_RECURSIVE_BIT): New flag.
(depset::DB_ENTRY_BIT): New flag.
(depset::is_maybe_recursive): New accessor.
(depset::is_entry): New accessor.
(depset::hash::writing_merge_key): New field.
(trees_out::decl_value): Inform dep_hash while we're writing the
merge key information for a decl.
(depset::hash::add_dependency): Find recursive deps and mark the
entry point.
(sort_cluster): Ensure that the entry dep is streamed first.
gcc/testsuite/ChangeLog:
* g++.dg/modules/late-ret-4_a.H: New test.
* g++.dg/modules/late-ret-4_b.C: New test.
Jeff Law [Sat, 2 Nov 2024 02:28:07 +0000 (20:28 -0600)]
[committed] Make LRA default for ft32 and remove -mlra option
I was looking to clean up an old patch I'm carrying in my tester. My first
thought was that ft32 was likely going to be deprecated because it wasn't using
LRA -- which in turn would mean the patch in question could just be removed.
But then I checked, ft32 has an LRA option and if turned on it gets the exact
same test results as with reload. While the port mentions a failure with
sieve.c, that's been there since the port was introduced in 2015.
It's working well enough that I think just converting it is the right thing to
do. The testsuite patch which precipitated this one will follow separately.
I've kept the -mlra option for compatibility sake, but it's ignored.
Pushing to the trunk.
gcc/
* config/ft32/ft32.cc (ft32_lra_p): Remove.
(TARGET_LRA_P): Likewise.
* config/ft32/ft32.opt: Make -mlra ignored.
* doc/invoke.texi: Adjust documentation for -mlra on ft32.
Jakub Jelinek [Fri, 1 Nov 2024 22:03:48 +0000 (23:03 +0100)]
builtins: Fix expand_builtin_prefetch [PR117407]
On Fri, Nov 01, 2024 at 04:47:35PM +0800, Haochen Jiang wrote:
> * builtins.cc (expand_builtin_prefetch): Use IN_RANGE to
> avoid second usage of INTVAL.
I doubt this has been actually tested.
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -1297,7 +1297,7 @@ expand_builtin_prefetch (tree exp)
> else
> op1 = expand_normal (arg1);
> /* Argument 1 must be 0, 1 or 2. */
> - if (INTVAL (op1) < 0 || INTVAL (op1) > 2)
> + if (IN_RANGE (INTVAL (op1), 0, 2))
> {
> warning (0, "invalid second argument to %<__builtin_prefetch%>;"
> " using zero");
> @@ -1315,7 +1315,7 @@ expand_builtin_prefetch (tree exp)
> else
> op2 = expand_normal (arg2);
> /* Argument 2 must be 0, 1, 2, or 3. */
> - if (INTVAL (op2) < 0 || INTVAL (op2) > 3)
> + if (IN_RANGE (INTVAL (op2), 0, 3))
> {
> warning (0, "invalid third argument to %<__builtin_prefetch%>; using zero");
> op2 = const0_rtx;
because it inverts the tests, previously it was warning when op1 wasn't
0, 1, 2, now it warns when it is 0, 1 or 2, previously it was warning
when op2 wasn't 0, 1, 2 or 3, now it warns when it is 0, 1, 2, or 3.
Fixed thusly.
2024-11-01 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/117407
* builtins.cc (expand_builtin_prefetch): Use !IN_RANGE rather
than IN_RANGE.
Andrew MacLeod [Thu, 31 Oct 2024 19:44:15 +0000 (15:44 -0400)]
Make fur_edge accessible.
Move the decl of fur_edge out of the source file into the header file.
* gimple-range-fold.cc (class fur_edge): Relocate from here.
(fur_edge::fur_edge): Also move to:
* gimple-range-fold.h (class fur_edge): Relocate to here.
(fur_edge::fur_edge): Likewise.
Jakub Jelinek [Fri, 1 Nov 2024 18:50:28 +0000 (19:50 +0100)]
c++: Adjust docs and option descriptions for the publishing of C++23
Now that C++23 has been finally published, the following patch attempts
to mention it in the option descriptions and documentation.
Given that it has been published about 1.5 years after being finalized
and has the 14882:2024 document number pair rather than :2023, I wasn't
sure when exactly to use 2023 (as informal name) and when 2024 (as year
of publishing), so I've tried to use 2024 in standards.texi which talks
more formally about the standards and a note that it has been published
in 2024 when it is talked about more informally.
I remember at least one older edition has been published in January too,
but the ISO pages pretend it was published still in December of the previous
year, in this case it doesn't.
2024-11-01 Jakub Jelinek <jakub@redhat.com>
gcc/
* doc/standards.texi (C++ Language): Mention also the 2024
revision and -std=gnu++23 option.
* doc/invoke.texi (-std=): Adjust description of c++23, c++2b,
gnu++23 and gnu++2b now that ISO C++ 14882:2024 is published.
gcc/c-family/
* c.opt (std=c++2b, std=c++23, std=gnu++2b, std=gnu++23): Adjust
description now that ISO C++ 14882:2024 is published.
Jakub Jelinek [Fri, 1 Nov 2024 18:42:28 +0000 (19:42 +0100)]
c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be Macros [PR114461]
This is an attempt to implement the https://wg21.link/p3034r1 paper,
but I'm afraid the wording in the paper is bad for multiple reasons.
I think I understand the intent, that the module name and partition
if any shouldn't come from macros so that they can be scanned for
without preprocessing, but on the other side doesn't want to disable
macro expansion in pp-module altogether, because e.g. the optional
attribute in module-declaration would be nice to come from macros
as which exact attribute is needed might need to be decided based on
preprocessor checks.
The paper added https://eel.is/c++draft/cpp.module#2
which uses partly the wording from https://eel.is/c++draft/cpp.module#1
The first issue I see is that using that "defined as an object-like macro"
from there means IMHO something very different in those 2 paragraphs.
As per https://eel.is/c++draft/cpp.pre#7.sentence-1 preprocessing tokens
in preprocessing directives aren't subject to macro expansion unless
otherwise stated, and so the export and module tokens aren't expanded
and so the requirement that they aren't defined as an object-like macro
makes perfect sense. The problem with the new paragraph is that
https://eel.is/c++draft/cpp.module#3.sentence-1 says that the rest of
the tokens are macro expanded and after macro expansion none of the
tokens can be defined as an object-like macro, if they would be, they'd
be expanded to that. So, I think either the wording needs to change
such that not all preprocessing tokens after module are macro expanded,
only those which are after the pp-module-name and if any pp-module-partition
tokens, or all tokens after module are macro expanded but none of the tokens in
pp-module-name and pp-module-partition if any must come from macro
expansion. The patch below implements it as if the former would be
specified (but see later), so essentially scans the preprocessing tokens
after module without expansion, if the first one is an identifier, it
disables expansion for it and then if followed by . or : expects another
such identifier (again with disabled expansion), but stops after second
: is seen.
Second issue is that while the global-module-fragment start is fine, matches
the syntax of the new paragraph where the pp-tokens[opt] aren't present,
there is also private-module-fragment in the syntax where module is
followed by : private ; and in that case the colon doesn't match the
pp-module-name grammar and appears now to be invalid. I think the
https://eel.is/c++draft/cpp.module#2
paragraph needs to change so that it allows also that pp-tokens of
a pp-module may also be : pp-tokens[opt] (and in that case, I think
the colon shouldn't come from a macro and private and/or ; can).
Third issue is that there are too many pp-tokens in
https://eel.is/c++draft/cpp.module , one is all the tokens between
module keyword and the semicolon and one is the optional extra tokens
after pp-module-partition (if any, if missing, after pp-module).
Perhaps introducing some other non-terminal would help talking about it?
So in "where the pp-tokens (if any) shall not begin with a ( preprocessing
token" it isn't obvious which pp-tokens it is talking about (my assumption
is the latter) and also whether ( can't appear there just before macro
expansion or also after expansion. The patch expects only before expansion,
so
#define F ();
export module foo F
would be valid during preprocessing but obviously invalid during
compilation, but
#define foo(n) n;
export module foo (3)
would be invalid already during preprocessing.
The last issue applies only if the first issue is resolved to allow
expansion of tokens after : if first token, or after pp-module-partition
if present or after pp-module-name if present. When non-preprocessing
scanner sees
export module foo.bar:baz.qux;
it knows nothing can come from preprocessing macros and is ok, but if it
sees
export module foo.bar:baz qux
then it can't know whether it will be
export module foo.bar:baz;
or
export module foo.bar:baz [[]];
or
export module foo.bar:baz.freddy.garply;
because qux could be validly a macro, which expands to ; or [[]];
or .freddy.garply; etc. So, either the non-preprocessing scanner would
need to note it as possible export of foo.bar:baz* module partitions
and preprocess if it needs to know the details or just compile, or if that
is not ok, the wording would need to rule out that the expansion of (the
second) pp-tokens if any can't start with . or : (colon would be only
problematic if it isn't present in the tokens before it already).
So, if e.g. defining qux above to . whatever is invalid, then the scanner
can rely it sees the whole module name and partition.
The patch below implements what is above described as the first variant
of the first issue resolution, i.e. disables expansion of as many tokens
as could be in the valid module name and module partition syntax, but
as soon as it e.g. sees two adjacent identifiers, the second one can be
macro expanded. If it is macro expanded though, the expansion can't
start with . or :, and if it expands to nothing, tokens after it (whether
they come from macro expansion or not) can't start with . or :.
So, effectively:
#define SEMI ;
export module SEMI
used to be valid and isn't anymore,
#define FOO bar
export module FOO;
isn't valid,
#define COLON :
export module COLON private;
isn't valid,
#define BAR baz
export module foo.bar:baz.qux.BAR;
isn't valid,
#define BAZ .qux
export module foo BAZ;
isn't valid,
#define FREDDY :garply
export module foo FREDDY;
isn't valid,
while
#define QUX [[]]
export module foo QUX;
or
#define GARPLY private
module : GARPLY;
etc. is.
2024-11-01 Jakub Jelinek <jakub@redhat.com>
PR c++/114461
libcpp/
* include/cpplib.h: Implement C++26 P3034R1
- Module Declarations Shouldn’t be Macros (or more precisely
its expected intent).
(NO_DOT_COLON): Define.
* internal.h (struct cpp_reader): Add diagnose_dot_colon_from_macro_p
member.
* lex.cc (cpp_maybe_module_directive): For pp-module, if
module keyword is followed by CPP_NAME, ensure all CPP_NAME
tokens possibly matching module name and module partition
syntax aren't expanded and aren't defined as object-like macros.
Verify first token after that doesn't start with open paren.
If the next token after module name/partition is CPP_NAME defined
as macro, set NO_DOT_COLON flag on it.
* macro.cc (cpp_get_token_1): Set
pfile->diagnose_dot_colon_from_macro_p if token to be expanded has
NO_DOT_COLON bit set in flags. Before returning, if
pfile->diagnose_dot_colon_from_macro_p is true and not returning
CPP_PADDING or CPP_COMMENT and not during macro expansion preparation,
set pfile->diagnose_dot_colon_from_macro_p to false and diagnose
if returning CPP_DOT or CPP_COLON.
gcc/testsuite/
* g++.dg/modules/cpp-7.C: New test.
* g++.dg/modules/cpp-8.C: New test.
* g++.dg/modules/cpp-9.C: New test.
* g++.dg/modules/cpp-10.C: New test.
* g++.dg/modules/cpp-11.C: New test.
* g++.dg/modules/cpp-12.C: New test.
* g++.dg/modules/cpp-13.C: New test.
* g++.dg/modules/cpp-14.C: New test.
* g++.dg/modules/cpp-15.C: New test.
* g++.dg/modules/cpp-16.C: New test.
* g++.dg/modules/cpp-17.C: New test.
* g++.dg/modules/cpp-18.C: New test.
* g++.dg/modules/cpp-19.C: New test.
* g++.dg/modules/cpp-20.C: New test.
* g++.dg/modules/pmp-4.C: New test.
* g++.dg/modules/pmp-5.C: New test.
* g++.dg/modules/pmp-6.C: New test.
* g++.dg/modules/token-6.C: New test.
* g++.dg/modules/token-7.C: New test.
* g++.dg/modules/token-8.C: New test.
* g++.dg/modules/token-9.C: New test.
* g++.dg/modules/token-10.C: New test.
* g++.dg/modules/token-11.C: New test.
* g++.dg/modules/token-12.C: New test.
* g++.dg/modules/token-13.C: New test.
* g++.dg/modules/token-14.C: New test.
* g++.dg/modules/token-15.C: New test.
* g++.dg/modules/token-16.C: New test.
* g++.dg/modules/dir-only-3.C: Expect an error.
* g++.dg/modules/dir-only-4.C: Expect an error.
* g++.dg/modules/dir-only-5.C: New test.
* g++.dg/modules/atom-preamble-2_a.C: In export module malcolm;
replace malcolm with kevin. Don't define malcolm macro.
* g++.dg/modules/atom-preamble-4.C: Expect an error.
* g++.dg/modules/atom-preamble-5.C: New test.
Xi Ruoyao [Fri, 1 Nov 2024 16:05:44 +0000 (00:05 +0800)]
testsuite: Fix up builtin-prefetch-1.c tests
How can you use "read-shared" as an identifier? It's not allowed by all
C standard versions.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/builtin-prefetch-1.c (rws): Use
"read_shared" instead of "read-shared" as the identifier for
enum value.
* gcc.dg/builtin-prefetch-1.c (rws): Likewise.
Xi Ruoyao [Thu, 10 Oct 2024 18:44:27 +0000 (02:44 +0800)]
Always set SECTION_RELRO for or .data.rel.ro{,.local} [PR116887]
At least two ports (hppa and loongarch) need to set SECTION_RELRO for
.data.rel.ro{,.local} in section_type_flags (PR52999 and PR116887), and
I cannot see a reason not to just set it in the generic code.
With this applied we can also remove the hppa-specific
pa_section_type_flags in a future patch.
gcc/ChangeLog:
PR target/116887
* varasm.cc (default_section_type_flags): Always set
SECTION_RELRO if name is .data.rel.ro{,.local}.
Jakub Jelinek [Fri, 1 Nov 2024 10:57:32 +0000 (11:57 +0100)]
openmp: Return error_mark_node from tsubst_attribute for errneous varid
We incorrectly accept some invalid declare variant cases as if declare
variant wasn't there, in particular if a function template has some dependent
arguments and variant name lookup fails, because that is during
fn_type_unification with complain=tf_none, it just sets it to error_mark_node
and doesn't complain further, because it doesn't know the substitution failed
(we don't return error_mark_node from tsubst_attribute, just create TREE_LIST
with error_mark_node TREE_PURPOSE).
The following patch fixes it by returning error_mark_node in that case, then
fn_type_unification caller can see it failed and can redo it with explain_p
so that errors are reported.
2024-11-01 Jakub Jelinek <jakub@redhat.com>
* pt.cc (tsubst_attribute): For "omp declare variant base" attribute
if varid is error_mark_node, set val to error_mark_node rather than
creating a TREE_LIST with error_mark_node TREE_PURPOSE.
Paul Thomas [Fri, 1 Nov 2024 07:45:00 +0000 (07:45 +0000)]
Fortran: Fix problems with substring selectors in ASSOCIATE [PR115700]
2024-11-01 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/115700
* resolve.cc (resolve_assoc_var): Extract a substring reference
with missing as well as non-constant start or end.
gcc/testsuite/
PR fortran/115700
* gfortran.dg/associate_69.f90: Activate commented out tests.
* gfortran.dg/associate_70.f90: Test correct functioning of
references in associate_69.f90 tests.
Sam James [Fri, 25 Oct 2024 21:59:13 +0000 (22:59 +0100)]
testsuite: move single-file LTO pr47333 test to torture
This only started being used recently in r15-4683-g04e0fbbc34e101 and
pinskia pointed out we may as well make it a proper torture test
instead as it's a single file LTO test.
Sam James [Fri, 25 Oct 2024 21:57:50 +0000 (22:57 +0100)]
testsuite: move single-file LTO pr95677 test to torture
This only started being used recently in r15-4681-g96110c14cf61a1 and
pinskia pointed out we may as well make it a proper torture test
instead as it's a single file LTO test.
aarch64: Require SVE2 and/or SME2 for SVE FAMINMAX intrinsics
After the previous patch, we can now accurately model the ISA
requirements for the SVE FAMINMAX intrinsics. They can be used
in non-streaming mode if TARGET_SVE2 and in streaming mode if
TARGET_SME2 (with both cases also requiring TARGET_FAMINMAX).
They can be used in streaming-compatible mode if TARGET_SVE2
&& TARGET_SME2.
Also, Kyrill pointed out in the original review of the FAMINMAX
support that it would be more consistent to define the rtl patterns
in aarch64-sve2.md rather than aarch64-sve.md, so the pushed patch
did that. This patch moves the definitions of the intrinsics to
the sve2 files too, for consistency.
aarch64: Record separate streaming and non-streaming ISA requirements
For some upcoming extensions, we need to add intrinsics whose
ISA requirements differ between streaming mode and non-streaming mode.
This patch tries to generalise the infrastructure to support that:
- Rather than have a single set of feature flags, the patch uses a
separate set for sm_off (non-streaming, PSTATE.SM==0) and sm_on
(streaming, PSTATE.SM==1).
- The sm_off set is zero if the intrinsic is streaming-only.
Otherwise it is AARCH64_FL_SM_OFF | <requirements>.
- Similarly, the sm_on set is zero if the intrinsic is non-streaming-only.
Otherwise it is AARCH64_FL_SM_ON | <requirements>. AARCH64_FL_SME is
taken as given in streaming mode.
- Streaming-compatible code must satisfy both sets of requirements.
There should be no functional change.
gcc/
* config.gcc (aarch64*-*-*): Add aarch64-protos.h to target_gtfiles.
* config/aarch64/aarch64-protos.h
(aarch64_required_extensions): New structure.
(aarch64_check_required_extensions): Change the type of the
required_extensions parameter from aarch64_feature_flags to
aarch64_required_extensions.
* config/aarch64/aarch64-sve-builtins.h
(function_builder::add_unique_function): Likewise.
(function_builder::add_overloaded_function): Likewise.
(function_builder::get_attributes): Likewise.
(function_builder::add_function): Likewise.
(function_group_info): Change the type of required_extensions
in the same way.
* config/aarch64/aarch64-builtins.cc
(aarch64_pragma_builtins_data::required_extensions): Change the type
from aarch64_feature_flags to aarch64_required_extensions.
(aarch64_check_required_extensions): Likewise change the type
of the required_extensions parameter. Separate the requirements
for non-streaming mode and streaming mode, ORing them together
for streaming-compatible mode.
(aarch64_general_required_extensions): New function.
(aarch64_general_check_builtin_call): Use it.
* config/aarch64/aarch64-sve-builtins.cc
(registered_function::required_extensions): Change the type
from aarch64_feature_flags to aarch64_required_extensions.
(DEF_NEON_SVE_FUNCTION, DEF_SME_ZA_FUNCTION_GS): Update accordingly.
(function_builder::get_attributes): Change the type of the
required_extensions parameter from aarch64_feature_flags to
aarch64_required_extensions.
(function_builder::add_function): Likewise.
(function_builder::add_unique_function): Likewise.
(function_builder::add_overloaded_function): Likewise.
* config/aarch64/aarch64-simd-pragma-builtins.def: Update
REQUIRED_EXTENSIONS definitions to use aarch64_required_extensions.
* config/aarch64/aarch64-sve-builtins-base.def: Likewise.
* config/aarch64/aarch64-sve-builtins-sme.def: Likewise.
* config/aarch64/aarch64-sve-builtins-sve2.def: Likewise.
aarch64: Move ENTRY_VHSDF to aarch64-simd-pragma-builtins.def
It's more convenient for later patches if we only define ENTRY_VHSDF
once, in the .def file. Then the only macro that needs to be defined
before including the file is ENTRY itself.
The patch also moves the architecture requirements out of the
individual ENTRY invocations into a block-level definition of
REQUIRED_EXTENSIONS. This reduces cut-&-paste a little and makes
things more consistent with aarch64-sve-builtins*.def.
gcc/
* config/aarch64/aarch64-builtins.cc (ENTRY): Remove the features
argument and get the features from REQUIRED_EXTENSIONS instead.
(ENTRY_VHSDF): Move definition to...
* config/aarch64/aarch64-simd-pragma-builtins.def: ...here.
Move the architecture requirements to REQUIRED_EXTENSIONS.
The current code was based on an early version of the SME spec,
which allowed the .Q forms of TRN1, TRN2, UZP1, UZP2, ZIP1, and ZIP2
to be used in streaming mode. We should now forbid them instead;
see https://developer.arm.com/documentation/ddi0602/2024-09/SVE-Instructions/TRN1--TRN2--vectors---Interleave-even-or-odd-elements-from-two-vectors-?lang=en
and the corresponding entries for the others.
This fixes two cases where variably-modified types were not recognized as
such. The first is when building composite types and the other when a type
is reconstructed for the 'vector' attribute. Construction of types in
the C FE is reorganized to use c_build_* functions which are responsible for
setting C_TYPE_VARIABLE_SIZE, C_TYPE_VARIABLY_MODIFIED and TYPE_TYPELESS_STORAGE
based on the properties of the type itself and these replace all other logic
elsewhere (e.g. in grokdeclarator). A new 'c_reconstruct_complex_type' based
on these functions is introduced which is called via a language hook when the
'vector' attribute is processed (as for C++).
One problem is are arrays of unspecified size 'T[*]' which were represented
identically to zero-sized arrays but with C_TYPE_VARIABLE_SIZE set. To avoid
having to create distinct type copies for this, the representation was changed
to make it a natural VLA by giving it an upper bound of '(0, 0)'. This also
then allows fixing of PR100420 where such arrays were printed as 'T[0]'.
Finally, a new function 'c_verify_type' checks consistency of properties
specific to C FE and is called when checking is on.
Joseph Myers [Thu, 31 Oct 2024 17:56:07 +0000 (17:56 +0000)]
testsuite: Fix prototype in gcc.dg/pr114115.c
One test failing with a -std=gnu23 default that I wanted to
investigate further is gcc.dg/pr114115.c. Building with -std=gnu23
produces a warning:
pr114115.c:18:8: warning: 'ifunc' resolver for 'foo_ifunc2' should return 'void * (*)(void)' [-Wattribute-alias=]
It turns out that this warning (from cgraphunit.cc) is disabled for
unprototyped functions. Fix the return type for foo_ifunc2 so the
test builds without warnings both with and without -std=gnu23.
Joseph Myers [Thu, 31 Oct 2024 17:01:09 +0000 (17:01 +0000)]
testsuite: Use noinline in gcc.dg/simulate-thread/simulate-thread.h
Among the changes of test results with a -std=gnu23 default were two
tests changing from PASS to UNSUPPORTED:
UNSUPPORTED: gcc.dg/simulate-thread/speculative-store.c -O2 -g thread simulation test
UNSUPPORTED: gcc.dg/simulate-thread/speculative-store.c -O3 -g thread simulation test
It appears that functions defined with () becoming prototyped affects
inlining, and changing the code to use (void) allows UNSUPPORTED
results to be reproduced with -std=gnu17. Add __attribute__
((noinline)) on one more function to avoid the UNSUPPORTED results;
some of the tests in this directory already have such an attribute on
some functions.
Tested for x86_64-pc-linux-gnu.
* gcc.dg/simulate-thread/simulate-thread.h
(simulate_thread_wrapper_final_verify): Mark noinline.
Vineet Gupta [Thu, 24 Oct 2024 22:15:40 +0000 (15:15 -0700)]
RISC-V: fix const interleaved stepped vector with a scalar pattern
When bisecting for ICE in PR/117353, commit 771256bcb9dd ("RISC-V: Emit costs for
bool and stepped const vectors") uncovered yet another latent issue (first noted [1])
David Malcolm [Thu, 31 Oct 2024 16:25:36 +0000 (12:25 -0400)]
diagnostics: add class lazy_diagnostic_path
This patch adds a new class lazy_diagnostic_path for
use when creating rich_location instances, to allow deferring
expensive computations until the path is actually used (when
a diagnostic using the rich_location is emitted).
gcc/ChangeLog:
* Makefile.in (OBJS): Add lazy-diagnostic-path.o.
* lazy-diagnostic-path.cc: New file.
* lazy-diagnostic-path.h: New file.
* selftest-diagnostic.cc: Include "diagnostic-format.h".
(test_diagnostic_context::test_diagnostic_context): Turn off
flushing for the output format's printer.
* selftest-run-tests.cc (selftest::run_tests): Call
selftest::lazy_diagnostic_path_cc_tests.
* selftest.h (selftest::lazy_diagnostic_path_cc_tests): New decl.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
The failure showed up in the rivos CI and it is due to f3 now using
LMUL m1 instead of m8.
I have reworked the test to make it more robust and maintainable. This
allowed most of the special casing of command line arguments to be
removed. It also fixes an issue where some targets would enable
multiple versions of the function body check e.g. `-march=rv32gcv
-mcmodel=medany`.
Changes since v1: Added missing ChangeLog.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/cpymem-1.c: Fix and rework f3.
Sam James [Thu, 31 Oct 2024 03:36:23 +0000 (03:36 +0000)]
testsuite: add testcase for fixed PR106073
This was fixed by r12-8835-ge8d5f3a1b5a583 which surely made it latent
but richi points out it was likely an instance of PR90348. -fstack-reuse
continues to be a menace, so let's add the testcase.
Tamar Christina [Thu, 31 Oct 2024 12:50:23 +0000 (12:50 +0000)]
middle-end: Lower all gconds during vector pattern matching [PR117176]
I have been taking a look at boolean handing once more in the vectorizer.
There are two situation to consider:
1. when the boolean being created are created from comparing data inputs then
for the resulting vector boolean we need to know the vector type and the
precision. In this case, when we have an operation such as NOT on the data
element, this has to be lowered to XOR because the truncation to the vector
precision needs to be explicit.
2. when the boolean being created comes from another boolean operation, then
we don't need to lower NOT, as the precision doesn't change. We don't do
any lowering for these (as denoted in check_bool_pattern) and instead the
precision is copied from the element feeding the boolean statement during
VF analysis.
For early break gcond lowering in order to correctly handle the second scenario
above we punted the lowering of VECT_SCALAR_BOOLEAN_TYPE_P comparisons that were
already in the right shape. e.g. e != 0 where e is a boolean does not need any
lowering.
The issue however is that the statement feeding e may need to be lowered in the
case where it's a data expression.
This patch changes a bit how we do the lowering. We now always emit an
additional compare. e.g. if the input is;
if (e != 0)
where is a boolean we would punt on thi before, but now we generate
f = e != 0
if (f != 0)
We then use the same infrastructre as recog_bool to ask it to lower f, and in
doing so handle and boolean conversions that need to be lowered.
Because we now guarantee that f is an internal def we can also simplify the
SLP building code.
When e is a boolean, the precision we build for f needs to reflect the precision
of the operation feeding e. To get this value we use integer_type_for_mask the
same way recog_bool does, and if it's defined (e.g. we have a data conversions
somewhere) we pass that precision on instead. This gets us the correct VF
on the newly lowered boolean expressions.
gcc/ChangeLog:
PR tree-optimization/117176
* tree-vect-patterns.cc (vect_recog_gcond_pattern): Lower all gconds.
* tree-vect-slp.cc (vect_analyze_slp): No longer check for in vect def.
gcc/testsuite/ChangeLog:
PR tree-optimization/117176
* gcc.dg/vect/vect-early-break_130-pr117176.c: New test.
Yangyu Chen [Thu, 24 Oct 2024 07:12:45 +0000 (15:12 +0800)]
RISC-V: Do not inline when callee is versioned but caller is not
When the callee is versioned but the caller is not, we should not inline
the callee into the caller, to prevent the default version of the callee
from being inlined into a not versioned caller.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_can_inline_p): Refuse to inline
when callee is versioned but caller is not.
Jakub Jelinek [Thu, 31 Oct 2024 09:52:56 +0000 (10:52 +0100)]
expand: Fix up expansion of VIEW_CONVERT_EXPR to BITINT_TYPE [PR117354]
The following testcase ICEs, because when trying to expand the
VIEW_CONVERT_EXPR operand which is SSA_NAME defined to
V32QI or V4DI MEM_REF which is aligned just to 8 bytes we force
it as unaligned into a register, but then try to call extract_bit_field
from the V32QI or V4DI register to BLKmode. extract_bit_field doesn't
obviously support BLKmode extraction and so ICEs.
The second hunk fixes the ICE by not calling extract_bit_field when
it can't handle it, the last if will handle it properly by storing
it to memory and using BLKmode access to the copy.
The first hunk is an optimization, if mode is BLKmode, by setting
inner_reference_p argument to expand_expr_real we avoid the
expand_misaligned_mem_ref calls which load it from memory into a register.
2024-10-31 Jakub Jelinek <jakub@redhat.com>
PR middle-end/117354
* expr.cc (expand_expr_real_1) <case VIEW_CONVERT_EXPR>: Pass
true as inner_reference_p argument to expand_expr_real if
mode is BLKmode. Don't call extract_bit_field if mode is BLKmode.
Yangyu Chen [Thu, 31 Oct 2024 08:31:24 +0000 (16:31 +0800)]
RISC-V: allow -fno-plt to disable PLT
Currently, the RISC-V target uses the target specific mplt option to
control PLT generation. This patch deprecates the target specific mplt
option and uses the common fplt option instead. This allows users to
use the same option for most targets.
Paul Thomas [Thu, 31 Oct 2024 07:22:36 +0000 (07:22 +0000)]
Fortran: Fix problem with substring selectors in ASSOCIATE [PR115700]
2024-10-31 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/115700
* resolve.cc (resolve_variable): The typespec of an expression,
which is not a substring, can be shared with a deferred length
associate name.
(resolve_assoc_var): Extract a substring reference with non-
constant start or end. Use it to flag up the need for array
associate name to be a pointer.
(resolve_block_construct): Change comment from past to future
tense.
gcc/testsuite/
PR fortran/115700
* gfortran.dg/associate_70.f90: New test.
Sam James [Thu, 31 Oct 2024 01:37:47 +0000 (01:37 +0000)]
testsuite: fix syntax in Wstringop-overflow-59.c
Fix quoting issues, escaping, and dg directive types.
There were two issues here:
1) The incorrect quoting in an earlier dg-message was covering up that the
syntax in the next part was wrong;
2) Fix dg-warning -> dg-message to correctly pick up the notes. Once 1) was
fixed, this was exposed.
With this, I get:
```
+PASS: gcc.dg/Wstringop-overflow-59.c note (test for warnings, line 192)
+PASS: gcc.dg/Wstringop-overflow-59.c note (test for warnings, line 193)
```
Andrew Pinski [Tue, 29 Oct 2024 21:43:42 +0000 (14:43 -0700)]
gimple: Remove special handling of COND_EXPR for COMPARISON_CLASS_P [PR116949, PR114785]
After r13-707-g68e0063397ba82, COND_EXPR for gimple assign no longer could contain a comparison.
The vectorizer was builting gimple assigns with comparison until r15-4695-gd17e672ce82e69
(which added an assert to make sure it no longer builds it).
So let's remove the special handling COND_EXPR in a few places and add an assert to
gimple_build_assign_1 to make sure we don't build a gimple assign any more with a comparison.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR middle-end/114785
PR middle-end/116949
* gimple-match-exports.cc (maybe_push_res_to_seq): Remove special
handling of COMPARISON_CLASS_P in COND_EXPR/VEC_COND_EXPR.
(gimple_extract): Likewise.
* gimple-walk.cc (walk_stmt_load_store_addr_ops): Likewise.
* gimple.cc (gimple_build_assign_1): Add assert for COND_EXPR
so its 1st operand is not a comparison.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
projects / thirdparty / gcc.git / log
