Re: [wwwdocs][Patch] gcc-15: mention wider offloading arch combination support (e.g. aarch64 + nvptx)
On Fri, 20 Sep 2024, Tobias Burnus wrote: > This is supposed to document that GCC now supports offloading, > e.g., from an ARM CPU to a Nvidia GPU (i.e. Grace<->Hopper) > or, e.g., x86-64 to RISC-V. → https://gcc.gnu.org/PR96265 > and https://gcc.gnu.org/PR111937 for the associated PRs. > > I think it is important enough to get it into the release notes. Agreed. > However, I am not sure about the wording. > > Thoughts or suggestions? Looks good to me, with one minor nit: + + +For offloading, issues preventing some host-device architecture +combinations have been resolved. In particular, offloading from an +aarch64 host to a nvptx device is now supported. + + The way "nvptx" is pronounced from what I can tell, this should be "...an nvptx device...". (And maybe note what kind of "offloading" at the beginning of the first sentence, if there is a good term for that?) Gerald
Re: [Fortran, Patch, PR117347, v2] Fix array constructor not resolved in associate
Hi all, pushed as gcc-15-6292-g9684e70952a. Thanks for the review. - Andre On Mon, 16 Dec 2024 19:15:12 +0100 Harald Anlauf wrote: > Hi Andre, > > Am 16.12.24 um 15:26 schrieb Andre Vehreschild: > > Hi Harald, > > > > thanks for finding the bug so quickly. I took another look and came up with > > the attached trivially looking patch, which replaces the old version 1 > > entirely. > > > > The new v2 version of the patch just makes use of existing code guessing the > > type of the associate variable, which once I found it worked surprisingly > > well. I have also extended the testcase. > > this patch is really obvious and does work, too! > > > Regtests ok on x86_64-pc-linux-gnu. Ok for mainline? > > Clearly OK for mainline. And since it is so simple, also for > backporting if you are inclined to do so. (14 is certainly fine). > > Thanks for the patch! > > Harald > > > Regards, > > Andre > > > > On Fri, 13 Dec 2024 14:09:25 +0100 > > Harald Anlauf wrote: > > > >> Hi Andre, > >> > >> while the patch works with the reduced testcase, it runs into the > >> newly added gcc_assert() when trying the original testcase in the PR. > >> > >> I also wonder if this use of gcc_assert() is a good idea or good style: > >> > >> + gcc_assert (gfc_resolve_expr (tgt_expr)); > >> > >> Since gcc_assert is a macro, and its precise definition depends on > >> configuration and could possibly be defined to be a no-op, I suggest > >> to evaluate arguments with side-effects outside and pass the > >> return code to gcc_assert. (There are also many other ways to handle > >> this situation. > >> > >> Then removing the gcc_assert around the gfc_resolve_expr() avoids > >> the ICE, but restores the reported error. > >> > >> So not OK yet. Sorry! > >> > >> Thanks, > >> Harald > >> > >> > >> Am 13.12.24 um 10:10 schrieb Andre Vehreschild: > >>> Hi all, > >>> > >>> attached patch fixes an reject-valid of an array constructor in an > >>> associate by resolving the array constructor before parsing the > >>> associate-block. I am not 100% sure, if that is the right place to do > >>> this. But given, that there is already a special casing before the patch, > >>> I just propose to do the resolve there. > >>> > >>> Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline ? > >>> > >>> Regards, > >>> Andre > >>> -- > >>> Andre Vehreschild * Email: vehre ad gmx dot de > >> > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH 2/5] LoongArch: Add bit reverse operations
On Tue, 2024-12-17 at 12:52 +0800, Lulu Cheng wrote: > > 在 2024/12/17 下午12:30, Xi Ruoyao 写道: > > On Tue, 2024-12-17 at 11:27 +0800, Lulu Cheng wrote: > > > 在 2024/12/16 下午9:20, Xi Ruoyao 写道: > > > /* snip */ > > > > +;; For HImode it's a little complicated... > > > > +(define_expand "rbithi" > > > I didn't find rtithi's template description. Are there any test cases > > > ? > > No, it's not a standard name. I just used the same name as AArch64. > > And due to PR50481 is unimplemented yet, there's no way to directly test > > it :(. > > Bitreverse is a standard operation. if "define_expand "rbithi"" > implementated using > > bitreverse, will it trigger optimization in some cases? > > If so, can we add an operation here? Quote from "Defining RTL Sequences for Code Generation" in GCC internal: [For define_expand] the RTL template is not used for matching, only for generating the initial insn list. If the preparation statement always invokes ‘DONE’ or ‘FAIL’, the RTL template may be reduced to a simple list of operands ... So adding a template containing bitreverse:HI here will be useless. If we want to translate bitreverse:HI to bitreverse:X and shift, we'll need to make a define_insn_and_split, but it'll still be useless: currently there's nothing emitting bitreverse:HI (otherwise it'd immediately trigger an ICE because of an unrecognizable insn). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH v2 1/2] aarch64: Use standard names for saturating arithmetic
Hi Akram,
> On 14 Nov 2024, at 16:53, Akram Ahmad wrote:
>
> This renames the existing {s,u}q{add,sub} instructions to use the
> standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
> IFN_SAT_SUB.
>
> The NEON intrinsics for saturating arithmetic and their corresponding
> builtins are changed to use these standard names too.
>
> Using the standard names for the instructions causes 32 and 64-bit
> unsigned scalar saturating arithmetic to use the NEON instructions,
> resulting in an additional (and inefficient) FMOV to be generated when
> the original operands are in GP registers. This patch therefore also
> restores the original behaviour of using the adds/subs instructions
> in this circumstance.
>
> Furthermore, this patch introduces a new optimisation for signed 32
> and 64-bit scalar saturating arithmetic which uses adds/subs in place
> of the NEON instruction.
>
> Addition, before:
> fmov d0, x0
> fmov d1, x1
> sqadd d0, d0, d1
> fmov x0, d0
>
> Addition, after:
> asr x2, x1, 63
> adds x0, x0, x1
> eor x2, x2, 0x8000
> csinv x0, x0, x2, vc
>
> In the above example, subtraction replaces the adds with subs and the
> csinv with csel. The 32-bit case follows the same approach. Arithmetic
> with a constant operand is simplified further by directly storing the
> saturating limit in the temporary register, resulting in only three
> instructions being used. It is important to note that this only works
> when early-ra is disabled due to an early-ra bug which erroneously
> assigns FP registers to the operands; if early-ra is enabled, then the
> original behaviour (NEON instruction) occurs.
>
> Additional tests are written for the scalar and Adv. SIMD cases to
> ensure that the correct instructions are used. The NEON intrinsics are
> already tested elsewhere. The signed scalar case is also tested with
> an execution test to check the results.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.cc: Expand iterators.
> * config/aarch64/aarch64-simd-builtins.def: Use standard names
> * config/aarch64/aarch64-simd.md: Use standard names, split insn
> definitions on signedness of operator and type of operands.
> * config/aarch64/arm_neon.h: Use standard builtin names.
> * config/aarch64/iterators.md: Add VSDQ_I_QI_HI iterator to
> simplify splitting of insn for scalar arithmetic.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect.inc:
> Template file for unsigned vector saturating arithmetic tests.
> * gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_1.c:
> 8-bit vector type tests.
> * gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_2.c:
> 16-bit vector type tests.
> * gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_3.c:
> 32-bit vector type tests.
> * gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_4.c:
> 64-bit vector type tests.
> * gcc.target/aarch64/saturating_arithmetic.inc: Template file
> for scalar saturating arithmetic tests.
> * gcc.target/aarch64/saturating_arithmetic_1.c: 8-bit tests.
> * gcc.target/aarch64/saturating_arithmetic_2.c: 16-bit tests.
> * gcc.target/aarch64/saturating_arithmetic_3.c: 32-bit tests.
> * gcc.target/aarch64/saturating_arithmetic_4.c: 64-bit tests.
> * gcc.target/aarch64/saturating_arithmetic_signed.c: Signed tests.
> ---
> gcc/config/aarch64/aarch64-builtins.cc| 13 +
> gcc/config/aarch64/aarch64-simd-builtins.def | 8 +-
> gcc/config/aarch64/aarch64-simd.md| 209 ++-
> gcc/config/aarch64/arm_neon.h | 96 +++
> gcc/config/aarch64/iterators.md | 4 +
> .../saturating_arithmetic_autovect.inc| 58 +
> .../saturating_arithmetic_autovect_1.c| 79 ++
> .../saturating_arithmetic_autovect_2.c| 79 ++
> .../saturating_arithmetic_autovect_3.c| 75 ++
> .../saturating_arithmetic_autovect_4.c| 77 ++
> .../aarch64/saturating-arithmetic-signed.c| 244 ++
> .../aarch64/saturating_arithmetic.inc | 39 +++
> .../aarch64/saturating_arithmetic_1.c | 36 +++
> .../aarch64/saturating_arithmetic_2.c | 36 +++
> .../aarch64/saturating_arithmetic_3.c | 30 +++
> .../aarch64/saturating_arithmetic_4.c | 30 +++
> 16 files changed, 1057 insertions(+), 56 deletions(-)
> create mode 100644
> gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect.inc
> create mode 100644
> gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_1.c
> create mode 100644
> gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_2.c
> create mode 100644
> gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_3.c
> create mode 100644
> gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_4.c
> create mode 100644
> gcc/testsu
[PATCH] RISC-V: Disallow negative step for interleaving [PR117682].
Hi,
in PR117682 we build an interleaving pattern
{ 1, 201, 209, 25, 161, 105, 113, 185, 65, 9,
17, 89, 225, 169, 177, 249, 129, 73, 81, 153,
33, 233, 241, 57, 193, 137, 145, 217, 97, 41,
49, 121 };
with negative step expecting wraparound semantics due to -fwrapv.
For building interleaved patterns we have an optimization that
does e.g.
{1, 209, ...} = { 1, 0, 209, 0, ...}
and
{201, 25, ...} >> 8 = { 0, 201, 0, 25, ...}
and IORs those.
The optimization only works if the lowpart bits are zero. When
overflowing e.g. with a negative step we cannot guarantee this.
This patch makes us fall back to the generic merge handling for negative
steps.
I'm not 100% certain we're good even for positive steps. If the
step or the vector length is large enough we'd still overflow and
have non-zero lower bits. I haven't seen this happen during my
testing, though and the patch doesn't make things worse, so...
Regtested on rv64gcv_zvl512b. Let's see what the CI says.
Regards
Robin
PR target/117682
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Fall back to
merging if either step is negative.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117682.c: New test.
---
gcc/config/riscv/riscv-v.cc | 11 +--
.../gcc.target/riscv/rvv/autovec/pr117682.c | 15 +++
2 files changed, 24 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117682.c
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index b0de4c52b83..93888c4fac0 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -1478,13 +1478,20 @@ expand_const_vector (rtx target, rtx src)
can be interpreted into:
- EEW = 32, { 2, 4, ... } */
+ EEW = 32, { 2, 4, ... }.
+
+This only works as long as the larger type does not overflow
+as we can't guarantee a zero value for each second element
+of the sequence with smaller EEW.
+??? For now we assume that no overflow happens with positive
+steps and forbid negative steps altogether. */
unsigned int new_smode_bitsize = builder.inner_bits_size () * 2;
scalar_int_mode new_smode;
machine_mode new_mode;
poly_uint64 new_nunits
= exact_div (GET_MODE_NUNITS (builder.mode ()), 2);
- if (int_mode_for_size (new_smode_bitsize, 0).exists (&new_smode)
+ if (known_ge (step1, 0) && known_ge (step2, 0)
+ && int_mode_for_size (new_smode_bitsize, 0).exists (&new_smode)
&& get_vector_mode (new_smode, new_nunits).exists (&new_mode))
{
rtx tmp1 = gen_reg_rtx (new_mode);
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117682.c
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117682.c
new file mode 100644
index 000..bbbcfcce626
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117682.c
@@ -0,0 +1,15 @@
+/* { dg-do run } */
+/* { dg-require-effective-target riscv_v } */
+/* { dg-require-effective-target rvv_zvl256b_ok } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=zvl -fwrapv" } */
+
+signed char a = 9;
+int main() {
+ for (char e = 0; e < 20; e++)
+for (char f = 0; f < 7; f++)
+ a *= 57;
+
+ if (a != 41)
+__builtin_abort ();
+}
+
--
2.47.1
Re: [PATCH] c++: modules: Fix 32-bit overflow with 64-bit location_t [PR117970]
On 12/13/24 6:05 PM, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117970
This fixes one place in module.cc that I missed updating for 64-bit
location_t in r15-5616. bootstrap + regtested on x86-64 + aarch64. Also
verified that the regression reported on the PR is fixed on that specific
configuration. OK to push? Thanks!
OK.
-- >8 --
With the move to 64-bit location_t in r15-6016, I missed a spot in module.cc
where a location_t was still being stored in a 32-bit int. Fixed.
The xtreme-header* tests in modules.exp were still passing fine on lots of
architectures that were tested (x86-64, i686, aarch64, sparc, riscv64), but
the PR shows that they were failing in some particular risc-v multilib
configurations. They pass now.
gcc/cp/ChangeLog:
* module.cc (module_state::read_ordinary_maps): Change argument to
line_map_uint_t instead of unsigned int.
---
gcc/cp/module.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index c3800b0f125..f2a4fb16c07 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -3823,7 +3823,7 @@ class GTY((chain_next ("%h.parent"), for_user))
module_state {
void write_ordinary_maps (elf_out *to, range_t &,
bool, unsigned *crc_ptr);
- bool read_ordinary_maps (unsigned, unsigned);
+ bool read_ordinary_maps (line_map_uint_t, unsigned);
void write_macro_maps (elf_out *to, range_t &, unsigned *crc_ptr);
bool read_macro_maps (line_map_uint_t);
@@ -17093,7 +17093,8 @@ module_state::write_macro_maps (elf_out *to, range_t &info, unsigned *crc_p)
}
bool
-module_state::read_ordinary_maps (unsigned num_ord_locs, unsigned range_bits)
+module_state::read_ordinary_maps (line_map_uint_t num_ord_locs,
+ unsigned range_bits)
{
bytes_in sec;
[PATCH 2/2] c++: optimize constraint subsumption [PR118069]
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Since atomic constraints are interned the subsumption machinery can
safely use pointer instead of structural hashing for them. This speeds
up compilation of the testcase in the PR from ~3s to ~2s.
PR c++/118069
gcc/cp/ChangeLog:
* constraint.cc (atom_hasher): Define here, instead of ...
* cp-tree.h (atom_hasher): ... here.
* logic.cc (clause::m_set): Use pointer instead of structural
hashing.
---
gcc/cp/constraint.cc | 21 +
gcc/cp/cp-tree.h | 21 -
gcc/cp/logic.cc | 2 +-
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 2af1bbc016b..c75982d8009 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -512,6 +512,27 @@ normalize_concept_check (tree check, tree args, norm_info
info)
return norm;
}
+/* A structural hasher for ATOMIC_CONSTRs. */
+
+struct atom_hasher : default_hash_traits
+{
+ static hashval_t hash (tree t)
+ {
+++comparing_specializations;
+hashval_t val = hash_atomic_constraint (t);
+--comparing_specializations;
+return val;
+ }
+
+ static bool equal (tree t1, tree t2)
+ {
+++comparing_specializations;
+bool eq = atomic_constraints_identical_p (t1, t2);
+--comparing_specializations;
+return eq;
+ }
+};
+
/* Used by normalize_atom to cache ATOMIC_CONSTRs. */
static GTY((deletable)) hash_table *atom_cache;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index c5e0fc5c440..53b47b63a2e 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -8712,27 +8712,6 @@ extern void diagnose_constraints
(location_t, tree, tree);
extern void note_failed_type_completion_for_satisfaction (tree);
-/* A structural hasher for ATOMIC_CONSTRs. */
-
-struct atom_hasher : default_hash_traits
-{
- static hashval_t hash (tree t)
- {
-++comparing_specializations;
-hashval_t val = hash_atomic_constraint (t);
---comparing_specializations;
-return val;
- }
-
- static bool equal (tree t1, tree t2)
- {
-++comparing_specializations;
-bool eq = atomic_constraints_identical_p (t1, t2);
---comparing_specializations;
-return eq;
- }
-};
-
/* in logic.cc */
extern bool subsumes(tree, tree);
diff --git a/gcc/cp/logic.cc b/gcc/cp/logic.cc
index e46ea0ebb78..6ee67713ae0 100644
--- a/gcc/cp/logic.cc
+++ b/gcc/cp/logic.cc
@@ -203,7 +203,7 @@ struct clause
}
std::list m_terms; /* The list of terms. */
- hash_set m_set; /* The set of atomic constraints.
*/
+ hash_set m_set; /* The set of atomic constraints. */
iterator m_current; /* The current term. */
};
--
2.48.0.rc0
[PATCH 1/2] c++: subsumption of complex constraints [PR118069]
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk? Shall we also backport this to release branches?
It's not a regression but seems like a safe fix for an inconvenient
issue.
-- >8 --
For the testcase in the PR we hang during constraint normalization
ultimately because one of the constraints is complex enough that its
conjunctive normal form is calculated to have more than 2^31 clauses,
which causes the size calculation (through an int) to overflow and so
the optimization in subsumes_constraints_nonnull
if (dnf_size (lhs) <= cnf_size (rhs))
// iterate over DNF of LHS
else
// iterate over CNF of RHS
incorrectly decides to loop over the CNF (billions of clauses) instead
of the DNF (thousands of clauses).
I haven't verified that the result of cnf_size is correct for the
problematic constraint but integer overflow is definitely plausible
given that CNF/DNF can be exponentially larger than the original
constraint in the worst case.
This patch fixes this by using a 64-bit unsigned int during DNF/CNF size
calculation which is enough to avoid overflow in the testcase, and we now
compile it in ~3 seconds.
In theory doubling the precision will only let us handle a ~2x bigger
constraint before risking overflow in the worst case given the
exponential-ness, but I suppose it should suffice for now.
PR c++/118069
gcc/cp/ChangeLog:
* logic.cc (dnf_size_r): Use unsigned HOST_WIDE_INT instead of int.
(cnf_size_r): Likewise.
(dnf_size): Likewise.
(cnf_size): Likewise.
---
gcc/cp/logic.cc | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/gcc/cp/logic.cc b/gcc/cp/logic.cc
index fab2c357dc4..e46ea0ebb78 100644
--- a/gcc/cp/logic.cc
+++ b/gcc/cp/logic.cc
@@ -349,7 +349,7 @@ atomic_p (tree t)
distributing. In general, a conjunction for which this flag is set
is considered a disjunction for the purpose of counting. */
-static std::pair
+static std::pair
dnf_size_r (tree t)
{
if (atomic_p (t))
@@ -360,9 +360,9 @@ dnf_size_r (tree t)
the results. */
tree lhs = TREE_OPERAND (t, 0);
tree rhs = TREE_OPERAND (t, 1);
- std::pair p1 = dnf_size_r (lhs);
- std::pair p2 = dnf_size_r (rhs);
- int n1 = p1.first, n2 = p2.first;
+ auto p1 = dnf_size_r (lhs);
+ auto p2 = dnf_size_r (rhs);
+ unsigned HOST_WIDE_INT n1 = p1.first, n2 = p2.first;
bool d1 = p1.second, d2 = p2.second;
if (disjunction_p (t))
@@ -457,7 +457,7 @@ dnf_size_r (tree t)
distributing. In general, a disjunction for which this flag is set
is considered a conjunction for the purpose of counting. */
-static std::pair
+static std::pair
cnf_size_r (tree t)
{
if (atomic_p (t))
@@ -468,9 +468,9 @@ cnf_size_r (tree t)
the results. */
tree lhs = TREE_OPERAND (t, 0);
tree rhs = TREE_OPERAND (t, 1);
- std::pair p1 = cnf_size_r (lhs);
- std::pair p2 = cnf_size_r (rhs);
- int n1 = p1.first, n2 = p2.first;
+ auto p1 = cnf_size_r (lhs);
+ auto p2 = cnf_size_r (rhs);
+ unsigned HOST_WIDE_INT n1 = p1.first, n2 = p2.first;
bool d1 = p1.second, d2 = p2.second;
if (disjunction_p (t))
@@ -560,10 +560,10 @@ cnf_size_r (tree t)
/* Count the number conjunctive clauses that would be created
when rewriting T to DNF. */
-static int
+static unsigned HOST_WIDE_INT
dnf_size (tree t)
{
- std::pair result = dnf_size_r (t);
+ auto result = dnf_size_r (t);
return result.first == 0 ? 1 : result.first;
}
@@ -571,10 +571,10 @@ dnf_size (tree t)
/* Count the number disjunctive clauses that would be created
when rewriting T to CNF. */
-static int
+static unsigned HOST_WIDE_INT
cnf_size (tree t)
{
- std::pair result = cnf_size_r (t);
+ auto result = cnf_size_r (t);
return result.first == 0 ? 1 : result.first;
}
--
2.48.0.rc0
Re: [PATCH] c++: ICE initializing array of aggrs [PR117985]
On 12/16/24 6:48 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
-- >8 --
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times. Let's
say we are initializing an array of A. Then we might end up in
a scenario similar to initlist-eh1.C:
try
{
call A::A in a loop
// #0
try
{
call a fn using the array
}
finally
{
// #1
call A::~A in a loop
}
}
catch
{
// #2
call A::~A in a loop
}
cleanup_flags makes us emit a statement like
D.3048 = 2;
at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.
But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value. Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.
PR c++/117985
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Clear CLEANUP_FLAGS if we're not
generating the loop.
truncate seems dangerous, there might be other things in cleanup_flags
that we want to leave alone. I think it would be safer to assert that
the last element in the vec is iterator, and then pop it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array23.C: New test.
* g++.dg/cpp0x/initlist-array24.C: New test.
---
gcc/cp/init.cc| 4 +++
gcc/testsuite/g++.dg/cpp0x/initlist-array23.C | 28 +++
gcc/testsuite/g++.dg/cpp0x/initlist-array24.C | 27 ++
3 files changed, 59 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index ae516407c92..5dcb24ef735 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -5109,6 +5109,10 @@ build_vec_init (tree base, tree maxindex, tree init,
{
if (!saw_non_const)
{
+ /* If we're not generating the loop, we don't need to reset the
+iterator. */
+ if (cleanup_flags)
+ vec_safe_truncate (*cleanup_flags, 0);
tree const_init = build_constructor (atype, const_vec);
return build2 (INIT_EXPR, atype, obase, const_init);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
new file mode 100644
index 000..cda2afb9fcc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
@@ -0,0 +1,28 @@
+// PR c++/117985
+// { dg-do compile { target c++11 } }
+
+struct _Vector_impl {
+ constexpr
+_Vector_impl() {}
+};
+struct _Vector_base {
+ ~_Vector_base();
+ _Vector_impl _M_impl;
+};
+struct vector : private _Vector_base {};
+struct string {
+ string();
+};
+struct VEC {
+ vector pane{};
+};
+struct FOO {
+ VEC screen[1]{};
+ string debug_name;
+};
+
+int
+main ()
+{
+ FOO{};
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
new file mode 100644
index 000..7dda00d5c0b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
@@ -0,0 +1,27 @@
+// PR c++/117985
+// { dg-do compile { target c++20 } }
+
+struct _Vector_impl {
+ constexpr _Vector_impl() {}
+};
+struct _Vector_base {
+ constexpr ~_Vector_base() {}
+ _Vector_impl _M_impl;
+};
+struct vector : private _Vector_base {};
+struct string {
+ string();
+};
+struct VEC {
+ vector pane{};
+};
+struct FOO {
+ VEC screen[1]{};
+ string debug_name;
+};
+
+int
+main ()
+{
+ FOO{};
+}
base-commit: 56f1863ade1bf416e09da305615ecb2ae04602a8
Re: The COBOL front end, in 8 notes + toplevel patch
On Tue, Dec 17, 2024 at 10:25:48AM +0100, Matthias Klose wrote: > On 17.12.24 00:58, Joseph Myers wrote: > > On Mon, 16 Dec 2024, Matthias Klose wrote: > > > > > On 14.12.24 15:38, Matthias Klose wrote: > > > > I tried to use the patches to build binary packages for Debian. Found > > > > some > > > > issues: > > > > > > tried to build libgcobol on more architectures, please find the attached > > > patch > > > to disable building libgcobol on some architectures. > > > > Enabling on x86_64-*-linux* and disabling on i?86-*-linux* is inherently > > suspect since the difference between those is only about what the default > > multilib is, and says nothing about the multilib used for a particular > > compilation of libgcobol. (Of course we first need to fix multilib > > support for libgcobol if that isn't working correctly - all target > > libraries in GCC need proper multilib support.) > > > > why is this suspect? looking at libtsan and libhwasan, these are only built > for the 64bit variant, not for 32 and x32. Even in that case it isn't decided based on the triplet but on whether it is lp64 or not: x86_64-*-linux* | i?86-*-linux*) if test x$ac_cv_sizeof_void_p = x8; then TSAN_SUPPORTED=yes etc. Though, it should be limited to lp64 only if there is a strong reason for that... Jakub
Re: [PATCH] testsuite: arm: Mark pr81812.C as xfail for thumb1
On 10/11/2024 19:25, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Test fails for Cortex-M0 with:
>
> .../pr81812.C:6:8: error: generic thunk code fails for method 'virtual void
> ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const' which uses '...'
>
> According to PR108277, it's expected that thumb1 targets does not
> support empty virtual functions with ellipsis.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/torture/pr81812.C: Add xfail for thumb1.
>
> Signed-off-by: Torbjörn SVENSSON
> ---
> gcc/testsuite/g++.dg/torture/pr81812.C | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/g++.dg/torture/pr81812.C
> b/gcc/testsuite/g++.dg/torture/pr81812.C
> index d235e237588..b5c621d2beb 100644
> --- a/gcc/testsuite/g++.dg/torture/pr81812.C
> +++ b/gcc/testsuite/g++.dg/torture/pr81812.C
> @@ -1,3 +1,5 @@
> +// { dg-xfail-if "PR108277" { arm_thumb1 } }
> +
> struct Error {
>virtual void error(... ) const;
> };
OK. There's no reason that I can see why this can't be fixed. It just needs
somebody to write (and test) the code :)
R.
Re: [PATCH] noncontiguous ifcombine: skip marking of non-SSA_NAMEs [PR117915]
Alexandre Oliva writes:
> When ifcombine_mark_ssa_name is called directly, rather than by
> ifcombine_mark_ssa_name_walk, we need to check that name is an
> SSA_NAME at the caller or in the function itself. For convenience and
> safety, I'm moving the checks from _walk to the implementation proper.
>
> Regstrapped on x86_64-linux-gnu and on ppc64-linux-gnu, along with 3
> other ifcombine patches. Ok to install?
>
>
> for gcc/ChangeLog
>
> PR tree-optimization/117915
> * tree-ssa-ifcombine.cc (ifcombine_mark_ssa_name): Move
> preconditions from...
> (ifcombine_mark_ssa_name_walk): ... here.
>
> for gcc/testsuite/ChangeLog
>
> PR tree-optimization/117915
> * gcc.dg/pr117915.c: New.
> ---
> gcc/testsuite/gcc.dg/pr117915.c |9 +
> gcc/tree-ssa-ifcombine.cc |5 ++---
> 2 files changed, 11 insertions(+), 3 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/pr117915.c
>
> diff --git a/gcc/testsuite/gcc.dg/pr117915.c b/gcc/testsuite/gcc.dg/pr117915.c
> new file mode 100644
> index 0..4029a20068e9d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr117915.c
> @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -fno-tree-copy-prop -fno-tree-vrp" */
Missing closing '}'.
Ping^7 [PATCH 0/2] Prime path coverage to gcc/gcov
Ping.
On 12/2/24 11:49, Jørgen Kvalsvik wrote:
Ping.
On 11/21/24 20:14, Jørgen Kvalsvik wrote:
Ping.
On 11/12/24 09:56, Jørgen Kvalsvik wrote:
Ping.
On 10/30/24 13:55, Jørgen Kvalsvik wrote:
Ping.
On 10/21/24 15:21, Jørgen Kvalsvik wrote:
Ping.
On 10/10/24 10:08, Jørgen Kvalsvik wrote:
Ping.
On 10/3/24 12:46, Jørgen Kvalsvik wrote:
This is both a ping and a minor update. A few of the patches from
the
previous set have been merged, but the big feature still needs
review.
Since then it has been quiet, but there are two notable changes:
1. The --prime-paths-{lines,source} flags take an optional
argument to
print covered or uncovered paths, or both. By default, uncovered
paths are printed like before.
2. Fixed a bad vector access when independent functions share
compiler
generated statements. A reproducing case is in gcov-23.C which
relied on printing the uncovered path of multiple destructors of
static objects.
Jørgen Kvalsvik (2):
gcov: branch, conds, calls in function summaries
Add prime path coverage to gcc/gcov
gcc/Makefile.in | 6 +-
gcc/builtins.cc | 2 +-
gcc/collect2.cc | 5 +-
gcc/common.opt | 16 +
gcc/doc/gcov.texi | 184 +++
gcc/doc/invoke.texi | 36 +
gcc/gcc.cc | 4 +-
gcc/gcov-counter.def | 3 +
gcc/gcov-io.h | 3 +
gcc/gcov.cc | 531 ++-
gcc/ipa-inline.cc | 2 +-
gcc/passes.cc | 4 +-
gcc/path-coverage.cc | 782 +
gcc/prime-paths.cc | 2031 +
+ + +
gcc/profile.cc | 6 +-
gcc/selftest-run-tests.cc | 1 +
gcc/selftest.h | 1 +
gcc/testsuite/g++.dg/gcov/gcov-22.C | 170 ++
gcc/testsuite/g++.dg/gcov/gcov-23-1.h | 9 +
gcc/testsuite/g++.dg/gcov/gcov-23-2.h | 9 +
gcc/testsuite/g++.dg/gcov/gcov-23.C | 30 +
gcc/testsuite/gcc.misc-tests/gcov-29.c | 869 ++
gcc/testsuite/gcc.misc-tests/gcov-30.c | 869 ++
gcc/testsuite/gcc.misc-tests/gcov-31.c | 35 +
gcc/testsuite/gcc.misc-tests/gcov-32.c | 24 +
gcc/testsuite/gcc.misc-tests/gcov-33.c | 27 +
gcc/testsuite/gcc.misc-tests/gcov-34.c | 29 +
gcc/testsuite/lib/gcov.exp | 118 +-
gcc/tree-profile.cc | 11 +-
29 files changed, 5795 insertions(+), 22 deletions(-)
create mode 100644 gcc/path-coverage.cc
create mode 100644 gcc/prime-paths.cc
create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-22.C
create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23-1.h
create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23-2.h
create mode 100644 gcc/testsuite/g++.dg/gcov/gcov-23.C
create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-29.c
create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-30.c
create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-31.c
create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-32.c
create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-33.c
create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-34.c
[Patch, fortran] PR117897 - [13/14 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)
Hi All,
This bug was so obviously in defiance of the standard that I pushed it to
mainline as r15-6260. I meant to post this message immediately but was
distracted before I could press send. I will be backporting today.
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 3718b0e645b..44a50c0edb1 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -12596,13 +12596,20 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
&& (expr2->ts.type == BT_CLASS || gfc_may_be_finalized (expr2->ts)))
{
expr2->must_finalize = 1;
+ /* F2023 7.5.6.3: If an executable construct references a nonpointer
+ function, the result is finalized after execution of the innermost
+ executable construct containing the reference. */
+ if (expr2->expr_type == EXPR_FUNCTION
+ && (gfc_expr_attr (expr2).pointer
+ || (expr2->ts.type == BT_CLASS && CLASS_DATA (expr2)->attr.class_pointer)))
+ expr2->must_finalize = 0;
/* F2008 4.5.6.3 para 5: If an executable construct references a
structure constructor or array constructor, the entity created by
the constructor is finalized after execution of the innermost
executable construct containing the reference.
These finalizations were later deleted by the Combined Techical
Corrigenda 1 TO 4 for fortran 2008 (f08/0011). */
- if (gfc_notification_std (GFC_STD_F2018_DEL)
+ else if (gfc_notification_std (GFC_STD_F2018_DEL)
&& (expr2->expr_type == EXPR_STRUCTURE
|| expr2->expr_type == EXPR_ARRAY))
expr2->must_finalize = 0;
Re: [wwwdocs][Patch] gcc-15: mention wider offloading arch combination support (e.g. aarch64 + nvptx)
On 17/12/2024 08:01, Gerald Pfeifer wrote: > On Fri, 20 Sep 2024, Tobias Burnus wrote: >> This is supposed to document that GCC now supports offloading, >> e.g., from an ARM CPU to a Nvidia GPU (i.e. Grace<->Hopper) >> or, e.g., x86-64 to RISC-V. → https://gcc.gnu.org/PR96265 >> and https://gcc.gnu.org/PR111937 for the associated PRs. >> >> I think it is important enough to get it into the release notes. > > Agreed. > >> However, I am not sure about the wording. >> >> Thoughts or suggestions? > > Looks good to me, with one minor nit: > > + > + > +For offloading, issues preventing some host-device architecture > +combinations have been resolved. In particular, offloading from an > +aarch64 host to a nvptx device is now supported. > + > + > > The way "nvptx" is pronounced from what I can tell, this should be > "...an nvptx device...". Or avoid the issue entirely by using the plural form "... offloading from aarch64 hosts to nvptx devices ..." > > (And maybe note what kind of "offloading" at the beginning of the first > sentence, if there is a good term for that?) > > Gerald R.
Re: [PATCH] testsuite: arm: Add -mtune to all arm_cpu_* effective targets
On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
> https://linaro.atlassian.net/browse/GNU-1463.
>
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp: Added corresponding -mtune= option
> for each fo the arm_cpu_* effective targets.
>
Please can you add to the comment before this table:
# NOTE: -mcpu does not override -mtune, so to ensure the tuning is consistent
# for tests using these flags all entries should set -mcpu and -mtune explicitly
OK with that change.
R.
> Signed-off-by: Torbjörn SVENSSON
> ---
> gcc/testsuite/lib/target-supports.exp | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index fe2970e024b..34a9b4d3816 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -5958,18 +5958,18 @@ foreach { armfunc armflag armdefs } {
> # This table should only be used to set -mcpu= (and associated
> # flags). See above for setting -march=.
> foreach { armfunc armflag armdefs } {
> - xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" "__XSCALE__ &&
> !__thumb__"
> - cortex_a57 "-mcpu=cortex-a57" __ARM_ARCH_8A__
> - cortex_m0 "-mcpu=cortex-m0 -mfloat-abi=soft -mthumb"
> "__ARM_ARCH_6M__ && __thumb__"
> - cortex_m0_small "-mcpu=cortex-m0.small-multiply -mfloat-abi=soft
> -mthumb" "__ARM_ARCH_6M__ && __thumb__"
> - cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply
> -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
> - cortex_m1_small "-mcpu=cortex-m1.small-multiply -mfloat-abi=soft
> -mthumb" "__ARM_ARCH_6M__ && __thumb__"
> - cortex_m3 "-mcpu=cortex-m3 -mfloat-abi=soft -mthumb"
> "__ARM_ARCH_7M__"
> - cortex_m4 "-mcpu=cortex-m4 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
> - cortex_m4_hard "-mcpu=cortex-m4 -mfpu=auto -mfloat-abi=hard
> -mthumb" "__ARM_ARCH_7EM__"
> - cortex_m7 "-mcpu=cortex-m7 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
> - cortex_m23 "-mcpu=cortex-m23 -mfloat-abi=soft -mthumb"
> "__ARM_ARCH_8M_BASE__ && __thumb__"
> - cortex_m55 "-mcpu=cortex-m55 -mfpu=auto -mthumb"
> "__ARM_ARCH_8M_MAIN__ && __thumb__"
> + xscale_arm "-mcpu=xscale -mtune=xscale -mfloat-abi=soft -marm"
> "__XSCALE__ && !__thumb__"
> + cortex_a57 "-mcpu=cortex-a57 -mtune=cortex-a57" __ARM_ARCH_8A__
> + cortex_m0 "-mcpu=cortex-m0 -mtune=cortex-m0 -mfloat-abi=soft
> -mthumb" "__ARM_ARCH_6M__ && __thumb__"
> + cortex_m0_small "-mcpu=cortex-m0.small-multiply
> -mtune=cortex-m0.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ &&
> __thumb__"
> + cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply
> -mtune=cortex-m0plus.small-multiply -mfloat-abi=soft -mthumb"
> "__ARM_ARCH_6M__ && __thumb__"
> + cortex_m1_small "-mcpu=cortex-m1.small-multiply
> -mtune=cortex-m1.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ &&
> __thumb__"
> + cortex_m3 "-mcpu=cortex-m3 -mtune=cortex-m3 -mfloat-abi=soft
> -mthumb" "__ARM_ARCH_7M__"
> + cortex_m4 "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto -mthumb"
> "__ARM_ARCH_7EM__"
> + cortex_m4_hard "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto
> -mfloat-abi=hard -mthumb" "__ARM_ARCH_7EM__"
> + cortex_m7 "-mcpu=cortex-m7 -mtune=cortex-m7 -mfpu=auto -mthumb"
> "__ARM_ARCH_7EM__"
> + cortex_m23 "-mcpu=cortex-m23 -mtune=cortex-m23 -mfloat-abi=soft
> -mthumb" "__ARM_ARCH_8M_BASE__ && __thumb__"
> + cortex_m55 "-mcpu=cortex-m55 -mtune=cortex-m55 -mfpu=auto -mthumb"
> "__ARM_ARCH_8M_MAIN__ && __thumb__"
> } {
> eval [string map [list FUNC $armfunc FLAG $armflag DEFS $armdefs ] {
> proc check_effective_target_arm_cpu_FUNC_ok { } {
Re: [PATCH 3/8] ipa: Skip type conversions in jump function constructions
Hi, On Tue, Dec 03 2024, Richard Biener wrote: > On Tue, Dec 3, 2024 at 12:09 PM Martin Jambor wrote: >> On Fri, Nov 15 2024, Richard Biener wrote: >> > On Fri, Nov 15, 2024 at 1:45 PM Jan Hubicka wrote: >> >> > >> >> > The patch only ever skips just one conversion, never a chain of them and >> [ 12 more citation lines. Click/Enter to show. ] >> >> > deliberately so, for the reasons shown in the example. >> >> > >> >> > However, I have just realized that combining pass_through jump functions >> >> > during inlining may unfortunately have exactly the same effect, so we >> >> > indeed need to be more careful. >> >> >> >> Ah, right. I was thinking if I can trigger someting like this and this >> >> option did not came to my mind. >> >> > >> >> > The motivating example converts a bool (integer with precision one) to >> >> > an int, so what about the patch below which allows converting between >> >> > integers and to a higher precision? (Assuming the patch will pass >> >> > bootstrap and testing on x86_64-linux which is underway). >> >> >> >> Allowing only conversion that monotonously increase precision looks. >> >> As in "looks better?" Or perhaps even "looks good?" >> >> >> Perhaps Richi may have opinion here. >> >> In a way this is similar to what we do in gimple_call_builtin that has >> [ 13 more citation lines. Click/Enter to show. ] >> >> some type checking and also allows widening conversions. So perhaps >> >> this can be unified. >> >> >> >> I just noticed that testusite has few examples that, for example, define >> >> >> >> void *calloc (long, long) >> >> >> >> and this makes the test fail since parameter is really unsigned long >> >> and in the turn we disable some calloc optimizations even though this >> >> does not affect code generation. Some passes use >> >> gimple_call_builtin while other look up callee decl by hand. >> > >> > I think all conversions that are not value changing (based on incoming >> > range) >> > are OK. Even signed int with [3, 10] -> unsigned char [3, 10] would be OK. >> > But signed int with [-1, 1] -> unsigned char [0, 1] [ 0xff ] might >> > cause problems. >> >> Right, I was not going to use ranges for this because I suspected that >> more often than not the range would be unknown. But if that's the >> suggestion, would something like the following (only very mildly tested) >> function be OK? >> >> I kept the type check because it looks quite a bit cheaper and would >> work also for conversions between integers with the same precision but >> different signedness which we can safely fold_convert between as well. > > Maybe you can use range_fits_type_p? (aka int_fits_type_p for INTEGER_CSTs) > > What I was saying is that your change looks OK (but it can be possibly > improved > upon). > thanks for the suggestion! range_fits_type_p is indeed a function I can use directly. I am going to commit the following patch which has been pre-approved by Honza and which has passed bootstrap and testing on x86_64 and together with other two patches also on ppc64le-linux and an LTO bootstrap on x86_64-linux. Martin -- 8< -- Originally, we did not stream any formal parameter types into WPA and were generally very conservative when it came to type mismatches in IPA-CP. Over the time, mismatches that happen in code and blew up in WPA made us to be much more resilient and also to stream the types of the parameters which we now use commonly. With that information, we can safely skip conversions when looking at the IL from which we build jump functions and then simply fold convert the constants and ranges to the resulting type, as long as we are careful that performing the corresponding folding of constants gives the corresponding results. In order to do that, we must ensure that the old value can be represented in the new one without any loss. With this change, we can nicely propagate non-NULLness in IPA-VR as demonstrated with the new test case. I have gone through all other uses of (all components of) jump functions which could be affected by this and verified they do indeed check types and can handle mismatches. gcc/ChangeLog: 2024-12-11 Martin Jambor * ipa-prop.cc: Include vr-values.h. (skip_a_safe_conversion_op): New function. (ipa_compute_jump_functions_for_edge): Use it. gcc/testsuite/ChangeLog: 2024-11-01 Martin Jambor * gcc.dg/ipa/vrp9.c: New test. --- gcc/ipa-prop.cc | 40 +++ gcc/testsuite/gcc.dg/ipa/vrp9.c | 48 + 2 files changed, 88 insertions(+) create mode 100644 gcc/testsuite/gcc.dg/ipa/vrp9.c diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc index 3d72794e37c..ae309ec78a2 100644 --- a/gcc/ipa-prop.cc +++ b/gcc/ipa-prop.cc @@ -59,6 +59,7 @@ along with GCC; see the file COPYING3. If not see #include "attr-fnspec.h" #include "gimple-range.h" #include "value-range-storage.h" +#include "vr-values.h" /* Function summary where
Re: [PATCH] RISC-V: Remove svvptc from riscv-ext-bitmask.def
On 12/16/24 10:28 AM, Palmer Dabbelt wrote:
On Mon, 16 Dec 2024 08:37:13 PST (-0800), c...@cyyself.name wrote:
There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace software to know that this
extension exists. So remove it from the riscv-ext-bitmask.def file.
Fixes: e4f4b2dc08 ("RISC-V: Minimal support for svvptc extension.")
Signed-off-by: Yangyu Chen
gcc/ChangeLog:
* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK):
Remove svvptc.
---
gcc/common/config/riscv/riscv-ext-bitmask.def | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/common/config/riscv/riscv-ext-bitmask.def b/gcc/
common/config/riscv/riscv-ext-bitmask.def
index a733533df98..ca5df1740f3 100644
--- a/gcc/common/config/riscv/riscv-ext-bitmask.def
+++ b/gcc/common/config/riscv/riscv-ext-bitmask.def
@@ -79,6 +79,5 @@ RISCV_EXT_BITMASK ("zcd", 1, 4)
RISCV_EXT_BITMASK ("zcf", 1, 5)
RISCV_EXT_BITMASK ("zcmop", 1, 6)
RISCV_EXT_BITMASK ("zawrs", 1, 7)
-RISCV_EXT_BITMASK ("svvptc", 1, 8)
#undef RISCV_EXT_BITMASK
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
I think we'll likely never expose this to userspace, the mappings are
all hidden behind kernel interfaces so userspace shouldn't need to know.
I've pushed this patch to the trunk.
jeff
Re: [PATCH] testsuite: arm: Add -mtune to all arm_cpu_* effective targets
On 2024-12-17 15:41, Richard Earnshaw (lists) wrote:
On 17/12/2024 14:32, Torbjorn SVENSSON wrote:
On 2024-12-17 12:06, Richard Earnshaw (lists) wrote:
On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
https://linaro.atlassian.net/browse/GNU-1463.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Added corresponding -mtune= option
for each fo the arm_cpu_* effective targets.
Please can you add to the comment before this table:
# NOTE: -mcpu does not override -mtune, so to ensure the tuning is consistent
# for tests using these flags all entries should set -mcpu and -mtune explicitly
OK with that change.
Pushed as r15-6302-g423ee61fdd9.
Should I do a similar change for releases/gcc-14?
I'm inclined to say no. We don't have the table of arm_cpu_... there, so the
patch would be very different rather than a simple backport.
Ok!
Thanks for the fast reply.
Kind regards,
Torbjörn
R.
Kind regards,
Torbjörn
R.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/lib/target-supports.exp | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index fe2970e024b..34a9b4d3816 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5958,18 +5958,18 @@ foreach { armfunc armflag armdefs } {
# This table should only be used to set -mcpu= (and associated
# flags). See above for setting -march=.
foreach { armfunc armflag armdefs } {
- xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" "__XSCALE__ &&
!__thumb__"
- cortex_a57 "-mcpu=cortex-a57" __ARM_ARCH_8A__
- cortex_m0 "-mcpu=cortex-m0 -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ &&
__thumb__"
- cortex_m0_small "-mcpu=cortex-m0.small-multiply -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
- cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
- cortex_m1_small "-mcpu=cortex-m1.small-multiply -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
- cortex_m3 "-mcpu=cortex-m3 -mfloat-abi=soft -mthumb" "__ARM_ARCH_7M__"
- cortex_m4 "-mcpu=cortex-m4 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
- cortex_m4_hard "-mcpu=cortex-m4 -mfpu=auto -mfloat-abi=hard -mthumb"
"__ARM_ARCH_7EM__"
- cortex_m7 "-mcpu=cortex-m7 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
- cortex_m23 "-mcpu=cortex-m23 -mfloat-abi=soft -mthumb" "__ARM_ARCH_8M_BASE__
&& __thumb__"
- cortex_m55 "-mcpu=cortex-m55 -mfpu=auto -mthumb" "__ARM_ARCH_8M_MAIN__ &&
__thumb__"
+ xscale_arm "-mcpu=xscale -mtune=xscale -mfloat-abi=soft -marm" "__XSCALE__
&& !__thumb__"
+ cortex_a57 "-mcpu=cortex-a57 -mtune=cortex-a57" __ARM_ARCH_8A__
+ cortex_m0 "-mcpu=cortex-m0 -mtune=cortex-m0 -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
+ cortex_m0_small "-mcpu=cortex-m0.small-multiply -mtune=cortex-m0.small-multiply
-mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
+ cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply -mtune=cortex-m0plus.small-multiply
-mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
+ cortex_m1_small "-mcpu=cortex-m1.small-multiply -mtune=cortex-m1.small-multiply
-mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
+ cortex_m3 "-mcpu=cortex-m3 -mtune=cortex-m3 -mfloat-abi=soft -mthumb"
"__ARM_ARCH_7M__"
+ cortex_m4 "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto -mthumb"
"__ARM_ARCH_7EM__"
+ cortex_m4_hard "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto -mfloat-abi=hard
-mthumb" "__ARM_ARCH_7EM__"
+ cortex_m7 "-mcpu=cortex-m7 -mtune=cortex-m7 -mfpu=auto -mthumb"
"__ARM_ARCH_7EM__"
+ cortex_m23 "-mcpu=cortex-m23 -mtune=cortex-m23 -mfloat-abi=soft -mthumb"
"__ARM_ARCH_8M_BASE__ && __thumb__"
+ cortex_m55 "-mcpu=cortex-m55 -mtune=cortex-m55 -mfpu=auto -mthumb"
"__ARM_ARCH_8M_MAIN__ && __thumb__"
} {
eval [string map [list FUNC $armfunc FLAG $armflag DEFS $armdefs ] {
proc check_effective_target_arm_cpu_FUNC_ok { } {
Re: [PATCH] testsuite: arm: Add -mtune to all arm_cpu_* effective targets
On 17/12/2024 14:32, Torbjorn SVENSSON wrote:
>
>
> On 2024-12-17 12:06, Richard Earnshaw (lists) wrote:
>> On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
>>> Ok for trunk?
>>>
>>> --
>>>
>>> Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
>>> https://linaro.atlassian.net/browse/GNU-1463.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * lib/target-supports.exp: Added corresponding -mtune= option
>>> for each fo the arm_cpu_* effective targets.
>>>
>>
>> Please can you add to the comment before this table:
>>
>> # NOTE: -mcpu does not override -mtune, so to ensure the tuning is consistent
>> # for tests using these flags all entries should set -mcpu and -mtune
>> explicitly
>>
>> OK with that change.
>
> Pushed as r15-6302-g423ee61fdd9.
>
> Should I do a similar change for releases/gcc-14?
I'm inclined to say no. We don't have the table of arm_cpu_... there, so the
patch would be very different rather than a simple backport.
R.
>
> Kind regards,
> Torbjörn
>
>>
>> R.
>>
>>> Signed-off-by: Torbjörn SVENSSON
>>> ---
>>> gcc/testsuite/lib/target-supports.exp | 24
>>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/gcc/testsuite/lib/target-supports.exp
>>> b/gcc/testsuite/lib/target-supports.exp
>>> index fe2970e024b..34a9b4d3816 100644
>>> --- a/gcc/testsuite/lib/target-supports.exp
>>> +++ b/gcc/testsuite/lib/target-supports.exp
>>> @@ -5958,18 +5958,18 @@ foreach { armfunc armflag armdefs } {
>>> # This table should only be used to set -mcpu= (and associated
>>> # flags). See above for setting -march=.
>>> foreach { armfunc armflag armdefs } {
>>> - xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" "__XSCALE__ &&
>>> !__thumb__"
>>> - cortex_a57 "-mcpu=cortex-a57" __ARM_ARCH_8A__
>>> - cortex_m0 "-mcpu=cortex-m0 -mfloat-abi=soft -mthumb"
>>> "__ARM_ARCH_6M__ && __thumb__"
>>> - cortex_m0_small "-mcpu=cortex-m0.small-multiply -mfloat-abi=soft
>>> -mthumb" "__ARM_ARCH_6M__ && __thumb__"
>>> - cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply
>>> -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
>>> - cortex_m1_small "-mcpu=cortex-m1.small-multiply -mfloat-abi=soft
>>> -mthumb" "__ARM_ARCH_6M__ && __thumb__"
>>> - cortex_m3 "-mcpu=cortex-m3 -mfloat-abi=soft -mthumb"
>>> "__ARM_ARCH_7M__"
>>> - cortex_m4 "-mcpu=cortex-m4 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
>>> - cortex_m4_hard "-mcpu=cortex-m4 -mfpu=auto -mfloat-abi=hard
>>> -mthumb" "__ARM_ARCH_7EM__"
>>> - cortex_m7 "-mcpu=cortex-m7 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
>>> - cortex_m23 "-mcpu=cortex-m23 -mfloat-abi=soft -mthumb"
>>> "__ARM_ARCH_8M_BASE__ && __thumb__"
>>> - cortex_m55 "-mcpu=cortex-m55 -mfpu=auto -mthumb"
>>> "__ARM_ARCH_8M_MAIN__ && __thumb__"
>>> + xscale_arm "-mcpu=xscale -mtune=xscale -mfloat-abi=soft -marm"
>>> "__XSCALE__ && !__thumb__"
>>> + cortex_a57 "-mcpu=cortex-a57 -mtune=cortex-a57" __ARM_ARCH_8A__
>>> + cortex_m0 "-mcpu=cortex-m0 -mtune=cortex-m0 -mfloat-abi=soft
>>> -mthumb" "__ARM_ARCH_6M__ && __thumb__"
>>> + cortex_m0_small "-mcpu=cortex-m0.small-multiply
>>> -mtune=cortex-m0.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__
>>> && __thumb__"
>>> + cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply
>>> -mtune=cortex-m0plus.small-multiply -mfloat-abi=soft -mthumb"
>>> "__ARM_ARCH_6M__ && __thumb__"
>>> + cortex_m1_small "-mcpu=cortex-m1.small-multiply
>>> -mtune=cortex-m1.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__
>>> && __thumb__"
>>> + cortex_m3 "-mcpu=cortex-m3 -mtune=cortex-m3 -mfloat-abi=soft
>>> -mthumb" "__ARM_ARCH_7M__"
>>> + cortex_m4 "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto -mthumb"
>>> "__ARM_ARCH_7EM__"
>>> + cortex_m4_hard "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto
>>> -mfloat-abi=hard -mthumb" "__ARM_ARCH_7EM__"
>>> + cortex_m7 "-mcpu=cortex-m7 -mtune=cortex-m7 -mfpu=auto -mthumb"
>>> "__ARM_ARCH_7EM__"
>>> + cortex_m23 "-mcpu=cortex-m23 -mtune=cortex-m23 -mfloat-abi=soft
>>> -mthumb" "__ARM_ARCH_8M_BASE__ && __thumb__"
>>> + cortex_m55 "-mcpu=cortex-m55 -mtune=cortex-m55 -mfpu=auto -mthumb"
>>> "__ARM_ARCH_8M_MAIN__ && __thumb__"
>>> } {
>>> eval [string map [list FUNC $armfunc FLAG $armflag DEFS $armdefs ] {
>>> proc check_effective_target_arm_cpu_FUNC_ok { } {
>>
>
Re: [PATCH] testsuite: arm: Mark pr81812.C as xfail for thumb1
On 2024-12-17 14:33, Richard Earnshaw (lists) wrote:
On 10/11/2024 19:25, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Test fails for Cortex-M0 with:
.../pr81812.C:6:8: error: generic thunk code fails for method 'virtual void
ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const' which uses '...'
According to PR108277, it's expected that thumb1 targets does not
support empty virtual functions with ellipsis.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr81812.C: Add xfail for thumb1.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/g++.dg/torture/pr81812.C | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/g++.dg/torture/pr81812.C
b/gcc/testsuite/g++.dg/torture/pr81812.C
index d235e237588..b5c621d2beb 100644
--- a/gcc/testsuite/g++.dg/torture/pr81812.C
+++ b/gcc/testsuite/g++.dg/torture/pr81812.C
@@ -1,3 +1,5 @@
+// { dg-xfail-if "PR108277" { arm_thumb1 } }
+
struct Error {
virtual void error(... ) const;
};
OK. There's no reason that I can see why this can't be fixed. It just needs
somebody to write (and test) the code :)
Pushed as r15-6305-gf111d8e20b6.
Absolutely, but I don't see it as urgent to implement... ;)
Kind regards,
Torbjörn
R.
Re: [PATCH] RISC-V: optimization on checking certain bits set ((x & mask) == val)
On 12/16/24 8:31 AM, Oliver Kozul wrote: The patch optimizes code generation for comparisons of the form X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1). C1 is a constant that requires li and addi to be loaded, while ~C1 requires a single lui instruction. As the values of C1 and C2 are not visible within the equality expression, a plus pattern is matched instead. 2024-12-16 Oliver Kozul PR target/114087 gcc/ChangeLog: * config/riscv/riscv.md (*lui_constraint_and_to_or): New pattern gcc/testsuite/ChangeLog: * gcc.target/riscv/pr114087-1.c: New test. Thanks! I've pushed this to the trunk. jeff
Re: [PATCH 8/8] ipa: Improve how we derive value ranges from IPA invariants
Hi,
On Tue, Nov 05 2024, Jan Hubicka wrote:
>> Hi,
>>
>> I believe that the current function ipa_range_set_and_normalize lacks
>> a check that a base of an ADDR_EXPR lacks a test whether the base
>> really cannot be NULL, so this patch adds it. Moreover, I never liked
>> the name as I do not think it makes the value of ranges any more
>> normal but rather just special-cases non-zero ip_invariant pointers.
>> Therefore, I have given it a different name and moved it to a .cc
>> file, our LTO bootstrap should inline (and/or split) it if necessary
>> anyway.
>>
>> Bootstrapped and tested on x86_64-linux, the whole patch series has
>> additionally passed LTO and profiled-LTO bootstrap on the same platform
>> and a bootstrap and testsuite on ppc64-linux. Aarch64-linux bootstrap
>> and testing is in progress. OK for master is that passes too?
>>
>> Thanks,
>>
>> Martin
>>
>>
>> gcc/ChangeLog:
>>
>> 2024-11-04 Martin Jambor
>>
>> * ipa-prop.h (ipa_get_range_from_ip_invariant): Declare.
>> (ipa_range_set_and_normalize): Remove.
>> * ipa-prop.cc (ipa_get_range_from_ip_invariant): New function.
>> * ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Use
>> ipa_get_range_from_ip_invariant instead of
>> ipa_range_set_and_normalize.
>> * ipa-fnsummary.cc (evaluate_conditions_for_known_args): Likewise.
>> +/* Given VAL that conforms to is_gimple_ip_invariant, produce a VRANGE that
>> + represents it as a range. */
>> +
>> +void
>> +ipa_get_range_from_ip_invariant (vrange &r, tree val)
>> +{
>> + if (TREE_CODE (val) == ADDR_EXPR)
>> +{
>> + bool strict_overflow = false;
>> + if (tree_single_nonzero_warnv_p (val, &strict_overflow))
> this function uses maybe_nonzero_address that in turn checks
> symtab_node::nonzero_address which uses flag_delete_null_pointer_checks
> to verify that we can assume that defined symbols are non-NULL.
> Now -fdelete-null-pointer-checks is defined in common.opt as
> optimization and thus is stored in TREE_OPTIMIZATION_NODE.
>
> The patch is definitely an improvement. But it seems to me that we need
> to add function argument to tree_single_nonzero_warnv_p and propagate it
> down to symtab_node::nonzero_address so it can query in correct function
> context. This can be done incrementally, so the patch is OK.
>
I was looking for the use of the flag but somehow did not see it and in
some less-than-ideal state of mind assumed it must therefore be a global
option. Below is a patch that takes that into account.
The patch has been pre-approved by Honza and which has passed bootstrap
and testing on x86_64 and together with other two patches also on
ppc64le-linux and an LTO bootstrap on x86_64-linux, so I am going to
push it to master in a few moments.
Thanks,
Martin
-- 8< --
I believe that the current function ipa_range_set_and_normalize lacks
a check that a base of an ADDR_EXPR lacks a test whether the base
really cannot be NULL, so this patch adds it. Moreover, I never liked
the name as I do not think it makes the value of ranges any more
normal but rather just special-cases non-zero ip_invariant pointers.
Therefore, I have given it a different name and moved it to a .cc
file, our LTO bootstrap should inline (and/or split) it if necessary
anyway.
Because, as Honza correctly pointed out, deriving non-NULLness from a
pointer depends on flag_delete_null_pointer_checks which is an
optimization flag and thus depends on a given function, in this
version of the patch ipa_get_range_from_ip_invariant gets a
context_node parameter for that purpose. This then needs to be used
within symtab_node::nonzero_address which gets a special overload in
which the value of the flag can be provided as a parameter.
gcc/ChangeLog:
2024-12-11 Martin Jambor
* cgraph.h (symtab_node): Add a new overload of nonzero_address.
* symtab.cc (symtab_node::nonzero_address): Add a new overload whith a
parameter for delete_null_pointer_checks. Make the original overload
call the new one which has retains the actual implementation.
* ipa-prop.h (ipa_get_range_from_ip_invariant): Declare.
(ipa_range_set_and_normalize): Remove.
* ipa-prop.c (ipa_get_range_from_ip_invariant): New function.
(ipa_range_set_and_normalize): Remove.
* ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Add a new parameter
context_node. Use ipa_get_range_from_ip_invariant instead of
ipa_range_set_and_normalize and pass to it the new parameter.
(ipa_value_range_from_jfunc): Pass cs->caller as the context_node to
ipa_vr_intersect_with_arith_jfunc.
(propagate_vr_across_jump_function): Likewise.
(ipa_get_range_from_ip_invariant): New function.
* ipa-fnsummary.cc (evaluate_conditions_for_known_args): Use
ipa_get_range_from_ip_invariant instead of ipa_range_set_and_normalize
---
gcc/cgraph.h | 4
gcc/ipa-cp.cc| 12 -
Re: [PATCH v2] RISC-V: Fix ICE for unrecognizable insn `UNSPEC_VSETVL` for XTheadVector
> > --- a/gcc/config/riscv/riscv-vector-builtins.cc
> > +++ b/gcc/config/riscv/riscv-vector-builtins.cc
> > @@ -4089,7 +4089,23 @@ function_expander::add_input_operand (unsigned argno)
> > {
> > tree arg = CALL_EXPR_ARG (exp, argno);
> > rtx x = expand_normal (arg);
> > - add_input_operand (TYPE_MODE (TREE_TYPE (arg)), x);
> > +
> > + /* Since the parameter vl of XTheadVector does not support
> > + immediate numbers, we need to put it in the register
> > + in advance. */
> > + if (TARGET_XTHEADVECTOR
> > + && CONST_INT_P (x)
> > + && base->apply_vl_p ()
> > + && argno == (unsigned) (call_expr_nargs (exp) - 1)
> > + && x != CONST0_RTX (GET_MODE (x)))
> > +{
> > + rtx tmp = gen_reg_rtx (word_mode);
> > + /* Use UNSPEC to avoid being optimized before vsetvl pass. */
> > + emit_insn (gen_th_pred_vl_mov (word_mode, tmp, x));
> > + add_input_operand (TYPE_MODE (TREE_TYPE (arg)), tmp);
> > +}
> > + else
> > +add_input_operand (TYPE_MODE (TREE_TYPE (arg)), x);
> > }
> So I would just do:
>
>
> tmp = force_reg (word_mode, x);
> add_input_operand (TYPE_MODE (TREE_TYPE (arg)), tmp);
>
> In the thead specific code. That generates the initial code correctly.
> At that point we just need to make sure nothing like combine, cprop, etc
> propagates the constant into the vsetvl. The way to prevent that is
> with the operand predicates on the vsetvl insns.
>
>
> jeff
Hi, jeff
I missed some information because of the long time.
As I said before, instead of using UNSPEC, In the curr_insn_transform function,
the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128]
A32])
(if_then_else:RVVM8SF (unspec:RVVMF4BI [
(const_vector:RVVMF4BI repeat [
(const_int 1 [0x1])
])
(reg:DI 209)
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(reg/v:RVVM8SF 143 [ _xx ])
(mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128] A32])))
"pr116593.C":14:24 discrim 1 3883 {pred_storervvm8sf}
(expr_list:REG_DEAD (reg/v:RVVM8SF 143 [ _xx ])
(nil)))
to
(insn 69 284 225 11 (set (mem:RVVM8SF (reg/f:DI 18 s2 [orig:218 _77 ] [218]) [0
S[128, 128] A32])
(if_then_else:RVVM8SF (unspec:RVVMF4BI [
(const_vector:RVVMF4BI repeat [
(const_int 1 [0x1])
])
(const_int 1 [0x1])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(reg/v:RVVM8SF 104 v8 [orig:143 _xx ] [143])
(mem:RVVM8SF (reg/f:DI 18 s2 [orig:218 _77 ] [218]) [0 S[128, 128]
A32]))) "pr116593.C":14:24 discrim 1 3883 {pred_storervvm8sf}
(nil))
Looking at the log for the reload pass, it is found that "Changing pseudo 209
in operand 3 of insn 69 on equiv 0x 1".
It converts the vl operand in insn from the expected register(reg:DI 209) to
the constant 1(const_int 1 [0x1]).
This conversion occurs because, although the predicate for the vl operand is
restricted by "vector_length_operand" in the pattern,
the constraint is still "rK", which allows the transformation.
The issue is that changing the "rK" constraint to "rJ" for the constraint of vl
operand in the pattern would prevent this conversion,
But unfortunately this will conflict with RVV (RISC-V Vector Extension).
This is why I initially considered using UNSPEC to address the XTheadVector
problem while minimizing interference with RVV.
I'm not sure if there is a better way, do you have any suggestions?
BR
Jin
Re: [PATCH 0/5] New Asm Constraints and Modifiers - RVC, Raw Encodings, Pairs
On Sun, Dec 15, 2024 at 1:31 AM Jeff Law wrote: > > > > On 12/9/24 1:56 AM, Kito Cheng wrote: > > This patch set implements the proposal from riscv-c-api-doc[1]. > > It adds two constraints and one modifier with the goal of improving the user > > experience for `.insn`, making it easier for users to experiment with new > > ISA > > extensions. > > > > A quick summary of this patch set: > > > > - Add R constraint for even-odd pairs of general-purpose registers. > > - Add cr and cf constraints for RVC-compatible registers. > > - Add N modifier for the raw encoding of a register. > > > > The c constraint and N modifier were already in use before, but only > > internally. > > Therefore, I believe it is safe to rename them for broader use. > > > > [1] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/92 > > > > Kito Cheng (5): > >RISC-V: Rename constraint c0* to k0* > >RISC-V: Add cr and cf constraint > >RISC-V Rename internal operand modifier N to n > >RISC-V: Implment N modifier for printing the register number rather > > than the register name > >RISC-V: Add new constraint R for register even-odd pairs > ps. I think it's pretty unlikely the xtreme-header failures from > pre-commit CI are related to this change. But I'd do a quick check > before committing. Tried two different servers, but couldn't reproduce either, so I pushed to the trunk :) > > jeff > >
Re: [PATCH v2 1/2] RISC-V: Document thead-c906, xiangshan-nanhu, and generic-ooo
On 12/15/24 3:47 PM, Anton Blanchard wrote: gcc/ChangeLog * doc/invoke.texi (RISC-V): Add thead-c906, xiangshan-nanhu to -mcpu, add generic-ooo and remove thead-c906 from -mtune. Signed-off-by: Anton Blanchard Thanks. I've pushed this to the trunk. jeff
Re: [PATCH v2 2/2] RISC-V: Add Tenstorrent Ascalon 8 wide architecture
On 12/15/24 3:47 PM, Anton Blanchard wrote: This adds the Tenstorrent Ascalon 8 wide architecture (tt-ascalon-d8) to the list of known cores. gcc/ChangeLog: * config/riscv/riscv-cores.def: Add tt-ascalon-d8. * config/riscv/riscv.cc (tt_ascalon_d8_tune_info): New. * doc/invoke.texi (RISC-V): Add tt-ascalon-d8 to -mcpu. gcc/testsuite/ChangeLog: * gcc.target/riscv/mcpu-tt-ascalon-d8.c: New test. THanks. I've pushed this to the trunk. Jeff
Re: [PATCH] testsuite: arm: Add -mtune to all arm_cpu_* effective targets
On 2024-12-17 12:06, Richard Earnshaw (lists) wrote:
On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
https://linaro.atlassian.net/browse/GNU-1463.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Added corresponding -mtune= option
for each fo the arm_cpu_* effective targets.
Please can you add to the comment before this table:
# NOTE: -mcpu does not override -mtune, so to ensure the tuning is consistent
# for tests using these flags all entries should set -mcpu and -mtune explicitly
OK with that change.
Pushed as r15-6302-g423ee61fdd9.
Should I do a similar change for releases/gcc-14?
Kind regards,
Torbjörn
R.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/lib/target-supports.exp | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index fe2970e024b..34a9b4d3816 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5958,18 +5958,18 @@ foreach { armfunc armflag armdefs } {
# This table should only be used to set -mcpu= (and associated
# flags). See above for setting -march=.
foreach { armfunc armflag armdefs } {
- xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" "__XSCALE__ &&
!__thumb__"
- cortex_a57 "-mcpu=cortex-a57" __ARM_ARCH_8A__
- cortex_m0 "-mcpu=cortex-m0 -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ &&
__thumb__"
- cortex_m0_small "-mcpu=cortex-m0.small-multiply -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
- cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
- cortex_m1_small "-mcpu=cortex-m1.small-multiply -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
- cortex_m3 "-mcpu=cortex-m3 -mfloat-abi=soft -mthumb"
"__ARM_ARCH_7M__"
- cortex_m4 "-mcpu=cortex-m4 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
- cortex_m4_hard "-mcpu=cortex-m4 -mfpu=auto -mfloat-abi=hard -mthumb"
"__ARM_ARCH_7EM__"
- cortex_m7 "-mcpu=cortex-m7 -mfpu=auto -mthumb" "__ARM_ARCH_7EM__"
- cortex_m23 "-mcpu=cortex-m23 -mfloat-abi=soft -mthumb" "__ARM_ARCH_8M_BASE__
&& __thumb__"
- cortex_m55 "-mcpu=cortex-m55 -mfpu=auto -mthumb" "__ARM_ARCH_8M_MAIN__
&& __thumb__"
+ xscale_arm "-mcpu=xscale -mtune=xscale -mfloat-abi=soft -marm" "__XSCALE__
&& !__thumb__"
+ cortex_a57 "-mcpu=cortex-a57 -mtune=cortex-a57" __ARM_ARCH_8A__
+ cortex_m0 "-mcpu=cortex-m0 -mtune=cortex-m0 -mfloat-abi=soft -mthumb"
"__ARM_ARCH_6M__ && __thumb__"
+ cortex_m0_small "-mcpu=cortex-m0.small-multiply -mtune=cortex-m0.small-multiply
-mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
+ cortex_m0plus_small "-mcpu=cortex-m0plus.small-multiply
-mtune=cortex-m0plus.small-multiply -mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ &&
__thumb__"
+ cortex_m1_small "-mcpu=cortex-m1.small-multiply -mtune=cortex-m1.small-multiply
-mfloat-abi=soft -mthumb" "__ARM_ARCH_6M__ && __thumb__"
+ cortex_m3 "-mcpu=cortex-m3 -mtune=cortex-m3 -mfloat-abi=soft -mthumb"
"__ARM_ARCH_7M__"
+ cortex_m4 "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto -mthumb"
"__ARM_ARCH_7EM__"
+ cortex_m4_hard "-mcpu=cortex-m4 -mtune=cortex-m4 -mfpu=auto -mfloat-abi=hard
-mthumb" "__ARM_ARCH_7EM__"
+ cortex_m7 "-mcpu=cortex-m7 -mtune=cortex-m7 -mfpu=auto -mthumb"
"__ARM_ARCH_7EM__"
+ cortex_m23 "-mcpu=cortex-m23 -mtune=cortex-m23 -mfloat-abi=soft -mthumb"
"__ARM_ARCH_8M_BASE__ && __thumb__"
+ cortex_m55 "-mcpu=cortex-m55 -mtune=cortex-m55 -mfpu=auto -mthumb"
"__ARM_ARCH_8M_MAIN__ && __thumb__"
} {
eval [string map [list FUNC $armfunc FLAG $armflag DEFS $armdefs ] {
proc check_effective_target_arm_cpu_FUNC_ok { } {
Re: The COBOL front end, in 8 notes + toplevel patch
On 17.12.24 00:58, Joseph Myers wrote: On Mon, 16 Dec 2024, Matthias Klose wrote: On 14.12.24 15:38, Matthias Klose wrote: I tried to use the patches to build binary packages for Debian. Found some issues: tried to build libgcobol on more architectures, please find the attached patch to disable building libgcobol on some architectures. Enabling on x86_64-*-linux* and disabling on i?86-*-linux* is inherently suspect since the difference between those is only about what the default multilib is, and says nothing about the multilib used for a particular compilation of libgcobol. (Of course we first need to fix multilib support for libgcobol if that isn't working correctly - all target libraries in GCC need proper multilib support.) why is this suspect? looking at libtsan and libhwasan, these are only built for the 64bit variant, not for 32 and x32. Matthias
[PATCH] middle-end/118062 - bogus lowering of vector compares
The generic expand_vector_piecewise routine supports lowering of a vector operation to vector operations of smaller size. When computing the extract position from the larger vector it uses the element size in bits of the original result vector to determine the number of elements in the smaller vector. That is wrong when lowering a compare as the vector element size of a bool vector does not have to agree with that of the compare operand. The following simplifies this, fixing the error. Bootstrap and regtest running on x86_64-unknown-linux-gnu. PR middle-end/118062 * tree-vect-generic.cc (expand_vector_piecewise): Properly compute delta. --- gcc/tree-vect-generic.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc index 78f6e552cc7..4b9cf734bdd 100644 --- a/gcc/tree-vect-generic.cc +++ b/gcc/tree-vect-generic.cc @@ -292,7 +292,8 @@ expand_vector_piecewise (gimple_stmt_iterator *gsi, elem_op_func f, tree part_width = TYPE_SIZE (inner_type); tree index = bitsize_int (0); int nunits = nunits_for_known_piecewise_op (type); - int delta = tree_to_uhwi (part_width) / vector_element_bits (type); + int delta = (VECTOR_TYPE_P (inner_type) + ? nunits_for_known_piecewise_op (inner_type) : 1); int i; location_t loc = gimple_location (gsi_stmt (*gsi)); -- 2.43.0
Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args
Hi all, hello PA,
Tobias Burnus wrote:
Paul-Antoine Arras wrote:
See the revised patch attached and my comments below.
I have not looked in depth at the patch, but managed to
write C-ism code, which caused a segfault (due to a missing "call"),
Additional comments: Can you hoist the condition out of the loop in:
+ for (gfc_omp_namelist *n = *head; n != NULL; n = n->next) + if
(need_device_ptr_p) + n->u.need_device_ptr = true;
* * *
I was about to complain that it didn't handle VALUE + OPTIONAL
correctly, but that's a generic gfortran bug (or two):
->https://gcc.gnu.org/PR118080
* * *
There is a bug - 'nowait' is not propagated. Trying:
!$omp dispatch depend(inout:x) nowait
call g(a)
!$omp end dispatch
gives (-fdump-tree-gimple): #pragma omp taskwait depend(inout:&x) nowait
but doing the equivalent !$omp dispatch depend(inout:x) call g(a) !$omp
end dispatch nowait gives: #pragma omp taskwait depend(inout:&x) i.e.
the 'nowait' got lost. * * *
Similar the original C code, which to my knowledge is now
fixed + tested for, there is an issue related to handling nested
function calls.
I think the attached testcase is fine, but it segfaults unless
the default device is the initial device. The problem is that
the pointer conversion also happens for the inner function but
it should only do so for the outer one.
See attached testcase. – I think it can be seen by looking at the
dump (and adding an -fdump-tree-gimple + scan test probably won't
harm, as not everyone has a GPU and we might implement map as
selfmap on APUs).
Otherwise LGTM.
Tobias
module m
use omp_lib
use iso_c_binding
implicit none(type,external)
contains
integer function f(x, y1, y2, z1, z2)
allocatable :: f
integer, value :: x
type(c_ptr), value :: y1, y2
type(c_ptr) :: z1, z2
if (x == 1) then ! HOST
block
integer, pointer :: iy1, iy2, iz1, iz2
call c_f_pointer (y1, iy1)
call c_f_pointer (y2, iy2)
call c_f_pointer (z1, iz1)
call c_f_pointer (z2, iz2)
f = (iy1 + iy2) + 10 * (iz1+iz2)
end block
else
!$omp target is_device_ptr(y1, y2, z1, z2) map(from: f)
block
integer, pointer :: iy1, iy2, iz1, iz2
call c_f_pointer (y1, iy1)
call c_f_pointer (y2, iy2)
call c_f_pointer (z1, iz1)
call c_f_pointer (z2, iz2)
f = -(iy1+iy2)*23 -127 * (iz1+iz2) - x * 3
end block
end if
end
integer function g(x, y1, y2, z1, z2)
!$omp declare variant(f) match(construct={dispatch}) adjust_args(need_device_ptr : y1, y2, z1, z2)
allocatable :: g
integer, value :: x
type(c_ptr), value :: y1, y2
type(c_ptr) :: z1, z2
g = x
end
end
program main
use m
implicit none (type, external)
integer, target :: v1, v2
integer :: res, ref
v1 = 5
v2 = 11
ref = 5*2 + 10 * 11*2
ref = -(5*2)*23 -127 * (11*2) - ref * 3
!$omp target data map(v1,v2)
res = func (c_loc(v1), c_loc(v1), c_loc(v2), c_loc(v2))
!$omp end target data
if (res /= ref) stop 1
contains
integer function func(x1, x2, x3, x4)
use m
implicit none(type,external)
type(c_ptr) :: x1, x2, x3, x4
value :: x1, x3
!$omp dispatch
func = g(g(1,x1,x2,x3,x4), x1,x2,x3,x4)
end
end
[PATCH] ifcombine field merge: stricten loads tests, swap compare to match
ACATS-4 ca11d02 exposed an error in the logic for recognizing and
identifying the inner object in decode_field_ref: a view-converting
load, inserted in a previous successful field merging operation, was
recognized by gimple_convert_def_p within decode_field_reference, and
as a result we took its operand as the expression, and failed to take
note of the load location.
Without that load, we couldn't compare vuses, and then we ended up
inserting a wider load before relevant parts of the object were
initialized.
This patch makes gimple_convert_def_p recognize loads only when
requested, and requires that either both or neither parts of a
potentially merged operand have associated loads.
As a bonus, it enables additional optimizations by swapping the
operands of the second compare when that makes left-hand operands
of both compares match.
Regstrapped on x86_64-linux-gnu and on ppc64-linux-gnu, along with 3
other ifcombine patches. Ok to install?
for gcc/ChangeLog
* gimple-fold.cc (gimple_convert_def_p): Reject load stmts
unless requested.
(decode_field_reference): Accept a converting load at the last
conversion matcher, subsuming the load identification.
(fold_truth_andor_for_ifcombine): Refuse to merge operands
when only one of them has an associated load stmt. Swap
operands of one of the compares if that helps them match.
for gcc/testsuite/ChangeLog
* gcc.dg/field-merge-13.c: New.
---
gcc/gimple-fold.cc| 93 -
gcc/testsuite/gcc.dg/field-merge-13.c | 93 +
2 files changed, 162 insertions(+), 24 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/field-merge-13.c
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 6c11654a2c65b..92f02ddd77408 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -7440,26 +7440,42 @@ maybe_fold_comparisons_from_match_pd (tree type, enum
tree_code code,
}
/* Return TRUE and set op[0] if T, following all SSA edges, is a type
- conversion. */
+ conversion. Reject loads if LOAD is NULL, otherwise set *LOAD if a
+ converting load is found. */
static bool
-gimple_convert_def_p (tree t, tree op[1])
+gimple_convert_def_p (tree t, tree op[1], gimple **load = NULL)
{
+ bool ret = false;
+
if (TREE_CODE (t) == SSA_NAME
&& !SSA_NAME_IS_DEFAULT_DEF (t))
if (gassign *def = dyn_cast (SSA_NAME_DEF_STMT (t)))
- switch (gimple_assign_rhs_code (def))
- {
- CASE_CONVERT:
- op[0] = gimple_assign_rhs1 (def);
- return true;
- case VIEW_CONVERT_EXPR:
- op[0] = TREE_OPERAND (gimple_assign_rhs1 (def), 0);
- return true;
- default:
- break;
- }
- return false;
+ {
+ bool load_p = gimple_assign_load_p (def);
+ if (load_p && !load)
+ return false;
+ switch (gimple_assign_rhs_code (def))
+ {
+ CASE_CONVERT:
+ op[0] = gimple_assign_rhs1 (def);
+ ret = true;
+ break;
+
+ case VIEW_CONVERT_EXPR:
+ op[0] = TREE_OPERAND (gimple_assign_rhs1 (def), 0);
+ ret = true;
+ break;
+
+ default:
+ break;
+ }
+
+ if (ret && load_p)
+ *load = def;
+ }
+
+ return ret;
}
/* Return TRUE and set op[*] if T, following all SSA edges, resolves to a
@@ -7604,19 +7620,23 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
return NULL_TREE;
}
- /* Yet another chance to drop conversions. */
- if (gimple_convert_def_p (exp, res_ops))
+ /* Yet another chance to drop conversions. This one is allowed to
+ match a converting load, subsuming the load identification block
+ below. */
+ if (gimple_convert_def_p (exp, res_ops, load))
{
if (!outer_type)
{
outer_type = TREE_TYPE (exp);
loc[0] = gimple_location (SSA_NAME_DEF_STMT (exp));
}
+ if (*load)
+ loc[3] = gimple_location (*load);
exp = res_ops[0];
}
/* Identify the load, if there is one. */
- if (TREE_CODE (exp) == SSA_NAME
+ if (!(*load) && TREE_CODE (exp) == SSA_NAME
&& !SSA_NAME_IS_DEFAULT_DEF (exp))
{
gimple *def = SSA_NAME_DEF_STMT (exp);
@@ -8056,13 +8076,37 @@ fold_truth_andor_for_ifcombine (enum tree_code code,
tree truth_type,
/* It must be true that the inner operation on the lhs of each
comparison must be the same if we are to be able to do anything.
Then see if we have constants. If not, the same must be true for
- the rhs's. */
+ the rhs's. If one is a load and the other isn't, we have to be
+ conservative and avoid the optimization, otherwise we could get
+ SRAed fields wrong. */
if (volatilep
|| ll_reversep != rl_reversep
- || ll_inner == 0 || rl_inner == 0
- || ! operand_equal_p (ll_inner, rl_inner, 0)
- || (ll_load && rl_lo
[PATCH] ifcombine field merge: do not follow a second conversion [PR118046]
The testcase shows that conversions that would impact negatively the
ifcombine field merging implementation won't always have been
optimized out by the time we reach ifcombine.
There's probably room to support multiple conversions with extra
logic, but this workaround should avoid codegen errors until that
logic is figured out.
Regstrapped on x86_64-linux-gnu and on ppc64-linux-gnu, along with 3
other ifcombine patches. Ok to install?
for gcc/ChangeLog
PR tree-optimization/118046
* gimple-fold.cc (decode_field_reference): Don't follow more
than one conversion.
for gcc/testsuite/ChangeLog
PR tree-optimization/118046
* gcc.dg/field-merge-14.c: New.
---
gcc/gimple-fold.cc| 27 +--
gcc/testsuite/gcc.dg/field-merge-14.c | 26 ++
2 files changed, 35 insertions(+), 18 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/field-merge-14.c
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 92f02ddd77408..06913d57f8aec 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -7554,13 +7554,10 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
narrowing then widening casts, or vice-versa, for those that are not
essential for the compare have already been optimized out at this
point. */
- if (gimple_convert_def_p (exp, res_ops))
+ if (!outer_type && gimple_convert_def_p (exp, res_ops))
{
- if (!outer_type)
- {
- outer_type = TREE_TYPE (exp);
- loc[0] = gimple_location (SSA_NAME_DEF_STMT (exp));
- }
+ outer_type = TREE_TYPE (exp);
+ loc[0] = gimple_location (SSA_NAME_DEF_STMT (exp));
exp = res_ops[0];
}
@@ -7597,13 +7594,10 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
}
/* Another chance to drop conversions. */
- if (gimple_convert_def_p (exp, res_ops))
+ if (!outer_type && gimple_convert_def_p (exp, res_ops))
{
- if (!outer_type)
- {
- outer_type = TREE_TYPE (exp);
- loc[0] = gimple_location (SSA_NAME_DEF_STMT (exp));
- }
+ outer_type = TREE_TYPE (exp);
+ loc[0] = gimple_location (SSA_NAME_DEF_STMT (exp));
exp = res_ops[0];
}
@@ -7623,13 +7617,10 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
/* Yet another chance to drop conversions. This one is allowed to
match a converting load, subsuming the load identification block
below. */
- if (gimple_convert_def_p (exp, res_ops, load))
+ if (!outer_type && gimple_convert_def_p (exp, res_ops, load))
{
- if (!outer_type)
- {
- outer_type = TREE_TYPE (exp);
- loc[0] = gimple_location (SSA_NAME_DEF_STMT (exp));
- }
+ outer_type = TREE_TYPE (exp);
+ loc[0] = gimple_location (SSA_NAME_DEF_STMT (exp));
if (*load)
loc[3] = gimple_location (*load);
exp = res_ops[0];
diff --git a/gcc/testsuite/gcc.dg/field-merge-14.c
b/gcc/testsuite/gcc.dg/field-merge-14.c
new file mode 100644
index 0..91d84cfebf196
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/field-merge-14.c
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* { dg-options "-O -fdump-tree-ifcombine-details" } */
+
+/* Check that we don't get confused by multiple conversions. */
+
+__attribute__((noipa))
+int f(int *a,int *d)
+{
+ signed char b = *a;
+ int c = b;
+ *d = c; // This store is important even if otherwise unused
+ if (c < 0 && (b&1))
+return 1;
+ return 0;
+}
+
+int main()
+{
+ unsigned char t = 0x81;
+ int x = t, y;
+ int tt = f(&x, &y);
+ if (!tt)
+__builtin_abort();
+}
+
+/* { dg-final { scan-tree-dump-not "optimizing" "ifcombine" } } */
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] ifcombine field merge: adjust testcases [PR118025]
There was a thinko in the testcase field-merge-9.c: I overcorrected it
for big-endian.
As a bonus, I'm including stdbool.h in field-merge-12.c, because I
used bool without the header there.
Regstrapped on x86_64-linux-gnu and on ppc64-linux-gnu, along with 3
other ifcombine patches. Barring objections, I'm going to put this one
in as obvious.
for gcc/testsuite/ChangeLog
PR testsuite/118025
* field-merge-9.c (q): Drop overcorrection for big-endian.
* field-merge-12.c: Include stdbool.h.
---
gcc/testsuite/gcc.dg/field-merge-12.c |2 ++
gcc/testsuite/gcc.dg/field-merge-9.c |4 +---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/field-merge-12.c
b/gcc/testsuite/gcc.dg/field-merge-12.c
index 7056eb607e904..2c1e71ef69235 100644
--- a/gcc/testsuite/gcc.dg/field-merge-12.c
+++ b/gcc/testsuite/gcc.dg/field-merge-12.c
@@ -4,6 +4,8 @@
/* Check that we don't crash when trying to handle masks that don't match the
width of the original type. */
+#include
+
struct s {
long long q;
};
diff --git a/gcc/testsuite/gcc.dg/field-merge-9.c
b/gcc/testsuite/gcc.dg/field-merge-9.c
index b9e08d8fa37d2..04df54c2b74ef 100644
--- a/gcc/testsuite/gcc.dg/field-merge-9.c
+++ b/gcc/testsuite/gcc.dg/field-merge-9.c
@@ -17,9 +17,7 @@ struct s2 {
static const char le = __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ ? 1 : 0;
struct s1 p = { { -!le , -le }, 42 };
-struct s2 q = { (le
-? -2 << (__CHAR_BIT__ - 1)
-: -1 & ((1 << (__CHAR_BIT__ - 1) << 1) - 1)), 42 };
+struct s2 q = { -2 << (__CHAR_BIT__ - 1), 42 };
void f (void) {
if (0
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[PATCH] noncontiguous ifcombine: skip marking of non-SSA_NAMEs [PR117915]
When ifcombine_mark_ssa_name is called directly, rather than by
ifcombine_mark_ssa_name_walk, we need to check that name is an
SSA_NAME at the caller or in the function itself. For convenience and
safety, I'm moving the checks from _walk to the implementation proper.
Regstrapped on x86_64-linux-gnu and on ppc64-linux-gnu, along with 3
other ifcombine patches. Ok to install?
for gcc/ChangeLog
PR tree-optimization/117915
* tree-ssa-ifcombine.cc (ifcombine_mark_ssa_name): Move
preconditions from...
(ifcombine_mark_ssa_name_walk): ... here.
for gcc/testsuite/ChangeLog
PR tree-optimization/117915
* gcc.dg/pr117915.c: New.
---
gcc/testsuite/gcc.dg/pr117915.c |9 +
gcc/tree-ssa-ifcombine.cc |5 ++---
2 files changed, 11 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr117915.c
diff --git a/gcc/testsuite/gcc.dg/pr117915.c b/gcc/testsuite/gcc.dg/pr117915.c
new file mode 100644
index 0..4029a20068e9d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr117915.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-tree-copy-prop -fno-tree-vrp" */
+
+unsigned a;
+int b, c;
+int main() {
+ a = a & b || (c || b) | a;
+ return 0;
+}
diff --git a/gcc/tree-ssa-ifcombine.cc b/gcc/tree-ssa-ifcombine.cc
index de8db2be5572a..02c2f5a29b561 100644
--- a/gcc/tree-ssa-ifcombine.cc
+++ b/gcc/tree-ssa-ifcombine.cc
@@ -475,7 +475,7 @@ update_profile_after_ifcombine (basic_block inner_cond_bb,
static void
ifcombine_mark_ssa_name (bitmap used, tree name, basic_block outer)
{
- if (SSA_NAME_IS_DEFAULT_DEF (name))
+ if (!name || TREE_CODE (name) != SSA_NAME || SSA_NAME_IS_DEFAULT_DEF (name))
return;
gimple *def = SSA_NAME_DEF_STMT (name);
@@ -502,8 +502,7 @@ ifcombine_mark_ssa_name_walk (tree *t, int *, void *data_)
{
ifcombine_mark_ssa_name_t *data = (ifcombine_mark_ssa_name_t *)data_;
- if (*t && TREE_CODE (*t) == SSA_NAME)
-ifcombine_mark_ssa_name (data->used, *t, data->outer);
+ ifcombine_mark_ssa_name (data->used, *t, data->outer);
return NULL;
}
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH 4/8] ipa: Better value ranges for zero pointer constants
On Fri, Nov 15 2024, Martin Jambor wrote:
> Hi,
>
> On Thu, Nov 07 2024, Aldy Hernandez wrote:
>> Jan Hubicka writes:
>>
> 2024-11-01 Martin Jambor
>
> * ipa-prop.cc (ipa_compute_jump_functions_for_edge): When
> creating
> value-range jump functions from pointer type constant zero, do so
> as if it was not a pointer.
> ---
> gcc/ipa-prop.cc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
> index 9bd2e4bc60c..012f8a32386 100644
> --- a/gcc/ipa-prop.cc
> +++ b/gcc/ipa-prop.cc
> @@ -2368,7 +2368,8 @@ ipa_compute_jump_functions_for_edge (struct
> ipa_func_body_info *fbi,
> }
>
>value_range vr (TREE_TYPE (arg));
> - if (POINTER_TYPE_P (TREE_TYPE (arg)))
> + if (POINTER_TYPE_P (TREE_TYPE (arg))
> + && !zerop (arg))
integer_zerop (arg) - I also think this deserves a comment.
>
> thanks for the pointer, I was not aware of that function. But given
> Honza's and Aldi's feedback, I may take a different path.
>
>>>
>>> Comment would indeed be nice. It is not clear to me why special
>>> handling is needed here and ranger does not give the same or better
>>> value range than one we compute based on alignment+offset and non-zero
>>> ness?
>>
>> Yeah, this doesn't smell right. Martin, could you look at what's going on?
>
> If you quickly glance at the code it is not surprising. The pointer
> handling code looks if it knows that the argument is non-zero, and
> depending on that either starts with a (freshly initialized) non_zero or
> varying value_range. Afterwards, it proceeds to attempt to imbue it
> with alignment info. That is, the code does not try to store the result
> of the get_range_query into the jump function, it is simply interested
> in the non-NULLness.
>
> I thought that was intentional but given Aldy's reaction perhaps it
> wasn't, so I decided to be bolder and rework the code a bit. Please see
> an alternative patch below.
>
>>
>>>
>>> The code was needed since we did not have value ranges for pointer typed
>>> SSA names, but do we still need to special case them these days?
>>
>> Note that the prange implementation doesn't do anything extra we weren't
>> already doing with irange for pointers. And the original code didn't
>> update ranges or value/mask pairs based on alignment, so you probably
>> still have to keep doing whatever alignment magic you were doing.
>
> I also work with the assumption that the extra code is necessary but my
> understanding of ranger and its capabilities is limited.
>
> Below is the new patch which has also passed bootstrap and testing on
> x86_64-linux on its own and along with the verifier patch.
The patch has been approved by Honza and so I pushed it as 1eb41aeb49a
after re-testing it.
Thanks,
Martin
>
> Martin
>
> -- 8< 8< 8< --
>
> When looking into cases where we know an actual argument of a call is
> a constant but we don't generate a singleton value-range for the jump
> function, I found out that the special handling of pointer constants
> does not work well for constant zero pointer values. In fact the code
> only attempts to see if it can figure out that an argument is not zero
> and if it can figure out any alignment information.
>
> With this patch, we try to use the value_range that ranger can give us
> in the jump function if we can and we query ranger for all kinds of
> arguments, not just SSA_NAMES (and so also pointer integer constants).
> If we cannot figure out a useful range we fall back again on figuring
> out non-NULLness with tree_single_nonzero_warnv_p.
>
> With this patch, we generate
>
> [prange] struct S * [0, 0] MASK 0x0 VALUE 0x0
>
> instead of for example:
>
> [prange] struct S * [0, +INF] MASK 0xfff0 VALUE 0x0
>
> for a zero constant passed in a call.
>
> If you are wondering why we check whether the value range obtained
> from range_of_expr can be undefined, even when the function returns
> true, that is because that can apparently happen for default-definition
> SSA_NAMEs.
>
> gcc/ChangeLog:
>
> 2024-11-15 Martin Jambor
>
> * ipa-prop.cc (ipa_compute_jump_functions_for_edge): Try harder to
> use the value range obtained from ranger for pointer values.
> ---
> gcc/ipa-prop.cc | 35 ---
> 1 file changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
> index fd0d9b7c15c..50ec8e0cf28 100644
> --- a/gcc/ipa-prop.cc
> +++ b/gcc/ipa-prop.cc
> @@ -2382,28 +2382,27 @@ ipa_compute_jump_functions_for_edge (struct
> ipa_func_body_info *fbi,
>value_range vr (TREE_TYPE (arg));
>if (POINTER_TYPE_P (TREE_TYPE (arg)))
> {
> - bool addr_nonzero = false;
> - bool strict_overflow = false;
> -
> - if (TREE_CODE
Re: [PATCH] testsuite: arm: Prune incremental link warning
On 15/11/2024 10:15, Christophe Lyon wrote:
> On Thu, 14 Nov 2024 at 18:33, Torbjorn SVENSSON
> wrote:
>>
>>
>>
>> On 2024-11-14 16:53, Christophe Lyon wrote:
>>> On Sun, 10 Nov 2024 at 17:44, Torbjörn SVENSSON
>>> wrote:
Ok for trunk and releases/gcc-14?
--
When the feature "needs_status_wrapper" in dejagnu is used, the
resulting gcc_tg.o file is a regular object file and thus the following
warning will be emitted if doing an incremental link:
.../ld: warning: incremental linking of LTO and non-LTO objects; using
which will bypass whole program optimization
Since the warning causes test cases, like pr61123-enum-size, to fail,
prune it.
>>>
>>> This makes sense. Just to be sure that -flinker-output=nolto-rel does
>>> not avoid the problem described in PR61123,
>>> any chance you could try revering SVN r211832 (well just remove "LTO"
>>> from short-enums entry in c.opt) and see the original bug with the
>>> warning (pruned)?
>>
>> If I build r15-5047-g7e1d9f58858 with the following change (I obviously
>> have my patch applied when testing it...):
>>
>> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
>> index 9b9f5e744f6..80d934b516d 100644
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -2277,7 +2277,7 @@ C++ ObjC++ Optimization Var(flag_rtti) Init(1)
>> Generate run time type descriptor information.
>>
>> fshort-enums
>> -C ObjC C++ ObjC++ LTO Optimization Var(flag_short_enums)
>> +C ObjC C++ ObjC++ Optimization Var(flag_short_enums)
>> Use the narrowest integer type possible for enumeration types.
>>
>> fshort-wchar
>>
>>
>>
>> For Cortex-A7, Cortex-M0/3/4/7/33/55/85, I get the following failure:
>>
>> FAIL: object-readelf Tag_ABI_enum_size size is incorrect.
>>
>> I suppose this is what you wanted to get confirmed, right?
>>
>> We could, instead of pruning, add the -flonker-output=nolto-rel, but
>> that fails to link as there is no main function etc.
>>
>> I'm not sure that this answers you question, so if it's not what you had
>> in mind, please let me know. :)
>>
>
> Yes exactly: I wanted to make sure that we'd still have caught the
> original bug even when using the status_wrapper (and that
> -flinker-output=nolto-rel didn't have the side effect of hiding the
> bug).
>
> Thanks for the clarification.
I wonder if we could address this by building the wrapper as a fat LTO object.
It would then be compatible with both LTO and non-LTO compilations.
We could experiment with this by setting [target_info wrap_compile_flags] to
return "-flto -ffat-lto-objects".
R.
>
> Christophe
>
>>
>> Kind regards,
>> Torbjörn
>>
>>>
>>> Thanks,
>>>
>>> Christophe
>>>
gcc/testsuite/ChangeLog:
* gcc.target/arm/lto/lto.exp: Prune incremental link warning if
status wrapper is used.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target/arm/lto/lto.exp | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/testsuite/gcc.target/arm/lto/lto.exp
b/gcc/testsuite/gcc.target/arm/lto/lto.exp
index 4ccb0737253..3f8377bdd3e 100644
--- a/gcc/testsuite/gcc.target/arm/lto/lto.exp
+++ b/gcc/testsuite/gcc.target/arm/lto/lto.exp
@@ -43,6 +43,14 @@ if { ![check_effective_target_lto] } {
return
}
+# This variable should only apply to tests called in this exp file.
+global dg_runtest_extra_prunes
+set dg_runtest_extra_prunes ""
+if { ![check_effective_target_unwrapped] } {
+# The status wrapper is a regular object file
+lappend dg_runtest_extra_prunes "warning: incremental linking of LTO
and non-LTO objects"
+}
+
gcc_init
lto_init no-mathlib
@@ -60,4 +68,5 @@ foreach src [lsort [find $srcdir/$subdir *_0.c]] {
lto-execute $src $sid
}
+set dg_runtest_extra_prunes ""
lto_finish
--
2.25.1
>>
[PATCH] avoid-store-forwarding: Fix base register initialization when eliminating loads [PR117835]
From: kelefth
During the initialization of the base register for the zero-offset store, in
the case that we are eliminating the load, we used a paradoxical subreg
assuming that we don't care about the higher bits of the register. This led to
writing wrong values when we were not updating the whole register.
This patch fixes the issue by zero-extending the value stored in the base
register instead of using a paradoxical subreg.
Bootstrapped/regtested on x86 and AArch64.
PR rtl-optimization/117835
gcc/ChangeLog:
* avoid-store-forwarding.cc
(store_forwarding_analyzer::process_store_forwarding):
Zero-extend the value stored in the base register instead of using a
paradoxical subreg.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr117835.c: New test.
---
gcc/avoid-store-forwarding.cc| 6 +-
gcc/testsuite/gcc.target/i386/pr117835.c | 20
2 files changed, 21 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr117835.c
diff --git a/gcc/avoid-store-forwarding.cc b/gcc/avoid-store-forwarding.cc
index 1b8c35bc6cb..fa83e10fedc 100644
--- a/gcc/avoid-store-forwarding.cc
+++ b/gcc/avoid-store-forwarding.cc
@@ -238,11 +238,7 @@ process_store_forwarding (vec &stores,
rtx_insn *load_insn,
{
start_sequence ();
- /* We can use a paradoxical subreg to force this to a wider mode, as
-the only use will be inserting the bits (i.e., we don't care about
-the value of the higher bits). */
- rtx ext0 = lowpart_subreg (GET_MODE (dest), it->mov_reg,
-GET_MODE (it->mov_reg));
+ rtx ext0 = gen_rtx_ZERO_EXTEND (GET_MODE (dest), it->mov_reg);
if (ext0)
{
rtx_insn *move0 = emit_move_insn (dest, ext0);
diff --git a/gcc/testsuite/gcc.target/i386/pr117835.c
b/gcc/testsuite/gcc.target/i386/pr117835.c
new file mode 100644
index 000..eac71aac916
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr117835.c
@@ -0,0 +1,20 @@
+/* { dg-do run } */
+/* { dg-options "-O -favoid-store-forwarding -mno-push-args
--param=store-forwarding-max-distance=0 -Wno-psabi" } */
+
+typedef __attribute__((__vector_size__ (64))) unsigned short V;
+
+__attribute__((__noipa__)) V
+foo (V v, V)
+{
+ return v;
+}
+
+int main ()
+{
+ V a = (V){3, 5, 0, 8, 9, 3, 5, 1, 3, 4, 2, 5, 5, 0, 5, 3, 61886};
+ V b = (V){6, 80, 15, 2, 2, 1, 1, 3, 5};
+ V x = foo (a, b);
+ for (unsigned i = 0; i < sizeof(x)/sizeof(x[0]); i++)
+if (x[i] != a[i])
+ __builtin_abort();
+}
\ No newline at end of file
--
2.47.0
[PATCH v2] Add new hardreg PRE pass
This pass is used to optimise assignments to the FPMR register in
aarch64. I chose to implement this as a middle-end pass because it
mostly reuses the existing RTL PRE code within gcse.cc.
Compared to RTL PRE, the key difference in this new pass is that we
insert new writes directly to the destination hardreg, instead of
writing to a new pseudo-register and copying the result later. This
requires changes to the analysis portion of the pass, because sets
cannot be moved before existing instructions that set, use or clobber
the hardreg, and the value becomes unavailable after any uses of
clobbers of the hardreg.
Any uses of the hardreg in debug insns will be deleted. We could do
better than this, but for the aarch64 fpmr I don't think we emit useful
debuginfo for deleted fp8 instructions anyway (and I don't even know if
it's possible to have a debug fpmr use when entering hardreg PRE).
Compared to the first version, I've now fixed the broken debug uses, and
simplified a lot of the analysis (it turns out DF analysis already provides
cleaner versions of the checks I need). I also fixed a couple of other minor
bugs (including one that broke the build on every target except aarch64).
The new tests pass; I haven't rerun a bootstrap or full regression test yet,
but this should be NFC except for aarch64 code that uses the fpmr register.
Is this ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.h (HARDREG_PRE_REGNOS): New macro.
* gcse.cc (doing_hardreg_pre_p): New global variable.
(do_load_motion): New boolean check.
(current_hardreg_regno): New global variable.
(compute_local_properties): Unset transp for hardreg clobbers.
(prune_hardreg_uses): New function.
(want_to_gcse_p): Use different checks for hardreg PRE.
(oprs_unchanged_p): Disable load motion for hardreg PRE pass.
(hash_scan_set): For hardreg PRE, skip non-hardreg sets and
check for hardreg clobbers.
(record_last_mem_set_info): Skip for hardreg PRE.
(compute_pre_data): Prune hardreg uses from transp bitmap.
(pre_expr_reaches_here_p_work): Add sentence to comment.
(insert_insn_start_basic_block): New functions.
(pre_edge_insert): Don't add hardreg sets to predecessor block.
(pre_delete): Use hardreg for the reaching reg.
(reset_hardreg_debug_uses): New function.
(pre_gcse): For hardreg PRE, reset debug uses and don't insert
copies.
(one_pre_gcse_pass): Disable load motion for hardreg PRE.
(execute_hardreg_pre): New.
(class pass_hardreg_pre): New.
(pass_hardreg_pre::gate): New.
(make_pass_hardreg_pre): New.
* passes.def (pass_hardreg_pre): New pass.
* tree-pass.h (make_pass_hardreg_pre): New.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/acle/fpmr-1.c: New test.
* gcc.target/aarch64/acle/fpmr-2.c: New test.
* gcc.target/aarch64/acle/fpmr-3.c: New test.
* gcc.target/aarch64/acle/fpmr-4.c: New test.
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index
f1251f67c74e8da8420bad2d07a11a98a7de37ff..61837a4a98744225b9d15cfbc37cc914ac48421b
100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1652,6 +1652,10 @@ enum class aarch64_tristate_mode : int { NO, YES, MAYBE
};
{ int (aarch64_tristate_mode::MAYBE), \
int (aarch64_local_sme_state::ANY) }
+/* Zero terminated list of regnos for which hardreg PRE should be
+ applied. */
+#define HARDREG_PRE_REGNOS { FPM_REGNUM, 0 }
+
#endif
#endif /* GCC_AARCH64_H */
diff --git a/gcc/gcse.cc b/gcc/gcse.cc
index
31b92f30fa1ba6c519429d4b7bc55547b2d71c01..f33de3747b896950568154acbfac1817519fe748
100644
--- a/gcc/gcse.cc
+++ b/gcc/gcse.cc
@@ -415,6 +415,17 @@ static int gcse_create_count;
/* Doing code hoisting. */
static bool doing_code_hoisting_p = false;
+
+/* Doing hardreg_pre. */
+static bool doing_hardreg_pre_p = false;
+
+inline bool
+do_load_motion ()
+{
+ return flag_gcse_lm && !doing_hardreg_pre_p;
+}
+
+static unsigned int current_hardreg_regno;
/* For available exprs */
static sbitmap *ae_kill;
@@ -689,14 +700,32 @@ compute_local_properties (sbitmap *transp, sbitmap *comp,
sbitmap *antloc,
int indx = expr->bitmap_index;
struct gcse_occr *occr;
- /* The expression is transparent in this block if it is not killed.
-We start by assuming all are transparent [none are killed], and
-then reset the bits for those that are. */
+ /* In most cases, the expression is transparent in the block if it is
+not killed. The exception to this is during hardreg PRE, in which
+uses of the hardreg prevent transparency but do not kill the
+expression.
+
+We start by assuming all expressions are transparent [none are
+killed], and then reset the bits for those that are. */
[PATCH v3] ada: PR target/117538 Traceback includes load address if executable is PIE.
If s-trasym.adb (System.Traceback.Symbolic, used as a renaming by GNAT.Traceback.Symbolic) is given a traceback from a position-independent executable, it does not include the executable's load address in the report. This is necessary in order to decode the traceback report. This version of the patch is considerably simplified, as requested. Bootstrapped and regtested (ada onlyj) on x86_64-apple-darwin. * gcc/ada/libgnat/s-trasym.adb: Returns the traceback in the required form, using __gnat_get_executable_load_address to get the address (or null, if not present). 2024-12-17 Simon Wright gcc/ada/Changelog: PR target/117538 * libgnat/s-trasym.adb: Returns the traceback, with the program load address if available. — diff --git a/gcc/ada/libgnat/s-trasym.adb b/gcc/ada/libgnat/s-trasym.adb index 894fcf37ffd..a83d60f 100644 --- a/gcc/ada/libgnat/s-trasym.adb +++ b/gcc/ada/libgnat/s-trasym.adb @@ -69,7 +69,24 @@ package body System.Traceback.Symbolic is end loop; Result (Last) := ASCII.LF; -return Result (1 .. Last); +declare + function Executable_Load_Address return System.Address; + pragma Import + (C, Executable_Load_Address, + "__gnat_get_executable_load_address"); + + Load_Address : constant System.Address := + Executable_Load_Address; +begin + if Load_Address = System.Null_Address then + return Result (1 .. Last); + else + return "Load address: 0x" +& System.Address_Image (Load_Address) + & ASCII.LF + & Result (1 .. Last); + end if; +end; end; end if; end Symbolic_Traceback;
Ping [PATCH v3 0/3] Match: support additional cases of unsigned scalar arithmetic
Pinging
On 27/11/2024 20:27, Akram Ahmad wrote:
Hi all,
This patch series adds support for 2 new cases of unsigned scalar saturating
arithmetic
(one addition, one subtraction). This results in more valid patterns being
recognised,
which results in a call to .SAT_ADD or .SAT_SUB where relevant.
v3 of this series now introduces support for dg-require-effective-target for
both usadd
and ussub optabs as well as individual modes that these optabs may be
implemented for.
aarch64 support for these optabs is in review, so there are currently no
targets listed
in these effective-target options.
Regression tests for aarch64 all pass with no failures.
v3 changes:
- add support for new effective-target keywords.
- tests for the two new patterns now use the dg-require-effective-target so
that they are
skipped on relevant targets.
v2 changes:
- add new tests for both patterns (these will fail on targets which don't
implement
the standard insn names for IFN_SAT_ADD and IFN_SAT_SUB; another patch
series adds
support for this in aarch64).
- minor adjustment to the constraints on the match statement for
usadd_left_part_1.
If this is OK for master, please commit these on my behalf, as I do not have
the ability
to do so.
Many thanks,
Akram
---
Akram Ahmad (3):
testsuite: Support dg-require-effective-target for us{add, sub}
Match: support new case of unsigned scalar SAT_SUB
Match: make SAT_ADD case 7 commutative
gcc/match.pd | 12 +++-
.../gcc.dg/tree-ssa/sat-u-add-match-1-u16.c | 22
.../gcc.dg/tree-ssa/sat-u-add-match-1-u32.c | 22
.../gcc.dg/tree-ssa/sat-u-add-match-1-u64.c | 22
.../gcc.dg/tree-ssa/sat-u-add-match-1-u8.c| 22
.../gcc.dg/tree-ssa/sat-u-sub-match-1-u16.c | 15 +
.../gcc.dg/tree-ssa/sat-u-sub-match-1-u32.c | 15 +
.../gcc.dg/tree-ssa/sat-u-sub-match-1-u64.c | 15 +
.../gcc.dg/tree-ssa/sat-u-sub-match-1-u8.c| 15 +
gcc/testsuite/lib/target-supports.exp | 56 +++
10 files changed, 214 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-add-match-1-u16.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-add-match-1-u32.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-add-match-1-u64.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-add-match-1-u8.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-sub-match-1-u16.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-sub-match-1-u32.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-sub-match-1-u64.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/sat-u-sub-match-1-u8.c
Re: [PATCH v2 0/2] aarch64: Use standard names for saturating arithmetic
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668794.html On 14/11/2024 15:53, Akram Ahmad wrote: Hi all, This patch series introduces standard names for scalar, Adv. SIMD, and SVE saturating arithmetic instructions in the aarch64 backend. Additional tests are added for scalar saturating arithmetic, as well as to test that the auto-vectorizer correctly inserts NEON instructions or scalar instructions where necessary, such as in 32 and 64-bit scalar unsigned arithmetic. There are also tests for the auto-vectorized SVE code. The biggest change from V1-V2 of this series is the optimisation for signed scalar arithmetic (32 and 64-bit) to avoid the use of FMOV in the case of a constant and non-constant operand (immediate or GP reg values respectively). This is only exhibited if early-ra is disabled due to an early-ra bug which is assigning FP registers for operands even if this would unnecessarily result in FMOV being used. This new optimisation is tested by means of check-function-bodies as well as an execution test. As with v1 of this patch, the only new regression failures on aarch64 are to do with unsigned scalar intrinsics (32 and 64-bit) not using the NEON instructions any more. Otherwise, there are no regressions. SVE currently uses the unpredicated version of the instruction in the backend. v1 -> v2: - Add new split for signed saturating arithmetic - New test for signed saturating arithmetic - Make addition tests accept commutative operands, other test fixes Only the first patch in this series is updated in v2. The other patch is already approved. If this is ok, could this be committed for me please? I do not have commit rights. Many thanks, Akram --- Akram Ahmad (2): aarch64: Use standard names for saturating arithmetic aarch64: Use standard names for SVE saturating arithmetic gcc/config/aarch64/aarch64-builtins.cc| 13 + gcc/config/aarch64/aarch64-simd-builtins.def | 8 +- gcc/config/aarch64/aarch64-simd.md| 209 ++- gcc/config/aarch64/aarch64-sve.md | 4 +- gcc/config/aarch64/arm_neon.h | 96 +++ gcc/config/aarch64/iterators.md | 4 + .../saturating_arithmetic_autovect.inc| 58 + .../saturating_arithmetic_autovect_1.c| 79 ++ .../saturating_arithmetic_autovect_2.c| 79 ++ .../saturating_arithmetic_autovect_3.c| 75 ++ .../saturating_arithmetic_autovect_4.c| 77 ++ .../aarch64/saturating-arithmetic-signed.c| 244 ++ .../aarch64/saturating_arithmetic.inc | 39 +++ .../aarch64/saturating_arithmetic_1.c | 36 +++ .../aarch64/saturating_arithmetic_2.c | 36 +++ .../aarch64/saturating_arithmetic_3.c | 30 +++ .../aarch64/saturating_arithmetic_4.c | 30 +++ .../aarch64/sve/saturating_arithmetic.inc | 68 + .../aarch64/sve/saturating_arithmetic_1.c | 60 + .../aarch64/sve/saturating_arithmetic_2.c | 60 + .../aarch64/sve/saturating_arithmetic_3.c | 62 + .../aarch64/sve/saturating_arithmetic_4.c | 62 + 22 files changed, 1371 insertions(+), 58 deletions(-) create mode 100644 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect.inc create mode 100644 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_1.c create mode 100644 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_2.c create mode 100644 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_3.c create mode 100644 gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_autovect_4.c create mode 100644 gcc/testsuite/gcc.target/aarch64/saturating-arithmetic-signed.c create mode 100644 gcc/testsuite/gcc.target/aarch64/saturating_arithmetic.inc create mode 100644 gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_1.c create mode 100644 gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_2.c create mode 100644 gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_3.c create mode 100644 gcc/testsuite/gcc.target/aarch64/saturating_arithmetic_4.c create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/saturating_arithmetic.inc create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/saturating_arithmetic_1.c create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/saturating_arithmetic_2.c create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/saturating_arithmetic_3.c create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/saturating_arithmetic_4.c
Re: [PATCH v2] RISC-V: Fix ICE for unrecognizable insn `UNSPEC_VSETVL` for XTheadVector
> Looking at the log for the reload pass, it is found that "Changing pseudo 209 > in operand 3 of insn 69 on equiv 0x 1". It converts the vl operand in insn > from the expected register(reg:DI 209) to the constant 1(const_int 1 [0x1]). > > This conversion occurs because, although the predicate for the vl operand is > restricted by "vector_length_operand" in the pattern, the constraint is still > "rK", which allows the transformation. > > The issue is that changing the "rK" constraint to "rJ" for the constraint of > vl operand in the pattern would prevent this conversion, But unfortunately > this will conflict with RVV (RISC-V Vector Extension). > > This is why I initially considered using UNSPEC to address the XTheadVector > problem while minimizing interference with RVV. > > I'm not sure if there is a better way, do you have any suggestions? We'd probably need to disable the alternatives via the "spec_restriction" attribute as we do for the fma ops. -- Regards Robin
Re: The COBOL front end, in 8 notes
On Mon, 2024-12-16 at 11:32 -0500, James K. Lowden wrote: > On Mon, 16 Dec 2024 23:48:52 + (UTC) > Joseph Myers wrote: > > > However, if introducing a Bison dependency, it needs to be > > documented > > (being specific about version requirements) in install.texi. > > Under "Tools/packages necessary for building GCC", in Prequisites, > yes? > > In gcc/cobol/parse,y, we have, > > %require "3.5.1" // 3.8.2 also works, but not 3.8.0 > > David Malcolm reports success with 3.5. with the caveats that "success" here means: - it built, and I managed to compile *one* .cbl file and that seemed to work - I didn't attempt to run any test suite, and - I have zero expertise in COBOL Dave > Should I change the above on > the strength of his experience, or is a more methodical approach > indicated? > > I will add install.texi to the next version of the COBOL patches. > > --jkl > > P.S. i am acting on the recommendations everyone posted. Thank you > for the comments, which were mostly very helpful. I'm restricting my > on-list replies unless I have a question, to minimize the noise. I > will have a new patchset ready this week, possibly tomorrow. >
Re: [PATCH] c and c++: Make sure LHS and RHS has identical named types [PR116060]
Hi Jason,
Thanks for the quick feedback!
On 2024-12-16 17:11, Jason Merrill wrote:
On 12/16/24 7:16 AM, Torbjörn SVENSSON wrote:
Hi,
I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
for any of the out-of-bounds-diagram* tests on any of the 2 platforms.
I'm a bit puzzled if the C++ part is enough, but I can't think of a way
to trigger anything that show the wrong output after my change.
Do you think that I need to add any additional tests? I think the
existing test covers the problem well enough.
Ok for trunk and releases/gcc-14?
This won't be a candidate for backporting to 14.
Ok!
--
gcc/ChangeLog:
PR c/116060
c/c-typeck.cc: Make sure left hand side and right hand side has
identical named types to aid diagnostic output.
cp/call.cc: Likewise.
I've also split this into one block for gcc/c/ChangeLog and one for
gcc/cp/ChangeLog as mentioned by Marek in the other review.
gcc/testsuite/ChangeLog:
PR c/116060
c-c++-common/analyzer/out-of-bounds-diagram-8.c: Update to
correct type.
c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise.
gcc.dg/analyzer/out-of-bounds-diagram-10.c: Likewise.
Signed-off-by: Torbjörn SVENSSON
---
gcc/c/c-typeck.cc | 3 ++
gcc/cp/call.cc | 9 ++
.../analyzer/out-of-bounds-diagram-11.c | 28 +--
.../analyzer/out-of-bounds-diagram-8.c | 28 +--
.../analyzer/out-of-bounds-diagram-10.c | 28 +--
5 files changed, 54 insertions(+), 42 deletions(-)
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 902898d1944..e3e85d1ecde 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -7831,6 +7831,9 @@ convert_for_assignment (location_t location,
location_t expr_loc, tree type,
if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (rhstype))
{
warn_for_address_of_packed_member (type, orig_rhs);
+ if (type != rhstype)
+ /* Convert RHS to TYPE in order to not loose TYPE in
diagnostics. */
+ rhs = convert (type, rhs);
return rhs;
}
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index c8420db568e..d859ce9a2d6 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -1319,6 +1319,9 @@ standard_conversion (tree to, tree from, tree
expr, bool c_cast_p,
{
if (CLASS_TYPE_P (to) && conv->kind == ck_rvalue)
conv->type = qualified_to;
+ else if (from != to)
+ /* Use TO in order to not loose TO in diagnostics. */
"lose"
+ conv->type = to;
return conv;
}
@@ -8741,6 +8744,12 @@ convert_like_internal (conversion *convs, tree
expr, tree fn, int argnum,
continue to warn about uses of EXPR as an integer, rather
than as a
pointer. */
expr = build_int_cst (totype, 0);
+ if (TREE_CODE (expr) == NON_LVALUE_EXPR && TREE_TYPE (expr) !=
totype)
You might check !obvalue_p (expr) instead of just NON_LVALUE_EXPR?
Appears to work as expected with !obvalue_p(expr), thanks!
+ {
+ /* Use TOTYPE in order to not loose TOTYPE in diagnostics. */
"lose"
+ expr = copy_node (expr);
+ TREE_TYPE (expr) = totype;
+ }
Let's use cp_fold_convert instead of manually optimizing the conversion.
I've tried to use cp_fold_convert and cp_convert, but neither of them
work (either during when building, or in the case of cp_fold_convert,
ICE when running the regression test).
For cp_fold_convert, I see the following stack trace in the ICE (just
one of many examples):
Testing torture/pr47333.C, -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects
doing compile
Executing on host: /tmp/build/gcc/testsuite/g++/../../xg++
-B/tmp/build/gcc/testsuite/g++/../../
/home/user/gcc/gcc/testsuite/g++.dg/torture/pr47333.C
-fdiagnostics-plain-output -nostdinc++
-I/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/user/gcc/libstdc++-v3/libsupc++
-I/home/user/gcc/libstdc++-v3/include/backward
-I/home/user/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects -Wno-template-body -S
-o pr47333.s(timeout = 300)
spawn -ignore SIGHUP /tmp/build/gcc/testsuite/g++/../../xg++
-B/tmp/build/gcc/testsuite/g++/../../
/home/user/gcc/gcc/testsuite/g++.dg/torture/pr47333.C
-fdiagnostics-plain-output -nostdinc++
-I/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/user/gcc/libstdc++-v3/libsupc++
-I/home/user/gcc/libstdc++-v3/include/backward
-I/home/user/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects -Wno-template-body -S -o
pr47333.s
pid is 3620856 -3620856
/home/user/gcc/gcc/testsuite/g++.dg/torture/pr47333.C: In member
f
[PATCH] libstdc++: Clear std::priority_queue after moving from it [PR118088]
We don't know what state an arbitrary sequence container will be in
after moving from it, so a moved-from std::priority_queue needs to clear
the moved-from container to ensure it doesn't contain elements that are
in an invalid order for the queue. An alternative would be to call
std::make_heap again to re-establish the rvalue queue's invariant, but
that could potentially cause an exception to be thrown. Just clearing it
so the sequence is empty seems safer and more likely to match user
expectations.
libstdc++-v3/ChangeLog:
PR libstdc++/118088
* include/bits/stl_queue.h (priority_queue(priority_queue&&)):
Clear the source object after moving from it.
(priority_queue(priority_queue&&, const Alloc&)): Likewise.
(operator=(priority_queue&&)): Likewise.
* testsuite/23_containers/priority_queue/118088.cc: New test.
---
Tested x86_64-linux.
libstdc++-v3/include/bits/stl_queue.h | 26 +-
.../23_containers/priority_queue/118088.cc| 83 +++
2 files changed, 106 insertions(+), 3 deletions(-)
create mode 100644
libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc
diff --git a/libstdc++-v3/include/bits/stl_queue.h
b/libstdc++-v3/include/bits/stl_queue.h
index ada354b911d..53a9a47a2d2 100644
--- a/libstdc++-v3/include/bits/stl_queue.h
+++ b/libstdc++-v3/include/bits/stl_queue.h
@@ -564,6 +564,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: c(std::move(__s)), comp(__x)
{ std::make_heap(c.begin(), c.end(), comp); }
+ priority_queue(const priority_queue&) = default;
+ priority_queue& operator=(const priority_queue&) = default;
+
+ priority_queue(priority_queue&& __q)
+ noexcept(__and_,
+ is_nothrow_move_constructible<_Compare>>::value)
+ : c(std::move(__q.c)), comp(std::move(__q.comp))
+ { __q.c.clear(); }
+
+ priority_queue&
+ operator=(priority_queue&& __q)
+ noexcept(__and_,
+ is_nothrow_move_assignable<_Compare>>::value)
+ {
+ c = std::move(__q.c);
+ __q.c.clear();
+ comp = std::move(__q.comp);
+ return *this;
+ }
+
template>
explicit
priority_queue(const _Alloc& __a)
@@ -592,7 +612,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template>
priority_queue(priority_queue&& __q, const _Alloc& __a)
- : c(std::move(__q.c), __a), comp(std::move(__q.comp)) { }
+ : c(std::move(__q.c), __a), comp(std::move(__q.comp))
+ { __q.c.clear(); }
#endif
/**
@@ -607,8 +628,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* the copy according to @a __x.
*
* For more information on function objects, see the
- * documentation on @link functors functor base
- * classes@endlink.
+ * documentation on @link functors functor base classes@endlink.
*/
#if __cplusplus < 201103L
template
diff --git a/libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc
b/libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc
new file mode 100644
index 000..b59175d8786
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc
@@ -0,0 +1,83 @@
+// { dg-do run { target c++11 } }
+
+#include
+#include
+#include
+
+template
+bool
+check(std::priority_queue& p)
+{
+ if (!p.empty())
+{
+ T prev = p.top();
+ p.pop();
+ while (!p.empty())
+ {
+ if ( prev < p.top() )
+ return false;
+ prev = p.top();
+ p.pop();
+ }
+}
+ return true;
+}
+
+// A vector-like type that has a non-empty moved-from state.
+struct Vector : std::vector
+{
+ using Base = std::vector;
+
+ using Base::Base;
+
+ Vector(const Vector&) = default;
+ Vector& operator=(const Vector&) = default;
+
+ Vector(Vector&& v) : Base(static_cast(v))
+ {
+invalidate_heap(v);
+ }
+
+ Vector(Vector&& v, const std::allocator&)
+ : Base(static_cast(v))
+ {
+invalidate_heap(v);
+ }
+
+ Vector&
+ operator=(Vector&& v)
+ {
+static_cast(*this) = static_cast(v);
+invalidate_heap(v);
+return *this;
+ }
+
+ void invalidate_heap(Base& v) { v = {1,2,3}; }
+};
+
+void
+test_moves()
+{
+ std::priority_queue p;
+ p.push(1);
+ p.push(3);
+ p.push(5);
+ p.push(2);
+ p.push(2);
+ p.push(2);
+ p.push(2);
+ std::priority_queue p2 = std::move(p);
+ VERIFY( check(p) );
+
+ // Allocator-extended move constructor:
+ std::priority_queue p3(std::move(p2), std::allocator());
+ VERIFY( check(p2) );
+
+ p2 = std::move(p3);
+ VERIFY( check(p3) );
+}
+
+int main()
+{
+ test_moves();
+}
--
2.47.1
Re: [PATCH] libstdc++: Fix future.wait_until when given a negative time_point
On Tue, 17 Dec 2024 at 19:38, Jonathan Wakely wrote:
>
> On Wed, 31 Jul 2024 at 22:39, Jonathan Wakely wrote:
> >
> > On Wed, 24 Jul 2024 at 14:14, William Tsai wrote:
> > >
> > > The template `future.wait_until` will expand to
> > > `_M_load_and_test_until_impl` where it will call
> > > `_M_load_and_test_until*` with given time_point casted into second and
> > > nanosecond. The callee expects the caller to provide the values
> > > correctly from caller while the caller did not make check with those
> > > values. One possible error is that if `future.wait_until` is given with
> > > a negative time_point, the underlying system call will raise an error as
> > > the system call does not accept second < 0 and nanosecond < 1.
> >
> > Thanks for the patch, it looks correct. The futex syscall returns
> > EINVAL in this case, which we don't handle, so the caller loops and
> > keeps calling the syscall again, which fails again the same way.
> >
> > I think it would be good to mention EINVAL, e.g. "will raise an EINVAL
> > error" instead of just "will raise an error".
>
> I was finally getting around to merging this patch and realised the
> fix is actually much simpler. We do already check for negative
> timeouts, we just didn't handle values between -1s and 0s. We can fix
> it in the library, without changing the headers:
>
> --- a/libstdc++-v3/src/c++11/futex.cc
> +++ b/libstdc++-v3/src/c++11/futex.cc
> @@ -128,7 +128,7 @@ namespace
>if (!futex_clock_realtime_unavailable.load(std::memory_order_relaxed))
> {
>// futex sets errno=EINVAL for absolute timeouts before the epoch.
> - if (__s.count() < 0)
> + if (__s.count() < 0 || __ns.count() < 0) [[unlikely]]
> return false;
>
>syscall_timespec rt;
> @@ -204,7 +204,7 @@ namespace
>if (!futex_clock_monotonic_unavailable.load(std::memory_order_relaxed))
> {
>// futex sets errno=EINVAL for absolute timeouts before the epoch.
> - if (__s.count() < 0) [[unlikely]]
> + if (__s.count() < 0 || __ns.count() < 0) [[unlikely]]
> return false;
>
>syscall_timespec rt;
>
>
> A timeout of 10ms before the epoch gets broken down into 0s and -10ms
> and so the __s.count() < 0 check is false, but the futex syscall still
> returns EINVAL.
>
> So I'll fix this that way instead.
Here's what I'm testing.
commit a3f4ab3c7bfda80b5dd3ffe56b2accad15de3d71
Author: Jonathan Wakely
AuthorDate: Tue Dec 17 21:32:19 2024
Commit: Jonathan Wakely
CommitDate: Wed Dec 18 00:35:16 2024
libstdc++: Fix std::future::wait_until for subsecond negative times
[PR118093]
The current check for negative times (i.e. before the epoch) only checks
for a negative number of seconds. For a time 1ms before the epoch the
seconds part will be zero, but the futex syscall will still fail with an
EINVAL error. Extend the check to handle this case.
This change adds a redundant check in the headers too, so that we avoid
even calling into the library for negative times. Both checks can be
marked [[unlikely]].
libstdc++-v3/ChangeLog:
PR libstdc++/118093
* include/bits/atomic_futex.h (_M_load_and_test_until_impl):
Return false for times before the epoch.
* src/c++11/futex.cc (_M_futex_wait_until): Extend check for
negative times to check for subsecond times. Add unlikely
attribute.
(_M_futex_wait_until_steady): Likewise.
* testsuite/30_threads/future/members/118093.cc: New test.
diff --git a/libstdc++-v3/include/bits/atomic_futex.h
b/libstdc++-v3/include/bits/atomic_futex.h
index c7d90466418..fe13508462a 100644
--- a/libstdc++-v3/include/bits/atomic_futex.h
+++ b/libstdc++-v3/include/bits/atomic_futex.h
@@ -172,11 +172,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool __equal, memory_order __mo,
const chrono::time_point& __atime)
{
- auto __s = chrono::time_point_cast(__atime);
- auto __ns = chrono::duration_cast(__atime - __s);
- // XXX correct?
+ auto __d = __atime.time_since_epoch();
+ if (__d < __d.zero()) [[__unlikely__]]
+ return false;
+ auto __s = chrono::duration_cast(__d);
+ auto __ns = chrono::duration_cast(__d - __s);
return _M_load_and_test_until(__assumed, __operand, __equal, __mo,
- true, __s.time_since_epoch(), __ns);
+ true, __s, __ns);
}
template
@@ -185,11 +187,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool __equal, memory_order __mo,
const chrono::time_point& __atime)
{
- auto __s = chrono::time_point_cast(__atime);
- auto __ns = chrono::duration_cast(__atime - __s);
- // XXX correct?
+ auto __d = __atime.time_since_epoch();
+ if (__d < __d.zero()) [[__unlikely__]]
+ return false;
+ auto __s = chrono::duration_cast(__d);
+ auto
Re: [PATCH] c++: Implement for namespace statics CWG 2867 - Order of initialization for structured bindings [PR115769]
On 9/11/24 8:26 AM, Jakub Jelinek wrote:
On Wed, Sep 11, 2024 at 10:16:18PM +1000, Nathaniel Shead wrote:
In the header_module_p case, it is valid to have internal linkage
definitions (e.g. in an anonymous namespace), but in that case the
{static,tls}_aggregates lists should still be in place to be streamed
and everything should work as "normal".
As the patch doesn't touch the streaming of {static,tls}_aggregates
in that case, I guess that means CWG 2867 will not be fixed for those
cases (i.e. temporaries from the structured binding base initialization
will be destructed at the end of that initialization, rather than at the
end of subsequent get initializers); perhaps we should stream the
STATIC_INIT_DECOMP_*BASE_P flags say by streaming there integer_zero_node
or integer_one_node right before the decls and on streaming it back set
the flags again.
We don't stream *_aggregates at all; rather, read_var_def builds them up
as we read in the variables. Can we set the appropriate flags at that time?
For the !header_module_p case, we'll need a testcase too
to make sure it works properly.
For the !header_module_p case, the structured binding initialization
would be handled by the module .o, so importers wouldn't need to worry
about it.
Jason
Re: [PATCH] c++: Add {,un}likely attribute further test coverage [PR110345]
On 9/5/24 3:20 AM, Jakub Jelinek wrote:
Hi!
Similarly for likely/unlikely attributes.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-likely1.C: New test.
* g++.dg/cpp0x/attr-unlikely1.C: New test.
--- gcc/testsuite/g++.dg/cpp0x/attr-likely1.C.jj2024-09-04
16:53:59.829472783 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-likely1.C 2024-09-04 17:04:52.566048248
+0200
@@ -0,0 +1,149 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+ [[likely]];
+ [[likely (1)]]; // { dg-error "'likely' attribute does not
take any arguments" }
+ [[likely]] ++n;
+ [[likely]] int x1; // { dg-warning "'likely' attribute
ignored" }
+
+ auto a = [] [[likely]] () {};// { dg-warning "ISO C\\\+\\\+
'likely' attribute does not apply to functions; treating as
'\\\[\\\[gnu::hot\\\]\\\]'" }
+ auto b = [] constexpr [[likely]] {}; // { dg-warning "'likely' attribute
ignored" }
+ // { dg-error "parameter declaration before lambda
declaration specifiers only optional with" "" { target c++20_down } .-1 }
+ // { dg-error "'constexpr' lambda only available
with" "" { target c++14_down } .-2 }
+ auto c = [] noexcept [[likely]] {}; // { dg-warning "'likely' attribute
ignored" }
+ // { dg-error "parameter declaration before lambda
exception specification only optional with" "" { target c++20_down } .-1 }
+ auto d = [] () [[likely]] {};// { dg-warning "'likely' attribute
ignored" }
+ auto e = new int [n] [[likely]]; // { dg-warning "attributes ignored on
outermost array type in new expression" }
+ auto e2 = new int [n] [[likely]] [42];// { dg-warning "attributes ignored on
outermost array type in new expression" }
+ auto f = new int [n][42] [[likely]]; // { dg-warning "'likely' attribute
ignored" }
+ [[likely]];
+ [[likely]] {}
+ [[likely]] if (true) {}
+ [[likely]] while (false) {}
+ [[likely]] goto lab;
+ [[likely]] lab:;
+ [[likely]] try {} catch (int) {}
+ if ([[likely]] int x = 0) {} // { dg-warning "'likely' attribute
ignored" }
+ switch (n)
+{
+[[likely]] case 1:
+[[likely]] break;
+[[likely]] default:
+break;
+}
+ for ([[likely]] auto a : arr) {} // { dg-warning "'likely' attribute
ignored" }
+ for ([[likely]] auto [a, b] : arr2) {}// { dg-warning "'likely' attribute
ignored" }
+ // { dg-error "structured bindings only available
with" "" { target c++14_down } .-1 }
+ [[likely]] asm (""); // { dg-warning "attributes ignored on
'asm' declaration" }
+ try {} catch ([[likely]] int x) {} // { dg-warning "'likely' attribute
ignored" }
+ try {} catch ([[likely]] int) {} // { dg-warning "'likely' attribute
ignored" }
+ try {} catch (int [[likely]] x) {} // { dg-warning "attribute ignored" }
+ try {} catch (int [[likely]]) {} // { dg-warning "attribute ignored" }
+ try {} catch (int x [[likely]]) {} // { dg-warning "'likely' attribute
ignored" }
+}
+
+[[likely]] int bar (); // { dg-warning "ISO C\\\+\\\+ 'likely'
attribute does not apply to functions; treating as '\\\[\\\[gnu::hot\\\]\\\]'" }
+using foobar [[likely]] = int; // { dg-warning "'likely' attribute
ignored" }
+[[likely]] int a; // { dg-warning "'likely' attribute
ignored" }
+[[likely]] auto [b, c] = arr; // { dg-warning "'likely' attribute
ignored" }
+ // { dg-error "structured bindings only available
with" "" { target c++14_down } .-1 }
+[[likely]];// { dg-warning "attribute ignored" }
+inline [[likely]] void baz () {} // { dg-warning "attribute ignored" }
+ // { dg-error "standard attributes in middle of
decl-specifiers" "" { target *-*-* } .-1 }
+constexpr [[likely]] int qux () { return 0; } // { dg-warning "attribute
ignored" }
+ // { dg-error "standard attributes in middle of
decl-specifiers" "" { target *-*-* } .-1 }
+int [[likely]] d; // { dg-warning "attribute ignored" }
+int const [[likely]] e = 1;// { dg-warning "attribute ignored" }
+struct A {} [[likely]];// { dg-warning "attribute ignored
in declaration of 'struct A'" }
+struct A [[likely]]; // { dg-warning "attribute ignored" }
+struct A [[likely]] a1;// { dg-warning "attribute
ignored" }
+A [[likely]] a2; // { dg-warning "attribute ignored" }
+enum B { B0 } [[likely]]; // { dg-warn
Re: [PATCH] c++: Fix up maybe_unused attribute handling [PR110345]
On 9/5/24 3:27 AM, Jakub Jelinek wrote:
Hi!
When adding test coverage for maybe_unused attribute, I've run into
several things:
1) similarly to deprecated attribute, the attribute shouldn't pedantically
appertain to types other than class/enumeration definitions
2) similarly to deprecated attribute, the attribute shouldn't pedantically
appertain to unnamed bit-fields
3) the standard says that it can appertain to identifier labels, but
we handled it silently also on case and default labels
As with deprecated, wouldn't it be an improvement to warn for the GNU
attribute in these cases as well?
4) I've run into a weird spurious error on
int f [[maybe_unused]];
int & [[maybe_unused]] i = f;
int && [[maybe_unused]] j = 0;
The problem was that we create an attribute variant for the int &
type, then create an attribute variant for the int && type, and
the type_canon_hash hashing just thought those 2 are the same,
so used int & [[maybe_unused]] type for j rather than
int && [[maybe_unused]]. As TYPE_REF_IS_RVALUE is a flag in the
generic code, it was easily possible to hash that flag and compare
it
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-09-05 Jakub Jelinek
PR c++/110345
gcc/
* tree.cc (type_hash_canon_hash): Hash TYPE_REF_IS_RVALUE for
REFERENCE_TYPE.
(type_cache_hasher::equal): Compare TYPE_REF_IS_RVALUE for
REFERENCE_TYPE.
gcc/cp/
* tree.cc (handle_maybe_unused_attribute): New function.
(std_attributes): Use handle_maybe_unused_attribute instead
of handle_unused_attribute for maybe_unused attribute.
gcc/testsuite/
* g++.dg/cpp0x/attr-maybe_unused1.C: New test.
--- gcc/tree.cc.jj 2024-08-30 16:41:34.712367197 +0200
+++ gcc/tree.cc 2024-09-04 18:52:37.792157965 +0200
@@ -6085,6 +6085,10 @@ type_hash_canon_hash (tree type)
hstate.add_poly_int (TYPE_VECTOR_SUBPARTS (type));
break;
+case REFERENCE_TYPE:
+ hstate.add_flag (TYPE_REF_IS_RVALUE (type));
+ break;
+
default:
break;
}
@@ -6127,7 +6131,6 @@ type_cache_hasher::equal (type_hash *a,
case OPAQUE_TYPE:
case COMPLEX_TYPE:
case POINTER_TYPE:
-case REFERENCE_TYPE:
case NULLPTR_TYPE:
return true;
@@ -6217,6 +6220,9 @@ type_cache_hasher::equal (type_hash *a,
break;
return false;
+case REFERENCE_TYPE:
+ return TYPE_REF_IS_RVALUE (a->type) == TYPE_REF_IS_RVALUE (b->type);
+
default:
return false;
}
--- gcc/cp/tree.cc.jj 2024-09-04 12:36:51.904244104 +0200
+++ gcc/cp/tree.cc 2024-09-04 17:56:08.946371353 +0200
@@ -5106,6 +5106,27 @@ handle_std_deprecated_attribute (tree *n
return ret;
}
+/* The C++17 [[maybe_unused]] attribute mostly maps to the GNU unused
+ attribute. */
+
+static tree
+handle_maybe_unused_attribute (tree *node, tree name, tree args, int flags,
+ bool *no_add_attrs)
+{
+ tree t = *node;
+ tree ret = handle_unused_attribute (node, name, args, flags, no_add_attrs);
+ if (TYPE_P (*node) && t != *node)
+pedwarn (input_location, OPT_Wattributes,
+"%qE on a type other than class or enumeration definition", name);
+ else if (TREE_CODE (*node) == FIELD_DECL && DECL_UNNAMED_BIT_FIELD (*node))
+pedwarn (input_location, OPT_Wattributes, "%qE on unnamed bit-field",
+name);
+ else if (TREE_CODE (*node) == LABEL_DECL && DECL_NAME (*node) == NULL_TREE)
+pedwarn (input_location, OPT_Wattributes,
+"%qE on % or % label", name);
+ return ret;
+}
+
/* Table of valid C++ attributes. */
static const attribute_spec cxx_gnu_attributes[] =
{
@@ -5132,7 +5153,7 @@ static const attribute_spec std_attribut
{ "deprecated", 0, 1, false, false, false, false,
handle_std_deprecated_attribute, NULL },
{ "maybe_unused", 0, 0, false, false, false, false,
-handle_unused_attribute, NULL },
+handle_maybe_unused_attribute, NULL },
{ "nodiscard", 0, 1, false, false, false, false,
handle_nodiscard_attribute, NULL },
{ "no_unique_address", 0, 0, true, false, false, false,
--- gcc/testsuite/g++.dg/cpp0x/attr-maybe_unused1.C.jj 2024-09-04
17:28:44.552574792 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-maybe_unused1.C 2024-09-04
18:54:14.207069672 +0200
@@ -0,0 +1,148 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+ [[maybe_unused]] int x1;
+ [[maybe_unused ("foobar")]] int x2;// { dg-error "'maybe_unused'
attribute does not take any arguments" }
+ // { dg-error "expected primary-expression
before 'int'" "" { target *-*-* } .-1 }
+ [[maybe_unused (0)]] int x3; // { dg-error "'maybe_unused'
attribute does not take any ar
[PATCH] Add RISC-V/rv64gc as a secondary platform
This came up on IRC this morning and we talked a bit on the patchwork call this morning. I'm not really sure what the right answer is here, but it seems at least reasonable to talk about -- we've got a lot more testing these days are we've been somewhat reasonable about following the release stages. Either way it looks like a mailing list discussion and this seems like the easiest way to start it. I figured it'd be best to start with just rv64gc, as that's the target that is widley used by distros and has hardware to test on. Hopefully at some point we'll add a more exciting target, but it seems safer to start with something small. --- htdocs/gcc-15/criteria.html | 1 + 1 file changed, 1 insertion(+) diff --git a/htdocs/gcc-15/criteria.html b/htdocs/gcc-15/criteria.html index 7faa54e9..25ea7e61 100644 --- a/htdocs/gcc-15/criteria.html +++ b/htdocs/gcc-15/criteria.html @@ -125,6 +125,7 @@ application testing. i686-mingw32 s390x-linux-gnu mips64-linux-gnu +riscv64-linux-gnu (for rv64gc) Code Quality and Compilation Time -- 2.45.2
Re: [PATCH] c++, v2: Disallow [[deprecated]] on types other than class/enum definitions [PR110345]
On 8/30/24 1:34 PM, Jakub Jelinek wrote:
On Mon, Aug 19, 2024 at 05:05:51PM -0400, Jason Merrill wrote:
I've tried to compile it also with latest clang and there is agreement in
most of the diagnostics, just at block scope (inside of foo) it doesn't
diagnose
auto e = new int [n] [[deprecated]];
auto e2 = new int [n] [[deprecated]] [42];
[[deprecated]] lab:;
and at namespace scope
[[deprecated]];
I think that all feels like clang++ bug.
On the other side, clang++ diagnoses
enum B { B0 } [[deprecated]];
but GCC with all the patches I've posted today doesn't, is that a GCC bug?
I think so, yes.
Fixed in the just posted 2 patches.
The FIXMEs are where there is agreement with clang++, but I'm not sure.
One thing is I'm not sure if "a variable" above is meant to include function
parameters, and/or unused function parameters without a specified name,
function parameters inside of a function declaration rather than definition
and/or static data members.
All of those, I believe.
Removed the FIXMEs.
Also unsure about
[[deprecated]] int : 0;
at class scope, that isn't a non-static data member...
Indeed, pedantically the standard says it can't apply to an unnamed
bit-field.
And the following updated version on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
patches also diagnoses the attribute on unnamed bit-fields.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-08-30 Jakub Jelinek
PR c++/110345
* parser.cc (cp_parser_std_attribute): Don't transform
[[deprecated]] into [[gnu::deprecated]].
* tree.cc (handle_std_deprecated_attribute): New function.
(std_attributes): Add deprecated entry.
* g++.dg/cpp0x/attr-deprecated1.C: New test.
--- gcc/cp/parser.cc.jj 2024-08-30 11:13:18.612089567 +0200
+++ gcc/cp/parser.cc2024-08-30 12:55:17.875362909 +0200
@@ -30357,12 +30357,11 @@ cp_parser_std_attribute (cp_parser *pars
/* We used to treat C++11 noreturn attribute as equivalent to GNU's,
but no longer: we have to be able to tell [[noreturn]] and
-__attribute__((noreturn)) apart. */
- /* C++14 deprecated attribute is equivalent to GNU's. */
- if (is_attribute_p ("deprecated", attr_id))
- TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
+__attribute__((noreturn)) apart.
+Similarly for C++14 deprecated attribute, we need to emit extra
+diagnostics for [[deprecated]] compared to [[gnu::deprecated]]. */
/* C++17 fallthrough attribute is equivalent to GNU's. */
- else if (is_attribute_p ("fallthrough", attr_id))
+ if (is_attribute_p ("fallthrough", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
/* C++23 assume attribute is equivalent to GNU's. */
else if (is_attribute_p ("assume", attr_id))
--- gcc/cp/tree.cc.jj 2024-08-15 22:23:07.908239976 +0200
+++ gcc/cp/tree.cc 2024-08-30 13:15:26.863829810 +0200
@@ -5087,6 +5087,25 @@ handle_likeliness_attribute (tree *node,
return error_mark_node;
}
+/* The C++14 [[deprecated]] attribute mostly maps to the GNU deprecated
+ attribute. */
+
+static tree
+handle_std_deprecated_attribute (tree *node, tree name, tree args, int flags,
+bool *no_add_attrs)
+{
+ tree t = *node;
+ tree ret = handle_deprecated_attribute (node, name, args, flags,
+ no_add_attrs);
+ if (TYPE_P (*node) && t != *node)
+pedwarn (input_location, OPT_Wattributes,
+"%qE on a type other than class or enumeration definition", name);
+ else if (TREE_CODE (*node) == FIELD_DECL && DECL_UNNAMED_BIT_FIELD (*node))
+pedwarn (input_location, OPT_Wattributes, "%qE on unnamed bit-field",
+name);
Why not warn about these for the GNU deprecated attribute as well?
Jason
RE: [gcc-wwwdocs PATCH] gcc-15: Mention new ISA and Diamond Rapids support for x86_64 backend
> From: Gerald Pfeifer > Sent: Tuesday, December 17, 2024 3:57 PM > > On Mon, 25 Nov 2024, Jiang, Haochen wrote: > > I will do all of the changes with little tweak here. The "and" should > > be added (actually changed the previous "or" to "and") between > > -mtune=knl and -mtune=knm. > > Thank you. > > I just pushed a little follow up patch, see below. > Thank for your correction on trivial grammar mistakes! :) Thx, Haochen > Gerald > > > commit 7f4a4f377ca5e5fae8ffe6ab45a300799bd75b6f > Author: Gerald Pfeifer > Date: Tue Dec 17 16:54:47 2024 +0900 > > gcc-15: Copy edit Xeon Phi CPU support removal > > diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index > 23866bde..1c690c4a 100644 > --- a/htdocs/gcc-15/changes.html > +++ b/htdocs/gcc-15/changes.html > @@ -242,11 +242,11 @@ a work-in-progress. > CMPccXADD, MOVRS, SHA512, SM3, SM4 and USER_MSR ISA extensions. > >Support for Xeon Phi CPUs (a.k.a. Knight Landing and Knight Mill) were > - removed in GCC 15. GCC will no longer accepts -march=knl, > + removed in GCC 15. GCC will no longer accept > + -march=knl, >-march=knm, -mavx5124fmaps, >-mavx5124vnniw, -mavx512er, >-mavx512pf, -mprefetchwt1, > - -mtune=knl and -mtune=knm compiler > switches. > + -mtune=knl, and -mtune=knm compiler > switches. > > >
[Fortran, Patch, PR117643] Implement F_C_STRING()
All,
First, I would like to thank both mikael and fx for providing
help in my debugging of the in-lining in trans-intrinsic.cc.
It seems I have forgotten much of what I once knew about trees.
I have attached a patch that implements F2023 F_C_STRING() to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
and to this email. This function is provided by ISO_C_BINDING,
and the current implementation in-lines the function when the
intrinsic module is used.
On x86_64-*-freebsd, I have
=== gfortran Summary ===
# of expected passes71796
# of unexpected failures24
# of expected failures 274
# of unsupported tests 87
/usr/home/kargl/gcc/obj/gcc/gfortran version 15.0.0 20241217
(experimental) (GCC)
The unexpected failures are all ASAN or LTO related. Jerryd has
indicated that the patch bootstraps on x86_64_linux_gnu and also
regression tests cleanly. The specific changes are
* check.cc (gfc_check_f_c_string): Check arguments of f_c_string().
* gfortran.h: New symbol GFC_ISYM_F_C_STRING.
* intrinsic.cc (add_functions): Add the ISO C Binding routine f_c_string().
Wrap nearby long line to less than 80 characters.
* intrinsic.h: Prototype for gfc_check_f_c_string().
* iso-c-binding.def: Declare for ISO C Binding routine f_c_string().
* primary.cc (gfc_match_rvalue): Fix comment that has been untrue since 2011.
Add ISOCBINDING_F_C_STRING to conditional.
* trans-intrinsic.cc(conv_trim): Specialized version of trim() for
f_c_string().
(conv_isocbinding_function): Inline implementation of f_c_string().
(gfc_conv_intrinsic_function): Use GFC_ISYM_F_C_STRING to trigger in-lining.
* gfortran.dg/f_c_string1.f90: New testcase.
--
Steve
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index f10e665088d..9b717fb934c 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -1829,6 +1829,42 @@ gfc_check_image_status (gfc_expr *image, gfc_expr *team)
}
+/* Check the arguments for f_c_string. */
+
+bool
+gfc_check_f_c_string (gfc_expr *string, gfc_expr *asis)
+{
+
+ if (gfc_invalid_null_arg (string))
+return false;
+
+ if (!scalar_check (string, 0))
+return false;
+
+ if (string->ts.type != BT_CHARACTER
+ || (string->ts.type == BT_CHARACTER
+ && (string->ts.kind != 1 || string->ts.is_c_interop != 1)))
+{
+ gfc_error ("%qs argument of %qs intrinsic at %L shall have "
+ "a type of CHARACTER(KIND=C_CHAR)",
+ gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
+ &string->where);
+ return false;
+}
+
+ if (asis)
+{
+ if (!type_check (asis, 1, BT_LOGICAL))
+ return false;
+
+ if (!scalar_check (asis, 1))
+ return false;
+}
+
+ return true;
+}
+
+
bool
gfc_check_failed_or_stopped_images (gfc_expr *team, gfc_expr *kind)
{
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d08439019a3..4e82e7b36e5 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -508,6 +508,7 @@ enum gfc_isym_id
GFC_ISYM_EXP,
GFC_ISYM_EXPONENT,
GFC_ISYM_EXTENDS_TYPE_OF,
+ GFC_ISYM_F_C_STRING,
GFC_ISYM_FAILED_IMAGES,
GFC_ISYM_FDATE,
GFC_ISYM_FE_RUNTIME_ERROR,
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index a2e241280c3..c5e423e666a 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -3145,6 +3145,14 @@ add_functions (void)
x, BT_UNKNOWN, 0, REQUIRED);
make_from_module();
+ add_sym_2 ("f_c_string", GFC_ISYM_F_C_STRING, CLASS_TRANSFORMATIONAL,
+ ACTUAL_NO,
+ BT_CHARACTER, dc, GFC_STD_F2023,
+ gfc_check_f_c_string, NULL, NULL,
+ stg, BT_CHARACTER, dc, REQUIRED,
+ "asis", BT_CHARACTER, dc, OPTIONAL);
+ make_from_module();
+
add_sym_1 ("c_sizeof", GFC_ISYM_C_SIZEOF, CLASS_INQUIRY, ACTUAL_NO,
BT_INTEGER, gfc_index_integer_kind, GFC_STD_F2008,
gfc_check_c_sizeof, gfc_simplify_sizeof, NULL,
@@ -3301,7 +3309,8 @@ add_functions (void)
make_generic ("transpose", GFC_ISYM_TRANSPOSE, GFC_STD_F95);
- add_sym_1 ("trim", GFC_ISYM_TRIM, CLASS_TRANSFORMATIONAL, ACTUAL_NO, BT_CHARACTER, dc, GFC_STD_F95,
+ add_sym_1 ("trim", GFC_ISYM_TRIM, CLASS_TRANSFORMATIONAL, ACTUAL_NO,
+ BT_CHARACTER, dc, GFC_STD_F95,
gfc_check_trim, gfc_simplify_trim, gfc_resolve_trim,
stg, BT_CHARACTER, dc, REQUIRED);
diff --git a/gcc/fortran/intrinsic.h b/gcc/fortran/intrinsic.h
index 61d85eedc69..640d1bc15eb 100644
--- a/gcc/fortran/intrinsic.h
+++ b/gcc/fortran/intrinsic.h
@@ -71,6 +71,7 @@ bool gfc_check_dshift (gfc_expr *, gfc_expr *, gfc_expr *);
bool gfc_check_eoshift (gfc_expr *, gfc_expr *, gfc_expr *, gfc_expr *);
bool gfc_check_dtime_etime (gfc_expr *);
bool gfc_check_event_query (gfc_expr *, gfc_expr *, gfc_expr *);
+bool gfc_check_f_c_string (gfc_expr *, gfc_expr *);
bool gfc_check_failed_or_stopped_images (gfc_expr *, gfc_expr *);
bo
Ping: [RFC PATCH v2] cselib: Reuse VALUEs on reg adjustments
Hi all! I would like to ping the patch in https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670763.html (Message-Id: <20241204045717.12982-1-garth...@linux.alibaba.com>). It is supposed to be a generalization of the existing stack pointer VALUE reuse mechanism, based on Jakub's commit 2c0fa3ecf70d199af18785702e9e0548fd3ab793. Could anyone review this? Thanks, Bohan
Re: [PATCH] c++: Handle attributes on exception declarations [PR110345]
On 9/5/24 3:15 AM, Jakub Jelinek wrote:
Hi!
This is a continuation of the series for the ignorability of standard
attributes, on top of
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661906.html
I've added a test for assume attribute diagnostics appertaining to various
entities (mostly invalid) and while doing that, I've discovered that
attributes on exception declarations were mostly ignored, this patch
adds the missing cp_decl_attributes call and also in the
cp_parser_type_specifier_seq case differentiates between attributes and
std_attributes to be able to differentiate between attributes which apply
to the declaration using type-specifier-seq and attributes after the type
specifiers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-09-05 Jakub Jelinek
PR c++/110345
* parser.cc (cp_parser_type_specifier_seq): Chain cxx11_attribute_p
attributes after any type specifier in the is_declaration case
to std_attributes rather than attributes. Set also ds_attribute
or ds_std_attribute locations if not yet set.
(cp_parser_exception_declaration): Pass &type_specifiers.attributes
instead of NULL as last argument, call cp_decl_attributes.
* g++.dg/cpp0x/attr-assume1.C: New test.
* g++.dg/cpp0x/attr-deprecated1.C: Add tests for attributes
after type specifiers before parameter or exception declarations
and after parameter or exception declaration declarators.
--- gcc/cp/parser.cc.jj 2024-09-04 12:36:51.903244117 +0200
+++ gcc/cp/parser.cc2024-09-04 15:13:22.875960509 +0200
@@ -25375,9 +25375,24 @@ cp_parser_type_specifier_seq (cp_parser*
|| tok->type == CPP_EQ || tok->type == CPP_OPEN_BRACE)
break;
}
- type_specifier_seq->attributes
- = attr_chainon (type_specifier_seq->attributes,
- cp_parser_attributes_opt (parser));
+ location_t attr_loc = cp_lexer_peek_token (parser->lexer)->location;
+ tree attrs = cp_parser_attributes_opt (parser);
+ if (seen_type_specifier
+ && is_declaration
+ && cxx11_attribute_p (attrs))
+ {
+ type_specifier_seq->std_attributes
+ = attr_chainon (type_specifier_seq->std_attributes, attrs);
+ if (type_specifier_seq->locations[ds_std_attribute] == 0)
+ type_specifier_seq->locations[ds_std_attribute] = attr_loc;
+ }
+ else
+ {
+ type_specifier_seq->attributes
+ = attr_chainon (type_specifier_seq->attributes, attrs);
+ if (type_specifier_seq->locations[ds_attribute] == 0)
+ type_specifier_seq->locations[ds_attribute] = attr_loc;
+ }
continue;
}
@@ -29630,7 +29645,12 @@ cp_parser_exception_declaration (cp_pars
if (!type_specifiers.any_specifiers_p)
return error_mark_node;
- return grokdeclarator (declarator, &type_specifiers, CATCHPARM, 1, NULL);
+ tree decl = grokdeclarator (declarator, &type_specifiers, CATCHPARM, 1,
+ &type_specifiers.attributes);
+ if (decl != error_mark_node && type_specifiers.attributes)
+cplus_decl_attributes (&decl, type_specifiers.attributes, 0);
+
+ return decl;
}
/* Parse a throw-expression.
--- gcc/testsuite/g++.dg/cpp0x/attr-assume1.C.jj2024-09-04
12:47:19.356072957 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-assume1.C 2024-09-04 15:28:42.486057664
+0200
@@ -0,0 +1,151 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+ [[assume (n > 0)]];
+ [[assume]]; // { dg-error "wrong number of
arguments specified for 'assume' attribute" }
+ [[assume ("abc")]];
+ [[assume (1, 2, 3)]];// { dg-error "wrong number
of arguments specified for 'assume' attribute" }
+
+ [[assume (true)]] int x1;// { dg-error "'assume' attribute
ignored" }
+
+ auto a = [] [[assume (true)]] () {}; // { dg-error "'assume' attribute
ignored" }
+ auto b = [] constexpr [[assume (true)]] {}; // { dg-error "'assume' attribute
ignored" }
+ // { dg-error "parameter declaration before
lambda declaration specifiers only optional with" "" { target c++20_down } .-1 }
+ // { dg-error "'constexpr' lambda only
available with" "" { target c++14_down } .-2 }
+ auto c = [] noexcept [[assume (true)]] {}; // { dg-error "'assume' attribute
ignored" }
+ // { dg-error "parameter declaration before
lambda e
Re: [PATCH] c++: Fix up pedantic handling of alignas [PR110345]
On 9/6/24 2:37 PM, Jakub Jelinek wrote:
Hi!
The following patch on top of the PR110345 P2552R3 series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661906.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662330.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662331.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662333.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662334.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662336.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
emits pedantic pedwarns for alignas appertaining to incorrect entities.
As the middle-end and attribute exclusions look for "aligned" attribute,
the patch transforms alignas into "internal "::aligned attribute (didn't
use [[aligned (x)]] so that people can't type it that way).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-09-06 Jakub Jelinek
PR c++/110345
gcc/c-family/
* c-common.h (attr_aligned_exclusions): Declare.
(handle_aligned_attribute): Likewise.
* c-attribs.cc (handle_aligned_attribute): No longer
static.
(attr_aligned_exclusions): Use extern instead of static.
gcc/cp/
* cp-tree.h (enum cp_tree_index): Add CPTI_INTERNAL_IDENTIFIER.
(internal_identifier): Define.
(internal_attribute_table): Declare.
* parser.cc (cp_parser_exception_declaration): Error on alignas
on exception declaration.
(cp_parser_std_attribute_spec): Turn alignas into internal
ns aligned attribute rather than gnu.
* decl.cc (initialize_predefined_identifiers): Initialize
internal_identifier.
* tree.cc (handle_alignas_attribute): New function.
(internal_attributes): New variable.
(internal_attribute_table): Likewise.
* cp-objcp-common.h (cp_objcp_attribute_table): Add
internal_attribute_table entry.
gcc/testsuite/
* g++.dg/cpp0x/alignas1.C: Add dg-options "".
* g++.dg/cpp0x/alignas2.C: Likewise.
* g++.dg/cpp0x/alignas7.C: Likewise.
* g++.dg/cpp0x/alignas21.C: New test.
* g++.dg/ext/bitfield9.C: Expect a warning.
* g++.dg/cpp2a/is-layout-compatible3.C: Add dg-options -pedantic.
Expect a warning.
--- gcc/c-family/c-common.h.jj 2024-09-06 13:43:37.311307920 +0200
+++ gcc/c-family/c-common.h 2024-09-06 15:33:47.497616169 +0200
@@ -1645,8 +1645,10 @@ extern int parse_tm_stmt_attr (tree, int
extern int tm_attr_to_mask (tree);
extern tree tm_mask_to_attr (int);
extern tree find_tm_attribute (tree);
+extern const struct attribute_spec::exclusions attr_aligned_exclusions[];
extern const struct attribute_spec::exclusions attr_cold_hot_exclusions[];
extern const struct attribute_spec::exclusions attr_noreturn_exclusions[];
+extern tree handle_aligned_attribute (tree *, tree, tree, int, bool *);
extern tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
extern tree handle_musttail_attribute (tree *, tree, tree, int, bool *);
extern bool has_attribute (location_t, tree, tree, tree (*)(tree));
--- gcc/c-family/c-attribs.cc.jj2024-09-06 13:43:37.300308064 +0200
+++ gcc/c-family/c-attribs.cc 2024-09-06 16:00:55.864465359 +0200
@@ -100,7 +100,6 @@ static tree handle_destructor_attribute
static tree handle_mode_attribute (tree *, tree, tree, int, bool *);
static tree handle_section_attribute (tree *, tree, tree, int, bool *);
static tree handle_special_var_sec_attribute (tree *, tree, tree, int, bool
*);
-static tree handle_aligned_attribute (tree *, tree, tree, int, bool *);
static tree handle_warn_if_not_aligned_attribute (tree *, tree, tree,
int, bool *);
static tree handle_strict_flex_array_attribute (tree *, tree, tree,
@@ -192,7 +191,7 @@ static tree handle_null_terminated_strin
{ name, function, type, variable }
/* Define attributes that are mutually exclusive with one another. */
-static const struct attribute_spec::exclusions attr_aligned_exclusions[] =
+extern const struct attribute_spec::exclusions attr_aligned_exclusions[] =
{
/* Attribute name exclusion applies to:
function, type, variable */
@@ -2806,7 +2805,7 @@ common_handle_aligned_attribute (tree *n
/* Handle a "aligned" attribute; arguments as in
struct attribute_spec.handler. */
-static tree
+tree
handle_aligned_attribute (tree *node, tree name, tree args,
int flags, bool *no_add_attrs)
{
--- gcc/cp/cp-tree.h.jj 2024-09-06 13:58:09.428940803 +0200
+++ gcc/cp/cp-tree.h2024-09-06 15:51:23.012904
Re: [PATCH] c++: Diagnose attributes on class/enum declarations [PR110345]
On 8/30/24 1:31 PM, Jakub Jelinek wrote:
Hi!
The following testcase shows another issue where we just ignored
attributes without telling user we did that.
If there are any declarators, the ignoring of the attribute
are diagnosed in grokdeclarator etc., but if there is none
(and we don't error such as on
int;
), the following patch emits diagnostics.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-08-30 Jakub Jelinek
PR c++/110345
* decl.cc (check_tag_decl): Diagnose std_attributes.
* g++.dg/cpp0x/gen-attrs-86.C: New test.
--- gcc/cp/decl.cc.jj 2024-08-30 11:47:55.341290872 +0200
+++ gcc/cp/decl.cc 2024-08-30 15:53:31.259185581 +0200
@@ -5775,6 +5775,14 @@ check_tag_decl (cp_decl_specifier_seq *d
warn_misplaced_attr_for_class_type (loc, declared_type);
}
+ if (declspecs->std_attributes
+ && declared_type
+ && any_nonignored_attribute_p (declspecs->std_attributes)
+ && warning_at (declspecs->locations[ds_std_attribute], OPT_Wattributes,
+"attribute ignored"))
+inform (declspecs->locations[ds_std_attribute],
+ "an attribute that appertains to a type-specifier is ignored");
This seems to need auto_diagnostic_group. OK with that fixed.
+
/* Diagnose invalid application of contracts, if any. */
if (find_contract (declspecs->attributes))
diagnose_misapplied_contracts (declspecs->attributes);
--- gcc/testsuite/g++.dg/cpp0x/gen-attrs-86.C.jj2024-08-30
15:54:50.010180205 +0200
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-86.C 2024-08-30 15:55:29.030682043
+0200
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++11 } }
+
+struct S {};
+struct S [[gnu::deprecated]]; // { dg-warning "attribute ignored" }
+// { dg-message "an attribute that appertains to a type-specifier is ignored"
"" { target *-*-* } .-1 }
+enum E {};
+enum E [[gnu::deprecated]];// { dg-warning "attribute ignored" }
+// { dg-message "an attribute that appertains to a type-specifier is ignored"
"" { target *-*-* } .-1 }
Jakub
[PATCH] libstdc++: Fix std::deque::emplace calling wrong _M_insert_aux [PR90389]
We have several overloads of std::deque::_M_insert_aux, one of which is
variadic and called by std::deque::emplace. With a suitable set of
arguments to emplace, it's possible for one of the non-variadic
_M_insert_aux overloads to be selected by overload resolution, making
emplace ill-formed.
Rename the variadic _M_insert_aux to _M_emplace_aux so that calls to
emplace never select an _M_insert_aux overload. Also add an inline
_M_insert_aux for the const lvalue overload that is called from
insert(const_iterator, const value_type&).
libstdc++-v3/ChangeLog:
PR libstdc++/90389
* include/bits/deque.tcc (_M_insert_aux): Rename variadic
overload to _M_emplace_aux.
* include/bits/stl_deque.h (_M_insert_aux): Define inline.
(_M_emplace_aux): Declare.
* testsuite/23_containers/deque/modifiers/emplace/90389.cc: New
test.
---
Tested x86_64-linux.
libstdc++-v3/include/bits/deque.tcc | 6 +--
libstdc++-v3/include/bits/stl_deque.h | 6 ++-
.../deque/modifiers/emplace/90389.cc | 43 +++
3 files changed, 51 insertions(+), 4 deletions(-)
create mode 100644
libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/90389.cc
diff --git a/libstdc++-v3/include/bits/deque.tcc
b/libstdc++-v3/include/bits/deque.tcc
index 05929e9f812..c69ebb36df1 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -200,8 +200,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
return __tmp;
}
else
- return _M_insert_aux(__position._M_const_cast(),
- std::forward<_Args>(__args)...);
+ return _M_emplace_aux(__position._M_const_cast(),
+ std::forward<_Args>(__args)...);
}
#endif
@@ -646,7 +646,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
template
typename deque<_Tp, _Alloc>::iterator
deque<_Tp, _Alloc>::
- _M_insert_aux(iterator __pos, _Args&&... __args)
+ _M_emplace_aux(iterator __pos, _Args&&... __args)
{
value_type __x_copy(std::forward<_Args>(__args)...); // XXX copy
#else
diff --git a/libstdc++-v3/include/bits/stl_deque.h
b/libstdc++-v3/include/bits/stl_deque.h
index dd1212793de..899e46f6ad1 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -2059,9 +2059,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
iterator
_M_insert_aux(iterator __pos, const value_type& __x);
#else
+ iterator
+ _M_insert_aux(iterator __pos, const value_type& __x)
+ { return _M_emplace_aux(__pos, __x); }
+
template
iterator
- _M_insert_aux(iterator __pos, _Args&&... __args);
+ _M_emplace_aux(iterator __pos, _Args&&... __args);
#endif
// called by insert(p,n,x) via fill_insert
diff --git
a/libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/90389.cc
b/libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/90389.cc
new file mode 100644
index 000..b4932498700
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/90389.cc
@@ -0,0 +1,43 @@
+// { dg-do run { target c++11 } }
+
+// Bug 90389 - std::deque::emplace tries to call wrong overload internally
+
+#include
+#include
+
+struct X
+{
+ X() = default;
+ X(void*, void*, std::size_t) { }
+};
+
+void
+test_pr90389()
+{
+ const int n = 3;
+ std::deque d(n);
+ d.emplace(d.begin(), nullptr, nullptr, d.size());
+ VERIFY( d.size() == n+1 );
+}
+
+struct Y
+{
+ Y() = default;
+ Y(std::size_t, const Y&) { }
+};
+
+void
+test_pr118079()
+{
+ const int n = 3;
+ std::deque d(n);
+ const Y y{};
+ d.emplace(d.begin(), d.size(), y);
+ VERIFY( d.size() == n+1 );
+}
+
+int main()
+{
+ test_pr90389();
+ test_pr118079();
+}
--
2.47.1
[PATCH] libstdc++: Add missing character to __to_wstring_numeric map
The mapping from char to wchar_t needs to handle 'i' and 'I' but those were absent from the table that is used for some non-ASCII encodings. libstdc++-v3/ChangeLog: * include/bits/basic_string.h (__to_wstring_numeric): Add 'i' and 'I' to mapping. --- Tested x86_64-linux. libstdc++-v3/include/bits/basic_string.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h index 8369c24d3ae..431ca486ddb 100644 --- a/libstdc++-v3/include/bits/basic_string.h +++ b/libstdc++-v3/include/bits/basic_string.h @@ -4575,6 +4575,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 __wc['d'] = L'd'; __wc['e'] = L'e'; __wc['f'] = L'f'; + __wc['i'] = L'i'; // for "inf" __wc['n'] = L'n'; // for "nan" and "inf" __wc['p'] = L'p'; // for hexfloats "0x1p1" __wc['x'] = L'x'; @@ -4584,6 +4585,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 __wc['D'] = L'D'; __wc['E'] = L'E'; __wc['F'] = L'F'; + __wc['I'] = L'I'; __wc['N'] = L'N'; __wc['P'] = L'P'; __wc['X'] = L'X'; -- 2.47.1
[PATCH] ifcombine field merge: handle bitfield zero tests in range tests
Some bitfield compares with zero are optimized to range tests, so
instead of X & ~(Bit - 1) != 0 what reaches ifcombine is X > (Bit - 1),
where Bit is a power of two and X is unsigned.
This patch recognizes this optimized form of masked compares, and
attempts to merge them like masked compares, which enables some more
field merging that a folder version of fold_truth_andor used to handle
without additional effort.
I haven't seen X & ~(Bit - 1) == 0 become X <= (Bit - 1), or X < Bit
for that matter, but it was easy enough to handle the former
symmetrically to the above.
The latter was also easy enough, and so was its symmetric, X >= Bit,
that is handled like X & ~(Bit - 1) != 0.
Regstrapped on x86_64-linux-gnu and ppc64-linux-gnu, along with 4 other
ifcombine patches. Ok to install?
for gcc/ChangeLog
* gimple-fold.cc (decode_field_reference): Accept incoming
mask.
(fold_truth_andor_for_ifcombine): Handle some compares with
powers of two, minus 1 or 0, like masked compares with zero.
for gcc/testsuite/ChangeLog
* gcc.dg/field-merge-15.c: New.
---
gcc/gimple-fold.cc| 71 -
gcc/testsuite/gcc.dg/field-merge-15.c | 36 +
2 files changed, 104 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/field-merge-15.c
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 06913d57f8aec..856ee5369a8c9 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -7509,8 +7509,10 @@ gimple_binop_def_p (enum tree_code code, tree t, tree
op[2])
*PREVERSEP is set to the storage order of the field.
- *PAND_MASK is set to the mask found in a BIT_AND_EXPR, if any.
- If PAND_MASK *is NULL, BIT_AND_EXPR is not recognized.
+ *PAND_MASK is set to the mask found in a BIT_AND_EXPR, if any. If
+ PAND_MASK *is NULL, BIT_AND_EXPR is not recognized. If *PAND_MASK
+ is initially set to a mask with nonzero precision, that mask is
+ combined with the found mask, or adjusted in precision to match.
*XOR_P is to be FALSE if EXP might be a XOR used in a compare, in which
case, if XOR_CMP_OP is a zero constant, it will be overridden with *PEXP,
@@ -7561,14 +7563,30 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
exp = res_ops[0];
}
- /* Recognize and save a masking operation. */
+ /* Recognize and save a masking operation. Combine it with an
+ incoming mask. */
if (pand_mask && gimple_binop_def_p (BIT_AND_EXPR, exp, res_ops)
&& uniform_integer_cst_p (res_ops[1]))
{
loc[1] = gimple_location (SSA_NAME_DEF_STMT (exp));
exp = res_ops[0];
and_mask = wi::to_wide (res_ops[1]);
+ unsigned prec_in = pand_mask->get_precision ();
+ if (prec_in)
+ {
+ unsigned prec_op = and_mask.get_precision ();
+ if (prec_in >= prec_op)
+ {
+ if (prec_in > prec_op)
+ and_mask = wide_int::from (and_mask, prec_in, UNSIGNED);
+ and_mask &= *pand_mask;
+ }
+ else
+ and_mask &= wide_int::from (*pand_mask, prec_op, UNSIGNED);
+ }
}
+ else if (pand_mask)
+and_mask = *pand_mask;
/* Turn (a ^ b) [!]= 0 into a [!]= b. */
if (xor_p && gimple_binop_def_p (BIT_XOR_EXPR, exp, res_ops)
@@ -8019,6 +8037,8 @@ fold_truth_andor_for_ifcombine (enum tree_code code, tree
truth_type,
return 0;
}
+ /* Prepare to turn compares of signed quantities with zero into
+ sign-bit tests. */
bool lsignbit = false, rsignbit = false;
if ((lcode == LT_EXPR || lcode == GE_EXPR)
&& integer_zerop (lr_arg)
@@ -8028,6 +8048,31 @@ fold_truth_andor_for_ifcombine (enum tree_code code,
tree truth_type,
lsignbit = true;
lcode = (lcode == LT_EXPR ? NE_EXPR : EQ_EXPR);
}
+ /* Turn compares of unsigned quantities with powers of two into
+ equality tests of masks. */
+ else if ((lcode == LT_EXPR || lcode == GE_EXPR)
+ && INTEGRAL_TYPE_P (TREE_TYPE (ll_arg))
+ && TYPE_UNSIGNED (TREE_TYPE (ll_arg))
+ && uniform_integer_cst_p (lr_arg)
+ && wi::popcount (wi::to_wide (lr_arg)) == 1)
+{
+ ll_and_mask = ~(wi::to_wide (lr_arg) - 1);
+ lcode = (lcode == GE_EXPR ? NE_EXPR : EQ_EXPR);
+ lr_arg = wide_int_to_tree (TREE_TYPE (ll_arg), ll_and_mask * 0);
+}
+ /* Turn compares of unsigned quantities with powers of two minus one
+ into equality tests of masks. */
+ else if ((lcode == LE_EXPR || lcode == GT_EXPR)
+ && INTEGRAL_TYPE_P (TREE_TYPE (ll_arg))
+ && TYPE_UNSIGNED (TREE_TYPE (ll_arg))
+ && uniform_integer_cst_p (lr_arg)
+ && wi::popcount (wi::to_wide (lr_arg) + 1) == 1)
+{
+ ll_and_mask = ~wi::to_wide (lr_arg);
+ lcode = (lcode == GT_EXPR ? NE_EXPR : EQ_EXPR);
+ lr_arg = wide_int_to_tree (TREE_TYPE (ll_arg), ll_and_mask * 0);
+}
+ /* Likewise for the second compare
Re: [PATCH] noncontiguous ifcombine: skip marking of non-SSA_NAMEs [PR117915]
On Dec 17, 2024, Sam James wrote:
>> +/* { dg-options "-O3 -fno-tree-copy-prop -fno-tree-vrp" */
> Missing closing '}'.
Thanks, I've fixed that, and retested.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [COMMITTED] Documentation: Make OpenMP/OpenACC docs easier to find [PR26154]
On 12/17/24 14:21, Tobias Burnus wrote:
Hi Sandra,
thanks for the patch! One minor nit:
Sandra Loosemore wrote:
+To enable the processing of OpenACC directives @samp{#pragma omp}
#pragma acc – not #pragma omp.
Sigh, I need to get new glasses! Fixed with the attached patch.
-SandraFrom b34fbab529e64dbeb6db70263e35373c200f899a Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Wed, 18 Dec 2024 03:51:54 +
Subject: [PATCH] Documentation: Fix paste-o in recent OpenMP/OpenACC patch
gcc/ChangeLog
* doc/extend.texi (OpenACC): Fix paste-o.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 54465ddc23a..f045159963e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -29403,7 +29403,7 @@ GCC strives to be compatible with the
@uref{https://www.openacc.org/, OpenACC Application Programming
Interface v2.6}.
-To enable the processing of OpenACC directives @samp{#pragma omp}
+To enable the processing of OpenACC directives @samp{#pragma acc}
in C and C++, GCC needs to be invoked with the @option{-fopenacc} option.
This option also arranges for automatic linking of the OpenACC runtime
library.
--
2.25.1
Re: [PATCH] c++: Add carries_dependency further test coverage [PR110345]
On 9/5/24 3:17 AM, Jakub Jelinek wrote:
Hi!
This patch adds additional test coverage for the carries_dependency
attribute (unlike other attributes, the attribute actually isn't implemented
for real, so we warn even in the cases of valid uses because we ignore those
as well).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-carries_dependency2.C: New test.
--- gcc/testsuite/g++.dg/cpp0x/attr-carries_dependency2.C.jj2024-09-04
15:42:01.250738751 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-carries_dependency2.C 2024-09-04
16:21:50.416239580 +0200
@@ -0,0 +1,152 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+xyzzy (int *a [[carries_dependency]], // { dg-warning
"'carries_dependency' attribute ignored" }
+ int *b [[carries_dependency (1)]]) // { dg-error
"'carries_dependency' attribute does not take any arguments" }
+{ // { dg-error "expected ',' or '...'
before 'b'" "" { target *-*-* } .-1 }
+}
+
+void
+foo (int n)
+{
+ [[carries_dependency]] int x1; // { dg-warning
"'carries_dependency' attribute can only be applied to functions or parameters"
}
+
+ auto a = [] [[carries_dependency]] () {};// { dg-warning
"'carries_dependency' attribute ignored" }
+ auto b = [] constexpr [[carries_dependency]] {}; // { dg-warning
"'carries_dependency' attribute does not apply to types" }
+ // { dg-error "parameter declaration
before lambda declaration specifiers only optional with" "" { target c++20_down }
.-1 }
+ // { dg-error "'constexpr' lambda only
available with" "" { target c++14_down } .-2 }
+ auto c = [] noexcept [[carries_dependency]] {}; // { dg-warning
"'carries_dependency' attribute does not apply to types" }
+ // { dg-error "parameter declaration
before lambda exception specification only optional with" "" { target c++20_down }
.-1 }
+ auto d = [] () [[carries_dependency]] {};// { dg-warning
"'carries_dependency' attribute does not apply to types" }
+ auto e = new int [n] [[carries_dependency]]; // { dg-warning "attributes
ignored on outermost array type in new expression" }
+ auto e2 = new int [n] [[carries_dependency]] [42]; // { dg-warning "attributes
ignored on outermost array type in new expression" }
+ auto f = new int [n][42] [[carries_dependency]]; // { dg-warning
"'carries_dependency' attribute does not apply to types" }
+ [[carries_dependency]]; // { dg-warning "attributes
at the beginning of statement are ignored" }
+ [[carries_dependency]] {}// { dg-warning "attributes
at the beginning of statement are ignored" }
+ [[carries_dependency]] if (true) {} // { dg-warning "attributes
at the beginning of statement are ignored" }
+ [[carries_dependency]] while (false) {} // { dg-warning "attributes
at the beginning of statement are ignored" }
+ [[carries_dependency]] goto lab; // { dg-warning "attributes
at the beginning of statement are ignored" }
+ [[carries_dependency]] lab:; // { dg-warning
"'carries_dependency' attribute can only be applied to functions or parameters"
}
+ [[carries_dependency]] try {} catch (int) {} // { dg-warning "attributes
at the beginning of statement are ignored" }
+ if ([[carries_dependency]] int x = 0) {} // { dg-warning
"'carries_dependency' attribute can only be applied to functions or parameters"
}
+ switch (n)
+{
+[[carries_dependency]] case 1: // { dg-warning
"'carries_dependency' attribute can only be applied to functions or parameters"
}
+[[carries_dependency]] break; // { dg-warning "attributes
at the beginning of statement are ignored" }
+[[carries_dependency]] default:// { dg-warning
"'carries_dependency' attribute can only be applied to functions or parameters"
}
+break;
+}
+ for ([[carries_dependency]] auto a : arr) {} // { dg-warning
"'carries_dependency' attribute can only be applied to functions or parameters"
}
+ for ([[carries_dependency]] auto [a, b] : arr2) {} // { dg-warning
"'carries_dependency' attribute can only be applied to functions or parameters"
}
+ // { dg-error "structured bindings
only available with" "" { target c++14_down } .-1 }
+ [[carries_dependency]] asm (""); // { dg-warning "attributes
ignored on 'asm' declaration" }
+
Re: [PATCH] c++: Add fallthrough attribute further test coverage [PR110345]
On 9/5/24 3:19 AM, Jakub Jelinek wrote:
Hi!
Similarly for fallthrough attribute. Had to add a second testcase because
the diagnostics for fallthrough not used within switch at all is done during
expansion and expansion won't happen if there are other errors in the
testcase.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-fallthrough1.C: New test.
* g++.dg/cpp0x/attr-fallthrough2.C: New test.
--- gcc/testsuite/g++.dg/cpp0x/attr-fallthrough1.C.jj 2024-09-04
16:27:52.786654084 +0200
+++ gcc/testsuite/g++.dg/cpp0x/attr-fallthrough1.C 2024-09-04
16:44:41.879666097 +0200
@@ -0,0 +1,169 @@
+// C++ 26 P2552R3 - On the ignorability of standard attributes
+// { dg-do compile { target c++11 } }
+
+int arr[2];
+struct S { int a, b; };
+S arr2[2];
+
+void
+foo (int n)
+{
+ switch (n)
+{
+case 1:
+ [[fallthrough (n > 0)]]; // { dg-error "'fallthrough'
attribute does not take any arguments" }
+case 2:
+ break;
+case 3:
+ [[fallthrough]];
+case 4:
+ break;
+case 5:
+ [[fallthrough ("abc")]]; // { dg-error "'fallthrough'
attribute does not take any arguments" }
+case 6:
+ break;
+case 7:
+ [[fallthrough (1, 2, 3)]]; // { dg-error "'fallthrough'
attribute does not take any arguments" }
+case 8:
+ [[fallthrough]]; // { dg-error "attribute
'fallthrough' not preceding a case label or default label" }
+ foo (n - 1);
+ break;
+default:
+ break;
+}
+
+ [[fallthrough]] int x1; // { dg-error "'fallthrough'
attribute ignored" }
+
+ auto a = [] [[fallthrough]] () {}; // { dg-error "'fallthrough'
attribute ignored" }
+ auto b = [] constexpr [[fallthrough]] {};// { dg-error "'fallthrough'
attribute ignored" }
+ // { dg-error "parameter declaration before
lambda declaration specifiers only optional with" "" { target c++20_down } .-1 }
+ // { dg-error "'constexpr' lambda only
available with" "" { target c++14_down } .-2 }
+ auto c = [] noexcept [[fallthrough]] {}; // { dg-error "'fallthrough'
attribute ignored" }
+ // { dg-error "parameter declaration before
lambda exception specification only optional with" "" { target c++20_down } .-1 }
+ auto d = [] () [[fallthrough]] {}; // { dg-error "'fallthrough'
attribute ignored" }
+ auto e = new int [n] [[fallthrough]];// { dg-warning "attributes
ignored on outermost array type in new expression" }
+ auto e2 = new int [n] [[fallthrough]] [42]; // { dg-warning "attributes ignored
on outermost array type in new expression" }
+ auto f = new int [n][42] [[fallthrough]];// { dg-error "'fallthrough'
attribute ignored" }
+ [[fallthrough]] {} // { dg-warning "attributes at the
beginning of statement are ignored" }
+ [[fallthrough]] if (true) {} // { dg-warning "attributes at the
beginning of statement are ignored" }
+ [[fallthrough]] while (false) {} // { dg-warning "attributes at the
beginning of statement are ignored" }
+ [[fallthrough]] goto lab;// { dg-warning "attributes at the
beginning of statement are ignored" }
+ [[fallthrough]] lab:;// { dg-error "'fallthrough'
attribute ignored" }
+ [[fallthrough]] try {} catch (int) {}// { dg-warning "attributes
at the beginning of statement are ignored" }
+ if ([[fallthrough]] int x = 0) {}// { dg-error "'fallthrough'
attribute ignored" }
+ switch (n)
+{
+[[fallthrough]] case 1:// { dg-error "'fallthrough'
attribute ignored" }
+[[fallthrough]] break; // { dg-warning "attributes at the
beginning of statement are ignored" }
+[[fallthrough]] default: // { dg-error "'fallthrough'
attribute ignored" }
+break;
+}
+ for ([[fallthrough]] auto a : arr) {}// { dg-error "'fallthrough'
attribute ignored" }
+ for ([[fallthrough]] auto [a, b] : arr2) {} // { dg-error "'fallthrough'
attribute ignored" }
+ // { dg-error "structured bindings only
available with" "" { target c++14_down } .-1 }
+ [[fallthrough]] asm (""); // { dg-warning "attributes ignored on
'asm' declaration" }
+ try {} catch ([[fallthrough]] int x) {} // { dg-error "'fallthrough'
attribute ignored" }
+ try {} catch ([[fallthrough]] int) {}// { dg-error "'fallthrough'
attribute ignored" }
+ try {} catch (int [[fallthrough]] x) {} // { dg-warning "attribute
ignored" }
+ try {} catch (int [[fallthrough]]) {}
Re: [PATCH] c++: Handle enum attributes like class attributes [PR110345]
On 8/30/24 1:29 PM, Jakub Jelinek wrote:
Hi!
As the following testcase shows, cp_parser_decl_specifier_seq
was calling warn_misplaced_attr_for_class_type only for class types
and not for enum types, while check_tag_decl calls them for both
class and enum types.
Enum types are really the same case here, the attribute needs to go
before the type name to apply to all instances of the type.
Additionally, when warn_misplaced_attr_for_class_type is called, it
diagnoses something and so it is fine to drop the attributes then
on the floor, but in case it wasn't a type decision, it silently
discarded the attributes, which is invalid for the ignorability of
standard attributes paper. This patch in that case adds them to
decl_specs->std_attributes and let it be diagnosed later (e.g.
in grokdeclarator).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-08-30 Jakub Jelinek
PR c++/110345
* parser.cc (cp_parser_decl_specifier_seq): Call
warn_misplaced_attr_for_class_type for all OVERLOAD_TYPE_P
types, not just CLASS_TYPE_P. When not calling
warn_misplaced_attr_for_class_type, don't clear attrs and
add it to decl_specs->std_attributes instead.
* g++.dg/cpp0x/gen-attrs-85.C: New test.
--- gcc/cp/parser.cc.jj 2024-08-30 12:55:17.875362909 +0200
+++ gcc/cp/parser.cc2024-08-30 13:44:42.485290076 +0200
@@ -16565,13 +16565,13 @@ cp_parser_decl_specifier_seq (cp_parser*
diagnose_misapplied_contracts (attrs);
attrs = NULL_TREE;
}
- else if (decl_specs->type && CLASS_TYPE_P (decl_specs->type))
+ else if (decl_specs->type
+ && decl_specs->type_definition_p
+ && OVERLOAD_TYPE_P (decl_specs->type))
{
- /* This is an attribute following a
- class-specifier. */
- if (decl_specs->type_definition_p)
- warn_misplaced_attr_for_class_type (token->location,
- decl_specs->type);
+ /* This is an attribute following a class-specifier. */
+ warn_misplaced_attr_for_class_type (token->location,
+ decl_specs->type);
attrs = NULL_TREE;
}
else
--- gcc/testsuite/g++.dg/cpp0x/gen-attrs-85.C.jj2024-08-30
13:54:12.356968839 +0200
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-85.C 2024-08-30 13:54:05.846052485
+0200
@@ -0,0 +1,7 @@
+// { dg-do compile { target c++11 } }
+
+struct S {};
+struct S [[gnu::deprecated]] s;// { dg-warning "attribute ignored" }
+// { dg-message "an attribute that appertains to a type-specifier is ignored"
"" { target *-*-* } .-1 }
+enum E {} [[gnu::deprecated]]; // { dg-warning "attribute ignored in declaration of
'enum E'" }
+// { dg-message "attribute for 'enum E' must follow the 'enum' keyword" "" {
target *-*-* } .-1 }
Jakub
Re: [PATCH] c++: Use type_id_in_expr_sentinel in 6 further spots in the parser
On 11/22/24 11:00 AM, Marek Polacek wrote:
On Thu, Sep 19, 2024 at 10:36:01PM +0200, Jakub Jelinek wrote:
Hi!
The following patch uses type_id_in_expr_sentinel in a few spots which
did it all manually.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Nice cleanup. Patch looks good to me.
Agreed, OK.
2024-09-19 Jakub Jelinek
* parser.cc (cp_parser_postfix_expression): Use
type_id_in_expr_sentinel instead of manually saving+setting/restoring
parser->in_type_id_in_expr_p around cp_parser_type_id calls.
(cp_parser_has_attribute_expression): Likewise.
(cp_parser_cast_expression): Likewise.
(cp_parser_sizeof_operand): Likewise.
--- gcc/cp/parser.cc.jj 2024-09-07 09:31:20.708482757 +0200
+++ gcc/cp/parser.cc2024-09-19 10:46:21.916155154 +0200
@@ -7554,7 +7554,6 @@ cp_parser_postfix_expression (cp_parser
tree type;
cp_expr expression;
const char *saved_message;
- bool saved_in_type_id_in_expr_p;
/* All of these can be handled in the same way from the point
of view of parsing. Begin by consuming the token
@@ -7569,11 +7568,11 @@ cp_parser_postfix_expression (cp_parser
/* Look for the opening `<'. */
cp_parser_require (parser, CPP_LESS, RT_LESS);
/* Parse the type to which we are casting. */
- saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p;
- parser->in_type_id_in_expr_p = true;
- type = cp_parser_type_id (parser, CP_PARSER_FLAGS_TYPENAME_OPTIONAL,
- NULL);
- parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p;
+ {
+ type_id_in_expr_sentinel s (parser);
+ type = cp_parser_type_id (parser, CP_PARSER_FLAGS_TYPENAME_OPTIONAL,
+ NULL);
+ }
/* Look for the closing `>'. */
cp_parser_require_end_of_template_parameter_list (parser);
/* Restore the old message. */
@@ -7643,7 +7642,6 @@ cp_parser_postfix_expression (cp_parser
{
tree type;
const char *saved_message;
- bool saved_in_type_id_in_expr_p;
/* Consume the `typeid' token. */
cp_lexer_consume_token (parser->lexer);
@@ -7658,10 +7656,10 @@ cp_parser_postfix_expression (cp_parser
expression. */
cp_parser_parse_tentatively (parser);
/* Try a type-id first. */
- saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p;
- parser->in_type_id_in_expr_p = true;
- type = cp_parser_type_id (parser);
- parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p;
+ {
+ type_id_in_expr_sentinel s (parser);
+ type = cp_parser_type_id (parser);
+ }
/* Look for the `)' token. Otherwise, we can't be sure that
we're not looking at an expression: consider `typeid (int
(3))', for example. */
@@ -7916,10 +7914,8 @@ cp_parser_postfix_expression (cp_parser
else
{
/* Parse the type. */
- bool saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p;
- parser->in_type_id_in_expr_p = true;
+ type_id_in_expr_sentinel s (parser);
type = cp_parser_type_id (parser);
- parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p;
parens.require_close (parser);
}
@@ -9502,11 +9498,11 @@ cp_parser_has_attribute_expression (cp_p
expression. */
cp_parser_parse_tentatively (parser);
- bool saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p;
- parser->in_type_id_in_expr_p = true;
- /* Look for the type-id. */
- oper = cp_parser_type_id (parser);
- parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p;
+ {
+type_id_in_expr_sentinel s (parser);
+/* Look for the type-id. */
+oper = cp_parser_type_id (parser);
+ }
cp_parser_parse_definitely (parser);
@@ -10268,15 +10264,13 @@ cp_parser_cast_expression (cp_parser *pa
cp_parser_simulate_error (parser);
else
{
- bool saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p;
- parser->in_type_id_in_expr_p = true;
+ type_id_in_expr_sentinel s (parser);
/* Look for the type-id. */
type = cp_parser_type_id (parser);
/* Look for the closing `)'. */
cp_token *close_paren = parens.require_close (parser);
if (close_paren)
close_paren_loc = close_paren->location;
- parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p;
}
/* Restore the saved message. */
@@ -34299,13 +34293,11 @@ cp_parser_sizeof_operand (cp_parser* par
cp_parser_simulate_error (parser);
else
{
- bool saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p;
- parser->in_type_id_in_expr_p = true;
+ type_id_in_expr_sentinel s (parser);
[PATCH] ifcombine field merge: handle masks with sign extensions
When a loaded field is sign extended, masked and compared, we used to
drop from the mask the bits past the original field width, which is
not correct.
Take note of the fact that the mask covered copies of the sign bit,
before clipping it, and arrange to test the sign bit if we're
comparing with zero. Punt in other cases.
If bits_test fail recoverably, try other ifcombine strategies.
Regstrapped on x86_64-linux-gnu and ppc64-linux-gnu, along with 5 other
ifcombine patches. Ok to install?
for gcc/ChangeLog
* gimple-fold.cc (decode_field_reference): Add psignbit
parameter. Set it if the mask references sign-extending
bits.
(fold_truth_andor_for_ifcombine): Adjust calls with new
variables. Swap them along with other r?_* variables. Handle
extended sign bit compares with zero.
* tree-ssa-ifcombine.cc (ifcombine_ifandif): If bits_test
fails in a way that doesn't prevent other ifcombine strategies
from passing, give them a try.
for gcc/testsuite/ChangeLog
* gcc.dg/field-merge-16.c: New.
---
gcc/gimple-fold.cc| 69 -
gcc/testsuite/gcc.dg/field-merge-16.c | 66
gcc/tree-ssa-ifcombine.cc |5 +-
3 files changed, 128 insertions(+), 12 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/field-merge-16.c
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 856ee5369a8c9..b84269d6b4179 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -7514,6 +7514,9 @@ gimple_binop_def_p (enum tree_code code, tree t, tree
op[2])
is initially set to a mask with nonzero precision, that mask is
combined with the found mask, or adjusted in precision to match.
+ *PSIGNBIT is set to TRUE if, before clipping to *PBITSIZE, the mask
+ encompassed bits that corresponded to extensions of the sign bit.
+
*XOR_P is to be FALSE if EXP might be a XOR used in a compare, in which
case, if XOR_CMP_OP is a zero constant, it will be overridden with *PEXP,
*XOR_P will be set to TRUE, and the left-hand operand of the XOR will be
@@ -7533,7 +7536,8 @@ static tree
decode_field_reference (tree *pexp, HOST_WIDE_INT *pbitsize,
HOST_WIDE_INT *pbitpos,
bool *punsignedp, bool *preversep, bool *pvolatilep,
- wide_int *pand_mask, bool *xor_p, tree *xor_cmp_op,
+ wide_int *pand_mask, bool *psignbit,
+ bool *xor_p, tree *xor_cmp_op,
gimple **load, location_t loc[4])
{
tree exp = *pexp;
@@ -7545,6 +7549,7 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
machine_mode mode;
*load = NULL;
+ *psignbit = false;
/* All the optimizations using this function assume integer fields.
There are problems with FP fields since the type_for_size call
@@ -7708,12 +7713,23 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
if (outer_type && *pbitsize == TYPE_PRECISION (outer_type))
*punsignedp = TYPE_UNSIGNED (outer_type);
- /* Make the mask the expected width. */
- if (and_mask.get_precision () != 0)
-and_mask = wide_int::from (and_mask, *pbitsize, UNSIGNED);
-
if (pand_mask)
-*pand_mask = and_mask;
+{
+ /* Make the mask the expected width. */
+ if (and_mask.get_precision () != 0)
+ {
+ /* If the AND_MASK encompasses bits that would be extensions of
+the sign bit, set *PSIGNBIT. */
+ if (!unsignedp
+ && and_mask.get_precision () > *pbitsize
+ && (and_mask
+ & wi::mask (*pbitsize, true, and_mask.get_precision ())) != 0)
+ *psignbit = true;
+ and_mask = wide_int::from (and_mask, *pbitsize, UNSIGNED);
+ }
+
+ *pand_mask = and_mask;
+}
return inner;
}
@@ -7995,6 +8011,7 @@ fold_truth_andor_for_ifcombine (enum tree_code code, tree
truth_type,
HOST_WIDE_INT rnbitsize, rnbitpos, rnprec;
bool ll_unsignedp, lr_unsignedp, rl_unsignedp, rr_unsignedp;
bool ll_reversep, lr_reversep, rl_reversep, rr_reversep;
+ bool ll_signbit, lr_signbit, rl_signbit, rr_signbit;
scalar_int_mode lnmode, lnmode2, rnmode;
wide_int ll_and_mask, lr_and_mask, rl_and_mask, rr_and_mask;
wide_int l_const, r_const;
@@ -8114,19 +8131,19 @@ fold_truth_andor_for_ifcombine (enum tree_code code,
tree truth_type,
bool l_xor = false, r_xor = false;
ll_inner = decode_field_reference (&ll_arg, &ll_bitsize, &ll_bitpos,
&ll_unsignedp, &ll_reversep, &volatilep,
-&ll_and_mask, &l_xor, &lr_arg,
+&ll_and_mask, &ll_signbit, &l_xor, &lr_arg,
&ll_load, ll_loc);
lr_inner = decode_field_reference (&lr_arg, &lr_bitsize, &lr_bitpos,
&lr_unsignedp, &lr_revers
Re: [Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.
On Mon, Dec 16, 2024 at 04:53:42AM -0800, Damian Rouson wrote: > including automatic GPU offloading. Then a few months ago, the death blow > that I couldn’t work around was robust support for kind type parameters. > gfortran doesn't have robust kind type parameters? % cat xx.f90 program foo use iso_fortran_env print '(A,*(I0,1X))', ' real kinds: ', real_kinds print '(A,*(I0,1X))', ' integer kinds: ', integer_kinds print '(A,*(I0,1X))', ' logical kinds: ', logical_kinds print '(A,*(I0,1X))', 'character kinds: ', character_kinds end program foo % gfcx -o z xx.f90 && ./z real kinds: 4 8 10 16 integer kinds: 1 2 4 8 16 logical kinds: 1 2 4 8 16 character kinds: 1 4 % ../tmp/lfortran/work/bin/lfortran -o z xx.f90 Segmentation fault (core dumped) % root/build/bin/flang -o z xx.f90 && ./z real kinds: 2 3 4 8 10 integer kinds: 1 2 4 8 16 logical kinds: 1 2 4 8 character kinds: 1 2 4 So, flang supports IEEE binary16 and brain float16, which makes sense as Nvidia has a vested interest in these types. flang does not support IEEE binary128; while gfortran does. flang also has an additional character kind type. Are you doing work with 'CHARACTER(KIND=2)' while not needing a 16-byte logical kind type? Or, perhaps, you care to qualify your generalization? -- steve
[PATCH v2] c++: ICE initializing array of aggrs [PR117985]
On Tue, Dec 17, 2024 at 10:36:09AM -0500, Jason Merrill wrote:
> On 12/16/24 6:48 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
> >
> > -- >8 --
> > This crash started with my r12-7803 but I believe the problem lies
> > elsewhere.
> >
> > build_vec_init has cleanup_flags whose purpose is -- if I grok this
> > correctly -- to avoid destructing an object multiple times. Let's
> > say we are initializing an array of A. Then we might end up in
> > a scenario similar to initlist-eh1.C:
> >
> >try
> > {
> >call A::A in a loop
> >// #0
> >try
> > {
> > call a fn using the array
> > }
> >finally
> > {
> > // #1
> > call A::~A in a loop
> > }
> > }
> >catch
> > {
> >// #2
> >call A::~A in a loop
> > }
> >
> > cleanup_flags makes us emit a statement like
> >
> >D.3048 = 2;
> >
> > at #0 to disable performing the cleanup at #2, since #1 will take
> > care of the destruction of the array.
> >
> > But if we are not emitting the loop because we can use a constant
> > initializer (and use a single { a, b, ...}), we shouldn't generate
> > the statement resetting the iterator to its initial value. Otherwise
> > we crash in gimplify_var_or_parm_decl because it gets the stray decl
> > D.3048.
> >
> > PR c++/117985
> >
> > gcc/cp/ChangeLog:
> >
> > * init.cc (build_vec_init): Clear CLEANUP_FLAGS if we're not
> > generating the loop.
>
> truncate seems dangerous, there might be other things in cleanup_flags that
> we want to leave alone. I think it would be safer to assert that the last
> element in the vec is iterator, and then pop it.
Yeah, that does sound much safer. Like so?
dg.exp passed.
-- >8 --
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times. Let's
say we are initializing an array of A. Then we might end up in
a scenario similar to initlist-eh1.C:
try
{
call A::A in a loop
// #0
try
{
call a fn using the array
}
finally
{
// #1
call A::~A in a loop
}
}
catch
{
// #2
call A::~A in a loop
}
cleanup_flags makes us emit a statement like
D.3048 = 2;
at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.
But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value. Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.
PR c++/117985
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not
generating the loop.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array23.C: New test.
* g++.dg/cpp0x/initlist-array24.C: New test.
---
gcc/cp/init.cc| 9 ++
gcc/testsuite/g++.dg/cpp0x/initlist-array23.C | 28 +++
gcc/testsuite/g++.dg/cpp0x/initlist-array24.C | 27 ++
3 files changed, 64 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index ae516407c92..7dcc1152c72 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -5109,6 +5109,15 @@ build_vec_init (tree base, tree maxindex, tree init,
{
if (!saw_non_const)
{
+ /* If we're not generating the loop, we don't need to reset the
+iterator. */
+ if (cleanup_flags
+ && !vec_safe_is_empty (*cleanup_flags))
+ {
+ auto l = (*cleanup_flags)->last ();
+ gcc_assert (TREE_PURPOSE (l) == iterator);
+ (*cleanup_flags)->pop ();
+ }
tree const_init = build_constructor (atype, const_vec);
return build2 (INIT_EXPR, atype, obase, const_init);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
new file mode 100644
index 000..cda2afb9fcc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
@@ -0,0 +1,28 @@
+// PR c++/117985
+// { dg-do compile { target c++11 } }
+
+struct _Vector_impl {
+ constexpr
+_Vector_impl() {}
+};
+struct _Vector_base {
+ ~_Vector_base();
+ _Vector_impl _M_impl;
+};
+struct vector : private _Vector_base {};
+struct string {
+ string();
+};
+struct VEC {
+ vector pane{};
+};
+struct FOO {
+ VEC screen[1]{};
+ string debug_name;
+};
+
+int
+main ()
+{
+ FOO{};
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
new file mode 100644
ind
RE: [PATCH 2/2][libstdc++]: Adjust probabilities of hashmap loop conditions
> On Fri, 13 Dec 2024 at 17:13, Tamar Christina wrote:
> >
> > Hi All,
> >
> > We are currently generating a loop which has more comparisons than you'd
> > typically need as the probablities on the small size loop are such that it
> > assumes the likely case is that an element is not found.
> >
> > This again generates a pattern that's harder for branch predictors to
> > follow,
> > but also just generates more instructions for the what one could say is the
> > typical case: That your hashtable contains the entry you are looking for.
> >
> > This patch adds a __builtin_expect to indicate that it's likely that you'd
> > find the element that's being searched for.
> >
> > The second change is in _M_find_before_node where at the moment the loop
> > is optimized for the case where we don't do any iterations.
> >
> > A simple testcase is:
> >
> > #include
> >
> > bool foo (int **a, int n, int val, int *tkn)
> > {
> > for (int i = 0; i < n; i++)
> > {
> > if (!a[i] || a[i]==tkn)
> > return false;
> >
> > if (*a[i] == val)
> > return true;
> > }
> > }
> >
> > which generataes:
> >
> > foo:
> > cmp w1, 0
> > ble .L1
> > add x1, x0, w1, uxtw 3
> > b .L4
> > .L9:
> > ldr w4, [x4]
> > cmp w4, w2
> > beq .L6
> > cmp x0, x1
> > beq .L1
> > .L4:
> > ldr x4, [x0]
> > add x0, x0, 8
> > cmp x4, 0
> > ccmpx4, x3, 4, ne
> > bne .L9
> > mov w0, 0
> > .L1:
> > ret
> > .L6:
> > mov w0, 1
> > ret
> >
> > i.e. BB rotation makes is generate an unconditional branch to a conditional
> > branch. However this method is only called when the size is above a certain
> > threshold, and so it's likely that we have to do that first iteration.
> >
> > Adding:
> >
> > #include
> >
> > bool foo (int **a, int n, int val, int *tkn)
> > {
> > for (int i = 0; i < n; i++)
> > {
> > if (__builtin_expect(!a[i] || a[i]==tkn, 0))
> > return false;
> >
> > if (*a[i] == val)
> > return true;
> > }
> > }
> >
> > to indicate that we will likely do an iteration more generates:
> >
> > foo:
> > cmp w1, 0
> > ble .L1
> > add x1, x0, w1, uxtw 3
> > .L4:
> > ldr x4, [x0]
> > add x0, x0, 8
> > cmp x4, 0
> > ccmpx4, x3, 4, ne
> > beq .L5
> > ldr w4, [x4]
> > cmp w4, w2
> > beq .L6
> > cmp x0, x1
> > bne .L4
> > .L1:
> > ret
> > .L5:
> > mov w0, 0
> > ret
> > .L6:
> > mov w0, 1
> > ret
> >
> > which results in ~0-20% extra on top of the previous patch.
> >
> > In table form:
> >
> > +---++---+--++
> > | Group | Benchmark | Size | % Inline | % Unlikely all |
> > +---++---+--++
> > | Find | unord > | Find | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find | unord > | Find | unord > | Find | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find | unord > | Find | unord > | Find | unord > | Find | unord > | Find | unord > | Find | unord > | Find | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find Many | unord > | Find | unord > | Find | unord > | Find | vec > +---++---+--++
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master? and possible backports?
> >
> > Thanks,
> > Tamar
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/hashtable.h (_M_locate): Make it likely that we find
> > an
> > element.
> > (_M_find_before_node): Make it likely that the map has at least one
> > entry and so we do at least one iteration.
> >
> > ---
> > diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-
> v3/include/bits/hashtable.h
> > index
> e791e52ec329277474f3218d8a44cd37ded14ac3..8101d868d0c5f7ac4f97931a
> ffcf71d826c88094 100644
> > --- a/libstdc++-v3/include/bits/hashtable.h
> > +++ b/libstdc++-v3/include/bits/hashtable.h
> > @@ -2171,7 +2171,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > if (this->_M_equals(__k, __code, *__p))
> > return __prev_p;
> >
> > - if (!__p->_M_nxt || _M_bucket_index(*__p->_M_next()) != __bkt)
> > + if (__builtin_expect (!__p->_M_nxt ||
> > _M_bucket_index(*__p->_M_next())
> != __bkt, 0))
> >
[PATCH] c++: convert_to_void during requires-expr partial subst [PR118060]
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14/13?
-- >8 --
Here during partial substitution of the requires-expression (as part of
CTAD constraint rewriting) we segfault from the INDIRECT_REF case of
convert_to_void due *f(u) being type-dependent. We should just defer
checking convert_to_void until satisfaction.
PR c++/118060
gcc/cp/ChangeLog:
* constraint.cc (tsubst_valid_expression_requirement): Don't
check convert_to_void during partial substitution.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires40.C: New test.
---
gcc/cp/constraint.cc | 4 +++-
gcc/testsuite/g++.dg/cpp2a/concepts-requires40.C | 12
2 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires40.C
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c75982d8009..eb47862fda0 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1336,7 +1336,9 @@ tsubst_valid_expression_requirement (tree t, tree args,
sat_info info)
{
tsubst_flags_t quiet = info.complain & ~tf_warning_or_error;
tree r = tsubst_expr (t, args, quiet, info.in_decl);
- if (convert_to_void (r, ICV_STATEMENT, quiet) != error_mark_node)
+ if (r != error_mark_node
+ && (processing_template_decl
+ || convert_to_void (r, ICV_STATEMENT, quiet) != error_mark_node))
return r;
if (info.diagnose_unsatisfaction_p ())
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires40.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires40.C
new file mode 100644
index 000..918bab410f3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires40.C
@@ -0,0 +1,12 @@
+// PR c++/118060
+// { dg-do compile { target c++20 } }
+
+int* f(int);
+
+template
+struct A {
+ template requires requires (U u) { *f(u); }
+ A(T, U);
+};
+
+A a{0, 0};
--
2.48.0.rc0
Re: The COBOL front end, in 8 notes
On Mon, 16 Dec 2024 23:48:52 + (UTC) Joseph Myers wrote: > However, if introducing a Bison dependency, it needs to be documented > (being specific about version requirements) in install.texi. Under "Tools/packages necessary for building GCC", in Prequisites, yes? In gcc/cobol/parse,y, we have, %require "3.5.1" //3.8.2 also works, but not 3.8.0 David Malcolm reports success with 3.5. Should I change the above on the strength of his experience, or is a more methodical approach indicated? I will add install.texi to the next version of the COBOL patches. --jkl P.S. i am acting on the recommendations everyone posted. Thank you for the comments, which were mostly very helpful. I'm restricting my on-list replies unless I have a question, to minimize the noise. I will have a new patchset ready this week, possibly tomorrow.
[committed] libstdc++: Fix -Wparentheses warning in Debug Mode macro
libstdc++-v3/ChangeLog: * include/debug/safe_local_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS): Add parentheses to avoid -Wparentheses warning. --- Tested x86_64-linux. Pushed to trunk. libstdc++-v3/include/debug/safe_local_iterator.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/include/debug/safe_local_iterator.h b/libstdc++-v3/include/debug/safe_local_iterator.h index b4da11d5ee1..1766cb7e72a 100644 --- a/libstdc++-v3/include/debug/safe_local_iterator.h +++ b/libstdc++-v3/include/debug/safe_local_iterator.h @@ -32,7 +32,7 @@ #include #define _GLIBCXX_DEBUG_VERIFY_OPERANDS(_Lhs, _Rhs) \ - _GLIBCXX_DEBUG_VERIFY(!_Lhs._M_singular() && !_Rhs._M_singular() \ + _GLIBCXX_DEBUG_VERIFY((!_Lhs._M_singular() && !_Rhs._M_singular()) \ || (_Lhs._M_value_initialized() \ && _Rhs._M_value_initialized()),\ _M_message(__msg_iter_compare_bad) \ -- 2.47.1
Re: [PATCH] libstdc++: Fix future.wait_until when given a negative time_point
On Wed, 31 Jul 2024 at 22:39, Jonathan Wakely wrote:
>
> On Wed, 24 Jul 2024 at 14:14, William Tsai wrote:
> >
> > The template `future.wait_until` will expand to
> > `_M_load_and_test_until_impl` where it will call
> > `_M_load_and_test_until*` with given time_point casted into second and
> > nanosecond. The callee expects the caller to provide the values
> > correctly from caller while the caller did not make check with those
> > values. One possible error is that if `future.wait_until` is given with
> > a negative time_point, the underlying system call will raise an error as
> > the system call does not accept second < 0 and nanosecond < 1.
>
> Thanks for the patch, it looks correct. The futex syscall returns
> EINVAL in this case, which we don't handle, so the caller loops and
> keeps calling the syscall again, which fails again the same way.
>
> I think it would be good to mention EINVAL, e.g. "will raise an EINVAL
> error" instead of just "will raise an error".
I was finally getting around to merging this patch and realised the
fix is actually much simpler. We do already check for negative
timeouts, we just didn't handle values between -1s and 0s. We can fix
it in the library, without changing the headers:
--- a/libstdc++-v3/src/c++11/futex.cc
+++ b/libstdc++-v3/src/c++11/futex.cc
@@ -128,7 +128,7 @@ namespace
if (!futex_clock_realtime_unavailable.load(std::memory_order_relaxed))
{
// futex sets errno=EINVAL for absolute timeouts before the epoch.
- if (__s.count() < 0)
+ if (__s.count() < 0 || __ns.count() < 0) [[unlikely]]
return false;
syscall_timespec rt;
@@ -204,7 +204,7 @@ namespace
if (!futex_clock_monotonic_unavailable.load(std::memory_order_relaxed))
{
// futex sets errno=EINVAL for absolute timeouts before the epoch.
- if (__s.count() < 0) [[unlikely]]
+ if (__s.count() < 0 || __ns.count() < 0) [[unlikely]]
return false;
syscall_timespec rt;
A timeout of 10ms before the epoch gets broken down into 0s and -10ms
and so the __s.count() < 0 check is false, but the futex syscall still
returns EINVAL.
So I'll fix this that way instead.
>
> It would also be good to add a test to the testsuite for this.
>
> Do you have git write access, or do you need me to push it once it's approved?
>
>
> >
> > Following is a simple testcase:
> > ```
> > #include
> > #include
> > #include
> >
> > using namespace std;
> >
> > int main() {
> > promise p;
> > future f = p.get_future();
> > chrono::steady_clock::time_point tp(chrono::milliseconds{-10});
> > future_status status = f.wait_until(tp);
> > if (status == future_status::timeout) {
> > cout << "Timed out" << endl;
> > }
> > return 0;
> > }
> > ```
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/atomic_futex.h: Check if __s and __ns is valid before
> > calling before calling _M_load_and_test_until*
> >
> > Signed-off-by: William Tsai
> > ---
> > libstdc++-v3/include/bits/atomic_futex.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libstdc++-v3/include/bits/atomic_futex.h
> > b/libstdc++-v3/include/bits/atomic_futex.h
> > index dd654174873..4c31946a97f 100644
> > --- a/libstdc++-v3/include/bits/atomic_futex.h
> > +++ b/libstdc++-v3/include/bits/atomic_futex.h
> > @@ -173,6 +173,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >auto __s = chrono::time_point_cast(__atime);
> >auto __ns = chrono::duration_cast(__atime -
> > __s);
> >// XXX correct?
> > + if ((__s.time_since_epoch().count() < 0) || (__ns.count() < 0))
> > + return false;
> >return _M_load_and_test_until(__assumed, __operand, __equal, __mo,
> > true, __s.time_since_epoch(), __ns);
> > }
> > @@ -186,6 +188,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >auto __s = chrono::time_point_cast(__atime);
> >auto __ns = chrono::duration_cast(__atime -
> > __s);
> >// XXX correct?
> > + if ((__s.time_since_epoch().count() < 0) || (__ns.count() < 0))
> > + return false;
> >return _M_load_and_test_until_steady(__assumed, __operand, __equal,
> > __mo,
> > true, __s.time_since_epoch(), __ns);
> > }
> > --
> > 2.37.1
> >
[PATCH] c++: print NONTYPE_ARGUMENT_PACK [PR118073]
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR points out that we're not pretty-printing NONTYPE_ARGUMENT_PACK
so the compiler emits the ugly:
'nontype_argument_pack' not supported by dump_expr>
Fixed thus. I've wrapped the elements of the pack in { } because that's
what cxx_pretty_printer::expression does.
PR c++/118073
gcc/cp/ChangeLog:
* error.cc (dump_expr) : New case.
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/arg-pack1.C: New test.
---
gcc/cp/error.cc | 15 +++
gcc/testsuite/g++.dg/diagnostic/arg-pack1.C | 10 ++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
index 4736f4875ea..8c0644fba7e 100644
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -3173,6 +3173,21 @@ dump_expr (cxx_pretty_printer *pp, tree t, int flags)
dump_expr_list (pp, t, flags);
break;
+case NONTYPE_ARGUMENT_PACK:
+ {
+ tree args = ARGUMENT_PACK_ARGS (t);
+ int len = TREE_VEC_LENGTH (args);
+ pp_cxx_left_brace (pp);
+ for (int i = 0; i < len; ++i)
+ {
+ if (i > 0)
+ pp_separate_with_comma (pp);
+ dump_expr (pp, TREE_VEC_ELT (args, i), flags);
+ }
+ pp_cxx_right_brace (pp);
+ break;
+ }
+
/* This list is incomplete, but should suffice for now.
It is very important that `sorry' does not call
`report_error_function'. That could cause an infinite loop. */
diff --git a/gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
b/gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
new file mode 100644
index 000..643fc7f665e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
@@ -0,0 +1,10 @@
+// PR c++/118073
+// { dg-do compile { target c++11 } }
+
+template
+struct index_sequence {};
+
+void foo()
+{
+index_sequence<5> bar = index_sequence<1>(); // { dg-error {conversion
from 'index_sequence<\{1\}>' to non-scalar type 'index_sequence<\{5\}>'
requested} }
+}
base-commit: 7d6dc2130970ccf6555d4e9f977515c6c20f7d2f
--
2.47.1
Re: [PATCH] c++: print NONTYPE_ARGUMENT_PACK [PR118073]
On 12/17/24 2:43 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This PR points out that we're not pretty-printing NONTYPE_ARGUMENT_PACK
so the compiler emits the ugly:
'nontype_argument_pack' not supported by dump_expr>
Fixed thus. I've wrapped the elements of the pack in { } because that's
what cxx_pretty_printer::expression does.
PR c++/118073
gcc/cp/ChangeLog:
* error.cc (dump_expr) : New case.
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/arg-pack1.C: New test.
---
gcc/cp/error.cc | 15 +++
gcc/testsuite/g++.dg/diagnostic/arg-pack1.C | 10 ++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
index 4736f4875ea..8c0644fba7e 100644
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -3173,6 +3173,21 @@ dump_expr (cxx_pretty_printer *pp, tree t, int flags)
dump_expr_list (pp, t, flags);
break;
+case NONTYPE_ARGUMENT_PACK:
+ {
+ tree args = ARGUMENT_PACK_ARGS (t);
+ int len = TREE_VEC_LENGTH (args);
+ pp_cxx_left_brace (pp);
+ for (int i = 0; i < len; ++i)
+ {
+ if (i > 0)
+ pp_separate_with_comma (pp);
+ dump_expr (pp, TREE_VEC_ELT (args, i), flags);
+ }
+ pp_cxx_right_brace (pp);
+ break;
+ }
+
/* This list is incomplete, but should suffice for now.
It is very important that `sorry' does not call
`report_error_function'. That could cause an infinite loop. */
diff --git a/gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
b/gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
new file mode 100644
index 000..643fc7f665e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/arg-pack1.C
@@ -0,0 +1,10 @@
+// PR c++/118073
+// { dg-do compile { target c++11 } }
+
+template
+struct index_sequence {};
+
+void foo()
+{
+index_sequence<5> bar = index_sequence<1>(); // { dg-error {conversion from
'index_sequence<\{1\}>' to non-scalar type 'index_sequence<\{5\}>' requested} }
+}
base-commit: 7d6dc2130970ccf6555d4e9f977515c6c20f7d2f
Re: [PATCH] c and c++: Make sure LHS and RHS has identical named types [PR116060]
On 12/17/24 1:44 PM, Torbjorn SVENSSON wrote:
Hi Jason,
Thanks for the quick feedback!
On 2024-12-16 17:11, Jason Merrill wrote:
On 12/16/24 7:16 AM, Torbjörn SVENSSON wrote:
Hi,
I've reg-tested this patch on both the trunk and the releases/gcc-14
branches for x86_64-linux-gnu and arm-none-eabi and it no longer fails
for any of the out-of-bounds-diagram* tests on any of the 2 platforms.
I'm a bit puzzled if the C++ part is enough, but I can't think of a way
to trigger anything that show the wrong output after my change.
Do you think that I need to add any additional tests? I think the
existing test covers the problem well enough.
Ok for trunk and releases/gcc-14?
This won't be a candidate for backporting to 14.
Ok!
--
gcc/ChangeLog:
PR c/116060
c/c-typeck.cc: Make sure left hand side and right hand side has
identical named types to aid diagnostic output.
cp/call.cc: Likewise.
I've also split this into one block for gcc/c/ChangeLog and one for gcc/
cp/ChangeLog as mentioned by Marek in the other review.
gcc/testsuite/ChangeLog:
PR c/116060
c-c++-common/analyzer/out-of-bounds-diagram-8.c: Update to
correct type.
c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise.
gcc.dg/analyzer/out-of-bounds-diagram-10.c: Likewise.
Signed-off-by: Torbjörn SVENSSON
---
gcc/c/c-typeck.cc | 3 ++
gcc/cp/call.cc | 9 ++
.../analyzer/out-of-bounds-diagram-11.c | 28 +--
.../analyzer/out-of-bounds-diagram-8.c | 28 +--
.../analyzer/out-of-bounds-diagram-10.c | 28 +--
5 files changed, 54 insertions(+), 42 deletions(-)
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 902898d1944..e3e85d1ecde 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -7831,6 +7831,9 @@ convert_for_assignment (location_t location,
location_t expr_loc, tree type,
if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (rhstype))
{
warn_for_address_of_packed_member (type, orig_rhs);
+ if (type != rhstype)
+ /* Convert RHS to TYPE in order to not loose TYPE in
diagnostics. */
+ rhs = convert (type, rhs);
return rhs;
}
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index c8420db568e..d859ce9a2d6 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -1319,6 +1319,9 @@ standard_conversion (tree to, tree from, tree
expr, bool c_cast_p,
{
if (CLASS_TYPE_P (to) && conv->kind == ck_rvalue)
conv->type = qualified_to;
+ else if (from != to)
+ /* Use TO in order to not loose TO in diagnostics. */
"lose"
+ conv->type = to;
return conv;
}
@@ -8741,6 +8744,12 @@ convert_like_internal (conversion *convs, tree
expr, tree fn, int argnum,
continue to warn about uses of EXPR as an integer, rather
than as a
pointer. */
expr = build_int_cst (totype, 0);
+ if (TREE_CODE (expr) == NON_LVALUE_EXPR && TREE_TYPE (expr) !=
totype)
You might check !obvalue_p (expr) instead of just NON_LVALUE_EXPR?
Appears to work as expected with !obvalue_p(expr), thanks!
+ {
+ /* Use TOTYPE in order to not loose TOTYPE in diagnostics. */
"lose"
+ expr = copy_node (expr);
+ TREE_TYPE (expr) = totype;
+ }
Let's use cp_fold_convert instead of manually optimizing the conversion.
I've tried to use cp_fold_convert and cp_convert, but neither of them
work (either during when building, or in the case of cp_fold_convert,
ICE when running the regression test).
For cp_fold_convert, I see the following stack trace in the ICE (just
one of many examples):
Testing torture/pr47333.C, -O2 -flto -fuse-linker-plugin -fno-fat-lto-
objects
doing compile
Executing on host: /tmp/build/gcc/testsuite/g++/../../xg++ -B/tmp/build/
gcc/testsuite/g++/../../ /home/user/gcc/gcc/testsuite/g++.dg/torture/
pr47333.C -fdiagnostics-plain-output -nostdinc++ -I/tmp/build/x86_64-
pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/build/
x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/user/gcc/libstdc++-v3/
libsupc++ -I/home/user/gcc/libstdc++-v3/include/backward -I/home/user/
gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -fuse-
linker-plugin -fno-fat-lto-objects -Wno-template-body -S -o
pr47333.s (timeout = 300)
spawn -ignore SIGHUP /tmp/build/gcc/testsuite/g++/../../xg++ -B/tmp/
build/gcc/testsuite/g++/../../ /home/user/gcc/gcc/testsuite/g++.dg/
torture/pr47333.C -fdiagnostics-plain-output -nostdinc++ -I/tmp/build/
x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/
build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/user/gcc/libstdc+
+-v3/libsupc++ -I/home/user/gcc/libstdc++-v3/include/backward -I/home/
user/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -fuse-
linker-plugin -fno-fat-lto-objects -Wno-template-body -S -o pr47333.s
pid is 3620856 -3620856
/home/use
Re: [PATCH] testsuite: arm: Use effective-target for memset-inline* tests
On 05/11/2024 07:55, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-04 15:41, Richard Earnshaw wrote:
>> On 01/11/2024 18:40, Richard Earnshaw (lists) wrote:
>>> On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
As these tests are set to execute and require neon hardware to do so,
add the missing dg-require-effective-target arm_neon_hw.
gcc/testsuite/ChangeLog:
* gcc.target/arm/memset-inline-4.c: Use effective-target
arm_neon_hw.
* gcc.target/arm/memset-inline-5.c: Likewise.
* gcc.target/arm/memset-inline-6.c: Likewise.
Signed-off-by: Torbjörn SVENSSON
>>>
>>> These tests combine both a scan-assembler and a run. Unconditionally
>>> requiring neon hardware before running the test means we lose the
>>> scan-assembler when the hardware is not available. But I think you can
>>> write
>>>
>>> /* { dg-do run { arm_neon_hw } } */
>>>
>>> instead and now the framework will only try to run the test if hardware is
>>> available, but will fall back to a compile test otherwise.
>>
>> I've been doing some more digging into this and it looks as though I was
>> mistaken about this fall-back behaviour. Firstly, I'd missed out the
>> 'target' keyword, the code would need to be
>>
>> /* { dg-do run { target arm_neon_hw } } */
>>
>> but this still doesn't work as I expected. Instead the test is skipped
>> entirely if the selector fails to match. So we shouldn't combine assembly
>> scan tests and execution tests in a single file, but need to have separate
>> tests: one for execution and one for assembly output.
>
> Do you want me to move the assembler checks to a new file, like suffixing
> with "-asm" (memset-inline-5-asm.c) and then include the base file in it or
> do you have something else in mind?
Sorry for the slow reply, I'd incorrectly marked this thread as resolved in my
mailbox.
I would keep the existing files as they are for the compile tests, but remove
the dg-do run statement. Then, when we want to run the test as well, we can
simply create the new test (with, perhaps -exe appended and just #include the
main test. Something like
memset-inline-5-exe.c:
-
/* { dg-do run } */
/* ... other dg-directives copied from main test ... */
#include "memset-inline-5.c"
-
I believe the framework does not follow the include path to find additional
directives, so this will do what we need with the minimum of changes to the
original test.
R.
Re: [PATCH] COBOL 2/8 par: parser
A further diagnostic remark: * When moving to the GCC diagnostic functions, please prefer the versions that take an explicit location (which should be based on the locations of the relevant source tokens in the COBOL source - preferably an accurate range for exactly which tokens are relevant for each diagnostic, failing that the location for some relevant token) over those that implicitly use input_location. New code such as this front end shouldn't need to use input_location implicitly at all; it should track explicit locations for everything throughout the front end. -- Joseph S. Myers josmy...@redhat.com
Re: [PATCH v2] RISC-V: Fix ICE for unrecognizable insn `UNSPEC_VSETVL` for XTheadVector
On 12/17/24 5:05 AM, Jin Ma wrote:
I missed some information because of the long time.
Happens to me all the time ;-)
As I said before, instead of using UNSPEC, In the curr_insn_transform function,
the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128]
A32])
(if_then_else:RVVM8SF (unspec:RVVMF4BI [
(const_vector:RVVMF4BI repeat [
(const_int 1 [0x1])
])
(reg:DI 209)
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(reg/v:RVVM8SF 143 [ _xx ])
(mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128] A32])))
"pr116593.C":14:24 discrim 1 3883 {pred_storervvm8sf}
(expr_list:REG_DEAD (reg/v:RVVM8SF 143 [ _xx ])
(nil)))
to
(insn 69 284 225 11 (set (mem:RVVM8SF (reg/f:DI 18 s2 [orig:218 _77 ] [218]) [0
S[128, 128] A32])
(if_then_else:RVVM8SF (unspec:RVVMF4BI [
(const_vector:RVVMF4BI repeat [
(const_int 1 [0x1])
])
(const_int 1 [0x1])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(reg/v:RVVM8SF 104 v8 [orig:143 _xx ] [143])
(mem:RVVM8SF (reg/f:DI 18 s2 [orig:218 _77 ] [218]) [0 S[128, 128] A32])))
"pr116593.C":14:24 discrim 1 3883 {pred_storervvm8sf}
(nil))
Looking at the log for the reload pass, it is found that "Changing pseudo 209 in
operand 3 of insn 69 on equiv 0x 1".
It converts the vl operand in insn from the expected register(reg:DI 209) to
the constant 1(const_int 1 [0x1]).
OK. This is where we need to focus.
This conversion occurs because, although the predicate for the vl operand is restricted
by "vector_length_operand" in the pattern,
the constraint is still "rK", which allows the transformation.
That's a bit odd, I would have expected the predicate to be checked, but
sometimes things are "odd" in reload.
The issue is that changing the "rK" constraint to "rJ" for the constraint of vl
operand in the pattern would prevent this conversion,
But unfortunately this will conflict with RVV (RISC-V Vector Extension).
This is why I initially considered using UNSPEC to address the XTheadVector
problem while minimizing interference with RVV.
I'm not sure if there is a better way, do you have any suggestions?
I think Robin mentioned disabling certain alternatives which is one
approach (I've never used that capability, but I know it exists and this
would be a pretty good fit). For this approach I'd suggest disabling
the rK alternative for thead-vector and (if we don't have it) adding an
alternative that only accepts a register.
We could also create a new constraint that mostly behaves like rK, but
rejects (const_int 1) when thead-vector is enabled and use that in the
vsetvl pattern instead of rK.
The brute force, but least favorite, approach would be to create two
distinct patterns, one for thead the other for rvv. Obviously the thead
pattern would use different constraints to prevent replacing registers
with constants.
Jeff
Jeff
Re: [PATCH] c++: Speed up compilation of large char array initializers when not using #embed
On 8/3/24 2:36 PM, Jakub Jelinek wrote:
Hi!
The following patch (again, on top of the #embed patchset, so
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655013.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657049.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657053.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658137.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659331.html
) attempts to optimize compilation of large {{{,un}signed ,}char,std::byte}
array initializers when not using #embed in the source.
Unlike the C patch which is done during the parsing of initializers this
is done when lexing tokens into an array, because C++ lexes all tokens
upfront and so by the time we parse the initializers we already have 16
bytes per token allocated (i.e. 32 extra compile time memory bytes per
one byte in the array).
The drawback is again that it can result in worse locations for diagnostics
(-Wnarrowing, -Wconversion) when initializing signed char arrays with values
128..255. Not really sure what to do about this though unlike the C case,
the locations would need to be preserved through reshape_init* and perhaps
till template instantiation.
For #embed, there is just a single location_t (could be range of the
directive), for diagnostics perhaps we could extend it to say byte xyz of
the file embedded here or something like that, but the optimization done by
this patch, either we'd need to bump the minimum limit at which to try it,
or say temporarily allocate a location_t array for each byte and then clear
it when we no longer need it or something.
I've been using the same testcases as for C, with #embed of 100'000'000
bytes:
time ./cc1plus -quiet -O2 -o test4a.s2 test4a.c
real0m0.972s
user0m0.578s
sys 0m0.195s
with xxd -i alternative of the same data without this patch it consumed
around 13.2GB of RAM and
time ./cc1plus -quiet -O2 -o test4b.s4 test4b.c
real3m47.968s
user3m41.907s
sys 0m5.015s
and the same with this patch it consumed around 3.7GB of RAM and
time ./cc1plus -quiet -O2 -o test4b.s3 test4b.c
real0m24.772s
user0m23.118s
sys 0m1.495s
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-08-03 Jakub Jelinek
* parser.cc (cp_lexer_new_main): Attempt to optimize large sequences
of CPP_NUMBER with int type and values 0-255 separated by CPP_COMMA
into CPP_EMBED with RAW_DATA_CST u.value.
--- gcc/cp/parser.cc.jj 2024-08-02 11:34:20.343813689 +0200
+++ gcc/cp/parser.cc2024-08-02 19:35:12.380611787 +0200
@@ -734,6 +734,12 @@ cp_lexer_new_main (void)
gcc_assert (!the_parser);
the_parser = cp_parser_new (lexer);
+ unsigned raw_data_tokens = 0;
+ char *raw_data_buf = NULL;
+ const unsigned int raw_data_max_len
+= 131072 - offsetof (struct tree_string, str) - 1;
+ const unsigned int raw_data_min_len = 128;
+
/* Get the remaining tokens from the preprocessor. */
while (tok->type != CPP_EOF)
{
@@ -742,6 +748,72 @@ cp_lexer_new_main (void)
module_token_lang (tok->type, tok->keyword, tok->u.value,
tok->location, filter);
+ /* Attempt to optimize long lists of 0-255 integers
+separated by commas into CPP_EMBED. */
+recheck:
+ if (tok->type == CPP_NUMBER
+ && (raw_data_tokens & 1) == 0
+ && TREE_CODE (tok->u.value) == INTEGER_CST
+ && TREE_TYPE (tok->u.value) == integer_type_node
+ && !wi::neg_p (wi::to_wide (tok->u.value))
+ && wi::to_widest (tok->u.value) <= UCHAR_MAX
+ && raw_data_tokens < raw_data_max_len * 2)
+ {
+ raw_data_tokens++;
+ if (raw_data_tokens >= raw_data_min_len * 2 + 3)
The logic in this patch could use more explanation in the initial comment.
The +3 is number, comma, number?
+ {
+ unsigned int len = lexer->buffer->length ();
+ unsigned int new_len;
+ if (raw_data_tokens == raw_data_min_len * 2 + 3)
+ {
+ if (raw_data_buf == NULL)
+ raw_data_buf = XNEWVEC (char, raw_data_max_len);
+ for (unsigned i = len - raw_data_tokens, j = 0;
+ i < len; i += 2, ++j)
+ raw_data_buf[j]
+ = (char) tree_to_uhwi ((*lexer->buffer)[i].u.value);
+ new_len = len - raw_data_tokens + 5;
The +5 is number, comma, embed, comma, number?
+ }
+ else
+ {
+ raw_data_buf[raw_data_tokens / 2]
+ = (char) tree_to_uhwi (tok->u.value);
+ new_len = len - 2;
+ }
+ (*lexer->buffer)[new_len - 2] = (*lexer->buffer)[len - 2];
+ (*lexer->buffer)[new_len - 1] = (*lexer->buffer)[len - 1];
+ lexer->buffer->truncate (new_len);
+ }
+ }
Re: [PATCH] inline asm, v3: Add new constraint for symbol definitions
On 11/22/24 4:31 AM, Jakub Jelinek wrote:
On Thu, Nov 21, 2024 at 11:57:13PM +, Joseph Myers wrote:
On Wed, 6 Nov 2024, Jakub Jelinek wrote:
+ error_at (loc, "%<:%> constraint operand is not address "
+"of a function or non-automatic variable");
I think a testcase for this error is needed.
Here is an updated patch with the additional test coverage.
The C++ change is OK.
2024-11-21 Jakub Jelinek
gcc/
* genpreds.cc (mangle): Add ':' mangling.
(add_constraint): Allow : constraint.
* common.md (:): New define_constraint.
* stmt.cc (parse_output_constraint): Diagnose "=:".
(parse_input_constraint): Handle ":" and diagnose invalid
uses.
* doc/md.texi (Simple Constraints): Document ":" constraint.
gcc/c/
* c-typeck.cc (build_asm_expr): Diagnose invalid ":" constraint
uses.
gcc/cp/
* semantics.cc (finish_asm_stmt): Diagnose invalid ":" constraint
uses.
gcc/testsuite/
* c-c++-common/toplevel-asm-4.c: New test.
* c-c++-common/toplevel-asm-5.c: New test.
--- gcc/genpreds.cc.jj 2024-02-10 11:25:10.404468273 +0100
+++ gcc/genpreds.cc 2024-11-05 14:57:14.193060528 +0100
@@ -753,6 +753,7 @@ mangle (const char *name)
case '_': obstack_grow (rtl_obstack, "__", 2); break;
case '<':obstack_grow (rtl_obstack, "_l", 2); break;
case '>':obstack_grow (rtl_obstack, "_g", 2); break;
+ case ':': obstack_grow (rtl_obstack, "_c", 2); break;
default: obstack_1grow (rtl_obstack, *name); break;
}
@@ -797,12 +798,13 @@ add_constraint (const char *name, const
for (p = name; *p; p++)
if (!ISALNUM (*p))
{
- if (*p == '<' || *p == '>' || *p == '_')
+ if (*p == '<' || *p == '>' || *p == '_' || *p == ':')
need_mangled_name = true;
else
{
error_at (loc, "constraint name '%s' must be composed of letters,"
- " digits, underscores, and angle brackets", name);
+ " digits, underscores, colon and angle brackets",
+ name);
return;
}
}
--- gcc/common.md.jj2024-01-03 11:51:24.519828508 +0100
+++ gcc/common.md 2024-11-05 14:51:29.098989927 +0100
@@ -100,6 +100,11 @@ (define_constraint "s"
(match_test "!CONST_SCALAR_INT_P (op)")
(match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))
+(define_constraint ":"
+ "Defines a symbol."
+ (and (match_test "CONSTANT_P (op)")
+ (match_test "!CONST_SCALAR_INT_P (op)")))
+
(define_constraint "n"
"Matches a non-symbolic integer constant."
(and (match_test "CONST_SCALAR_INT_P (op)")
--- gcc/stmt.cc.jj 2024-10-25 10:00:29.523767070 +0200
+++ gcc/stmt.cc 2024-11-05 18:31:11.518948252 +0100
@@ -278,6 +278,10 @@ parse_output_constraint (const char **co
error ("matching constraint not valid in output operand");
return false;
+ case ':':
+ error ("%<:%> constraint used for output operand");
+ return false;
+
case '<': case '>':
/* ??? Before flow, auto inc/dec insns are not supposed to exist,
excepting those that expand_call created. So match memory
@@ -325,6 +329,7 @@ parse_input_constraint (const char **con
size_t c_len = strlen (constraint);
size_t j;
bool saw_match = false;
+ bool at_checked = false;
/* Assume the constraint doesn't allow the use of either
a register or memory. */
@@ -362,6 +367,21 @@ parse_input_constraint (const char **con
case 'N': case 'O': case 'P': case ',':
break;
+ case ':':
+ /* Verify that if : is used, it is just ":" or say ":,:" but not
+ mixed with other constraints or say ",:,," etc. */
+ if (!at_checked)
+ {
+ for (size_t k = 0; k < c_len; ++k)
+ if (constraint[k] != ((k & 1) ? ',' : ':') || (c_len & 1) == 0)
+ {
+ error ("%<:%> constraint mixed with other constraints");
+ return false;
+ }
+ at_checked = true;
+ }
+ break;
+
/* Whether or not a numeric constraint allows a register is
decided by the matching constraint, and so there is no need
to do anything special with them. We must handle them in
--- gcc/doc/md.texi.jj 2024-10-16 14:41:45.553757783 +0200
+++ gcc/doc/md.texi 2024-11-05 18:46:30.795896301 +0100
@@ -1504,6 +1504,13 @@ as the predicate in the @code{match_oper
the mode specified in the @code{match_operand} as the mode of the memory
reference for which the address would be valid.
+@cindex @samp{:} in constraint
+@item @samp{:}
+This constraint, allowed only in input operands, says the inline @code{asm}
+pattern defines specific function or variable symbol. The constraint
+shouldn't be mixed with other constraints on the same
Re: [PATCH] inline-asm, v2: Add - constraint modifier support for toplevel extended asm [PR41045]
On 11/22/24 4:07 AM, Jakub Jelinek wrote:
On Fri, Nov 22, 2024 at 12:01:21AM +, Joseph Myers wrote:
On Mon, 18 Nov 2024, Jakub Jelinek wrote:
+@smallexample
+extern void foo (void), bar (void);
+int v;
+extern int w;
+asm (".globl %cc0, %cc2; .text; %cc0: call %cc1; ret; .data; %cc2: .word %cc3"
+ :: ":" (foo), "-s" (&bar), ":" (&w), "-i" (&v));
+@end smallexample
+
+This asm declaration tells the compiler it defines function foo and variable
+w and uses function bar and variable v. This will compile even with PIC,
+but it is up to the user to ensure it will assemble correctly and have the
+expected behavior.
That should be @code{foo}, @code{w}, @code{bar}, @code{v}.
The C front-end changes in this patch are OK.
Thanks, here is the adjusted patch.
The C++ change is OK.
2024-11-21 Jakub Jelinek
PR c/41045
gcc/
* stmt.cc (parse_output_constraint, parse_input_constraint): Handle
- modifier.
* recog.h (raw_constraint_p): Declare.
* recog.cc (raw_constraint_p): New variable.
(asm_operand_ok, constrain_operands): Handle - modifier.
* common.md (i, s, n): For raw_constraint_p don't require
LEGITIMATE_PIC_OPERAND_P.
* doc/md.texi: Document - constraint modifier.
gcc/c/
* c-typeck.cc (build_asm_expr): Reject - constraint modifier inside
of a function.
gcc/cp/
* semantics.cc (finish_asm_stmt): Reject - constraint modifier inside
of a function.
gcc/testsuite/
* c-c++-common/toplevel-asm-4.c: Add missing %cc2 use in template, add
bar, x, &y operands with "-i" and "-s" constraints.
(x, y): New variables.
(bar): Declare.
* c-c++-common/toplevel-asm-7.c: New test.
* c-c++-common/toplevel-asm-8.c: New test.
--- gcc/stmt.cc.jj 2024-11-17 21:07:06.712510933 -1100
+++ gcc/stmt.cc 2024-11-17 21:45:30.201294501 -1100
@@ -269,7 +269,7 @@ parse_output_constraint (const char **co
case 'E': case 'F': case 'G': case 'H':
case 's': case 'i': case 'n':
case 'I': case 'J': case 'K': case 'L': case 'M':
- case 'N': case 'O': case 'P': case ',':
+ case 'N': case 'O': case 'P': case ',': case '-':
break;
case '0': case '1': case '2': case '3': case '4':
@@ -364,7 +364,7 @@ parse_input_constraint (const char **con
case 'E': case 'F': case 'G': case 'H':
case 's': case 'i': case 'n':
case 'I': case 'J': case 'K': case 'L': case 'M':
- case 'N': case 'O': case 'P': case ',':
+ case 'N': case 'O': case 'P': case ',': case '-':
break;
case ':':
--- gcc/recog.h.jj 2024-08-15 09:23:26.981012468 -1100
+++ gcc/recog.h 2024-11-17 22:26:47.190602347 -1100
@@ -335,6 +335,9 @@ private:
matched. */
extern int which_alternative;
+/* True for inline asm operands with - constraint modifier. */
+extern bool raw_constraint_p;
+
/* The following vectors hold the results from insn_extract. */
struct recog_data_d
--- gcc/recog.cc.jj 2024-10-24 21:00:29.511767242 -1100
+++ gcc/recog.cc2024-11-17 23:16:00.654874432 -1100
@@ -86,6 +86,9 @@ static operand_alternative asm_op_alt[MA
int which_alternative;
+/* True for inline asm operands with - constraint modifier. */
+bool raw_constraint_p;
+
/* Nonzero after end of reload pass.
Set to 1 or 0 by toplev.cc.
Controls the significance of (SUBREG (MEM)). */
@@ -2300,6 +2303,7 @@ asm_operand_ok (rtx op, const char *cons
switch (c)
{
case ',':
+ raw_constraint_p = false;
constraint++;
continue;
@@ -2350,6 +2354,11 @@ asm_operand_ok (rtx op, const char *cons
result = 1;
break;
+ case '-':
+ raw_constraint_p = true;
+ constraint++;
+ continue;
+
case '<':
case '>':
/* ??? Before auto-inc-dec, auto inc/dec insns are not supposed
@@ -2407,8 +2416,12 @@ asm_operand_ok (rtx op, const char *cons
constraint++;
while (--len && *constraint && *constraint != ',');
if (len)
- return 0;
+ {
+ raw_constraint_p = false;
+ return 0;
+ }
}
+ raw_constraint_p = false;
/* For operands without < or > constraints reject side-effects. */
if (AUTO_INC_DEC && !incdec_ok && result && MEM_P (op))
@@ -3202,6 +3215,9 @@ constrain_operands (int strict, alternat
case ',':
c = '\0';
break;
+ case '-':
+ raw_constraint_p = true;
+ break;
case '#':
/* Ignore rest of this alternative as far as
@@ -3357,6 +3373,7 @@ constrain_operands (int strict, alternat
}
while (p += len, c);
+ raw_constraint_p = false;
constraints[opno] = p;
/* If this operand did not win somehow,
this alternative loses.
Re: [PATCH] RISC-V: Disallow negative step for interleaving [PR117682].
> +/* { dg-require-effective-target riscv_v } */
> +/* { dg-require-effective-target rvv_zvl256b_ok } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=zvl -fwrapv" }
> */
Ah, I forgot _zvl256b in the -march string. It seems to still fail with the
settings as posted but I'll still adjust that. Either in a revision or before
merging.
--
Regards
Robin
Re: [PATCH v2] c++: ICE initializing array of aggrs [PR117985]
On 12/17/24 12:08 PM, Marek Polacek wrote:
On Tue, Dec 17, 2024 at 10:36:09AM -0500, Jason Merrill wrote:
On 12/16/24 6:48 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
-- >8 --
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times. Let's
say we are initializing an array of A. Then we might end up in
a scenario similar to initlist-eh1.C:
try
{
call A::A in a loop
// #0
try
{
call a fn using the array
}
finally
{
// #1
call A::~A in a loop
}
}
catch
{
// #2
call A::~A in a loop
}
cleanup_flags makes us emit a statement like
D.3048 = 2;
at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.
But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value. Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.
PR c++/117985
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Clear CLEANUP_FLAGS if we're not
generating the loop.
truncate seems dangerous, there might be other things in cleanup_flags that
we want to leave alone. I think it would be safer to assert that the last
element in the vec is iterator, and then pop it.
Yeah, that does sound much safer. Like so?
OK.
dg.exp passed.
-- >8 --
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times. Let's
say we are initializing an array of A. Then we might end up in
a scenario similar to initlist-eh1.C:
try
{
call A::A in a loop
// #0
try
{
call a fn using the array
}
finally
{
// #1
call A::~A in a loop
}
}
catch
{
// #2
call A::~A in a loop
}
cleanup_flags makes us emit a statement like
D.3048 = 2;
at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.
But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value. Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.
PR c++/117985
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not
generating the loop.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array23.C: New test.
* g++.dg/cpp0x/initlist-array24.C: New test.
---
gcc/cp/init.cc| 9 ++
gcc/testsuite/g++.dg/cpp0x/initlist-array23.C | 28 +++
gcc/testsuite/g++.dg/cpp0x/initlist-array24.C | 27 ++
3 files changed, 64 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index ae516407c92..7dcc1152c72 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -5109,6 +5109,15 @@ build_vec_init (tree base, tree maxindex, tree init,
{
if (!saw_non_const)
{
+ /* If we're not generating the loop, we don't need to reset the
+iterator. */
+ if (cleanup_flags
+ && !vec_safe_is_empty (*cleanup_flags))
+ {
+ auto l = (*cleanup_flags)->last ();
+ gcc_assert (TREE_PURPOSE (l) == iterator);
+ (*cleanup_flags)->pop ();
+ }
tree const_init = build_constructor (atype, const_vec);
return build2 (INIT_EXPR, atype, obase, const_init);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
new file mode 100644
index 000..cda2afb9fcc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array23.C
@@ -0,0 +1,28 @@
+// PR c++/117985
+// { dg-do compile { target c++11 } }
+
+struct _Vector_impl {
+ constexpr
+_Vector_impl() {}
+};
+struct _Vector_base {
+ ~_Vector_base();
+ _Vector_impl _M_impl;
+};
+struct vector : private _Vector_base {};
+struct string {
+ string();
+};
+struct VEC {
+ vector pane{};
+};
+struct FOO {
+ VEC screen[1]{};
+ string debug_name;
+};
+
+int
+main ()
+{
+ FOO{};
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array24.C
new file mode 100644
index 000..7dda00d5c0b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlis
Re: [RFC][PATCH] AArch64: Remove AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS
> Am 16.12.2024 um 09:10 schrieb Jennifer Schmitz :
>
>
>
>> On 14 Dec 2024, at 09:32, Richard Biener wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
Am 13.12.2024 um 18:00 schrieb Jennifer Schmitz :
>>>
>>>
>>>
On 13 Dec 2024, at 13:40, Richard Biener
wrote:
External email: Use caution opening links or attachments
> On Thu, Dec 12, 2024 at 5:27 PM Jennifer Schmitz
> wrote:
>
>
>
>> On 6 Dec 2024, at 08:41, Jennifer Schmitz wrote:
>>
>>
>>
>>> On 5 Dec 2024, at 20:07, Richard Sandiford
>>> wrote:
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Jennifer Schmitz writes:
> On 5 Dec 2024, at 11:44, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Thu, 5 Dec 2024, Jennifer Schmitz wrote:
>
>>
>>
>>> On 17 Oct 2024, at 19:23, Richard Sandiford
>>> wrote:
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Jennifer Schmitz writes:
[...]
Looking at the diff of the vect dumps (below is a section of the
diff for strided_store_2.c), it seemed odd that vec_to_scalar
operations cost 0 now, instead of the previous cost of 2:
+strided_store_1.c:38:151: note:=== vectorizable_operation ===
+strided_store_1.c:38:151: note:vect_model_simple_cost:
inside_cost = 1, prologue_cost = 0 .
+strided_store_1.c:38:151: note: ==> examining statement: *_6 =
_7;
+strided_store_1.c:38:151: note: vect_is_simple_use: operand _3
+ 1.0e+0, type of def:internal
+strided_store_1.c:38:151: note: Vectorizing an unaligned access.
+Applying pattern match.pd:236, generic-match-9.cc:4128
+Applying pattern match.pd:5285, generic-match-10.cc:4234
+strided_store_1.c:38:151: note: vect_model_store_cost:
inside_cost = 12, prologue_cost = 0 .
*_2 1 times unaligned_load (misalign -1) costs 1 in body
-_3 + 1.0e+0 1 times scalar_to_vec costs 1 in prologue
_3 + 1.0e+0 1 times vector_stmt costs 1 in body
-_7 1 times vec_to_scalar costs 2 in body
+ 1 times vector_load costs 1 in prologue
+_7 1 times vec_to_scalar costs 0 in body
_7 1 times scalar_store costs 1 in body
-_7 1 times vec_to_scalar costs 2 in body
+_7 1 times vec_to_scalar costs 0 in body
_7 1 times scalar_store costs 1 in body
-_7 1 times vec_to_scalar costs 2 in body
+_7 1 times vec_to_scalar costs 0 in body
_7 1 times scalar_store costs 1 in body
-_7 1 times vec_to_scalar costs 2 in body
+_7 1 times vec_to_scalar costs 0 in body
_7 1 times scalar_store costs 1 in body
Although the aarch64_use_new_vector_costs_p flag was used in
multiple places in aarch64.cc, the location that causes this
behavior is this one:
unsigned
aarch64_vector_costs::add_stmt_cost (int count, vect_cost_for_stmt
kind,
stmt_vec_info stmt_info, slp_tree,
tree vectype, int misalign,
vect_cost_model_location where)
{
[...]
/* Try to get a more accurate cost by looking at STMT_INFO instead
of just looking at KIND. */
- if (stmt_info && aarch64_use_new_vector_costs_p ())
+ if (stmt_info)
{
/* If we scalarize a strided store, the vectorizer costs one
vec_to_scalar for each element. However, we can store the first
element using an FP store without a separate extract step. */
if (vect_is_store_elt_extraction (kind, stmt_info))
count -= 1;
stmt_cost = aarch64_detect_scalar_stmt_subtype (m_vinfo, kind,
stmt_info,
stmt_cost);
if (vectype && m_vec_flags)
stmt_cost = aarch64_detect_vector_stmt_subtype (m_vinfo, kind,
stmt_info, vectype,
where, stmt_cost);
}
[...]
return record_stmt_cost (stmt_info, where, (count *
stmt_cost).ceil ());
}
Previously, for mtune=generic, this fu
Re: The COBOL front end, in 8 notes
On Mon, 16 Dec 2024, James K. Lowden wrote: > On Mon, 16 Dec 2024 23:48:52 + (UTC) > Joseph Myers wrote: > > > However, if introducing a Bison dependency, it needs to be documented > > (being specific about version requirements) in install.texi. > > Under "Tools/packages necessary for building GCC", in Prequisites, > yes? Yes (with an appropriate note that it's only needed for COBOL). At some point it would be desirable to test the workflow that applies with release tarballs (configure --enable-generated-files-in-srcdir and build; then take the resulting source directory that includes the Bison-generated files and make sure you can build from it on a system that doesn't have Bison installed). But the other issues identified in the discussions so far are probably higher priority, to get it building (and testing with an included testsuite) reliably from git (with Bison etc. installed) across a range of the most common configurations (build / host / target) that people use for building and testing GCC (which includes having working multilib support for the target libraries). > In gcc/cobol/parse,y, we have, > > %require "3.5.1" //3.8.2 also works, but not 3.8.0 > > David Malcolm reports success with 3.5. Should I change the above on > the strength of his experience, or is a more methodical approach > indicated? I'd advise testing to see what the minimum that actually works is (probably the version where some Bison feature you rely on was introduced). -- Joseph S. Myers josmy...@redhat.com
Re: [PATCH] COBOL 8/8 bld: "meta" files, such a gcc/cobol/Make-lang.in
On Fri, 13 Dec 2024, David Malcolm wrote: > For the rest of GCC we use either texinfo (.texi files) or sphinx > (.rst) files; the manpages and HTML are both generated from the same > sources. I don't if using these formats is a hard requirement. If so > one converter I know of that can supposedly do roff -> texi is pandoc: > https://pandoc.org/MANUAL.html I don't think we should introduce man pages as a new source format for documentation in GCC. Either .texi or .rst (with generated man pages) would be fine. For parts of GCC using Sphinx, I'd like us to move towards common build infrastructure for all Sphinx manuals that avoids needing duplicate Make-lang.in rules, which might facilitate future incremental transition of other manuals to Sphinx. I don't suggest this as a requirement for any new Sphinx manuals being added at present, however, but as an orthogonal refactoring. -- Joseph S. Myers josmy...@redhat.com
Re: [PATCH] testsuite: arm: Mark pr81812.C as xfail for thumb1
On 2024-12-17 15:38, Torbjorn SVENSSON wrote:
On 2024-12-17 14:33, Richard Earnshaw (lists) wrote:
On 10/11/2024 19:25, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Test fails for Cortex-M0 with:
.../pr81812.C:6:8: error: generic thunk code fails for method
'virtual void ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const'
which uses '...'
According to PR108277, it's expected that thumb1 targets does not
support empty virtual functions with ellipsis.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr81812.C: Add xfail for thumb1.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/g++.dg/torture/pr81812.C | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/g++.dg/torture/pr81812.C b/gcc/testsuite/
g++.dg/torture/pr81812.C
index d235e237588..b5c621d2beb 100644
--- a/gcc/testsuite/g++.dg/torture/pr81812.C
+++ b/gcc/testsuite/g++.dg/torture/pr81812.C
@@ -1,3 +1,5 @@
+// { dg-xfail-if "PR108277" { arm_thumb1 } }
+
struct Error {
virtual void error(... ) const;
};
OK. There's no reason that I can see why this can't be fixed. It
just needs somebody to write (and test) the code :)
Pushed as r15-6305-gf111d8e20b6.
Forgot to push this to releases/gcc-14, but I've done that know with
r14.2.0-573-g0361b4c440f.
Kind regards,
Torbjörn
Absolutely, but I don't see it as urgent to implement... ;)
Kind regards,
Torbjörn
R.
[COMMITTED] Documentation: Make OpenMP/OpenACC docs easier to find [PR26154]
PR c/26154 is one of our oldest documentation issues. The only discussion of OpenMP support in the GCC manual is buried in the "C Dialect Options" section, with nothing at all under "Extensions". The Fortran manual does have separate sections for OpenMP and OpenACC extensions so I have copy-edited/adapted that text for similar sections in the GCC manual, as well as breaking out the OpenMP and OpenACC options into their own section (they apply to all of C, C++, and Fortran). I also updated the information about what versions of OpenMP and OpenACC are supported and removed some redundant text from the Fortran manual to prevent it from getting out of sync on future updates, and inserted some cross-references to the new sections elsewhere. gcc/c-family/ChangeLog PR c/26154 * c.opt.urls: Regenerated. gcc/ChangeLog PR c/26154 * common.opt.urls: Regenerated. * doc/extend.texi (C Extensions): Adjust menu for new sections. (Attribute Syntax): Mention OpenMP directives. (Pragmas): Mention OpenMP and OpenACC directives. (OpenMP): New section. (OpenACC): New section. * doc/invoke.texi (Invoking GCC): Adjust menu for new section. (Option Summary): Move OpenMP and OpenACC options to their own category. (C Dialect Options): Move documentation for -foffload, -fopenacc, -fopenacc-dim, -fopenmp, -fopenmd-simd, and -fopenmp-target-simd-clone to... (OpenMP and OpenACC Options): ...this new section. Light copy-editing of the option descriptions. gcc/fortran/ChangeLog: PR c/26154 * gfortran.texi (Standards): Remove redundant info about OpenMP/OpenACC standard support. (OpenMP): Copy-editing and update version info. (OpenACC): Likewise. * lang.opt.urls: Regenerated. --- gcc/c-family/c.opt.urls | 8 +- gcc/common.opt.urls | 8 +- gcc/doc/extend.texi | 61 ++ gcc/doc/invoke.texi | 240 -- gcc/fortran/gfortran.texi | 52 + gcc/fortran/lang.opt.urls | 8 +- 6 files changed, 227 insertions(+), 150 deletions(-) diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls index 6c08b0ae052..421cc08e2c7 100644 --- a/gcc/c-family/c.opt.urls +++ b/gcc/c-family/c.opt.urls @@ -1256,16 +1256,16 @@ fobjc-nilcheck UrlSuffix(gcc/Objective-C-and-Objective-C_002b_002b-Dialect-Options.html#index-fobjc-nilcheck) fopenacc -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenacc) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenacc) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenacc) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenacc) fopenacc-dim= -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenacc-dim) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenacc-dim) fopenmp -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp) fopenmp-simd -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp-simd) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp-simd) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp-simd) LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-fopenmp-simd) foperator-names UrlSuffix(gcc/C_002b_002b-Dialect-Options.html#index-fno-operator-names) diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls index 577e00d7a27..79c322bed2b 100644 --- a/gcc/common.opt.urls +++ b/gcc/common.opt.urls @@ -1005,19 +1005,19 @@ fnon-call-exceptions UrlSuffix(gcc/Code-Gen-Options.html#index-fnon-call-exceptions) foffload= -UrlSuffix(gcc/C-Dialect-Options.html#index-foffload) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-foffload) foffload-options= -UrlSuffix(gcc/C-Dialect-Options.html#index-foffload-options) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-foffload-options) fomit-frame-pointer UrlSuffix(gcc/Optimize-Options.html#index-fomit-frame-pointer) fopenmp-target-simd-clone -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp-target-simd-clone) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp-target-simd-clone) fopenmp-target-simd-clone= -UrlSuffix(gcc/C-Dialect-Options.html#index-fopenmp-target-simd-clone) +UrlSuffix(gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp-target-simd-clone) fopt-info UrlSuffix(gcc/Developer-Options.html#index-fopt-info) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index d991aa0a508..54465ddc23a 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -98,6 +98,8 @@ extensions, accepted by GCC in C90 mode and in C++. * Unnamed Fields:: Unnamed struct/union fields within structs/unions. * Thread-Local::Per-thread variables. * Binary constants::
Re: [PATCH] c++: ICE in TARGET_EXPR evaluation in cp_fold_r [PR117980]
On 12/12/24 1:42 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This ICE started with the recent prvalue optimization (r15-6052). In
cp_fold_r we have:
if (tree &init = TARGET_EXPR_INITIAL (stmt))
{
cp_walk_tree (&init, cp_fold_r, data, NULL);
// ...
tree folded = maybe_constant_init (init, TARGET_EXPR_SLOT (stmt));
What can happen here is that originally the TARGET_EXPR is:
TARGET_EXPR >>
&TARGET_EXPR }>
but after the first cp_walk_tree we fold the D.2707 TARGET_EXPR into:
TARGET_EXPR
and then we pass the EXPR_STMT to maybe_constant_init, with D.2707 as
the object. But their types don't match anymore, so we crash. We'd
have to pass D.2707.it as the object for it to work.
But I don't think we need to pass any object to maybe_constant_init;
it'll grab the appropriate one itself.
Hmm, it seems to me that the crash is happening because the deduced type
is wrong, and so with this change we'll end up only producing an
initializer for the first member. Because cp_fold_r throws away the
information that initialized_type needs to know the type of the complete
object being initialized.
What if we move cp_fold_r of init after the maybe_constant_init?
constexpr-prvalue3.C is reduced from a large std::ranges libstdc++ test.
PR c++/117980
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_fold_r) : Don't pass an object
to maybe_constant_init.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-prvalue2.C: New test.
* g++.dg/cpp0x/constexpr-prvalue3.C: New test.
---
gcc/cp/cp-gimplify.cc | 2 +-
.../g++.dg/cpp0x/constexpr-prvalue2.C | 15 +++
.../g++.dg/cpp0x/constexpr-prvalue3.C | 26 +++
3 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue2.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue3.C
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 623e2ee6e96..a861331c7c7 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1477,7 +1477,7 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
*walk_subtrees = 0;
if (!flag_no_inline)
{
- tree folded = maybe_constant_init (init, TARGET_EXPR_SLOT (stmt));
+ tree folded = maybe_constant_init (init);
if (folded != init && TREE_CONSTANT (folded))
init = folded;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue2.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue2.C
new file mode 100644
index 000..46053231cf8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue2.C
@@ -0,0 +1,15 @@
+// PR c++/117980
+// { dg-do compile { target c++11 } }
+// { dg-options "-O" }
+
+struct S {
+ constexpr S(S &); // { dg-warning "used but never defined" }
+ ~S();
+};
+struct B {
+ S s;
+};
+struct A {
+ B b;
+};
+void fn(B b) { A{b}; }
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue3.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue3.C
new file mode 100644
index 000..a2eb12c02d7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-prvalue3.C
@@ -0,0 +1,26 @@
+// PR c++/117980
+// { dg-do compile { target c++11 } }
+// { dg-options "-O" }
+
+struct _Safe_iterator {
+ _Safe_iterator();
+ ~_Safe_iterator();
+};
+template
+struct vector {
+ vector(int) {}
+ constexpr _Safe_iterator end() {
+return _Safe_iterator();
+ }
+};
+template struct sentinel {
+ It it;
+};
+template
+struct subrange {
+ subrange(sentinel<_Safe_iterator>) {}
+};
+void test01() {
+ vector v{0};
+ subrange>{sentinel<_Safe_iterator>{v.end()}};
+}
base-commit: 2cbb2408a830a63fbd901a4da3bfd341cec4b6ef
[committed] libstdc++: Fix std::deque::insert(pos, first, last) undefined behaviour [PR118035]
Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g. std::copy(first, last, first) which
violates the preconditions for the algorithms.
This fix simply returns early if there's nothing to insert. Most callers
already ensure that we don't even call _M_range_insert_aux with an empty
range, but some callers don't. Rather than checking for n == 0 in each
of the callers, this just does the check once and uses __builtin_expect
to treat empty insertions as unlikely.
libstdc++-v3/ChangeLog:
PR libstdc++/118035
* include/bits/deque.tcc (_M_range_insert_aux): Return
immediately if inserting an empty range.
* testsuite/23_containers/deque/modifiers/insert/118035.cc: New
test.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/bits/deque.tcc | 3 +++
.../deque/modifiers/insert/118035.cc | 26 +++
2 files changed, 29 insertions(+)
create mode 100644
libstdc++-v3/testsuite/23_containers/deque/modifiers/insert/118035.cc
diff --git a/libstdc++-v3/include/bits/deque.tcc
b/libstdc++-v3/include/bits/deque.tcc
index ee03c917a29..05929e9f812 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -601,6 +601,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
std::forward_iterator_tag)
{
const size_type __n = std::distance(__first, __last);
+ if (__builtin_expect(__n == 0, 0))
+ return;
+
if (__pos._M_cur == this->_M_impl._M_start._M_cur)
{
iterator __new_start = _M_reserve_elements_at_front(__n);
diff --git
a/libstdc++-v3/testsuite/23_containers/deque/modifiers/insert/118035.cc
b/libstdc++-v3/testsuite/23_containers/deque/modifiers/insert/118035.cc
new file mode 100644
index 000..a37d3dc3d04
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/modifiers/insert/118035.cc
@@ -0,0 +1,26 @@
+// { dg-do run }
+
+#include
+#include
+
+struct Sparks
+{
+ Sparks& operator=(const Sparks& s)
+ {
+VERIFY( this != &s ); // This town ain't big enough for the both of us.
+return *this;
+ }
+};
+
+void
+test_pr118035()
+{
+ std::deque d(3, Sparks());
+ Sparks s[1];
+ d.insert(d.begin() + 1, s, s);
+}
+
+int main()
+{
+ test_pr118035();
+}
--
2.47.1
RE: [PATCH 2/7]AArch64: Add SVE support for simd clones [PR96342]
> > +}
> > + cgraph_simd_clone *sc = node->simdclone;
> > +
> > + for (unsigned i = 0; i < sc->nargs; ++i)
> > +{
> > + bool is_mask = false;
> > + tree type;
> > + switch (sc->args[i].arg_type)
> > + {
> > + case SIMD_CLONE_ARG_TYPE_MASK:
> > + is_mask = true;
> > + gcc_fallthrough ();
> > + case SIMD_CLONE_ARG_TYPE_VECTOR:
> > + case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
> > + case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
> > + type = sc->args[i].vector_type;
> > + gcc_assert (VECTOR_TYPE_P (type));
> > + if (node->simdclone->vecsize_mangle == 's')
> > + type = simd_clone_adjust_sve_vector_type (type, is_mask,
> > + sc->simdlen);
> > + else if (is_mask)
> > + type = truth_type_for (type);
>
> Sorry, I have a horrible feeling I knew this once and have forgotten,
> but: why do we need to this for non-SVE, when we didn't before?
>
I don't think we do either. For Adv. SIMD the truth type is the same as
the vector type anyway so this is a no-op. Removed.
>
> I should have noticed this last time, sorry, but we don't seem to have
> any coverage for the linear cases above. Maybe that comes in a later
> patch though.
>
No, Though I tried to make some examples of linear cases.
On C the vectorizer just ignores the pragma.
In C++ with a linear reference we fail to vectorize because we hit the
Safe_len being an int and VF being a poly thing again and so we bail out.
I did manage to create a testcase that generates an ICE, but that's due to
an existing bug in the vectorizer with how it registers masks.
Since that's an existing bug I'm hoping that's not a blocker for this series.
gcc/ChangeLog:
PR target/96342
* config/aarch64/aarch64-protos.h (add_sve_type_attribute): Declare.
* config/aarch64/aarch64-sve-builtins.cc (add_sve_type_attribute): Make
visibility global and support use for non_acle types.
* config/aarch64/aarch64.cc
(aarch64_simd_clone_compute_vecsize_and_simdlen): Create VLA simd clone
when no simdlen is provided, according to ABI rules.
(simd_clone_adjust_sve_vector_type): New helper function.
(aarch64_simd_clone_adjust): Add '+sve' attribute to SVE simd clones
and modify types to use SVE types.
* omp-simd-clone.cc (simd_clone_mangle): Print 'x' for VLA simdlen.
(simd_clone_adjust): Adapt safelen check to be compatible with VLA
simdlen.
gcc/testsuite/ChangeLog:
PR target/96342
* gcc.target/aarch64/declare-simd-2.c: Add SVE clone scan.
* gcc.target/aarch64/vect-simd-clone-1.c: New test.
* g++.target/aarch64/vect-simd-clone-1.c: New test.
Co-authored-by: Victor Do Nascimento
Co-authored-by: Tamar Christina
Bootstrapped Regtested on aarch64-none-linux-gnu,
arm-none-linux-gnueabihf, x86_64-pc-linux-gnu
-m32, -m64 and no issues.
Ok for master?
Thanks,
Tamar
-- inline copy of patch --
diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index
bd17486e9128a21bd205ef1fb3ec3e323408ec59..7ab1316cf56850678d93b6fdb8d19eea18ad78f1
100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1151,6 +1151,8 @@ namespace aarch64_sve {
#ifdef GCC_TARGET_H
bool verify_type_context (location_t, type_context_kind, const_tree, bool);
#endif
+ void add_sve_type_attribute (tree, unsigned int, unsigned int,
+ const char *, const char *);
}
extern void aarch64_split_combinev16qi (rtx operands[3]);
diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc
b/gcc/config/aarch64/aarch64-sve-builtins.cc
index
5acc56f99c65498cbf5593a9ee21540fa55098c2..e93c3a78e6d6c909f5de32ba8672503fc42b8d1c
100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.cc
+++ b/gcc/config/aarch64/aarch64-sve-builtins.cc
@@ -1032,15 +1032,18 @@ static GTY(()) hash_map
*overload_names[2];
/* Record that TYPE is an ABI-defined SVE type that contains NUM_ZR SVE vectors
and NUM_PR SVE predicates. MANGLED_NAME, if nonnull, is the ABI-defined
- mangling of the type. ACLE_NAME is the name of the type. */
-static void
+ mangling of the type. mangling of the type. ACLE_NAME is the
+ name of the type, or null if does not provide the type. */
+void
add_sve_type_attribute (tree type, unsigned int num_zr, unsigned int num_pr,
const char *mangled_name, const char *acle_name)
{
tree mangled_name_tree
= (mangled_name ? get_identifier (mangled_name) : NULL_TREE);
+ tree acle_name_tree
+= (acle_name ? get_identifier (acle_name) : NULL_TREE);
- tree value = tree_cons (NULL_TREE, get_identifier (acle_name), NULL_TREE);
+ tree value = tree_cons (NULL_TREE, acle_name_tree, NULL_TREE);
value = tree_cons (NULL_TREE, mangled_name_tree, value);
value = tree_cons (NULL_TREE, size_int (num_pr), value);
value = tree_cons
Re: [PATCH 1/2] c++: subsumption of complex constraints [PR118069]
On Tue, Dec 17, 2024 at 10:43:49AM -0500, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk? Shall we also backport this to release branches?
> It's not a regression but seems like a safe fix for an inconvenient
> issue.
>
> -- >8 --
>
> For the testcase in the PR we hang during constraint normalization
> ultimately because one of the constraints is complex enough that its
> conjunctive normal form is calculated to have more than 2^31 clauses,
> which causes the size calculation (through an int) to overflow and so
> the optimization in subsumes_constraints_nonnull
>
> if (dnf_size (lhs) <= cnf_size (rhs))
> // iterate over DNF of LHS
> else
> // iterate over CNF of RHS
>
> incorrectly decides to loop over the CNF (billions of clauses) instead
> of the DNF (thousands of clauses).
>
> I haven't verified that the result of cnf_size is correct for the
> problematic constraint but integer overflow is definitely plausible
> given that CNF/DNF can be exponentially larger than the original
> constraint in the worst case.
>
> This patch fixes this by using a 64-bit unsigned int during DNF/CNF size
> calculation which is enough to avoid overflow in the testcase, and we now
> compile it in ~3 seconds.
Sorry for a silly question, but is there a reason to prefer
unsigned HOST_WIDE_INT over uint64_t?
Patch seems fine, though, thanks.
> In theory doubling the precision will only let us handle a ~2x bigger
> constraint before risking overflow in the worst case given the
> exponential-ness, but I suppose it should suffice for now.
>
> PR c++/118069
>
> gcc/cp/ChangeLog:
>
> * logic.cc (dnf_size_r): Use unsigned HOST_WIDE_INT instead of int.
> (cnf_size_r): Likewise.
> (dnf_size): Likewise.
> (cnf_size): Likewise.
> ---
> gcc/cp/logic.cc | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/cp/logic.cc b/gcc/cp/logic.cc
> index fab2c357dc4..e46ea0ebb78 100644
> --- a/gcc/cp/logic.cc
> +++ b/gcc/cp/logic.cc
> @@ -349,7 +349,7 @@ atomic_p (tree t)
> distributing. In general, a conjunction for which this flag is set
> is considered a disjunction for the purpose of counting. */
>
> -static std::pair
> +static std::pair
> dnf_size_r (tree t)
> {
>if (atomic_p (t))
> @@ -360,9 +360,9 @@ dnf_size_r (tree t)
> the results. */
>tree lhs = TREE_OPERAND (t, 0);
>tree rhs = TREE_OPERAND (t, 1);
> - std::pair p1 = dnf_size_r (lhs);
> - std::pair p2 = dnf_size_r (rhs);
> - int n1 = p1.first, n2 = p2.first;
> + auto p1 = dnf_size_r (lhs);
> + auto p2 = dnf_size_r (rhs);
> + unsigned HOST_WIDE_INT n1 = p1.first, n2 = p2.first;
>bool d1 = p1.second, d2 = p2.second;
>
>if (disjunction_p (t))
> @@ -457,7 +457,7 @@ dnf_size_r (tree t)
> distributing. In general, a disjunction for which this flag is set
> is considered a conjunction for the purpose of counting. */
>
> -static std::pair
> +static std::pair
> cnf_size_r (tree t)
> {
>if (atomic_p (t))
> @@ -468,9 +468,9 @@ cnf_size_r (tree t)
> the results. */
>tree lhs = TREE_OPERAND (t, 0);
>tree rhs = TREE_OPERAND (t, 1);
> - std::pair p1 = cnf_size_r (lhs);
> - std::pair p2 = cnf_size_r (rhs);
> - int n1 = p1.first, n2 = p2.first;
> + auto p1 = cnf_size_r (lhs);
> + auto p2 = cnf_size_r (rhs);
> + unsigned HOST_WIDE_INT n1 = p1.first, n2 = p2.first;
>bool d1 = p1.second, d2 = p2.second;
>
>if (disjunction_p (t))
> @@ -560,10 +560,10 @@ cnf_size_r (tree t)
> /* Count the number conjunctive clauses that would be created
> when rewriting T to DNF. */
>
> -static int
> +static unsigned HOST_WIDE_INT
> dnf_size (tree t)
> {
> - std::pair result = dnf_size_r (t);
> + auto result = dnf_size_r (t);
>return result.first == 0 ? 1 : result.first;
> }
>
> @@ -571,10 +571,10 @@ dnf_size (tree t)
> /* Count the number disjunctive clauses that would be created
> when rewriting T to CNF. */
>
> -static int
> +static unsigned HOST_WIDE_INT
> cnf_size (tree t)
> {
> - std::pair result = cnf_size_r (t);
> + auto result = cnf_size_r (t);
>return result.first == 0 ? 1 : result.first;
> }
>
> --
> 2.48.0.rc0
>
Marek
Re: [PATCH 1/2] c++: subsumption of complex constraints [PR118069]
On Tue, 17 Dec 2024, Marek Polacek wrote:
> On Tue, Dec 17, 2024 at 10:43:49AM -0500, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk? Shall we also backport this to release branches?
> > It's not a regression but seems like a safe fix for an inconvenient
> > issue.
> >
> > -- >8 --
> >
> > For the testcase in the PR we hang during constraint normalization
> > ultimately because one of the constraints is complex enough that its
> > conjunctive normal form is calculated to have more than 2^31 clauses,
> > which causes the size calculation (through an int) to overflow and so
> > the optimization in subsumes_constraints_nonnull
> >
> > if (dnf_size (lhs) <= cnf_size (rhs))
> > // iterate over DNF of LHS
> > else
> > // iterate over CNF of RHS
> >
> > incorrectly decides to loop over the CNF (billions of clauses) instead
> > of the DNF (thousands of clauses).
> >
> > I haven't verified that the result of cnf_size is correct for the
> > problematic constraint but integer overflow is definitely plausible
> > given that CNF/DNF can be exponentially larger than the original
> > constraint in the worst case.
> >
> > This patch fixes this by using a 64-bit unsigned int during DNF/CNF size
> > calculation which is enough to avoid overflow in the testcase, and we now
> > compile it in ~3 seconds.
>
> Sorry for a silly question, but is there a reason to prefer
> unsigned HOST_WIDE_INT over uint64_t?
Using HOST_WIDE_INT seems to be the more common practice, probably for
historical reasons. It seems neither u?int64_t nor long long are used
anywhere in the C++ FE currently, though they are used in other parts of
the compiler though so I guess it'd be fine to start using them in the
C++ FE.
>
> Patch seems fine, though, thanks.
>
> > In theory doubling the precision will only let us handle a ~2x bigger
> > constraint before risking overflow in the worst case given the
> > exponential-ness, but I suppose it should suffice for now.
> >
> > PR c++/118069
> >
> > gcc/cp/ChangeLog:
> >
> > * logic.cc (dnf_size_r): Use unsigned HOST_WIDE_INT instead of int.
> > (cnf_size_r): Likewise.
> > (dnf_size): Likewise.
> > (cnf_size): Likewise.
> > ---
> > gcc/cp/logic.cc | 24
> > 1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/gcc/cp/logic.cc b/gcc/cp/logic.cc
> > index fab2c357dc4..e46ea0ebb78 100644
> > --- a/gcc/cp/logic.cc
> > +++ b/gcc/cp/logic.cc
> > @@ -349,7 +349,7 @@ atomic_p (tree t)
> > distributing. In general, a conjunction for which this flag is set
> > is considered a disjunction for the purpose of counting. */
> >
> > -static std::pair
> > +static std::pair
> > dnf_size_r (tree t)
> > {
> >if (atomic_p (t))
> > @@ -360,9 +360,9 @@ dnf_size_r (tree t)
> > the results. */
> >tree lhs = TREE_OPERAND (t, 0);
> >tree rhs = TREE_OPERAND (t, 1);
> > - std::pair p1 = dnf_size_r (lhs);
> > - std::pair p2 = dnf_size_r (rhs);
> > - int n1 = p1.first, n2 = p2.first;
> > + auto p1 = dnf_size_r (lhs);
> > + auto p2 = dnf_size_r (rhs);
> > + unsigned HOST_WIDE_INT n1 = p1.first, n2 = p2.first;
> >bool d1 = p1.second, d2 = p2.second;
> >
> >if (disjunction_p (t))
> > @@ -457,7 +457,7 @@ dnf_size_r (tree t)
> > distributing. In general, a disjunction for which this flag is set
> > is considered a conjunction for the purpose of counting. */
> >
> > -static std::pair
> > +static std::pair
> > cnf_size_r (tree t)
> > {
> >if (atomic_p (t))
> > @@ -468,9 +468,9 @@ cnf_size_r (tree t)
> > the results. */
> >tree lhs = TREE_OPERAND (t, 0);
> >tree rhs = TREE_OPERAND (t, 1);
> > - std::pair p1 = cnf_size_r (lhs);
> > - std::pair p2 = cnf_size_r (rhs);
> > - int n1 = p1.first, n2 = p2.first;
> > + auto p1 = cnf_size_r (lhs);
> > + auto p2 = cnf_size_r (rhs);
> > + unsigned HOST_WIDE_INT n1 = p1.first, n2 = p2.first;
> >bool d1 = p1.second, d2 = p2.second;
> >
> >if (disjunction_p (t))
> > @@ -560,10 +560,10 @@ cnf_size_r (tree t)
> > /* Count the number conjunctive clauses that would be created
> > when rewriting T to DNF. */
> >
> > -static int
> > +static unsigned HOST_WIDE_INT
> > dnf_size (tree t)
> > {
> > - std::pair result = dnf_size_r (t);
> > + auto result = dnf_size_r (t);
> >return result.first == 0 ? 1 : result.first;
> > }
> >
> > @@ -571,10 +571,10 @@ dnf_size (tree t)
> > /* Count the number disjunctive clauses that would be created
> > when rewriting T to CNF. */
> >
> > -static int
> > +static unsigned HOST_WIDE_INT
> > cnf_size (tree t)
> > {
> > - std::pair result = cnf_size_r (t);
> > + auto result = cnf_size_r (t);
> >return result.first == 0 ? 1 : result.first;
> > }
> >
> > --
> > 2.48.0.rc0
> >
>
> Marek
>
>
Re: [PATCH v3 0/5] c++/modules: Implement P1815 "Translation-unit-local entities"
On 11/27/24 3:53 AM, Nathaniel Shead wrote:
Gentle ping for this series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665108.html
Most of the patches no longer applied cleanly to trunk since the last
time I pinged this so I'm attaching newly rebased patches.
One slight adjustment I've included as well is a test in internal-4_b.C
for exposures of namespace aliases, as in:
namespace { namespace internal {} }
export namespace exposure = internal;
By the standard this appears to be well-formed; we currently error, and
I think this might be the desired behaviour (an easy workaround is to
wrap the alias in an anonymous namespace), but thought I'd at least test
the existing behaviour here.
Tested modules.exp on x86_64-pc-linux-gnu, OK for trunk if full
bootstrap+regtest succeeds?
I tweaked some of these patches a bit; OK with these changes, or without
patch #2 if you'd rather not make that change.
From 287c5053b59631be749a802a3b88f83572ec578a Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Fri, 13 Dec 2024 19:10:03 -0500
Subject: [PATCH] c++: adjust "Ignore TU-local entities where necessary"
To: gcc-patches@gcc.gnu.org
That commit message, and a comment in the code, mention explicit
instantiations as a case we might want to suppress
-Wtemplate-names-tu-local, but they previously weren't on
DECL_TEMPLATE_INSTANTIATIONS. This patch adds all function template
instantiations to that list in modules so that we can check for it.
gcc/cp/ChangeLog:
* cp-tree.h (DECL_TEMPLATE_INSTANTIATIONS): Update comment.
* module.cc (template_has_explicit_inst): New.
(depset::hash::finalize_dependencies): Use it.
* pt.cc (register_specialization): Always register in a module.
gcc/testsuite/ChangeLog:
* g++.dg/modules/internal-5_a.C: Remove some warnings.
---
gcc/cp/cp-tree.h| 23 +-
gcc/cp/module.cc| 26 ++---
gcc/cp/pt.cc| 3 +++
gcc/testsuite/g++.dg/modules/internal-5_a.C | 4 ++--
4 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 216fdfa7b8a..d793e2bc8de 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5158,18 +5158,19 @@ get_vec_init_expr (tree t)
tree is converted to C++ class hiearchy. */
#define DECL_TEMPLATE_RESULT(NODE) \
((struct tree_template_decl *)CONST_CAST_TREE(TEMPLATE_DECL_CHECK (NODE)))->result
-/* For a function template at namespace scope, DECL_TEMPLATE_INSTANTIATIONS
- lists all instantiations and specializations of the function so that
- tsubst_friend_function can reassign them to another template if we find
- that the namespace-scope template is really a partial instantiation of a
- friend template.
+/* For a forward-declared function template at namespace scope, or for any
+ function template in an exporting module, DECL_TEMPLATE_INSTANTIATIONS lists
+ all instantiations and specializations of the function so that
+ tsubst_friend_function can reassign them to another template if we find that
+ the namespace-scope template is really a partial instantiation of a friend
+ template.
- For a class template the DECL_TEMPLATE_INSTANTIATIONS lists holds
- all instantiations and specializations of the class type, including
- partial instantiations and partial specializations, so that if we
- explicitly specialize a partial instantiation we can walk the list
- in maybe_process_partial_specialization and reassign them or complain
- as appropriate.
+ For a class or variable template the DECL_TEMPLATE_INSTANTIATIONS lists
+ holds all instantiations and specializations, including partial
+ instantiations and partial specializations, so that if we explicitly
+ specialize a partial instantiation we can walk the list in
+ maybe_process_partial_specialization and reassign them or complain as
+ appropriate.
In both cases, the TREE_PURPOSE of each node contains the arguments
used; the TREE_VALUE contains the generated variable. The template
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 6c5350064df..629863e4007 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -14491,6 +14491,24 @@ binding_cmp (const void *a_, const void *b_)
return DECL_UID (a_ent) < DECL_UID (b_ent) ? -1 : +1;
}
+/* True iff TMPL has an explicit instantiation definition.
+
+ This is local to module.cc because register_specialization skips adding most
+ instantiations unless module_maybe_has_cmi_p. */
+
+static bool
+template_has_explicit_inst (tree tmpl)
+{
+ for (tree t = DECL_TEMPLATE_INSTANTIATIONS (tmpl); t; t = TREE_CHAIN (t))
+{
+ tree spec = TREE_VALUE (t);
+ if (DECL_EXPLICIT_INSTANTIATION (spec)
+ && !DECL_REALLY_EXTERN (spec))
+ return true;
+}
+ return false;
+}
+
/* Sort the bindings, issue errors about bad internal refs. */
bool
@@ -14562,9 +14580,11 @@ depset::hash::finalize_dependencies ()
(T
[PATCH] arm: Properly escape tab, newline and semicolon in thumb1.md
Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85).
Ok for trunk?
--
Without the escape of the tab, newline and semicolon, the generated
assembler output will not match the expected assmbler in the test cases.
Fixes Linaro CI reported regression on r15-6166-gb7e11b499922 in
https://linaro.atlassian.net/browse/GNU-1464.
gcc/ChangeLog:
* config/arm/thumb1.md (thumb1_cbz): Escape tab, newline and
semicolon.
Signed-off-by: Torbjörn SVENSSON
---
gcc/config/arm/thumb1.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/config/arm/thumb1.md b/gcc/config/arm/thumb1.md
index b4d7c6ea981..09c4e81c1cc 100644
--- a/gcc/config/arm/thumb1.md
+++ b/gcc/config/arm/thumb1.md
@@ -1145,9 +1145,9 @@ (define_insn "thumb1_cbz"
switch (get_attr_length (insn))
{
- case 4: return "b%d0\t%l2";
- case 6: return "b%D0\t.LCB%=;b\t%l2\t%@long jump\n.LCB%=:";
- case 8: return "b%D0\t.LCB%=;bl\t%l2\t%@far jump\n.LCB%=:";
+ case 4: return \"b%d0\\t%l2\";
+ case 6: return \"b%D0\\t.LCB%=\;b\\t%l2\\t%@long jump\\n.LCB%=:\";
+ case 8: return \"b%D0\\t.LCB%=\;bl\\t%l2\\t%@far jump\\n.LCB%=:\";
default: gcc_unreachable ();
}
}
--
2.25.1
Re: [Patch, fortran] PR117897 - [13/14 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)
Thanks Paul. Regards, Jerry On Tue, Dec 17, 2024, 12:34 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This bug was so obviously in defiance of the standard that I pushed it to > mainline as r15-6260. I meant to post this message immediately but was > distracted before I could press send. I will be backporting today. > > Paul > >
Re: [PATCH] ifcombine field merge: handle masks with sign extensions
> Am 18.12.2024 um 05:00 schrieb Alexandre Oliva :
>
> When a loaded field is sign extended, masked and compared, we used to
> drop from the mask the bits past the original field width, which is
> not correct.
>
> Take note of the fact that the mask covered copies of the sign bit,
> before clipping it, and arrange to test the sign bit if we're
> comparing with zero. Punt in other cases.
>
> If bits_test fail recoverably, try other ifcombine strategies.
>
> Regstrapped on x86_64-linux-gnu and ppc64-linux-gnu, along with 5 other
> ifcombine patches. Ok to install?
Ok
Richard
> for gcc/ChangeLog
>
>* gimple-fold.cc (decode_field_reference): Add psignbit
>parameter. Set it if the mask references sign-extending
>bits.
>(fold_truth_andor_for_ifcombine): Adjust calls with new
>variables. Swap them along with other r?_* variables. Handle
>extended sign bit compares with zero.
>* tree-ssa-ifcombine.cc (ifcombine_ifandif): If bits_test
>fails in a way that doesn't prevent other ifcombine strategies
>from passing, give them a try.
>
> for gcc/testsuite/ChangeLog
>
>* gcc.dg/field-merge-16.c: New.
> ---
> gcc/gimple-fold.cc| 69 -
> gcc/testsuite/gcc.dg/field-merge-16.c | 66
> gcc/tree-ssa-ifcombine.cc |5 +-
> 3 files changed, 128 insertions(+), 12 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/field-merge-16.c
>
> diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
> index 856ee5369a8c9..b84269d6b4179 100644
> --- a/gcc/gimple-fold.cc
> +++ b/gcc/gimple-fold.cc
> @@ -7514,6 +7514,9 @@ gimple_binop_def_p (enum tree_code code, tree t, tree
> op[2])
>is initially set to a mask with nonzero precision, that mask is
>combined with the found mask, or adjusted in precision to match.
>
> + *PSIGNBIT is set to TRUE if, before clipping to *PBITSIZE, the mask
> + encompassed bits that corresponded to extensions of the sign bit.
> +
>*XOR_P is to be FALSE if EXP might be a XOR used in a compare, in which
>case, if XOR_CMP_OP is a zero constant, it will be overridden with *PEXP,
>*XOR_P will be set to TRUE, and the left-hand operand of the XOR will be
> @@ -7533,7 +7536,8 @@ static tree
> decode_field_reference (tree *pexp, HOST_WIDE_INT *pbitsize,
>HOST_WIDE_INT *pbitpos,
>bool *punsignedp, bool *preversep, bool *pvolatilep,
> -wide_int *pand_mask, bool *xor_p, tree *xor_cmp_op,
> +wide_int *pand_mask, bool *psignbit,
> +bool *xor_p, tree *xor_cmp_op,
>gimple **load, location_t loc[4])
> {
> tree exp = *pexp;
> @@ -7545,6 +7549,7 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
> *pbitsize,
> machine_mode mode;
>
> *load = NULL;
> + *psignbit = false;
>
> /* All the optimizations using this function assume integer fields.
> There are problems with FP fields since the type_for_size call
> @@ -7708,12 +7713,23 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
> *pbitsize,
> if (outer_type && *pbitsize == TYPE_PRECISION (outer_type))
> *punsignedp = TYPE_UNSIGNED (outer_type);
>
> - /* Make the mask the expected width. */
> - if (and_mask.get_precision () != 0)
> -and_mask = wide_int::from (and_mask, *pbitsize, UNSIGNED);
> -
> if (pand_mask)
> -*pand_mask = and_mask;
> +{
> + /* Make the mask the expected width. */
> + if (and_mask.get_precision () != 0)
> +{
> + /* If the AND_MASK encompasses bits that would be extensions of
> + the sign bit, set *PSIGNBIT. */
> + if (!unsignedp
> + && and_mask.get_precision () > *pbitsize
> + && (and_mask
> + & wi::mask (*pbitsize, true, and_mask.get_precision ())) != 0)
> +*psignbit = true;
> + and_mask = wide_int::from (and_mask, *pbitsize, UNSIGNED);
> +}
> +
> + *pand_mask = and_mask;
> +}
>
> return inner;
> }
> @@ -7995,6 +8011,7 @@ fold_truth_andor_for_ifcombine (enum tree_code code,
> tree truth_type,
> HOST_WIDE_INT rnbitsize, rnbitpos, rnprec;
> bool ll_unsignedp, lr_unsignedp, rl_unsignedp, rr_unsignedp;
> bool ll_reversep, lr_reversep, rl_reversep, rr_reversep;
> + bool ll_signbit, lr_signbit, rl_signbit, rr_signbit;
> scalar_int_mode lnmode, lnmode2, rnmode;
> wide_int ll_and_mask, lr_and_mask, rl_and_mask, rr_and_mask;
> wide_int l_const, r_const;
> @@ -8114,19 +8131,19 @@ fold_truth_andor_for_ifcombine (enum tree_code code,
> tree truth_type,
> bool l_xor = false, r_xor = false;
> ll_inner = decode_field_reference (&ll_arg, &ll_bitsize, &ll_bitpos,
> &ll_unsignedp, &ll_reversep, &volatilep,
> - &ll_and_mask, &l_xor, &lr_arg,
> + &ll_and_mask, &ll_signbit, &l_xor, &lr_arg,
> &ll_load, ll_loc);
> lr_inner = decode_field_reference (&lr_arg, &lr_bitsize, &lr_bitpos,
>
