Re: Re: [PATCH] test regression fix: Remove xfail for variable length targets
On Tue, 16 Jan 2024, juzhe.zh...@rivai.ai wrote:
> >> That's probably because we have vect_variable_length && vect128 instead?
> Yes. Both RVV and SVE uses 128bit vector SLP.
>
> The optimized IR (both ARM SVE and RVV are similiar):
> vect__1.5_189 = MEM [(int *)x_50(D)];
> vect__1.6_191 = MEM [(int *)x_50(D) + 16B];
> mask__2.7_192 = vect__1.5_189 == { 1, 1, 1, 1 };
> mask__2.7_193 = vect__1.6_191 == { 1, 1, 1, 1 };
> mask_patt_156.8_194 = VEC_PACK_TRUNC_EXPR ;
> vect__3.11_196 = MEM [(short int *)y_51(D)];
> mask__4.12_197 = vect__3.11_196 == { 2, 2, 2, 2, 2, 2, 2, 2 };
> mask_patt_157.13_198 = mask_patt_156.8_194 & mask__4.12_197;
> vect_patt_158.14_199 = .VCOND_MASK (mask_patt_157.13_198, { 1, 1, 1, 1, 1,
> 1, 1, 1 }, { 0, 0, 0, 0, 0, 0, 0, 0 });
> vect_patt_159.15_200 = [vec_unpack_lo_expr] vect_patt_158.14_199;
> vect_patt_159.15_201 = [vec_unpack_hi_expr] vect_patt_158.14_199;
so xfail { vect_variable_length && { ! vect256 } && { ! vect128 } } then?
>
>
> juzhe.zh...@rivai.ai
>
> From: Richard Biener
> Date: 2024-01-16 15:38
> To: Juzhe-Zhong
> CC: gcc-patches; Tamar.Christina
> Subject: Re: [PATCH] test regression fix: Remove xfail for variable length
> targets
> On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
>
> > Recently notice there is a XPASS in RISC-V:
> > XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not
> > slp2 "vector operands from scalars"
> > XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands
> > from scalars"
> >
> > And checked both ARM SVE and RVV:
> >
> > https://godbolt.org/z/T9cPa7fh3
> >
> > both has the same dump slp2. So I guess ARM SVE has the same XPASS in this
> > test.
>
> That's probably because we have vect_variable_length && vect128 instead?
> Thus, what's the IL after SLP2 (and some DCE)?
>
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/vect/bb-slp-43.c: Remove xfail for variable length.
> >
> > ---
> > gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> > b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> > index dad2d24262d..40bd2e0dfbf 100644
> > --- a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> > +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> > @@ -14,4 +14,4 @@ f (int *restrict x, short *restrict y)
> > }
> >
> > /* { dg-final { scan-tree-dump-not "mixed mask and nonmask" "slp2" } } */
> > -/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
> > target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign
> > } } xfail { vect_variable_length && { ! vect256 } } } } } */
> > +/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
> > target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign
> > } } } } } */
> >
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH] test regression fix: Remove xfail for variable length targets of bb-slp-subgroups-3.c
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> Notice there is a regression recently:
> XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects
> scan-tree-dump-times slp2 "optimized: basic block" 2
> XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized:
> basic block" 2
>
> Checked on both ARM SVE an RVV:
>
> https://godbolt.org/z/jz4cYbqc8
>
> "optimized: basic block" appears twice.
>
> I guess ARM SVE has the same XPASS as RVV.
>
> Hi, Andrew. Could you confirm about it ?
How does it vectorize it? See the comments in the testcase. The
intent was to check we can split the store and vectorize the
add and multiplication separately even when fed from the same
load group. So ideally we'd add sth similar as in bb-slp-43.c,
looking for not "vector operands from scalars"
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/bb-slp-subgroups-3.c: Remove XFAIL of variable length.
>
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
> b/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
> index fb719915db7..3f0d45ce4a1 100644
> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
> +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
> @@ -42,7 +42,7 @@ main (int argc, char **argv)
> /* Because we disable the cost model, targets with variable-length
> vectors can end up vectorizing the store to a[0..7] on its own.
> With the cost model we do something sensible. */
> -/* { dg-final { scan-tree-dump-times "optimized: basic block" 2 "slp2" {
> target { ! amdgcn-*-* } xfail vect_variable_length } } } */
> +/* { dg-final { scan-tree-dump-times "optimized: basic block" 2 "slp2" {
> target { ! amdgcn-*-* } } } } */
>
> /* amdgcn can do this in one vector. */
> /* { dg-final { scan-tree-dump-times "optimized: basic block" 1 "slp2" {
> target amdgcn-*-* } } } */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: Re: [PATCH] test regression fix: Remove xfail for variable length targets
>> That's probably because we have vect_variable_length && vect128 instead?
Yes. Both RVV and SVE uses 128bit vector SLP.
The optimized IR (both ARM SVE and RVV are similiar):
vect__1.5_189 = MEM [(int *)x_50(D)];
vect__1.6_191 = MEM [(int *)x_50(D) + 16B];
mask__2.7_192 = vect__1.5_189 == { 1, 1, 1, 1 };
mask__2.7_193 = vect__1.6_191 == { 1, 1, 1, 1 };
mask_patt_156.8_194 = VEC_PACK_TRUNC_EXPR ;
vect__3.11_196 = MEM [(short int *)y_51(D)];
mask__4.12_197 = vect__3.11_196 == { 2, 2, 2, 2, 2, 2, 2, 2 };
mask_patt_157.13_198 = mask_patt_156.8_194 & mask__4.12_197;
vect_patt_158.14_199 = .VCOND_MASK (mask_patt_157.13_198, { 1, 1, 1, 1, 1, 1,
1, 1 }, { 0, 0, 0, 0, 0, 0, 0, 0 });
vect_patt_159.15_200 = [vec_unpack_lo_expr] vect_patt_158.14_199;
vect_patt_159.15_201 = [vec_unpack_hi_expr] vect_patt_158.14_199;
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2024-01-16 15:38
To: Juzhe-Zhong
CC: gcc-patches; Tamar.Christina
Subject: Re: [PATCH] test regression fix: Remove xfail for variable length
targets
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> Recently notice there is a XPASS in RISC-V:
> XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not
> slp2 "vector operands from scalars"
> XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
> scalars"
>
> And checked both ARM SVE and RVV:
>
> https://godbolt.org/z/T9cPa7fh3
>
> both has the same dump slp2. So I guess ARM SVE has the same XPASS in this
> test.
That's probably because we have vect_variable_length && vect128 instead?
Thus, what's the IL after SLP2 (and some DCE)?
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/bb-slp-43.c: Remove xfail for variable length.
>
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> index dad2d24262d..40bd2e0dfbf 100644
> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> @@ -14,4 +14,4 @@ f (int *restrict x, short *restrict y)
> }
>
> /* { dg-final { scan-tree-dump-not "mixed mask and nonmask" "slp2" } } */
> -/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
> target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign }
> } xfail { vect_variable_length && { ! vect256 } } } } } */
> +/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
> target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign }
> } } } } */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH] test regression fix: Remove xfail for variable length targets
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> Recently notice there is a XPASS in RISC-V:
> XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not
> slp2 "vector operands from scalars"
> XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
> scalars"
>
> And checked both ARM SVE and RVV:
>
> https://godbolt.org/z/T9cPa7fh3
>
> both has the same dump slp2. So I guess ARM SVE has the same XPASS in this
> test.
That's probably because we have vect_variable_length && vect128 instead?
Thus, what's the IL after SLP2 (and some DCE)?
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/bb-slp-43.c: Remove xfail for variable length.
>
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> index dad2d24262d..40bd2e0dfbf 100644
> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> @@ -14,4 +14,4 @@ f (int *restrict x, short *restrict y)
> }
>
> /* { dg-final { scan-tree-dump-not "mixed mask and nonmask" "slp2" } } */
> -/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
> target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign }
> } xfail { vect_variable_length && { ! vect256 } } } } } */
> +/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
> target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign }
> } } } } */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[Bug libstdc++/113258] Pre-C++17 code that replaces malloc/free crashes when mixed with post-C++17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #26 from Sam James --- Just to close the loop: this ended up being covered originally a few months back with https://airlied.blogspot.com/2023/04/fedora-38-llvm-vs-team-fortress-2-tf2.html and https://gitlab.freedesktop.org/mesa/mesa/-/issues/8133. That's clearly what the original report above is derived from too. Unfortunately, getting fixed copies of libtcmalloc in games which were shipped a decade ago isn't likely. Thanks for the workaround.
[Bug target/107201] [avr] -nodevicelib not working for devices -mmcu=avr...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107201 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:3f6efe203484f7fb29c048d024dd8205e9e0f193 commit r13-8227-g3f6efe203484f7fb29c048d024dd8205e9e0f193 Author: Georg-Johann Lay Date: Mon Jan 15 13:25:59 2024 +0100 AVR: target/107201: Make -nodevicelib work for all devices. driver-avr.cc contains a spec that discriminates between cores and devices by means of a mmcu=avr* spec pattern. This does not work for new devices like AVR128* which also start with mmcu=avr like all cores do. The patch uses a new spec function in order to tell apart cores from devices. gcc/ PR target/107201 * config/avr/avr.h (EXTRA_SPEC_FUNCTIONS): Add no-devlib, avr_no_devlib. * config/avr/driver-avr.cc (avr_no_devlib): New function. (avr_devicespecs_file): Use it to remove -nodevicelib from the options for cores only. * config/avr/avr-arch.h (avr_get_parch): New prototype. * config/avr/avr-devices.cc (avr_get_parch): New function. (cherry picked from commit 86fac7ee1688bdec245a43f6d2ab49fb238892e4)
[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #15 from Richard Biener --- (In reply to Gaius Mulley from comment #14) > Ah apologies, is it best that I revert: > > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git; > h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 > > happy to do this in the morning. I think it might be better to define M2C_LONGREAL_FLOAT128/M2C_LONGREAL_PPC64LE (whatever they exactly indicate) in terms of the existing --with-long-double-128 --with-long-double-format aka the TARGET_DEFAULT_LONG_DOUBLE_128 that's put into the config plus with_long_double_format (I think that causes TARGET_IEEEQUAD_DEFAULT to be defined to 1/0, but only for ppc, via config.gcc and tm_defines). I can't say whether it's better to revert or disable/fix as I can't say how this for example affects the M2 ABI (like if there was any 'long double' before this change and what effective type this used).
Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971].
On Mon, 15 Jan 2024, Robin Dapp wrote:
> I gave it another shot now by introducing a separate function as
> Richard suggested. It's probably not at the location he intended.
>
> The way I read the discussion there hasn't been any consensus
> on how (or rather where) to properly tackle the problem. Any
> other ideas still?
I'm happy enough with the patch, esp. at this stage. OK if
Richard S. doesn't disagree.
Thanks,
Richard.
> Regards
> Robin
>
>
> Found in PR112971 this patch adds folding support for bitwise operations
> of const duplicate zero/one vectors with stepped vectors.
> On riscv we have the situation that a folding would perpetually continue
> without simplifying because e.g. {0, 0, 0, ...} & {7, 6, 5, ...} would
> not be folded to {0, 0, 0, ...}.
>
> gcc/ChangeLog:
>
> PR middle-end/112971
>
> * fold-const.cc (simplify_const_binop): New function for binop
> simplification of two constant vectors when element-wise
> handling is not necessary.
> (const_binop): Call new function.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/autovec/pr112971.c: New test.
> ---
> gcc/fold-const.cc | 31 +++
> .../gcc.target/riscv/rvv/autovec/pr112971.c | 18 +++
> 2 files changed, 49 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c
>
> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> index 385e4a69ab3..2ef425aec0f 100644
> --- a/gcc/fold-const.cc
> +++ b/gcc/fold-const.cc
> @@ -1343,6 +1343,29 @@ distributes_over_addition_p (tree_code op, int opno)
> }
> }
>
> +/* OP is the INDEXth operand to CODE (counting from zero) and OTHER_OP
> + is the other operand. Try to use the value of OP to simplify the
> + operation in one step, without having to process individual elements. */
> +static tree
> +simplify_const_binop (tree_code code, tree op, tree other_op,
> + int index ATTRIBUTE_UNUSED)
> +{
> + /* AND, IOR as well as XOR with a zerop can be simplified directly. */
> + if (TREE_CODE (op) == VECTOR_CST && TREE_CODE (other_op) == VECTOR_CST)
> +{
> + if (integer_zerop (other_op))
> + {
> + if (code == BIT_IOR_EXPR || code == BIT_XOR_EXPR)
> + return op;
> + else if (code == BIT_AND_EXPR)
> + return other_op;
> + }
> +}
> +
> + return NULL_TREE;
> +}
> +
> +
> /* Combine two constants ARG1 and ARG2 under operation CODE to produce a new
> constant. We assume ARG1 and ARG2 have the same data type, or at least
> are the same kind of constant and the same machine mode. Return zero if
> @@ -1646,6 +1669,14 @@ const_binop (enum tree_code code, tree arg1, tree arg2)
> return build_complex (type, real, imag);
> }
>
> + tree simplified;
> + if ((simplified = simplify_const_binop (code, arg1, arg2, 0)))
> +return simplified;
> +
> + if (commutative_tree_code (code)
> + && (simplified = simplify_const_binop (code, arg2, arg1, 1)))
> +return simplified;
> +
>if (TREE_CODE (arg1) == VECTOR_CST
>&& TREE_CODE (arg2) == VECTOR_CST
>&& known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)),
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c
> new file mode 100644
> index 000..816ebd3c493
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv_zvl256b -mabi=lp64d -O3
> -fno-vect-cost-model" } */
> +
> +int a;
> +short b[9];
> +char c, d;
> +void e() {
> + d = 0;
> + for (;; d++) {
> +if (b[d])
> + break;
> +a = 8;
> +for (; a >= 0; a--) {
> + char *f =
> + *f &= d == (a & d);
> +}
> + }
> +}
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372 --- Comment #18 from rguenther at suse dot de --- On Mon, 15 Jan 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372 > > --- Comment #17 from Jakub Jelinek --- > (In reply to Richard Biener from comment #15) > > (In reply to Jakub Jelinek from comment #14) > > > Created attachment 57085 [details] > > > gcc14-pr113372.patch > > > > > > The non-propagation workaround which seems to fix^H^H^Hworkaround all > > > those > > > 4 issues (PR90348 testcase actually doesn't FAIL anymore, but I've > > > verified > > > the patch results in in and buf no longer being shared) can look like > > > this. > > > > + || (INTEGRAL_TYPE_P (TREE_TYPE (use)) > > + && TYPE_PRECISION (TREE_TYPE (use)) == POINTER_SIZE))) > > > > ptrofftype_p (TREE_TYPE (use)) > > Aren't there targets where pointers are larger than sizetype? > I thought msp430, but that one uses __int20. There are also address-spaces with pointer sizes different from POINTER_SIZE. I suppose tracking all INTEGRAL_TYPE_P uses and instead relying on the def to identify a pointer source would work as well. > > I think it should be enough to look at gimple_assing_rhs1, that works > > for single non-invariant [i], for conversions and for offsetting of > > an invariant address (pointer-plus). > > Is the invariant operand guaranteed to go first? If it is pointer, guess > POINTER_PLUS_EXPR enforces that, and for sizetype addition guess an operand > can't be ADDR_EXPR, there would need to be a cast in a separate stmt. So > perhaps ok. Yes, I think that works. > As for Micha's fears, I can certainly try to dump statistics during > bootstrap/regtest on how many variables were shared and/or their cumulative > size without/with the patch and see if it has significant effects on > real-world > code. Might be interesting to dump the stack size saved due to sharing instead? Do we really need to handle the PHI nodes btw? With doing propagation we could avoid marking certain use sites as mentions, like compares of the address value. But of course we'd have to give up for uses in calls or other things we can't analyze.
[Bug middle-end/108016] RISC-V：Bad codegen in scalar code comparing to LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108016
--- Comment #2 from JuzheZhong ---
#include
std::pair full_add(unsigned a, unsigned b)
{ return std::make_pair(a + b, a + b < a); }
[Bug target/113416] New: ICE: in force_constant_size, at gimplify.cc:742 (in convert_move, at expr.cc:223) with -march=rv64gcv (-march=rv32gcv) and -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113416
Bug ID: 113416
Summary: ICE: in force_constant_size, at gimplify.cc:742 (in
convert_move, at expr.cc:223) with -march=rv64gcv
(-march=rv32gcv) and -ftree-parallelize-loops=2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 57098
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57098=edit
reduced testcase
This has been reduced from gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-27.c ;
it fails the same way with -ftree-parallelize-loops=2.
Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O -march=rv64gcv -ftree-parallelize-loops=2
testcase.c
during GIMPLE pass: parloops
testcase.c: In function 'f':
testcase.c:4:1: internal compiler error: in force_constant_size, at
gimplify.cc:743
4 | f(long out, int n)
| ^
0xa18136 force_constant_size
/repo/gcc-trunk/gcc/gimplify.cc:743
0x134e297 gimple_add_tmp_var(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:781
0x1304676 create_tmp_var(tree_node*, char const*)
/repo/gcc-trunk/gcc/gimple-expr.cc:491
0x1780c4d separate_decls_in_region
/repo/gcc-trunk/gcc/tree-parloops.cc:2125
0x1782dd1 gen_parallel_loop
/repo/gcc-trunk/gcc/tree-parloops.cc:3162
0x1784a48 parallelize_loops
/repo/gcc-trunk/gcc/tree-parloops.cc:4140
0x1785dc1 execute
/repo/gcc-trunk/gcc/tree-parloops.cc:4228
0x1785dc1 execute
/repo/gcc-trunk/gcc/tree-parloops.cc:4207
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -O -march=rv32gcv -mabi=ilp32
-ftree-parallelize-loops=2 testcase.c
during RTL pass: expand
testcase.c: In function 'f._loopfn.0':
testcase.c:6:17: internal compiler error: in convert_move, at expr.cc:223
6 | for (int i; i < n; i++) {
| ^
0x9f3dd1 convert_move(rtx_def*, rtx_def*, int)
/repo/gcc-trunk/gcc/expr.cc:223
0x127807a store_expr(tree_node*, rtx_def*, int, bool, bool)
/repo/gcc-trunk/gcc/expr.cc:6810
0x1279909 expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.cc:6443
0x112715c expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3966
0x112715c expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4064
0x112e2be expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6120
0x112fec7 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6855
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240115 (experimental) (GCC)
[PATCH] test regression fix: Remove xfail for variable length targets of bb-slp-subgroups-3.c
Notice there is a regression recently:
XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects
scan-tree-dump-times slp2 "optimized: basic block" 2
XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized:
basic block" 2
Checked on both ARM SVE an RVV:
https://godbolt.org/z/jz4cYbqc8
"optimized: basic block" appears twice.
I guess ARM SVE has the same XPASS as RVV.
Hi, Andrew. Could you confirm about it ?
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-subgroups-3.c: Remove XFAIL of variable length.
---
gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
index fb719915db7..3f0d45ce4a1 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-subgroups-3.c
@@ -42,7 +42,7 @@ main (int argc, char **argv)
/* Because we disable the cost model, targets with variable-length
vectors can end up vectorizing the store to a[0..7] on its own.
With the cost model we do something sensible. */
-/* { dg-final { scan-tree-dump-times "optimized: basic block" 2 "slp2" {
target { ! amdgcn-*-* } xfail vect_variable_length } } } */
+/* { dg-final { scan-tree-dump-times "optimized: basic block" 2 "slp2" {
target { ! amdgcn-*-* } } } } */
/* amdgcn can do this in one vector. */
/* { dg-final { scan-tree-dump-times "optimized: basic block" 1 "slp2" {
target amdgcn-*-* } } } */
--
2.36.3
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #6 from chenglulu --- Hi，Ruoyao: I am testing the spec2006 scores when the parameters 'align-loops', 'align-jumps', 'align-functions', and 'align-labels' are '1', '8', '16', and '32' respectively. However, the test was suspended due to the company's power maintenance last week, and it will take some time to retest.
[PATCH] test regression fix: Remove xfail for variable length targets
Recently notice there is a XPASS in RISC-V:
XPASS: gcc.dg/vect/bb-slp-43.c -flto -ffat-lto-objects scan-tree-dump-not slp2
"vector operands from scalars"
XPASS: gcc.dg/vect/bb-slp-43.c scan-tree-dump-not slp2 "vector operands from
scalars"
And checked both ARM SVE and RVV:
https://godbolt.org/z/T9cPa7fh3
both has the same dump slp2. So I guess ARM SVE has the same XPASS in this test.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-43.c: Remove xfail for variable length.
---
gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
index dad2d24262d..40bd2e0dfbf 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
@@ -14,4 +14,4 @@ f (int *restrict x, short *restrict y)
}
/* { dg-final { scan-tree-dump-not "mixed mask and nonmask" "slp2" } } */
-/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign } }
xfail { vect_variable_length && { ! vect256 } } } } } */
+/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign } }
} } } */
--
2.36.3
Re: Ping: [PATCH] LoongArch: Remove constraint z from movsi_internal
在 2024/1/16 下午2:20, Xi Ruoyao 写道:
On Tue, 2024-01-16 at 14:16 +0800, chenglulu wrote:
在 2024/1/16 下午1:34, Xi Ruoyao 写道:
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
We don't allow SImode in FCC, so constraint z is never really used
here.
gcc/ChangeLog:
* config/loongarch/loongarch.md (movsi_internal): Remove
constraint z.
---
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
gcc/config/loongarch/loongarch.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index a5d0dcd65fe..404a663c1a6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -2108,8 +2108,8 @@ (define_expand "movsi"
})
(define_insn_and_split "*movsi_internal"
- [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,w,*f,f,*r,*m,*r,*z")
- (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f,*z,*r"))]
+ [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,w,*f,f,*r,*m")
+ (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f"))]
"(register_operand (operands[0], SImode)
|| reg_or_0_operand (operands[1], SImode))"
{ return loongarch_output_move (operands[0], operands[1]); }
@@ -2122,7 +2122,7 @@ (define_insn_and_split "*movsi_internal"
DONE;
}
"
- [(set_attr "move_type"
"move,const,load,store,mgtf,fpload,mftg,fpstore,mftg,mgtf")
+ [(set_attr "move_type" "move,const,load,store,mgtf,fpload,mftg,fpstore")
(set_attr "mode" "SI")])
Sorry, I have a question. If this place is removed, is movgr2fr in the
loongarch_output_move function no longer needed?
It's needed for moving SImode into FPR. "z" is FCC_REGS, not FP_REGS.
I cannot see movgr2cf or movfr2cf in loongarch_output_move.
Well, I saw it wrong, I have no other questions.
Thanks!
Re: Ping: [PATCH] LoongArch: Remove constraint z from movsi_internal
On Tue, 2024-01-16 at 14:16 +0800, chenglulu wrote:
>
>
> 在 2024/1/16 下午1:34, Xi Ruoyao 写道:
> > Ping.
> >
> > On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
> > > We don't allow SImode in FCC, so constraint z is never really used
> > > here.
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/loongarch/loongarch.md (movsi_internal): Remove
> > > constraint z.
> > > ---
> > >
> > > Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
> > >
> > > gcc/config/loongarch/loongarch.md | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/gcc/config/loongarch/loongarch.md
> > > b/gcc/config/loongarch/loongarch.md
> > > index a5d0dcd65fe..404a663c1a6 100644
> > > --- a/gcc/config/loongarch/loongarch.md
> > > +++ b/gcc/config/loongarch/loongarch.md
> > > @@ -2108,8 +2108,8 @@ (define_expand "movsi"
> > > })
> > >
> > > (define_insn_and_split "*movsi_internal"
> > > - [(set (match_operand:SI 0 "nonimmediate_operand"
> > > "=r,r,r,w,*f,f,*r,*m,*r,*z")
> > > - (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f,*z,*r"))]
> > > + [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,w,*f,f,*r,*m")
> > > + (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f"))]
> > > "(register_operand (operands[0], SImode)
> > > || reg_or_0_operand (operands[1], SImode))"
> > > { return loongarch_output_move (operands[0], operands[1]); }
> > > @@ -2122,7 +2122,7 @@ (define_insn_and_split "*movsi_internal"
> > > DONE;
> > > }
> > > "
> > > - [(set_attr "move_type"
> > > "move,const,load,store,mgtf,fpload,mftg,fpstore,mftg,mgtf")
> > > + [(set_attr "move_type"
> > > "move,const,load,store,mgtf,fpload,mftg,fpstore")
> > > (set_attr "mode" "SI")])
> > >
> Sorry, I have a question. If this place is removed, is movgr2fr in the
> loongarch_output_move function no longer needed?
It's needed for moving SImode into FPR. "z" is FCC_REGS, not FP_REGS.
I cannot see movgr2cf or movfr2cf in loongarch_output_move.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: Ping: [PATCH] LoongArch: Remove constraint z from movsi_internal
在 2024/1/16 下午1:34, Xi Ruoyao 写道:
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
We don't allow SImode in FCC, so constraint z is never really used
here.
gcc/ChangeLog:
* config/loongarch/loongarch.md (movsi_internal): Remove
constraint z.
---
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
gcc/config/loongarch/loongarch.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index a5d0dcd65fe..404a663c1a6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -2108,8 +2108,8 @@ (define_expand "movsi"
})
(define_insn_and_split "*movsi_internal"
- [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,w,*f,f,*r,*m,*r,*z")
- (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f,*z,*r"))]
+ [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,w,*f,f,*r,*m")
+ (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f"))]
"(register_operand (operands[0], SImode)
|| reg_or_0_operand (operands[1], SImode))"
{ return loongarch_output_move (operands[0], operands[1]); }
@@ -2122,7 +2122,7 @@ (define_insn_and_split "*movsi_internal"
DONE;
}
"
- [(set_attr "move_type"
"move,const,load,store,mgtf,fpload,mftg,fpstore,mftg,mgtf")
+ [(set_attr "move_type" "move,const,load,store,mgtf,fpload,mftg,fpstore")
(set_attr "mode" "SI")])
Sorry, I have a question. If this place is removed, is movgr2fr in the
loongarch_output_move function no longer needed?
;; 16-bit Integer moves
[Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415 Andrew Pinski changed: What|Removed |Added Summary|ICE: RTL check: expected|ICE: RTL check: |elt 3 type 'e' or 'u', have |-mstringop-strategy=byte_lo |'0' (rtx code_label) in |op vs inline-asm goto with |PATTERN, at rtl.h:1511 with |block copies |-mstringop-strategy=byte_lo | |op and invalid __asm__ on | |_BitInt() | Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 --- Comment #2 from Andrew Pinski --- This code will not work with anything more fancy than insns, it does not support code_labels. ``` for (rtx_insn *curr = after_rtl_seq; curr != NULL_RTX; curr = NEXT_INSN (curr)) emit_insn (copy_insn (PATTERN (curr))); rtx_insn *copy = get_insns (); end_sequence (); ```
[Bug middle-end/113415] ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511 with -mstringop-strategy=byte_loop and invalid __asm__ on _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
--- Comment #1 from Andrew Pinski ---
This might fail the same way:
```
void
foo(void)
{
unsigned long bitint0[64];
lab:
__asm__ goto("" : "=r"(bitint0) : : : lab);
}
```
Re: [wwwdocs][PATCH] gcc-14/changes: Update APX inline asm behavior for x86_64
I'm going to check-in this if no objection Hongyu Wang 于2024年1月9日周二 15:14写道： > > Hi, > > This patch adds missing description for inline asm behavior and related > compiler switch for APX. > > Ok for gcc-wwwdocs? > > --- > htdocs/gcc-14/changes.html | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index e3a68998..73a90d30 100644 > --- a/htdocs/gcc-14/changes.html > +++ b/htdocs/gcc-14/changes.html > @@ -342,6 +342,12 @@ a work-in-progress. >NDD, PPX and PUSH2POP2. APX support is available via the >-mapxf compiler switch. > > + For inline asm support with APX, by default the EGPR feature was > + disabled to prevent potential illegal instruction with EGPR occurs. > + To invoke egpr usage in inline asm, use new compiler option > + -mapx-inline-asm-use-gpr32 and user should ensure the instruction > + supports EGPR. > + >New ISA extension support for Intel AVX10.1 was added. >AVX10.1 intrinsics are available via the -mavx10.1 or >-mavx10.1-256 compiler switch with 256-bit vector size > -- > 2.31.1 >
[Bug rtl-optimization/113415] New: ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511 with -mstringop-strategy=byte_loop and invalid __asm__ on _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
Bug ID: 113415
Summary: ICE: RTL check: expected elt 3 type 'e' or 'u', have
'0' (rtx code_label) in PATTERN, at rtl.h:1511 with
-mstringop-strategy=byte_loop and invalid __asm__ on
_BitInt()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57097=edit
reduced testcase
This probably needs RTL checking enabled. The asm constraints are invalid; ICEs
before the diagnostics.
Compiler output:
$ x86_64-pc-linux-gnu-gcc -mstringop-strategy=byte_loop testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:6:3: internal compiler error: RTL check: expected elt 3 type 'e' or
'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511
6 | __asm__ goto("" : "=r"(x) : : : lab);
| ^~~
0x800c3a rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:761
0x724644 PATTERN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1511
0x726bf6 PATTERN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1479
0x726bf6 expand_asm_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:3655
0xf88909 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3897
0xf88909 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4064
0xf8a007 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6120
0xf8c66e execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6855
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-7258-20240115151353-g731444b3c39-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240115 (experimental) (GCC)
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #4 from Eric Gallager --- I forget which other bug I mentioned this in, but this reminds me that I still think a -Wformat=3 that includes -Wformat-signedness would be nice, as currently it only goes up to -Wformat=2, which doesn't include -Wformat-signedness currently.
Ping: [PATCH] LoongArch: Remove constraint z from movsi_internal
Ping.
On Fri, 2023-12-15 at 20:56 +0800, Xi Ruoyao wrote:
> We don't allow SImode in FCC, so constraint z is never really used
> here.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.md (movsi_internal): Remove
> constraint z.
> ---
>
> Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
>
> gcc/config/loongarch/loongarch.md | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index a5d0dcd65fe..404a663c1a6 100644
> --- a/gcc/config/loongarch/loongarch.md
> +++ b/gcc/config/loongarch/loongarch.md
> @@ -2108,8 +2108,8 @@ (define_expand "movsi"
> })
>
> (define_insn_and_split "*movsi_internal"
> - [(set (match_operand:SI 0 "nonimmediate_operand"
> "=r,r,r,w,*f,f,*r,*m,*r,*z")
> - (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f,*z,*r"))]
> + [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,w,*f,f,*r,*m")
> + (match_operand:SI 1 "move_operand" "r,Yd,w,rJ,*r*J,m,*f,*f"))]
> "(register_operand (operands[0], SImode)
> || reg_or_0_operand (operands[1], SImode))"
> { return loongarch_output_move (operands[0], operands[1]); }
> @@ -2122,7 +2122,7 @@ (define_insn_and_split "*movsi_internal"
> DONE;
> }
> "
> - [(set_attr "move_type"
> "move,const,load,store,mgtf,fpload,mftg,fpstore,mftg,mgtf")
> + [(set_attr "move_type" "move,const,load,store,mgtf,fpload,mftg,fpstore")
> (set_attr "mode" "SI")])
>
> ;; 16-bit Integer moves
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #4 from LIU Hao --- Is there still such an error for you? It looks to me that this linker command line did not contain `-pthread` unlike the ones above. Maybe the configure script is worth looking at. ``` configure:16911: /R/winlibs32_stage/gcc-11-20210404/build_mingw/./gcc/xgcc -B/R/winlibs32_stage/gcc-11-20210404/build_mingw/./gcc/ -L/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/lib -L/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/mingw/lib -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/include -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/mingw/include -B/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/bin/ -B/R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/lib/ -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/include -isystem /R/winlibs32_stage/inst_gcc-11-20210404/share/gcc/i686-w64-mingw32/sys-include --sysroot=/R/winlibs32_stage/gcc-11-20210404/build_mingw/mingw-w64 -o conftest.exe -O0 -include confdefs.h -include ../../../libgomp/config/posix/omp-lock.h -s conftest.c -ldl >&5 D:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\bin\ld.exe: R:/winlibs32_stage/gcc-11-20210404/build_mingw/gcc/libgcc_eh.a(unwind-dw2.o): in function `_gthread_once': R:\winlibs32_stage\gcc-11-20210404\build_mingw\i686-w64-mingw32\libgcc/./gthr-default.h:700: undefined reference to `pthread_once' ```
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #9 from Xi Ruoyao --- (In reply to nightstrike from comment #8) > (In reply to Andrew Pinski from comment #7) > > So just this one left I think: > > > > /gcc/src/gcc/ira-conflicts.c: Line 125: > > > > Still there, size_t is long long (64bits) while long is 32bits. > > Assuming this is now line 153: > > ``` > diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc > index a4d93c8d734..4f2c2bdfebc 100644 > --- a/gcc/ira-conflicts.cc > +++ b/gcc/ira-conflicts.cc > @@ -150,9 +150,9 @@ build_conflict_bit_table (void) >if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) > fprintf >(ira_dump_file, > - "+++Allocating %ld bytes for conflict table (uncompressed size > %ld)\n", > - (long) allocated_words_num * sizeof (IRA_INT_TYPE), > - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); > + "+++Allocating %zu bytes for conflict table (uncompressed size > %zu)\n", > + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), > + (size_t)(object_set_words * ira_objects_num * sizeof > (IRA_INT_TYPE))); > >objects_live = sparseset_alloc (ira_objects_num); >for (i = 0; i < ira_max_point; i++) > ``` > > Perhaps that will address the remaining issue? Post patches to gcc-patches instead of bugzilla. The patches in bugzilla are not considered candidates to be applied for trunk.
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- And IMO it's not really "wrong" to suggest %lld. Using %lld may not be what you really want, but it's at least allowed by the standard (while using %d here is prohibited and leading to an undefined behavior).
Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
On Tue, 2024-01-16 at 10:57 +0800, chenxiaolong wrote: > 在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道： > > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote: > > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote： > > > > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote: > > > > > Xi Ruoyao wrote at 12:11pm on Monday, > > > > > January > > > > > 15, 2024： > > > > > > On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote: > > > > > > > At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote： > > > > > > > > At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong > > > > > > > > wrote： > > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > > > > > > > > > * gcc.dg/pr104992.c: Added additional "-mlsx" > > > > > > > > > compilation > > > > > > > > > options. > > > > > > > > > * gcc.dg/signbit-2.c: Dito. > > > > > > > > > * gcc.dg/tree-ssa/scev-16.c: Dito. > > > > > > > > > * gfortran.dg/graphite/vect-pr40979.f90: Dito. > > > > > > > > > * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito. > > > > > > > > > > > > > > > > I don't feel it right about the changes to pr104992.c and > > > > > > > > scev-16.c > > > > > > > > because no other architectures add special options > > > > > > > > there. > > > > > > > > Why are we > > > > > > > > so special? > > > > > > > Because on the LoongArch architecture, GCC requires the > > > > > > > addition of > > > > > > > vectorization options in order to generate vector code. Use > > > > > > > the > > > > > > > check_effective_target_vect_cmdline_needed command in the > > > > > > > lib/target- > > > > > > > supports.exp file to set whether the command line option is > > > > > > > needed to > > > > > > > enable vectorizations. For example, ia64,x86,aarch64, and > > > > > > > riscv > > > > > > > architectures, vectorization is enabled by default. > > > > > > > > > > > > But no. The default baseline of 32-bit x86 is i686, which is > > > > > > basically > > > > > > a Pentium III launched in 1999 without any vector > > > > > > instructions. > > > > > > > > > > > > We are still missing something here. > > > > > > > > > > > There is a line > > > > > #define vector > > > > > __attribute__((vector_size(4*sizeof(int > > > > > I guess it is the syntax needs to be supported. > > > > > > > > This is always supported. If the target does not have vector > > > > instructions GCC will just expand vector arithmetic as a loop. > > > > > > > > Maybe we should just move this test into gcc.dg/vect where the > > > > framework > > > > automatically add options like -mlsx or -msse2? > > > > > > > > > > The "-mlsx" option is turned on by default after vectorization > > > testing > > > is turned on. However, the use of dg-options in some files resets > > > the > > > compilation options for testing this file. Therefore, to detect > > > vectorization on LoongArch, it is necessary to add an additional "- > > > mlsx" option. > > > > Then it should use dg-additional-options instead of dg-options. > > > According to your advice, I have tried the following two ways: > > (1)Replace dg-options directly with dg-additional-options. The "-ansi- > pedantic-errors" set in the dg.exp file is used, and the following > problems occur: > > gcc.dg/pr104992.c:ISO C90 does not support complex types. > gcc.dg/tree-ssa/scev-16.c:‘for’ loop initial declarations are only > allowed in C99 or C11 mode > > Note: The ISO required by the program is inconsistent with the default > standard, resulting in an error. We can add -std=c11 into dg-additional-options as well. > (2)Move pr104992.c and scev-16.c to the gcc.dg/vect directory and > replace dg-options with dg-additional-options. The problems are as > follows: > > gcc.dg/vect/scev-16.c: Because there is no test rule starting with > scev* in the vect.exp file, you need to add a new test rule or change > the file name before the test can be performed. > > Summary: It is more appropriate to add the additional "-mlsx" option > directly to the pr104992.c and scev-16.c files. This supports > vectorization testing of the LoongArch architecture and does not > modify the testing behavior of other architectures. No, "not modifying the other architectures" may not be a good thing in some cases. There are only two possibilities here: (1) The test is broken for all architectures where vectorization needs additional options. Then we should fix it for all the architectures. (2) The test is only broken on LoongArch, then on other architectures some mechanism is already adding the proper options for vectorization. Then we should implement the same mechanism for LoongArch. For either case adding -mlsx only for LoongArch is only papering over the real issue. I'll run these tests on some other architectures and see what's happening... -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from nightstrike --- (In reply to Andrew Pinski from comment #7) > So just this one left I think: > > /gcc/src/gcc/ira-conflicts.c: Line 125: > > Still there, size_t is long long (64bits) while long is 32bits. Assuming this is now line 153: ``` diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index a4d93c8d734..4f2c2bdfebc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating %zu bytes for conflict table (uncompressed size %zu)\n", + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++) ``` Perhaps that will address the remaining issue?
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90205 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > >The code should be warned, but it did not. > > > No that is by design. You need to use -Wformat-signedness for that. > > But for the second example, the fix it note is wrong only with > -Wformat-signedness . But that is already PR 90205 .
[Bug c/113414] Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414 --- Comment #1 from Andrew Pinski --- >The code should be warned, but it did not. No that is by design. You need to use -Wformat-signedness for that. But for the second example, the fix it note is wrong only with -Wformat-signedness .
[Bug c/113414] New: Incorrent checking for printf format: does not distinguish whether the variable is signed or unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113414
Bug ID: 113414
Summary: Incorrent checking for printf format: does not
distinguish whether the variable is signed or unsigned
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tongxiangzheng.route at gmail dot com
Target Milestone: ---
When checking the printf() function, gcc does not distinguish whether the
variable is signed or unsigned.
for example:
$ gcc test.cpp
#include
int main(){
int n;
printf("%u",n);
}
The code should be warned, but it did not.
example 2:
$ gcc test.cpp
#include
int main(){
unsigned long long int n;
printf("%d",n);
}
The code be warned, but it's wrong:
test.cpp: In function ‘int main()’:
test.cpp:4:18: warning: format ‘%d’ expects argument of type ‘int’, but
argument 2 has type ‘long long unsigned int’ [-Wformat=]
4 | printf("%d",n);
| ~^ ~
| | |
| | long long unsigned int
| int
| %lld
gcc suggests using %lld, but in reality, %llu should be used.
[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113091 --- Comment #9 from GCC Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:57f611604e8bab67af6c0bcfe6ea88c001408412 commit r14-7272-g57f611604e8bab67af6c0bcfe6ea88c001408412 Author: Feng Xue Date: Thu Dec 28 16:55:39 2023 +0800 Do not count unused scalar use when marking STMT_VINFO_LIVE_P [PR113091] When pattern recognition is involved, a statement whose definition is consumed in some pattern, may not be included in the final replacement pattern statements, and would be skipped when building SLP graph. * Original char a_c = *(char *) a; char b_c = *(char *) b; unsigned short a_s = (unsigned short) a_c; int a_i = (int) a_s; int b_i = (int) b_c; int r_i = a_i - b_i; * After pattern replacement a_s = (unsigned short) a_c; a_i = (int) a_s; patt_b_s = (unsigned short) b_c;// b_i = (int) b_c patt_b_i = (int) patt_b_s; // b_i = (int) b_c patt_r_s = widen_minus(a_c, b_c); // r_i = a_i - b_i patt_r_i = (int) patt_r_s; // r_i = a_i - b_i The definitions of a_i(original statement) and b_i(pattern statement) are related to, but actually not part of widen_minus pattern. Vectorizing the pattern does not cause these definition statements to be marked as PURE_SLP. For this case, we need to recursively check whether their uses are all absorbed into vectorized code. But there is an exception that some use may participate in an vectorized operation via an external SLP node containing that use as an element. gcc/ChangeLog: PR tree-optimization/113091 * tree-vect-slp.cc (vect_slp_has_scalar_use): New function. (vect_bb_slp_mark_live_stmts): New parameter scalar_use_map, check scalar use with new function. (vect_bb_slp_mark_live_stmts): New function as entry to existing overriden functions with same name. (vect_slp_analyze_operations): Call new entry function to mark live statements. gcc/testsuite/ChangeLog: * gcc.target/aarch64/bb-slp-pr113091.c: New test.
[Bug target/113404] ICE: in to_constant, at poly-int.h:588 with -march=rv64gcv -mbig-endian --param=riscv-vector-abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404 --- Comment #1 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:5134d3074ad7a462b4c8e2c0bc904b5ba40b7373 commit r14-7271-g5134d3074ad7a462b4c8e2c0bc904b5ba40b7373 Author: Juzhe-Zhong Date: Tue Jan 16 11:04:49 2024 +0800 RISC-V: Report Sorry when users enable RVV in big-endian mode [PR113404] As PR113404 mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404 We have ICE when we enable RVV in big-endian mode: during RTL pass: expand a-float-point-dynamic-frm-66.i:2:14: internal compiler error: in to_constant, at poly-int.h:588 0xab4c2c poly_int<2u, unsigned short>::to_constant() const /repo/gcc-trunk/gcc/poly-int.h:588 0xab4de1 poly_int<2u, unsigned short>::to_constant() const /repo/gcc-trunk/gcc/tree.h:4055 0xab4de1 default_function_arg_padding(machine_mode, tree_node const*) /repo/gcc-trunk/gcc/targhooks.cc:844 0x12e2327 locate_and_pad_parm(machine_mode, tree_node*, int, int, int, tree_node*, args_size*, locate_and_pad_arg_data*) /repo/gcc-trunk/gcc/function.cc:4061 0x12e2aca assign_parm_find_entry_rtl /repo/gcc-trunk/gcc/function.cc:2614 0x12e2c89 assign_parms /repo/gcc-trunk/gcc/function.cc:3693 0x12e59df expand_function_start(tree_node*) /repo/gcc-trunk/gcc/function.cc:5152 0x112fafb execute /repo/gcc-trunk/gcc/cfgexpand.cc:6739 Report users that we don't support RVV in big-endian mode for the following reasons: 1. big-endian in RISC-V is pretty rare case. 2. We didn't test RVV in big-endian and we don't have enough time to test it since it's stage 4 now. Naive disallow RVV in big-endian. Tested no regression, ok for trunk ? gcc/ChangeLog: PR target/113404 * config/riscv/riscv.cc (riscv_override_options_internal): Report sorry for RVV in big-endian mode. gcc/testsuite/ChangeLog: PR target/113404 * gcc.target/riscv/rvv/base/big_endian-1.c: New test. * gcc.target/riscv/rvv/base/big_endian-2.c: New test.
Re: [PATCH] RISC-V: Report Sorry when users enable RVV in big-endian mode [PR113404]
LGTM, the big endian for RISC-V has been there for a while, but we
don't pay enough attention to that, so I think reporting sorry for now
is a very reasonable way :)
On Tue, Jan 16, 2024 at 11:05 AM Juzhe-Zhong wrote:
>
> As PR113404 mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404
>
> We have ICE when we enable RVV in big-endian mode:
>
> during RTL pass: expand
> a-float-point-dynamic-frm-66.i:2:14: internal compiler error: in to_constant,
> at poly-int.h:588
> 0xab4c2c poly_int<2u, unsigned short>::to_constant() const
> /repo/gcc-trunk/gcc/poly-int.h:588
> 0xab4de1 poly_int<2u, unsigned short>::to_constant() const
> /repo/gcc-trunk/gcc/tree.h:4055
> 0xab4de1 default_function_arg_padding(machine_mode, tree_node const*)
> /repo/gcc-trunk/gcc/targhooks.cc:844
> 0x12e2327 locate_and_pad_parm(machine_mode, tree_node*, int, int, int,
> tree_node*, args_size*, locate_and_pad_arg_data*)
> /repo/gcc-trunk/gcc/function.cc:4061
> 0x12e2aca assign_parm_find_entry_rtl
> /repo/gcc-trunk/gcc/function.cc:2614
> 0x12e2c89 assign_parms
> /repo/gcc-trunk/gcc/function.cc:3693
> 0x12e59df expand_function_start(tree_node*)
> /repo/gcc-trunk/gcc/function.cc:5152
> 0x112fafb execute
> /repo/gcc-trunk/gcc/cfgexpand.cc:6739
>
> Report users that we don't support RVV in big-endian mode for the following
> reasons:
> 1. big-endian in RISC-V is pretty rare case.
> 2. We didn't test RVV in big-endian and we don't have enough time to test it
> since it's stage 4 now.
>
> Naive disallow RVV in big-endian.
>
> Tested no regression, ok for trunk ?
>
> PR target/113404
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_override_options_internal): Report
> sorry for RVV in big-endian mode.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/big_endian-1.c: New test.
> * gcc.target/riscv/rvv/base/big_endian-2.c: New test.
>
> ---
> gcc/config/riscv/riscv.cc | 5 +
> gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c | 5 +
> gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c | 5 +
> 3 files changed, 15 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 89caf156f03..41626fa34e4 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -8787,6 +8787,11 @@ riscv_override_options_internal (struct gcc_options
> *opts)
> sorry ("Current RISC-V GCC cannot support VLEN greater than 4096bit for "
>"'V' Extension");
>
> + /* FIXME: We don't support RVV in big-endian for now, we may enable RVV
> with
> + big-endian after finishing full coverage testing. */
> + if (TARGET_VECTOR && TARGET_BIG_ENDIAN)
> +sorry ("Current RISC-V GCC cannot support RVV in big-endian mode");
> +
>/* Convert -march to a chunks count. */
>riscv_vector_chunks = riscv_convert_vector_bits (opts);
> }
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
> b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
> new file mode 100644
> index 000..9eaf7ad33b2
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
> @@ -0,0 +1,5 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64d -mbig-endian -O3" } */
> +
> +#pragma riscv intrinsic "vector"
> +vfloat32m1_t foo (vfloat32m1_t) {} // { dg-excess-errors "sorry,
> unimplemented: Current RISC-V GCC cannot support RVV in big-endian mode" }
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
> b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
> new file mode 100644
> index 000..86cf58370bf
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
> @@ -0,0 +1,5 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gc_zve32x -mabi=lp64d -mbig-endian -O3" } */
> +
> +#pragma riscv intrinsic "vector"
> +vint32m1_t foo (vint32m1_t) {} // { dg-excess-errors "sorry, unimplemented:
> Current RISC-V GCC cannot support RVV in big-endian mode" }
> --
> 2.36.3
>
[PATCH] RISC-V: Report Sorry when users enable RVV in big-endian mode [PR113404]
As PR113404 mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113404
We have ICE when we enable RVV in big-endian mode:
during RTL pass: expand
a-float-point-dynamic-frm-66.i:2:14: internal compiler error: in to_constant,
at poly-int.h:588
0xab4c2c poly_int<2u, unsigned short>::to_constant() const
/repo/gcc-trunk/gcc/poly-int.h:588
0xab4de1 poly_int<2u, unsigned short>::to_constant() const
/repo/gcc-trunk/gcc/tree.h:4055
0xab4de1 default_function_arg_padding(machine_mode, tree_node const*)
/repo/gcc-trunk/gcc/targhooks.cc:844
0x12e2327 locate_and_pad_parm(machine_mode, tree_node*, int, int, int,
tree_node*, args_size*, locate_and_pad_arg_data*)
/repo/gcc-trunk/gcc/function.cc:4061
0x12e2aca assign_parm_find_entry_rtl
/repo/gcc-trunk/gcc/function.cc:2614
0x12e2c89 assign_parms
/repo/gcc-trunk/gcc/function.cc:3693
0x12e59df expand_function_start(tree_node*)
/repo/gcc-trunk/gcc/function.cc:5152
0x112fafb execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6739
Report users that we don't support RVV in big-endian mode for the following
reasons:
1. big-endian in RISC-V is pretty rare case.
2. We didn't test RVV in big-endian and we don't have enough time to test it
since it's stage 4 now.
Naive disallow RVV in big-endian.
Tested no regression, ok for trunk ?
PR target/113404
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_override_options_internal): Report sorry
for RVV in big-endian mode.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/big_endian-1.c: New test.
* gcc.target/riscv/rvv/base/big_endian-2.c: New test.
---
gcc/config/riscv/riscv.cc | 5 +
gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c | 5 +
gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c | 5 +
3 files changed, 15 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 89caf156f03..41626fa34e4 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -8787,6 +8787,11 @@ riscv_override_options_internal (struct gcc_options
*opts)
sorry ("Current RISC-V GCC cannot support VLEN greater than 4096bit for "
"'V' Extension");
+ /* FIXME: We don't support RVV in big-endian for now, we may enable RVV with
+ big-endian after finishing full coverage testing. */
+ if (TARGET_VECTOR && TARGET_BIG_ENDIAN)
+sorry ("Current RISC-V GCC cannot support RVV in big-endian mode");
+
/* Convert -march to a chunks count. */
riscv_vector_chunks = riscv_convert_vector_bits (opts);
}
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
new file mode 100644
index 000..9eaf7ad33b2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-1.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -mbig-endian -O3" } */
+
+#pragma riscv intrinsic "vector"
+vfloat32m1_t foo (vfloat32m1_t) {} // { dg-excess-errors "sorry,
unimplemented: Current RISC-V GCC cannot support RVV in big-endian mode" }
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
new file mode 100644
index 000..86cf58370bf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/big_endian-2.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zve32x -mabi=lp64d -mbig-endian -O3" } */
+
+#pragma riscv intrinsic "vector"
+vint32m1_t foo (vint32m1_t) {} // { dg-excess-errors "sorry, unimplemented:
Current RISC-V GCC cannot support RVV in big-endian mode" }
--
2.36.3
[Bug testsuite/111850] [14 regression] gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850 Kewen Lin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #4 from Kewen Lin --- Just realized that we also escalated test issue to P1, I'm going to make a patch for the test case update.
Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道： > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote: > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote： > > > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote: > > > > Xi Ruoyao wrote at 12:11pm on Monday, > > > > January > > > > 15, 2024： > > > > > On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote: > > > > > > At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote： > > > > > > > At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong > > > > > > > wrote： > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > > > > > > >* gcc.dg/pr104992.c: Added additional "-mlsx" > > > > > > > > compilation > > > > > > > > options. > > > > > > > >* gcc.dg/signbit-2.c: Dito. > > > > > > > >* gcc.dg/tree-ssa/scev-16.c: Dito. > > > > > > > >* gfortran.dg/graphite/vect-pr40979.f90: Dito. > > > > > > > >* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito. > > > > > > > > > > > > > > I don't feel it right about the changes to pr104992.c and > > > > > > > scev-16.c > > > > > > > because no other architectures add special options > > > > > > > there. > > > > > > > Why are we > > > > > > > so special? > > > > > > Because on the LoongArch architecture, GCC requires the > > > > > > addition of > > > > > > vectorization options in order to generate vector code. Use > > > > > > the > > > > > > check_effective_target_vect_cmdline_needed command in the > > > > > > lib/target- > > > > > > supports.exp file to set whether the command line option is > > > > > > needed to > > > > > > enable vectorizations. For example, ia64,x86,aarch64, and > > > > > > riscv > > > > > > architectures, vectorization is enabled by default. > > > > > > > > > > But no. The default baseline of 32-bit x86 is i686, which is > > > > > basically > > > > > a Pentium III launched in 1999 without any vector > > > > > instructions. > > > > > > > > > > We are still missing something here. > > > > > > > > > There is a line > > > > #define vector > > > > __attribute__((vector_size(4*sizeof(int > > > > I guess it is the syntax needs to be supported. > > > > > > This is always supported. If the target does not have vector > > > instructions GCC will just expand vector arithmetic as a loop. > > > > > > Maybe we should just move this test into gcc.dg/vect where the > > > framework > > > automatically add options like -mlsx or -msse2? > > > > > > > The "-mlsx" option is turned on by default after vectorization > > testing > > is turned on. However, the use of dg-options in some files resets > > the > > compilation options for testing this file. Therefore, to detect > > vectorization on LoongArch, it is necessary to add an additional "- > > mlsx" option. > > Then it should use dg-additional-options instead of dg-options. > According to your advice, I have tried the following two ways: (1)Replace dg-options directly with dg-additional-options. The "-ansi- pedantic-errors" set in the dg.exp file is used, and the following problems occur: gcc.dg/pr104992.c:ISO C90 does not support complex types. gcc.dg/tree-ssa/scev-16.c:‘for’ loop initial declarations are only allowed in C99 or C11 mode Note: The ISO required by the program is inconsistent with the default standard, resulting in an error. (2)Move pr104992.c and scev-16.c to the gcc.dg/vect directory and replace dg-options with dg-additional-options. The problems are as follows: gcc.dg/vect/scev-16.c: Because there is no test rule starting with scev* in the vect.exp file, you need to add a new test rule or change the file name before the test can be performed. Summary: It is more appropriate to add the additional "-mlsx" option directly to the pr104992.c and scev-16.c files. This supports vectorization testing of the LoongArch architecture and does not modify the testing behavior of other architectures.
[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #5 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:39fa71a0882928a25bd170580e3e9e89a69dce36
commit r14-7270-g39fa71a0882928a25bd170580e3e9e89a69dce36
Author: Kewen Lin
Date: Mon Jan 15 20:55:40 2024 -0600
testsuite: Fix vect_long_mult on Power [PR109705]
As pointed out by the discussion in PR109705, the current
vect_long_mult effective target check on Power is broken.
This patch is to fix it accordingly.
With additional change by adding a guard vect_long_mult
in gcc.dg/vect/pr25413a.c, it's tested well on Power{8,9}
LE & BE (also on Power10 LE as before).
PR testsuite/109705
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_long_mult):
Fix powerpc*-*-* checks.
[PATCH] testsuite: Fix vect_long_mult on Power [PR109705]
Hi,
As pointed out by the discussion in PR109705, the current
vect_long_mult effective target check on Power is broken.
This patch is to fix it accordingly.
With additional change by adding a guard vect_long_mult
in gcc.dg/vect/pr25413a.c , it's tested well on Power{8,9}
LE & BE (also on Power10 LE as before).
I'm going to push this soon.
BR,
Kewen
-
PR testsuite/109705
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_long_mult):
Fix powerpc*-*-* checks.
---
gcc/testsuite/lib/target-supports.exp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 81ae92a0266..fac32fb3d0e 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9073,9 +9073,9 @@ proc check_effective_target_vect_int_mult { } {
proc check_effective_target_vect_long_mult { } {
if { [istarget i?86-*-*] || [istarget x86_64-*-*]
-|| (([istarget powerpc*-*-*]
- && ![istarget powerpc-*-linux*paired*])
- && [check_effective_target_ilp32])
+|| ([istarget powerpc*-*-*]
+ && [check_effective_target_powerpc_vsx_ok]
+ && [check_effective_target_has_arch_pwr10])
|| [is-effective-target arm_neon]
|| ([istarget sparc*-*-*] && [check_effective_target_ilp32])
|| [istarget aarch64*-*-*]
--
2.39.1
[PATCH v3] LoongArch: Define LOGICAL_OP_NON_SHORT_CIRCUIT
Define LOGICAL_OP_NON_SHORT_CIRCUIT as 0, for a short-circuit branch, use the
short-circuit operation instead of the non-short-circuit operation.
SPEC2017 performance evaluation shows 1% performance improvement for fprate
GEOMEAN and no obvious regression for others. Especially, 526.blender_r +10.6%
on 3A6000.
gcc/ChangeLog:
* config/loongarch/loongarch.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Define.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/short-circuit.c: New test.
diff --git a/gcc/config/loongarch/loongarch.h b/gcc/config/loongarch/loongarch.h
index 4e6ede926d3..8b453ab3140 100644
--- a/gcc/config/loongarch/loongarch.h
+++ b/gcc/config/loongarch/loongarch.h
@@ -869,6 +869,7 @@ typedef struct {
1 is the default; other values are interpreted relative to that. */
#define BRANCH_COST(speed_p, predictable_p) la_branch_cost
+#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
/* Return the asm template for a conditional branch instruction.
OPCODE is the opcode's mnemonic and OPERANDS is the asm template for
diff --git a/gcc/testsuite/gcc.target/loongarch/short-circuit.c
b/gcc/testsuite/gcc.target/loongarch/short-circuit.c
new file mode 100644
index 000..bed585ee172
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/short-circuit.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ffast-math -fdump-tree-gimple" } */
+
+int
+short_circuit (float *a)
+{
+ float t1x = a[0];
+ float t2x = a[1];
+ float t1y = a[2];
+ float t2y = a[3];
+ float t1z = a[4];
+ float t2z = a[5];
+
+ if (t1x > t2y || t2x < t1y || t1x > t2z || t2x < t1z || t1y > t2z || t2y <
t1z)
+return 0;
+
+ return 1;
+}
+/* { dg-final { scan-tree-dump-times "if" 6 "gimple" } } */
--
2.20.1
[Bug fortran/113413] ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 Priority|P3 |P4
[Bug fortran/113413] New: ATAND(Y,X) is unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113413 Bug ID: 113413 Summary: ATAND(Y,X) is unsupported Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Fortran 2023 added ATAND(X) and ATAND(Y,X). The former is supported. The latter is unsupported. Consider. program main real(4) x, y x = 1. y = x print*, atand(y,x), atan2d(y,x) end % gfcx -o z a.f90 a.f90:5:10: 5 |print*, atand(y,x), atan2d(y,x) | 1 Error: Too many arguments in call to ‘atand’ at (1)
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 Hans-Peter Nilsson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Hans-Peter Nilsson --- (In reply to Francois-Xavier Coudert from comment #5) > Not entirely, xtreme-header_b.C is still failing, as indicated above. See > recently: > https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805380.html > > FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) > FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) Confirmed for cris-elf @r14-7254-g4f141b051ef4, reopening.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112580, which changed state. Bug 112580 Summary: [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[PATCH] LoongArch: Fix pattern vec_concatz
In r14-7022-34d339bbd0c1f5b4ad9587e7ae8387c912cb028b I implement pattern
vec_concatz, the reg+reg addressing mode is not supported in
vec_concatz. This patch fixes that.
gcc/ChangeLog:
* config/loongarch/lasx.md (vec_concatz): Fix pattern to
support reg+reg addressing mode.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vect-concatz.c: New test.
diff --git a/gcc/config/loongarch/lasx.md b/gcc/config/loongarch/lasx.md
index 90f66ee4d24..77ab754fa9e 100644
--- a/gcc/config/loongarch/lasx.md
+++ b/gcc/config/loongarch/lasx.md
@@ -589,10 +589,8 @@ (define_insn "@vec_concatz"
(match_operand: 2 "const_0_operand")))]
"ISA_HAS_LASX"
{
- if (MEM_P (operands[1]))
-return "vld\t%w0,%1";
- else
-return "vori.b\t%w0,%w1,0";
+ return loongarch_output_move (gen_lowpart (mode,
+operands[0]), operands[1]);
}
[(set_attr "type" "simd_splat")
(set_attr "mode" "")])
diff --git a/gcc/testsuite/gcc.target/loongarch/vect-concatz.c
b/gcc/testsuite/gcc.target/loongarch/vect-concatz.c
new file mode 100644
index 000..45aa776c11b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vect-concatz.c
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -mlasx -fno-vect-cost-model" } */
+
+#include
+
+typedef struct
+{
+ int *rect;
+ float *rect_float;
+ unsigned int x;
+ unsigned int y;
+} ImBuf;
+
+ImBuf *
+IMB_double_fast_x(ImBuf *ibuf1, ImBuf *ibuf2)
+{
+ int *p1, *dest, i, col, do_rect, do_float;
+ float *p1f, *destf;
+
+ if (ibuf1 == NULL) return (NULL);
+ if (ibuf1->rect == NULL && ibuf1->rect_float == NULL) return (NULL);
+
+ do_rect = (ibuf1->rect != NULL);
+ do_float = (ibuf1->rect_float != NULL);
+
+
+ p1 = (int *) ibuf1->rect;
+ dest = (int *) ibuf2->rect;
+ p1f = (float *)ibuf1->rect_float;
+ destf = (float *)ibuf2->rect_float;
+
+ for (i = ibuf1->y * ibuf1->x; i > 0; i--) {
+ if (do_rect) {
+ col = *p1++;
+ *dest++ = col;
+ *dest++ = col;
+ }
+ if (do_float) {
+ destf[0] = destf[4] = p1f[0];
+ destf[1] = destf[5] = p1f[1];
+ destf[2] = destf[6] = p1f[2];
+ destf[3] = destf[7] = p1f[3];
+ destf += 8;
+ p1f += 4;
+ }
+ }
+
+ return (ibuf2);
+}
+
+int
+main()
+{
+ return 0;
+}
--
2.20.1
[PATCH] LoongArch: Split vec_selects of bottom elements into simple move
For below pattern, can be treated as a simple move because floating point
and vector share a common register on loongarch64.
(set (reg/v:SF 32 $f0 [orig:93 res ] [93])
(vec_select:SF (reg:V8SF 32 $f0 [115])
(parallel [
(const_int 0 [0])
])))
gcc/ChangeLog:
* config/loongarch/lasx.md (vec_extract_0):
New define_insn_and_split patten.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vect-extract.c: New test.
diff --git a/gcc/config/loongarch/lasx.md b/gcc/config/loongarch/lasx.md
index 72f7161311c..90f66ee4d24 100644
--- a/gcc/config/loongarch/lasx.md
+++ b/gcc/config/loongarch/lasx.md
@@ -761,6 +761,21 @@ (define_expand "vec_extract"
DONE;
})
+(define_insn_and_split "vec_extract_0"
+ [(set (match_operand: 0 "register_operand" "=f")
+(vec_select:
+ (match_operand:FLASX 1 "register_operand" "f")
+ (parallel [(const_int 0)])))]
+ "ISA_HAS_LSX"
+ "#"
+ "&& reload_completed"
+ [(set (match_dup 0) (match_dup 1))]
+{
+ operands[1] = gen_rtx_REG (mode, REGNO (operands[1]));
+}
+ [(set_attr "move_type" "fmove")
+ (set_attr "mode" "")])
+
(define_expand "vec_perm"
[(match_operand:LASX 0 "register_operand")
(match_operand:LASX 1 "register_operand")
diff --git a/gcc/testsuite/gcc.target/loongarch/vect-extract.c
b/gcc/testsuite/gcc.target/loongarch/vect-extract.c
new file mode 100644
index 000..ce126e3a4f1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vect-extract.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ffast-math -mlasx -fno-vect-cost-model
-fno-unroll-loops" } */
+/* { dg-final { scan-assembler-not "xvpickve.w" } } */
+/* { dg-final { scan-assembler-not "xvpickve.d" } } */
+
+float
+sum_float (float *a, int n) {
+ float res = 0.0;
+ for (int i = 0; i < n; i++)
+res += a[i];
+ return res;
+}
+
+double
+sum_double (double *a, int n) {
+ double res = 0.0;
+ for (int i = 0; i < n; i++)
+res += a[i];
+ return res;
+}
--
2.20.1
[Bug testsuite/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #6) > Fixed. I guess. Correct; sorry, I should have close it myself after the commit.
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-16 Priority|P3 |P4
[Bug fortran/113412] New: ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 Bug ID: 113412 Summary: ATAN(Y,X) does not check arguments and generates wrong error message. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Fortran 2008 added the misguided form ATAN(Y,X) where Y could be missing. However, if Y is present, then X is required to have the same type and kind as Y. Consider, % cat a.f90 program main real(4) x real(8) y x = 1. y = x print*, atan(y,x), atan2(y,x) end % gfcx -o z a.f90 a.f90:6:10: 6 |print*, atan(y,x), atan2(y,x) | 1 Error: Too many arguments in call to ‘atan’ at (1) a.f90:6:30: 6 |print*, atan(y,x), atan2(y,x) | 1 Error: ‘x’ argument of ‘atan2’ intrinsic at (1) must be the same type and kind as ‘y’ The error message for atan(y,x) is wrong.
[PATCH, expand] Add const0 move checking for CLEAR_BY_PIECES optabs
Hi,
This patch adds const0 move checking for CLEAR_BY_PIECES. The original
vec_duplicate handles duplicates of non-constant inputs. But 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports const0 move by that mode.
The test cases will be added in subsequent target specific patch.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
regressions.
Thanks
Gui Haochen
ChangeLog
expand: Add const0 move checking for CLEAR_BY_PIECES optabs
vec_duplicate handles duplicates of non-constant inputs. The 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports const0 move. This patch adds
the checking.
gcc/
* expr.cc (by_pieces_mode_supported_p): Add const0 move checking
for CLEAR_BY_PIECES.
patch.diff
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 34f5ff90a9f..cd960349a53 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -1006,14 +1006,21 @@ can_use_qi_vectors (by_pieces_operation op)
static bool
by_pieces_mode_supported_p (fixed_size_mode mode, by_pieces_operation op)
{
- if (optab_handler (mov_optab, mode) == CODE_FOR_nothing)
+ enum insn_code icode = optab_handler (mov_optab, mode);
+ if (icode == CODE_FOR_nothing)
return false;
- if ((op == SET_BY_PIECES || op == CLEAR_BY_PIECES)
+ if (op == SET_BY_PIECES
&& VECTOR_MODE_P (mode)
&& optab_handler (vec_duplicate_optab, mode) == CODE_FOR_nothing)
return false;
+ if (op == CLEAR_BY_PIECES
+ && VECTOR_MODE_P (mode)
+ && optab_handler (vec_duplicate_optab, mode) == CODE_FOR_nothing
+ && !insn_operand_matches (icode, 1, CONST0_RTX (mode)))
+return false;
+
if (op == COMPARE_BY_PIECES
&& !can_compare_p (EQ, mode, ccp_jump))
return false;
[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267 --- Comment #10 from Roger Sayle --- A revised and improved patch has been posted for review at https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643062.html
[PATCH] PR rtl-optimization/111267: Improved forward propagation.
This patch resolves PR rtl-optimization/111267 by improving RTL-level
forward propagation. This x86_64 code quality regression was caused
(exposed) by my changes to improve how x86's (TImode) argument passing
is represented at the RTL-level (reducing the use of SUBREGs to catch
more optimization opportunities in combine). The pitfall is that the
more complex RTL representations expose a limitation in RTL's fwprop
pass.
At the heart of fwprop, in try_fwprop_subst_pattern, the logic can
be summarized as three steps. Step 1 is a heuristic that rejects the
propagation attempt if the expression is too complex, step 2 calls
the backend's recog to see if the propagated/simplified instruction
is recognizable/valid, and step 3 then calls src_cost to compare
the rtx costs of the replacement vs. the original, and accepts the
transformation if the final cost is the same of better.
The logic error (or missed optimization opportunity) is that the
step 1 heuristic that attempts to predict (second guess) the
process is flawed. Ultimately the decision on whether to fwprop
or not should depend solely on actual improvement, as measured
by RTX costs. Hence the prototype fix in the bugzilla PR removes
the heuristic of calling prop.profitable_p entirely, relying
entirely on the cost comparison in step 3.
Unfortunately, things are a tiny bit more complicated. The cost
comparison in fwprop uses the older set_src_cost API and not the
newer (preffered) insn_cost API as currently used in combine.
This means that the cost improvement comparisons are only done
for single_set instructions (more complex PARALLELs etc. aren't
supported). Hence we can only rely on skipping step 1 for that
subset of instructions actually evaluated by step 3.
The other subtlety is that to avoid potential infinite loops
in fwprop we should only reply purely on rtx costs when the
transformation is obviously an improvement. If the replacement
has the same cost as the original, we can use the prop.profitable_p
test to preserve the current behavior.
Finally, to answer Richard Biener's remaining question about this
approach: yes, there is an asymmetry between how patterns are
handled and how REG_EQUAL notes are handled. For example, at
the moment propagation into notes doesn't use rtx costs at all,
and ultimately when fwprop is updated to use insn_cost, this
(and recog) obviously isn't applicable to notes. There's no reason
the logic need be identical between patterns and notes, and during
stage4 we only need update propagation into patterns to fix this
P1 regression (notes and use of cost_insn can be done for GCC 15).
For Jakub's reduced testcase:
struct S { float a, b, c, d; };
int bar (struct S x, struct S y) {
return x.b <= y.d && x.c >= y.a;
}
On x86_64-pc-linux-gnu with -O2 gcc currently generates:
bar:movq%xmm2, %rdx
movq%xmm3, %rax
movq%xmm0, %rsi
xchgq %rdx, %rax
movq%rsi, %rcx
movq%rax, %rsi
movq%rdx, %rax
shrq$32, %rcx
shrq$32, %rax
movd%ecx, %xmm4
movd%eax, %xmm0
comiss %xmm4, %xmm0
jb .L6
movd%esi, %xmm0
xorl%eax, %eax
comiss %xmm0, %xmm1
setnb %al
ret
.L6:xorl%eax, %eax
ret
with this simple patch to fwprop, we now generate:
bar:shufps $85, %xmm0, %xmm0
shufps $85, %xmm3, %xmm3
comiss %xmm0, %xmm3
jb .L6
xorl%eax, %eax
comiss %xmm2, %xmm1
setnb %al
ret
.L6:xorl%eax, %eax
ret
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures. Additionally, it also resolves the FAIL for
gcc.target/i386/pr82580.c. Ok for mainline?
2024-01-16 Roger Sayle
gcc/ChangeLog
PR rtl-optimization/111267
* fwprop.cc (try_fwprop_subst_pattern): Only bail-out early when
!prop.profitable_p for instructions that are not single sets.
When comparing costs, bail-out if the cost is unchanged and
!prop.profitable_p.
gcc/testsuite/ChangeLog
PR rtl-optimization/111267
* gcc.target/i386/pr111267.c: New test case.
Thanks in advance (and to Jeff Law for his guidance/help),
Roger
--
diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index 0c588f8..f06225a 100644
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -449,7 +449,10 @@ try_fwprop_subst_pattern (obstack_watermark ,
insn_change _change,
if (prop.num_replacements == 0)
return false;
- if (!prop.profitable_p ())
+ if (!prop.profitable_p ()
+ && (prop.changed_mem_p ()
+ || use_insn->is_asm ()
+ || !single_set (use_rtl)))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "cannot propagate from insn %d into"
@@ -481,7 +484,8 @@ try_fwprop_subst_pattern (obstack_watermark ,
insn_change
[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #14 from Gaius Mulley --- Ah apologies, is it best that I revert: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032 happy to do this in the morning.
[Bug tree-optimization/113334] wrong code with _BitInt() shift at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113334 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/113411] New: ABS*ABS can be simplified to ABS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113411
Bug ID: 113411
Summary: ABS*ABS can be simplified to ABS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
static inline int abs(int a)
{
signed b = a;
if (a < 0)
b = -b;
return b;
}
int foo1(int a, int b)
{
return abs(a) * abs(b);
}
```
foo1 can be simplified down to `abs(a*b)`. Note I think this is only valid for
signed overflowable types and not valid with -fwrapv (but I could be wrong).
Maybe ok for real types with -ffast-math.
[Bug analyzer/106229] False positives from -Wanalyzer-tainted-array-index with unsigned char index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106229 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed on trunk for GCC 14 by the above patch. Given that taint checking requires explicit opt-in in earlier releases, I don't plan to backport this. Marking this as resolved.
[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 Bug 106358 depends on bug 106229, which changed state. Bug 106229 Summary: False positives from -Wanalyzer-tainted-array-index with unsigned char index https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106229 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
Re: [PATCH v3] libstdc++: Implement C++26 std::text_encoding (P1885R12) [PR113318]
On Mon, 15 Jan 2024, Jonathan Wakely wrote: > I think I'm happy with this now. It has tests for all the new functions, > and the performance of the charset alias match algorithm is improved by > reusing part of . > > Tested x86_64-linux. > > -- >8 -- > > This is another C++26 change, approved in Varna 2022. We require a new 2023? > static array of data that is extracted from the IANA Character Sets > database. A new Python script to generate a header from the IANA CSV > file is added. > > libstdc++-v3/ChangeLog: > > PR libstdc++/113318 > * acinclude.m4 (GLIBCXX_CONFIGURE): Add c++26 directory. > (GLIBCXX_CHECK_TEXT_ENCODING): Define. > * config.h.in: Regenerate. > * configure: Regenerate. > * configure.ac: Use GLIBCXX_CHECK_TEXT_ENCODING. > * include/Makefile.am: Add new headers. > * include/Makefile.in: Regenerate. > * include/bits/locale_classes.h (locale::encoding): Declare new > member function. > * include/bits/unicode.h (__charset_alias_match): New function. > * include/bits/text_encoding-data.h: New file. > * include/bits/version.def (text_encoding): Define. > * include/bits/version.h: Regenerate. > * include/std/text_encoding: New file. > * src/Makefile.am: Add new subdirectory. > * src/Makefile.in: Regenerate. > * src/c++26/Makefile.am: New file. > * src/c++26/Makefile.in: New file. > * src/c++26/text_encoding.cc: New file. > * src/experimental/Makefile.am: Include c++26 convenience > library. > * src/experimental/Makefile.in: Regenerate. > * python/libstdcxx/v6/printers.py (StdTextEncodingPrinter): New > printer. > * scripts/gen_text_encoding_data.py: New file. > * testsuite/22_locale/locale/encoding.cc: New test. > * testsuite/ext/unicode/charset_alias_match.cc: New test. > * testsuite/std/text_encoding/cons.cc: New test. > * testsuite/std/text_encoding/members.cc: New test. > * testsuite/std/text_encoding/requirements.cc: New test. > --- > libstdc++-v3/acinclude.m4 | 30 +- > libstdc++-v3/config.h.in | 3 + > libstdc++-v3/configure| 70 +- > libstdc++-v3/configure.ac | 3 + > libstdc++-v3/include/Makefile.am | 2 + > libstdc++-v3/include/Makefile.in | 2 + > libstdc++-v3/include/bits/locale_classes.h| 14 + > .../include/bits/text_encoding-data.h | 902 ++ > libstdc++-v3/include/bits/unicode.h | 53 +- > libstdc++-v3/include/bits/version.def | 10 + > libstdc++-v3/include/bits/version.h | 13 +- > libstdc++-v3/include/std/text_encoding| 704 ++ > libstdc++-v3/python/libstdcxx/v6/printers.py | 17 + > .../scripts/gen_text_encoding_data.py | 70 ++ > libstdc++-v3/src/Makefile.am | 3 +- > libstdc++-v3/src/Makefile.in | 7 +- > libstdc++-v3/src/c++26/Makefile.am| 109 +++ > libstdc++-v3/src/c++26/Makefile.in| 747 +++ > libstdc++-v3/src/c++26/text_encoding.cc | 91 ++ > libstdc++-v3/src/experimental/Makefile.am | 2 + > libstdc++-v3/src/experimental/Makefile.in | 2 + > .../testsuite/22_locale/locale/encoding.cc| 36 + > .../ext/unicode/charset_alias_match.cc| 18 + > .../testsuite/std/text_encoding/cons.cc | 113 +++ > .../testsuite/std/text_encoding/members.cc| 41 + > .../std/text_encoding/requirements.cc | 31 + > 26 files changed, 3083 insertions(+), 10 deletions(-) > create mode 100644 libstdc++-v3/include/bits/text_encoding-data.h > create mode 100644 libstdc++-v3/include/std/text_encoding > create mode 100755 libstdc++-v3/scripts/gen_text_encoding_data.py > create mode 100644 libstdc++-v3/src/c++26/Makefile.am > create mode 100644 libstdc++-v3/src/c++26/Makefile.in > create mode 100644 libstdc++-v3/src/c++26/text_encoding.cc > create mode 100644 libstdc++-v3/testsuite/22_locale/locale/encoding.cc > create mode 100644 libstdc++-v3/testsuite/ext/unicode/charset_alias_match.cc > create mode 100644 libstdc++-v3/testsuite/std/text_encoding/cons.cc > create mode 100644 libstdc++-v3/testsuite/std/text_encoding/members.cc > create mode 100644 libstdc++-v3/testsuite/std/text_encoding/requirements.cc > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > index e7cbf0fcf96..f9ba7ef744b 100644 > --- a/libstdc++-v3/acinclude.m4 > +++ b/libstdc++-v3/acinclude.m4 > @@ -49,7 +49,7 @@ AC_DEFUN([GLIBCXX_CONFIGURE], [ ># Keep these sync'd with the list in Makefile.am. The first provides an ># expandable list at autoconf time; the second provides an expandable list ># (i.e., shell variable) at configure time. > - m4_define([glibcxx_SUBDIRS],[include libsupc++ src src/c++98 src/c++11 > src/c++17 src/c++20 src/c++23 src/filesystem
[Bug analyzer/113333] analyzer: False positives with calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #3 from David Malcolm --- Should be fixed on trunk for GCC 14 by the above patch. Still affects GCC 13 and earlier; keeping open to track backporting.
[pushed] analyzer: fix false +ves from -Wanalyzer-tainted-array-index with unsigned char index [PR106229]
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-7266-gce27b66d952127.
gcc/analyzer/ChangeLog:
PR analyzer/106229
* analyzer.h (compare_constants): New decl.
* constraint-manager.cc (compare_constants): Make non-static.
* sm-taint.cc: Add include "fold-const.h".
(class concrete_range): New.
(get_possible_range): New.
(index_can_be_out_of_bounds_p): New.
(region_model::check_region_for_taint): Reject
-Wanalyzer-tainted-array-index if the type of the value makes it
impossible for it to be out-of-bounds of the array.
gcc/testsuite/ChangeLog:
PR analyzer/106229
* c-c++-common/analyzer/taint-index-pr106229.c: New test.
Signed-off-by: David Malcolm
---
gcc/analyzer/analyzer.h | 3 +
gcc/analyzer/constraint-manager.cc| 2 +-
gcc/analyzer/sm-taint.cc | 114 +-
.../analyzer/taint-index-pr106229.c | 109 +
4 files changed, 223 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/c-c++-common/analyzer/taint-index-pr106229.c
diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index 8dec9649f2fb..23e3f71df0af 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -427,6 +427,9 @@ bit_offset_to_json (const bit_offset_t );
extern json::value *
byte_offset_to_json (const byte_offset_t );
+extern tristate
+compare_constants (tree lhs_const, enum tree_code op, tree rhs_const);
+
} // namespace ana
extern bool is_special_named_call_p (const gcall *call, const char *funcname,
diff --git a/gcc/analyzer/constraint-manager.cc
b/gcc/analyzer/constraint-manager.cc
index 2db6c1734638..e8bcabeb0cd5 100644
--- a/gcc/analyzer/constraint-manager.cc
+++ b/gcc/analyzer/constraint-manager.cc
@@ -54,7 +54,7 @@ along with GCC; see the file COPYING3. If not see
namespace ana {
-static tristate
+tristate
compare_constants (tree lhs_const, enum tree_code op, tree rhs_const)
{
tree comparison
diff --git a/gcc/analyzer/sm-taint.cc b/gcc/analyzer/sm-taint.cc
index 3f7e5cd55837..dc4b078c411f 100644
--- a/gcc/analyzer/sm-taint.cc
+++ b/gcc/analyzer/sm-taint.cc
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3. If not see
#include "digraph.h"
#include "stringpool.h"
#include "attribs.h"
+#include "fold-const.h"
#include "analyzer/supergraph.h"
#include "analyzer/call-string.h"
#include "analyzer/program-point.h"
@@ -1369,6 +1370,104 @@ make_taint_state_machine (logger *logger)
return new taint_state_machine (logger);
}
+/* A closed concrete range. */
+
+class concrete_range
+{
+public:
+ /* Return true iff THIS is fully within OTHER
+ i.e.
+ - m_min must be >= OTHER.m_min
+ - m_max must be <= OTHER.m_max. */
+ bool within_p (const concrete_range ) const
+ {
+if (compare_constants (m_min, GE_EXPR, other.m_min).is_true ())
+ if (compare_constants (m_max, LE_EXPR, other.m_max).is_true ())
+ return true;
+return false;
+ }
+
+ tree m_min;
+ tree m_max;
+};
+
+/* Attempt to get a closed concrete range for SVAL based on types.
+ If found, write to *OUT and return true.
+ Otherwise return false. */
+
+static bool
+get_possible_range (const svalue *sval, concrete_range *out)
+{
+ if (const svalue *inner = sval->maybe_undo_cast ())
+{
+ concrete_range inner_range;
+ if (!get_possible_range (inner, _range))
+ return false;
+
+ if (sval->get_type ()
+ && inner->get_type ()
+ && INTEGRAL_TYPE_P (sval->get_type ())
+ && INTEGRAL_TYPE_P (inner->get_type ())
+ && TYPE_UNSIGNED (inner->get_type ())
+ && (TYPE_PRECISION (sval->get_type ())
+ > TYPE_PRECISION (inner->get_type (
+ {
+ /* We have a cast from an unsigned type to a wider integral type.
+Assuming this is zero-extension, we can inherit the range from
+the inner type. */
+ enum tree_code op = ((const unaryop_svalue *)sval)->get_op ();
+ out->m_min = fold_unary (op, sval->get_type (), inner_range.m_min);
+ out->m_max = fold_unary (op, sval->get_type (), inner_range.m_max);
+ return true;
+ }
+}
+
+ if (sval->get_type ()
+ && INTEGRAL_TYPE_P (sval->get_type ()))
+{
+ out->m_min = TYPE_MIN_VALUE (sval->get_type ());
+ out->m_max = TYPE_MAX_VALUE (sval->get_type ());
+ return true;
+}
+
+ return false;
+}
+
+/* Determine if it's possible for tainted array access ELEMENT_REG to
+ actually be a problem.
+
+ Check here for index being from e.g. unsigned char when the array
+ contains >= 255 elements.
+
+ Return true if out-of-bounds is possible, false if it's impossible
+ (for suppressing false positives). */
+
+static bool
+index_can_be_out_of_bounds_p (const element_region *element_reg)
+{
[pushed] analyzer: casting all zeroes should give all zeroes [PR113333]
In particular, accessing the result of *calloc (1, SZ) (if non-NULL)
should be known to be all zeroes.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-7265-gd235bf2e807c5f.
gcc/analyzer/ChangeLog:
PR analyzer/11
* region-model-manager.cc
(region_model_manager::maybe_fold_unaryop): Casting all zeroes
should give all zeroes.
gcc/testsuite/ChangeLog:
PR analyzer/11
* c-c++-common/analyzer/calloc-1.c: Add tests.
* c-c++-common/analyzer/pr96639.c: Update expected results.
* gcc.dg/analyzer/data-model-9.c: Likewise.
Signed-off-by: David Malcolm
---
gcc/analyzer/region-model-manager.cc | 6
.../c-c++-common/analyzer/calloc-1.c | 34 +++
gcc/testsuite/c-c++-common/analyzer/pr96639.c | 2 +-
gcc/testsuite/gcc.dg/analyzer/data-model-9.c | 6 ++--
4 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/gcc/analyzer/region-model-manager.cc
b/gcc/analyzer/region-model-manager.cc
index fc3523f8815c..62f808a81c20 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -457,6 +457,12 @@ region_model_manager::maybe_fold_unaryop (tree type, enum
tree_code op,
&& region_sval->get_type ()
&& POINTER_TYPE_P (region_sval->get_type ()))
return get_ptr_svalue (type, region_sval->get_pointee ());
+
+ /* Casting all zeroes should give all zeroes. */
+ if (type
+ && arg->all_zeroes_p ()
+ && (INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)))
+ return get_or_create_int_cst (type, 0);
}
break;
case TRUTH_NOT_EXPR:
diff --git a/gcc/testsuite/c-c++-common/analyzer/calloc-1.c
b/gcc/testsuite/c-c++-common/analyzer/calloc-1.c
index 6bd658ec94a4..cb93fa8987f0 100644
--- a/gcc/testsuite/c-c++-common/analyzer/calloc-1.c
+++ b/gcc/testsuite/c-c++-common/analyzer/calloc-1.c
@@ -22,3 +22,37 @@ char *test_1 (size_t sz)
return p;
}
+
+char **
+test_pr11_1 (void)
+{
+ char **p = (char **)calloc (1, sizeof(char *));
+ if (p)
+{
+ __analyzer_eval (*p == 0); /* { dg-warning "TRUE" } */
+ __analyzer_eval (p[0] == 0); /* { dg-warning "TRUE" } */
+}
+ return p;
+}
+
+char **
+test_pr11_2 (void)
+{
+ char **p = (char **)calloc (2, sizeof(char *));
+ if (p)
+{
+ __analyzer_eval (*p == 0); /* { dg-warning "TRUE" } */
+ __analyzer_eval (p[0] == 0); /* { dg-warning "TRUE" } */
+ __analyzer_eval (p[1] == 0); /* { dg-warning "TRUE" } */
+}
+ return p;
+}
+
+char **
+test_pr11_3 (void)
+{
+ char **vec = (char **)calloc (1, sizeof(char *));
+ if (vec)
+for (char **p=vec ; *p ; p++); /* { dg-bogus "heap-based buffer over-read"
} */
+ return vec;
+}
diff --git a/gcc/testsuite/c-c++-common/analyzer/pr96639.c
b/gcc/testsuite/c-c++-common/analyzer/pr96639.c
index b95217df6c41..2610ce8d602a 100644
--- a/gcc/testsuite/c-c++-common/analyzer/pr96639.c
+++ b/gcc/testsuite/c-c++-common/analyzer/pr96639.c
@@ -6,5 +6,5 @@ x7 (void)
int **md = (int **) calloc (1, sizeof (void *));
return md[0][0]; /* { dg-warning "possibly-NULL" "unchecked deref" } */
- /* { dg-warning "leak of 'md'" "leak" { target *-*-* } .-1 } */
+ /* { dg-warning "Wanalyzer-null-dereference" "deref of NULL" { target *-*-*
} .-1 } */
}
diff --git a/gcc/testsuite/gcc.dg/analyzer/data-model-9.c
b/gcc/testsuite/gcc.dg/analyzer/data-model-9.c
index 159bc612576c..2121f20c4f02 100644
--- a/gcc/testsuite/gcc.dg/analyzer/data-model-9.c
+++ b/gcc/testsuite/gcc.dg/analyzer/data-model-9.c
@@ -14,8 +14,7 @@ void test_1 (void)
struct foo *f = calloc (1, sizeof (struct foo));
if (f == NULL)
return;
- __analyzer_eval (f->i == 0); /* { dg-warning "TRUE" "desired" { xfail *-*-*
} } */
- /* { dg-bogus "UNKNOWN" "status quo" { xfail *-*-* } .-1 } */
+ __analyzer_eval (f->i == 0); /* { dg-warning "TRUE" } */
free (f);
}
@@ -27,7 +26,6 @@ void test_2 (void)
if (f == NULL)
return;
memset (f, 0, sizeof (struct foo));
- __analyzer_eval (f->i == 0); /* { dg-warning "TRUE" "desired" { xfail *-*-*
} } */
- /* { dg-bogus "UNKNOWN" "status quo" { xfail *-*-* } .-1 } */
+ __analyzer_eval (f->i == 0); /* { dg-warning "TRUE" } */
free (f);
}
--
2.26.3
[Bug middle-end/113410] ICE: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 with _BitInt() used as array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113410 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, ice-checking Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-01-16 Component|tree-optimization |middle-end --- Comment #1 from Andrew Pinski --- Confirmed. The assert that is being triggered: ``` char sizstr[80]; ... gcc_checking_assert (strlen (s0) + strlen (s1) < sizeof sizstr - 4); sprintf (sizstr, "[%.37s, %.37s]", s0, s1); ``` Yes the size of the array is too small to print out the values now ...
[Bug analyzer/106229] False positives from -Wanalyzer-tainted-array-index with unsigned char index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106229 --- Comment #1 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ce27b66d952127b7abd0f8cceacb79eb6ecf71db commit r14-7266-gce27b66d952127b7abd0f8cceacb79eb6ecf71db Author: David Malcolm Date: Mon Jan 15 19:01:21 2024 -0500 analyzer: fix false +ves from -Wanalyzer-tainted-array-index with unsigned char index [PR106229] gcc/analyzer/ChangeLog: PR analyzer/106229 * analyzer.h (compare_constants): New decl. * constraint-manager.cc (compare_constants): Make non-static. * sm-taint.cc: Add include "fold-const.h". (class concrete_range): New. (get_possible_range): New. (index_can_be_out_of_bounds_p): New. (region_model::check_region_for_taint): Reject -Wanalyzer-tainted-array-index if the type of the value makes it impossible for it to be out-of-bounds of the array. gcc/testsuite/ChangeLog: PR analyzer/106229 * c-c++-common/analyzer/taint-index-pr106229.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/113333] analyzer: False positives with calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d235bf2e807c5f7e959ca5f3f8d92936801f5b80 commit r14-7265-gd235bf2e807c5f7e959ca5f3f8d92936801f5b80 Author: David Malcolm Date: Mon Jan 15 19:01:16 2024 -0500 analyzer: casting all zeroes should give all zeroes [PR11] In particular, accessing the result of *calloc (1, SZ) (if non-NULL) should be known to be all zeroes. gcc/analyzer/ChangeLog: PR analyzer/11 * region-model-manager.cc (region_model_manager::maybe_fold_unaryop): Casting all zeroes should give all zeroes. gcc/testsuite/ChangeLog: PR analyzer/11 * c-c++-common/analyzer/calloc-1.c: Add tests. * c-c++-common/analyzer/pr96639.c: Update expected results. * gcc.dg/analyzer/data-model-9.c: Likewise. Signed-off-by: David Malcolm
[Bug middle-end/113406] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113406
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-15
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Component|tree-optimization |middle-end
--- Comment #1 from Andrew Pinski ---
Confirmed, scrub is changing the IR to:
```
void * .strub.watermark.2;
_BitInt(146) retval.1;
[local count: 1]:
__builtin___strub_enter (&.strub.watermark.2);
retval.1_3 = foo.strub.0 (&.strub.watermark.2);
__builtin___strub_leave (&.strub.watermark.2);
.strub.watermark.2 ={v} {CLOBBER};
return retval.1_3;
```
Which looks fine but bitintlower is not expecting a gimple ssa of _BitInt(N) in
the GIMPLE_RETURN .
Here is a reduced _GIMPLE testcase without the need for -fstrub=internal :
```
_BitInt(146)
foo1(void);
_BitInt(146)
__GIMPLE()
foo(void)
{
_BitInt(146) t;
t = foo1();
return t;
}
```
[Bug c++/110065] [11/12/13/14 Regression] [C++20/2b] auto return type in template argument causes ICE, also accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:a3054489117085c095e480c71b6aaeea9a463c37 commit r14-7264-ga3054489117085c095e480c71b6aaeea9a463c37 Author: Marek Polacek Date: Mon Jan 15 09:15:59 2024 -0500 c++: ICE with auto in template arg [PR110065] Here we started crashing with r14-1659 because that removed the auto checking in cp_parser_template_type_arg which seemed like dead code. But the attached test shows that the code can still be reached because cp_parser_type_id_1 checks auto only when auto_is_implicit_function_template_parm_p is on. Then I noticed that we're still crashing in C++20, and that ICE started with r12-4772. So I changed the reemerged check to use flag_concepts_ts rather than flag_concepts on the basis that check_auto_in_tmpl_args also checks flag_concepts_ts. PR c++/110065 gcc/cp/ChangeLog: * parser.cc (cp_parser_template_type_arg): Add auto checking. gcc/testsuite/ChangeLog: * g++.dg/concepts/auto8.C: New test. * g++.dg/concepts/auto8a.C: New test.
[Bug c++/113360] [13/14 Regression] Truncated constexpr error messages with -std=c++23/26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113360
--- Comment #1 from Marek Polacek ---
The "deducing from brace-enclosed initializer" error is emitted during parsing
from listify. The body of init_list is not potentially-constant (due to
erroneous FOR_COND), so we register_constexpr_fundef it with result ==
error_mark_node.
require_rvalue_constant_expression in finish_static_assert thinks init_list is
potentially-constant, so we call cxx_constant_value. new_call.fundef->result
is error_mark_node so we don't bother evaluating the body. We call
explain_invalid_constexpr_fn but that has nothing to say, so we end up with a
missing reason.
But we already said what went wrong, so we shouldn't repeat it here anyway.
The body is:
{
int total = 0;
<>;
{
int x = <<< error >>>;
<<< error >>> __for_range;
<<< error >>> __for_begin;
<<< error >>> __for_end;
<<< Unknown tree: for_stmt
<<< error >>>
<<< error >>>
<>>;>>;
<(x)) >;
>>>;
}
return = VIEW_CONVERT_EXPR(total) == 6;
}
Can be reproduced in C++20 with -Wno-invalid-constexpr.
Re: [PATCH v2] c++/modules: Differentiate extern templates and TYPE_DECL_SUPPRESS_DEBUG [PR112820]
On 1/8/24 10:27, Patrick Palka wrote: On Mon, 8 Jan 2024, Nathaniel Shead wrote: On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote: On Sun, 3 Dec 2023, Nathaniel Shead wrote: The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same underlying bit. This is causing confusion when attempting to determine the interface for a streamed-in class type, since the modules code currently assumes that all DECL_EXTERNAL types are extern templates. However, when -g is specified then TYPE_DECL_SUPPRESS_DEBUG (and hence DECL_EXTERNAL) is marked on various other kinds of declarations, such as vtables, which causes them to never be emitted. But a vtable isn't a TYPE_DECL? I suspect what you mean is that maybe_suppress_debug_info is setting TYPE_DECL_SUPPRESS_DEBUG to try to avoid duplication of debug info for classes with vtables, and then the modules code is wrongly assuming that you can check DECL_EXTERNAL for TYPE_DECL, and that it's set only if CLASSTYPE_INTERFACE_ONLY is also set, which is wrong in this case, so we avoid emitting the vtable or anything else for that class. It seems unnecessary to start setting DECL_EXTERNAL on the TYPE_DECL to mean the exact same thing as CLASSTYPE_INTERFACE_ONLY. Rather, the modules code should stop trying to check DECL_EXTERNAL on a TYPE_DECL. Under what circumstances does it make sense for CLASSTYPE_INTERFACE_ONLY to be set in the context of modules, anyway? We probably want to propagate it for things in the global module so that various libstdc++ explicit instantiations work the same with import std. For an class imported from a named module, this ties into the earlier discussion about vtables and inlines that hasn't resolved yet in the ABI committee. But it's certainly significantly interface-like. And I would expect maybe_suppress_debug_info to suppress the debug info for such a class on the assumption that the module unit has the needed debug info. Jason
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Patrick Palka --- Fixed for GCC 12.4 / 13.3 / 14, thanks for the bug report.
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6477b3b9c3e5be5dfe549dcb7b3cef2b49e3690c commit r12-10098-g6477b3b9c3e5be5dfe549dcb7b3cef2b49e3690c Author: Patrick Palka Date: Mon Jan 15 16:49:19 2024 -0500 c++: non-dep array list-init w/ non-triv dtor [PR109899] The get_target_expr call added in r12-7069-g119cea98f66476 causes us for the below testcase to call build_vec_delete in a template context, which builds a templated destructor call and checks expr_noexcept_p for it, which ICEs because the call has templated form. Much of the work of build_vec_delete however is code generation and thus will just get discarded in a template context, and that includes the code guarded by expr_noexcept_p. So this patch narrowly fixes this ICE by eliding the expr_noexcept_p call when in a template context. PR c++/109899 gcc/cp/ChangeLog: * init.cc (build_vec_delete_1): Assume expr_noexcept_p returns false in a template context. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array21.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit d33c3b5ac9b9b3e314ae9118d483ade7e91a80a5)
[Bug middle-end/113395] RTL expansion of bitfield accesses drops MEM_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113395 Andrew Pinski changed: What|Removed |Added Depends on||45274 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > I am almost positive there is a dup of this bug somewhere ... Yes PR 45274 where the aliasing set is 0 ... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45274 [Bug 45274] __restrict__ type qualifier does not work on pointers to bitfields
[Bug middle-end/113395] RTL expansion of bitfield accesses drops MEM_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113395 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-15 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- I am almost positive there is a dup of this bug somewhere ...
Re: [PATCH] c-family: copy attribute diagnostic fixes [PR113262]
On 1/9/24 03:52, Jakub Jelinek wrote:
Hi!
The copy attributes is allowed on decls as well as types and even has
checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics
unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works
if it applies to a decl.
In the C++ front-end location_of checks to see if the type has a
TYPE_MAIN_DECL to get a location from, you might do that if !DECL_P? OK
either way.
The following patch fixes that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2024-01-09 Jakub Jelinek
PR c/113262
* c-attribs.cc (handle_copy_attribute): Don't use
DECL_SOURCE_LOCATION (decl) if decl is not DECL_P, use input_location
instead. Formatting fixes.
* gcc.dg/pr113262.c: New test.
--- gcc/c-family/c-attribs.cc.jj2024-01-03 12:07:02.020736256 +0100
+++ gcc/c-family/c-attribs.cc 2024-01-08 22:10:04.789616664 +0100
@@ -3143,13 +3143,14 @@ handle_copy_attribute (tree *node, tree
if (ref == error_mark_node)
return NULL_TREE;
+ location_t loc = input_location;
+ if (DECL_P (decl))
+loc = DECL_SOURCE_LOCATION (decl);
if (TREE_CODE (ref) == STRING_CST)
{
/* Explicitly handle this case since using a string literal
as an argument is a likely mistake. */
- error_at (DECL_SOURCE_LOCATION (decl),
- "%qE attribute argument cannot be a string",
- name);
+ error_at (loc, "%qE attribute argument cannot be a string", name);
return NULL_TREE;
}
@@ -3160,10 +3161,8 @@ handle_copy_attribute (tree *node, tree
/* Similar to the string case, since some function attributes
accept literal numbers as arguments (e.g., alloc_size or
nonnull) using one here is a likely mistake. */
- error_at (DECL_SOURCE_LOCATION (decl),
- "%qE attribute argument cannot be a constant arithmetic "
- "expression",
- name);
+ error_at (loc, "%qE attribute argument cannot be a constant arithmetic "
+ "expression", name);
return NULL_TREE;
}
@@ -3171,12 +3170,11 @@ handle_copy_attribute (tree *node, tree
{
/* Another possible mistake (but indirect self-references aren't
and diagnosed and shouldn't be). */
- if (warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wattributes,
+ if (warning_at (loc, OPT_Wattributes,
"%qE attribute ignored on a redeclaration "
- "of the referenced symbol",
- name))
- inform (DECL_SOURCE_LOCATION (node[1]),
- "previous declaration here");
+ "of the referenced symbol", name)
+ && DECL_P (node[1]))
+ inform (DECL_SOURCE_LOCATION (node[1]), "previous declaration here");
return NULL_TREE;
}
@@ -3196,7 +3194,8 @@ handle_copy_attribute (tree *node, tree
ref = TREE_OPERAND (ref, 1);
else
break;
-} while (!DECL_P (ref));
+}
+ while (!DECL_P (ref));
/* For object pointer expressions, consider those to be requests
to copy from their type, such as in:
@@ -3228,8 +3227,7 @@ handle_copy_attribute (tree *node, tree
to a variable, or variable attributes to a function. */
if (warning (OPT_Wattributes,
"%qE attribute ignored on a declaration of "
- "a different kind than referenced symbol",
- name)
+ "a different kind than referenced symbol", name)
&& DECL_P (ref))
inform (DECL_SOURCE_LOCATION (ref),
"symbol %qD referenced by %qD declared here", ref, decl);
@@ -3279,9 +3277,7 @@ handle_copy_attribute (tree *node, tree
}
else if (!TYPE_P (decl))
{
- error_at (DECL_SOURCE_LOCATION (decl),
- "%qE attribute must apply to a declaration",
- name);
+ error_at (loc, "%qE attribute must apply to a declaration", name);
return NULL_TREE;
}
--- gcc/testsuite/gcc.dg/pr113262.c.jj 2024-01-08 22:19:07.414588762 +0100
+++ gcc/testsuite/gcc.dg/pr113262.c 2024-01-08 22:18:51.327815573 +0100
@@ -0,0 +1,6 @@
+/* PR c/113262 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+int [[gnu::copy ("")]] a;/* { dg-error "'copy' attribute argument cannot be a
string" } */
+
Jakub
Re: [PATCH] c++/modules: Support thread_local statics in header modules [PR113292]
On 1/11/24 01:12, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk? -- >8 -- Currently, thread_locals in header modules cause ICEs. This patch makes the required changes for them to work successfully. Functions exported by a module need DECL_CONTEXT to be set, so we inherit it from the variable we're wrapping. We additionally require writing the DECL_TLS_MODEL for thread-local variables to the module interface, and the TLS wrapper function needs to have its DECL_BEFRIENDING_CLASSES written too as this is used to retrieve what VAR_DECL it's a wrapper for when emitting a definition at end of TU processing. PR c++/113292 gcc/cp/ChangeLog: * decl2.cc (get_tls_wrapper_fn): Set DECL_CONTEXT. (c_parse_final_cleanups): Suppress warning for no definition of TLS wrapper functions in header modules. * module.cc (trees_out::lang_decl_vals): Write wrapped variable for TLS wrapper functions. (trees_in::lang_decl_vals): Read it. (trees_out::decl_value): Write TLS model for thread-local vars. (trees_in::decl_value): Read it for new decls. Remember to emit definitions of TLS wrapper functions later. gcc/testsuite/ChangeLog: * g++.dg/modules/pr113292_a.H: New test. * g++.dg/modules/pr113292_b.C: New test. * g++.dg/modules/pr113292_c.C: New test. Signed-off-by: Nathaniel Shead --- gcc/cp/decl2.cc | 10 --- gcc/cp/module.cc | 22 +++ gcc/testsuite/g++.dg/modules/pr113292_a.H | 34 +++ gcc/testsuite/g++.dg/modules/pr113292_b.C | 13 + gcc/testsuite/g++.dg/modules/pr113292_c.C | 11 5 files changed, 86 insertions(+), 4 deletions(-) create mode 100644 gcc/testsuite/g++.dg/modules/pr113292_a.H create mode 100644 gcc/testsuite/g++.dg/modules/pr113292_b.C create mode 100644 gcc/testsuite/g++.dg/modules/pr113292_c.C diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc index fb996561f1b..ab348f8ecb7 100644 --- a/gcc/cp/decl2.cc +++ b/gcc/cp/decl2.cc @@ -3860,6 +3860,7 @@ get_tls_wrapper_fn (tree var) TREE_PUBLIC (fn) = TREE_PUBLIC (var); DECL_ARTIFICIAL (fn) = true; DECL_IGNORED_P (fn) = 1; + DECL_CONTEXT (fn) = DECL_CONTEXT (var); /* The wrapper is inline and emitted everywhere var is used. */ DECL_DECLARED_INLINE_P (fn) = true; if (TREE_PUBLIC (var)) @@ -5289,10 +5290,11 @@ c_parse_final_cleanups (void) #pragma interface, etc.) we decided not to emit the definition here. */ && !DECL_INITIAL (decl) - /* A defaulted fn in a header module can be synthesized on -demand later. (In non-header modules we should have -synthesized it above.) */ - && !(DECL_DEFAULTED_FN (decl) && header_module_p ()) + /* A defaulted fn or TLS wrapper in a header module can be +synthesized on demand later. (In non-header modules we +should have synthesized it above.) */ + && !(header_module_p () Hmm, should this be !module_attach_p instead of header_module_p? The patch is OK, that can change separately if appropriate. Jason
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 13.3 and 14, thanks for the bug report.
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:766ea9da8ccff3786ec5df414046f6b1640e7e01 commit r13-8224-g766ea9da8ccff3786ec5df414046f6b1640e7e01 Author: Patrick Palka Date: Mon Jan 15 16:49:19 2024 -0500 c++: non-dep array list-init w/ non-triv dtor [PR109899] The get_target_expr call added in r12-7069-g119cea98f66476 causes us for the below testcase to call build_vec_delete in a template context, which builds a templated destructor call and checks expr_noexcept_p for it, which ICEs because the call has templated form. Much of the work of build_vec_delete however is code generation and thus will just get discarded in a template context, and that includes the code guarded by expr_noexcept_p. So this patch narrowly fixes this ICE by eliding the expr_noexcept_p call when in a template context. PR c++/109899 gcc/cp/ChangeLog: * init.cc (build_vec_delete_1): Assume expr_noexcept_p returns false in a template context. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array21.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit d33c3b5ac9b9b3e314ae9118d483ade7e91a80a5)
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:854c9b682562b103f60e5f0a823f31df17a97568 commit r13-8225-g854c9b682562b103f60e5f0a823f31df17a97568 Author: Patrick Palka Date: Mon Jan 15 16:53:28 2024 -0500 c++: explicit inst w/ similar constrained partial specs [PR104634] Here we neglect to emit the definitions of A::f2 and A::f4 despite the explicit instantiations ultimately because TREE_PUBLIC isn't set on the corresponding partial specializations, whose declarations are created from maybe_new_partial_specialization which is responsible for disambiguating them from the first and third partial specializations (which have the same class-head but different constraints). This makes grokfndecl in turn clear TREE_PUBLIC for f2 and f4 as if they have internal linkage. This patch fixes this by setting TREE_PUBLIC appropriately for such partial specializations. PR c++/104634 gcc/cp/ChangeLog: * pt.cc (maybe_new_partial_specialization): Propagate TREE_PUBLIC to the newly created partial specialization. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-explicit-inst6.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 47673571b28278d857371167f4b67a04a1b87b59)
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3
Re: [PATCH v3] libstdc++: Implement C++26 std::text_encoding (P1885R12) [PR113318]
On Mon, Jan 15, 2024 at 9:45 PM Jonathan Wakely wrote: > I think I'm happy with this now. It has tests for all the new functions, > and the performance of the charset alias match algorithm is improved by > reusing part of . > > Tested x86_64-linux. Looks good to me. Good work, Jon.
Re: [PATCH V1] rs6000: New pass for replacement of adjacent (load) lxv with lxvp
Hello Richard: On 15/01/24 6:25 pm, Ajit Agarwal wrote: > > > On 15/01/24 6:14 pm, Ajit Agarwal wrote: >> Hello Richard: >> >> On 15/01/24 3:03 pm, Richard Biener wrote: >>> On Sun, Jan 14, 2024 at 4:29 PM Ajit Agarwal wrote: Hello All: This patch add the vecload pass to replace adjacent memory accesses lxv with lxvp instructions. This pass is added before ira pass. vecload pass removes one of the defined adjacent lxv (load) and replace with lxvp. Due to removal of one of the defined loads the allocno is has only uses but not defs. Due to this IRA pass doesn't assign register pairs like registers in sequence. Changes are made in IRA register allocator to assign sequential registers to adjacent loads. Some of the registers are cleared and are not set as profitable registers due to zero cost is greater than negative costs and checks are added to compare positive costs. LRA register is changed not to reassign them to different register and form the sequential register pairs intact. contrib/check_GNU_style.sh run on patch looks good. Bootstrapped and regtested for powerpc64-linux-gnu. Spec2017 benchmarks are run and I get impressive benefits for some of the FP benchmarks. >>> i >>> I want to point out the aarch64 target recently got a ld/st fusion >>> pass which sounds >>> related. It would be nice to have at least common infrastructure for >>> this (the aarch64 >>> one also looks quite more powerful) >> >> load/store fusion pass in aarch64 is scheduled to use before peephole2 pass >> and after register allocator pass. In our case, if we do after register >> allocator >> then we should keep register assigned to lower offset load and other load >> that is adjacent to previous load with offset difference of 16 is removed. >> >> Then we are left with one load with lower offset and register assigned >> by register allocator for lower offset load should be lower than other >> adjacent load. If not, we need to change it to lower register and >> propagate them with all the uses of the variable. Similary for other >> adjacent load that we are removing, register needs to be propagated to >> all the uses. >> >> In that case we are doing the work of register allocator. In most of our >> example testcases the lower offset load is assigned greater register >> than other adjacent load by register allocator and hence we are left >> with propagating them always and almost redoing the register allocator >> work. >> >> Is it same/okay to use load/store fusion pass as on aarch64 for our cases >> considering the above scenario. >> >> Please let me know what do you think. I have gone through the implementation of ld/st fusion in aarch64. Here is my understanding: First all its my mistake that I have mentioned in my earlier mail that this pass is done before peephole2 after RA-pass. This pass does it before RA-pass early before early-remat and also before peephole2 after RA-pass. This pass does load fusion 2 ldr instruction with adjacent accesses into ldp instruction. The assembly syntax of ldp instruction is ldp w3, w7, [x0] It loads [X0] into w3 and [X0+4] into W7. Both registers that forms pairs are mentioned in ldp instructions and might not be in sequntial order like first register is W3 and then next register would be W3+1. Thats why the pass before RA-pass works as it has both the defs and may not be required in sequential order like first_reg and then first_reg+1. It can be any valid registers. But in lxvp instructions: lxv vs32, 0(r2) lxv vs45, 16(r2) When we combine above lxv instruction into lxvp, lxvp instruction becomes lxvp vs32, 0(r2) wherein in lxvp r2+0 is loaded into vs32 and r2+16 is loaded into vs33 register (sequential registers). vs33 is hidden in lxvp instruction. This is mandatory requirement for lxvp instruction and cannot be in any other sequence. register assignment difference should be 1. All the uses of r45 has to be propagated with r33. And also register allocator can allocate two lxv instructions in the following registers. lxv vs33, 0(r2) lxv vs32, 16(r2) To generate lxvp for above lxv instructions lxvp vs32, 0(r2). And all the registers vs33 has to be propagated with vs32 and vs32 has to be propagated with vs33 if we do vecload pass after RA-pass. If we do before RA-pass the IRA and LRA register allocation cannot assign register with a difference of 1 and the order difference can be anything with a positive difference. IRA allocated one in vs32 and other can in vs45. In vecload pass we remove one lxv from 2 lxv instruction and 2nd lxv instruction with offset of 16 is removed and the use of register with 2nd lxv's will not have defs and IRA pass cannot allocate them in order with a difference of 1. Thats why we need to make changes in IRA and LRA pass to assign register with a
[Bug c++/113405] Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405 --- Comment #3 from Eddie Nolan --- Fixed (first two commands were superfluous): echo "module1 module1.gcm" >> ./module1.cpp.o.modmap echo "module2 module2.gcm" >> ./module2.cpp.o.modmap echo "module1 module1.gcm" >> ./module2.cpp.o.modmap g++ -I./include -g -std=c++20 -MD -MT ./module1.cpp.o -MF ./module1.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module1.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module1.cpp.o -c ./module1.cpp g++ -g -std=c++20 -MD -MT ./module2.cpp.o -MF ./module2.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module2.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module2.cpp.o -c ./module2.cpp
[COMMITTED] Add myself to the DCO section
It is time to add myself to DCO section for my quicinc email account. ChangeLog: * MAINTAINERS (DCO): Add myself. Signed-off-by: Andrew Pinski --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 882694cc47d..cb5a42501dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -766,6 +766,7 @@ Jeff Law Jeff Law Immad Mir Gaius Mulley +Andrew Pinski Siddhesh Poyarekar Navid Rahimi Rishi Raj -- 2.39.3
Re: [PATCH] c++: ICE with auto in template arg [PR110065]
On 1/15/24 17:14, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK, thanks.
-- >8 --
Here we started crashing with r14-1659 because that removed the
auto checking in cp_parser_template_type_arg which seemed like
dead code. But the attached test shows that the code can still
be reached because cp_parser_type_id_1 checks auto only when
auto_is_implicit_function_template_parm_p is on.
Then I noticed that we're still crashing in C++20, and that ICE
started with r12-4772. So I changed the reemerged check to use
flag_concepts_ts rather than flag_concepts on the basis that
check_auto_in_tmpl_args also checks flag_concepts_ts.
PR c++/110065
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_type_arg): Add auto checking.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/auto8.C: New test.
* g++.dg/concepts/auto8a.C: New test.
---
gcc/cp/parser.cc | 12 ++--
gcc/testsuite/g++.dg/concepts/auto8.C | 17 +
gcc/testsuite/g++.dg/concepts/auto8a.C | 18 ++
3 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/auto8.C
create mode 100644 gcc/testsuite/g++.dg/concepts/auto8a.C
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 8ab98cc0c23..e92309b8960 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -25063,12 +25063,20 @@ cp_parser_type_id (cp_parser *parser, cp_parser_flags
flags,
static tree
cp_parser_template_type_arg (cp_parser *parser)
{
- tree r;
const char *saved_message = parser->type_definition_forbidden_message;
parser->type_definition_forbidden_message
= G_("types may not be defined in template arguments");
- r = cp_parser_type_id_1 (parser, CP_PARSER_FLAGS_NONE, true, false, NULL);
+ tree r = cp_parser_type_id_1 (parser, CP_PARSER_FLAGS_NONE,
+ /*is_template_arg=*/true,
+ /*is_trailing_return=*/false, nullptr);
parser->type_definition_forbidden_message = saved_message;
+ /* cp_parser_type_id_1 checks for auto, but only for
+ ->auto_is_implicit_function_template_parm_p. */
+ if (cxx_dialect >= cxx14 && !flag_concepts_ts && type_uses_auto (r))
+{
+ error ("invalid use of % in template argument");
+ r = error_mark_node;
+}
return r;
}
diff --git a/gcc/testsuite/g++.dg/concepts/auto8.C b/gcc/testsuite/g++.dg/concepts/auto8.C
new file mode 100644
index 000..f9d98b2ec0f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/auto8.C
@@ -0,0 +1,17 @@
+// PR c++/110065
+// { dg-do compile { target c++17 } }
+
+template
+inline constexpr bool t = false;
+
+int
+f ()
+{
+ return t auto&>; // { dg-error "template argument" }
+}
+
+void
+g ()
+{
+ t auto&>; // { dg-error "template argument" }
+}
diff --git a/gcc/testsuite/g++.dg/concepts/auto8a.C
b/gcc/testsuite/g++.dg/concepts/auto8a.C
new file mode 100644
index 000..fc60dc871c2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/auto8a.C
@@ -0,0 +1,18 @@
+// PR c++/110065
+// { dg-do compile { target c++17 } }
+// { dg-additional-options -fconcepts-ts }
+
+template
+inline constexpr bool t = false;
+
+int
+f ()
+{
+ return t auto&>; // { dg-error "template argument" }
+}
+
+void
+g ()
+{
+ t auto&>; // { dg-error "template argument" }
+}
base-commit: 731444b3c39e3dc3dd8778f430a38742861dcca1
[PATCH] c++: ICE with auto in template arg [PR110065]
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we started crashing with r14-1659 because that removed the
auto checking in cp_parser_template_type_arg which seemed like
dead code. But the attached test shows that the code can still
be reached because cp_parser_type_id_1 checks auto only when
auto_is_implicit_function_template_parm_p is on.
Then I noticed that we're still crashing in C++20, and that ICE
started with r12-4772. So I changed the reemerged check to use
flag_concepts_ts rather than flag_concepts on the basis that
check_auto_in_tmpl_args also checks flag_concepts_ts.
PR c++/110065
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_type_arg): Add auto checking.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/auto8.C: New test.
* g++.dg/concepts/auto8a.C: New test.
---
gcc/cp/parser.cc | 12 ++--
gcc/testsuite/g++.dg/concepts/auto8.C | 17 +
gcc/testsuite/g++.dg/concepts/auto8a.C | 18 ++
3 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/auto8.C
create mode 100644 gcc/testsuite/g++.dg/concepts/auto8a.C
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 8ab98cc0c23..e92309b8960 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -25063,12 +25063,20 @@ cp_parser_type_id (cp_parser *parser, cp_parser_flags
flags,
static tree
cp_parser_template_type_arg (cp_parser *parser)
{
- tree r;
const char *saved_message = parser->type_definition_forbidden_message;
parser->type_definition_forbidden_message
= G_("types may not be defined in template arguments");
- r = cp_parser_type_id_1 (parser, CP_PARSER_FLAGS_NONE, true, false, NULL);
+ tree r = cp_parser_type_id_1 (parser, CP_PARSER_FLAGS_NONE,
+ /*is_template_arg=*/true,
+ /*is_trailing_return=*/false, nullptr);
parser->type_definition_forbidden_message = saved_message;
+ /* cp_parser_type_id_1 checks for auto, but only for
+ ->auto_is_implicit_function_template_parm_p. */
+ if (cxx_dialect >= cxx14 && !flag_concepts_ts && type_uses_auto (r))
+{
+ error ("invalid use of % in template argument");
+ r = error_mark_node;
+}
return r;
}
diff --git a/gcc/testsuite/g++.dg/concepts/auto8.C
b/gcc/testsuite/g++.dg/concepts/auto8.C
new file mode 100644
index 000..f9d98b2ec0f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/auto8.C
@@ -0,0 +1,17 @@
+// PR c++/110065
+// { dg-do compile { target c++17 } }
+
+template
+inline constexpr bool t = false;
+
+int
+f ()
+{
+ return t auto&>; // { dg-error "template argument" }
+}
+
+void
+g ()
+{
+ t auto&>; // { dg-error "template argument" }
+}
diff --git a/gcc/testsuite/g++.dg/concepts/auto8a.C
b/gcc/testsuite/g++.dg/concepts/auto8a.C
new file mode 100644
index 000..fc60dc871c2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/auto8a.C
@@ -0,0 +1,18 @@
+// PR c++/110065
+// { dg-do compile { target c++17 } }
+// { dg-additional-options -fconcepts-ts }
+
+template
+inline constexpr bool t = false;
+
+int
+f ()
+{
+ return t auto&>; // { dg-error "template argument" }
+}
+
+void
+g ()
+{
+ t auto&>; // { dg-error "template argument" }
+}
base-commit: 731444b3c39e3dc3dd8778f430a38742861dcca1
--
2.43.0
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 --- Comment #3 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:47673571b28278d857371167f4b67a04a1b87b59 commit r14-7261-g47673571b28278d857371167f4b67a04a1b87b59 Author: Patrick Palka Date: Mon Jan 15 16:53:28 2024 -0500 c++: explicit inst w/ similar constrained partial specs [PR104634] Here we neglect to emit the definitions of A::f2 and A::f4 despite the explicit instantiations ultimately because TREE_PUBLIC isn't set on the corresponding partial specializations, whose declarations are created from maybe_new_partial_specialization which is responsible for disambiguating them from the first and third partial specializations (which have the same class-head but different constraints). This makes grokfndecl in turn clear TREE_PUBLIC for f2 and f4 as if they have internal linkage. This patch fixes this by setting TREE_PUBLIC appropriately for such partial specializations. PR c++/104634 gcc/cp/ChangeLog: * pt.cc (maybe_new_partial_specialization): Propagate TREE_PUBLIC to the newly created partial specialization. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-explicit-inst6.C: New test. Reviewed-by: Jason Merrill
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |13.3 --- Comment #4 from Patrick Palka --- Fixed on trunk so far.
Ping^2: [PATCH] toplevel: don't override gettext-runtime/configure-discovered build args
Evening folks, Hope you had wonderful holidays. Gentle ping on this patch. Have a lovely night! -- Arsen Arsenović signature.asc Description: PGP signature
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/109899] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Patrick Palka changed: What|Removed |Added Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE in |in check_noexcept_r, at |check_noexcept_r, at |cp/except.cc:1065 |cp/except.cc:1065 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #10 from Patrick Palka --- Fixed on trunk so far.
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #9 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d33c3b5ac9b9b3e314ae9118d483ade7e91a80a5 commit r14-7260-gd33c3b5ac9b9b3e314ae9118d483ade7e91a80a5 Author: Patrick Palka Date: Mon Jan 15 16:49:19 2024 -0500 c++: non-dep array list-init w/ non-triv dtor [PR109899] The get_target_expr call added in r12-7069-g119cea98f66476 causes us for the below testcase to call build_vec_delete in a template context, which builds a templated destructor call and checks expr_noexcept_p for it, which ICEs because the call has templated form. Much of the work of build_vec_delete however is code generation and thus will just get discarded in a template context, and that includes the code guarded by expr_noexcept_p. So this patch narrowly fixes this ICE by eliding the expr_noexcept_p call when in a template context. PR c++/109899 gcc/cp/ChangeLog: * init.cc (build_vec_delete_1): Assume expr_noexcept_p returns false in a template context. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array21.C: New test. Reviewed-by: Jason Merrill
[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- This seems somewhat similar to the C++ issue that led to introducing STB_GNU_UNIQUE; a DSO keeping its own copy of something that we want to be shared. In the C++ case we were dealing with vague linkage variables that we have no control over, and decided that the first copy that gets loaded is used by all later DSOs, and so it can never be unloaded. Here, we have more control over the definition, and could say that everyone should get it from libgcc_s, as Jakub proposes. Or we could force it to be defined in the executable, so all DSOs will use the copy there. That latter might be another way to handle the STB_GNU_UNIQUE situation: if an executable links against a shared library that defines something STB_GNU_UNIQUE, copy the definition from the library into the executable? That would avoid the dlclose problem.
[Bug c++/113405] Can't access member type alias of concept-constrained class template specialization in global module fragment via alias template in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113405 --- Comment #2 from Eddie Nolan --- This series of commands reproduces the issue and does not use CMake: g++ -g -std=c++20 -E -x c++ ./module2.cpp \ -MT ./module2.cpp.o.ddi -MD -MF ./module2.cpp.o.ddi.d \ -fmodules-ts -fdeps-file=./module2.cpp.o.ddi -fdeps-target=./module2.cpp.o \ -fdeps-format=p1689r5 -o ./module2.cpp.o.ddi.i g++ -I./include -g -std=c++20 -E -x c++ ./module1.cpp \ -MT ./module1.cpp.o.ddi -MD -MF ./module1.cpp.o.ddi.d \ -fmodules-ts -fdeps-file=./module1.cpp.o.ddi -fdeps-target=./module1.cpp.o \ -fdeps-format=p1689r5 -o ./module1.cpp.o.ddi.i echo "module1 module1.gcm" >> ./module1.cpp.o.modmap echo "module2 module2.gcm" >> ./module2.cpp.o.modmap echo "module1 module1.gcm" >> ./module2.cpp.o.modmap g++ -I./include -g -std=c++20 -MD -MT ./module1.cpp.o -MF ./module1.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module1.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module1.cpp.o -c ./module1.cpp g++ -g -std=c++20 -MD -MT ./module2.cpp.o -MF ./module2.cpp.o.d \ -fmodules-ts -fmodule-mapper=./module2.cpp.o.modmap -MD \ -fdeps-format=p1689r5 -x c++ -o ./module2.cpp.o -c ./module2.cpp
Re: [commit] MIPS: Add ATTRIBUTE_UNUSED to mips_start_function_definition
On 11 January 2024 10:59:21 CET, YunQiang Su wrote:
>Fix build warning:
> mips.cc: warning: unused parameter 'decl'.
>
>gcc
> * config/mips/mips.cc (mips_start_function_definition):
> Add ATTRIBUTE_UNUSED.
>---
> gcc/config/mips/mips.cc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
>index 60b336e43d0..e752019b5e2 100644
>--- a/gcc/config/mips/mips.cc
>+++ b/gcc/config/mips/mips.cc
>@@ -7330,7 +7330,8 @@ mips_start_unique_function (const char *name)
>function contains MIPS16 code. */
>
> static void
>-mips_start_function_definition (const char *name, bool mips16_p, tree decl)
>+mips_start_function_definition (const char *name, bool mips16_p,
>+ tree decl ATTRIBUTE_UNUSED)
Nowadays in C++ you can just remove the identifier name:
+mips_start_function_definition (const char *name, bool mips16_p, tree)
> {
> if (mips16_p)
> fprintf (asm_out_file, "\t.set\tmips16\n");
Re: [PATCH] c++: Fix ENABLE_SCOPE_CHECKING printing
On 1/15/24 04:41, Nathaniel Shead wrote: While working on another bug, I noticed the ENABLE_SCOPE_CHECKING macro and thought to try it out. It caused selftest to ICE. This patch is a minimal fix to get it working again. Probably this should use a test to stop this regressing again in the future the next time new scope-kinds are added, but given it's dependent on a (almost certainly rarely-used) build-time macro I'm not sure exactly how you would do that? Or alternatively I could add a `sk_count` to the end of the scope kind list and `static_assert` that the size of the descriptor list matches? That sounds good. (Also not sure if this would be appropriate for stage 4 or if it should wait till next stage 1. I suppose this fixes a regression but I suspect this has been broken for a very long time.) I think it's OK now since it doesn't affect the normal codepath. -- >8 -- The lists of scope kinds used by ENABLE_SCOPE_CHECKING don't seem to have been updated in a long while, causing ICEs and confusing output. This patch brings the list into line. gcc/cp/ChangeLog: * name-lookup.cc (cp_binding_level_descriptor): Add missing scope kinds. Signed-off-by: Nathaniel Shead --- gcc/cp/name-lookup.cc | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc index d827d337d3b..2e93ed183f1 100644 --- a/gcc/cp/name-lookup.cc +++ b/gcc/cp/name-lookup.cc @@ -4464,11 +4464,16 @@ cp_binding_level_descriptor (cp_binding_level *scope) "try-scope", "catch-scope", "for-scope", +"cond-init-scope", +"stmt-expr-scope", "function-parameter-scope", "class-scope", +"enum-scope", "namespace-scope", "template-parameter-scope", -"template-explicit-spec-scope" +"template-explicit-spec-scope", +"transaction-scope", +"openmp-scope" }; const scope_kind kind = scope->explicit_spec_p ? sk_template_spec : scope->kind;
Re: [PATCH] c++: non-dep array list-init w/ non-triv dtor [PR109899]
On 1/8/24 13:40, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13/12?
OK.
-- >8 --
The get_target_expr call added in r12-7069-g119cea98f66476 causes us
for the below testcase to call build_vec_delete in a template context,
which builds a templated destructor call and checks expr_noexcept_p for
it, which ICEs because the call has templated form. Much of the work
of build_vec_delete however is code generation and thus will just get
throw away in a template context, including this expr_noexcept_p check
and the code generation guarded by it. So this patch narrowly fixes this
ICE by assuming the expr_noexcept_p call returns true in a template
context.
PR c++/109899
gcc/cp/ChangeLog:
* init.cc (build_vec_delete_1): Assume expr_noexcept_p is true
in a template context.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array21.C: New test.
---
gcc/cp/init.cc| 3 ++-
gcc/testsuite/g++.dg/cpp0x/initlist-array21.C | 12
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array21.C
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 09584719ee6..aa0a35a3885 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -4155,7 +4155,8 @@ build_vec_delete_1 (location_t loc, tree base, tree
maxindex, tree type,
/* If one destructor throws, keep trying to clean up the rest, unless we're
already in a build_vec_init cleanup. */
- if (flag_exceptions && !in_cleanup && !expr_noexcept_p (tmp, tf_none))
+ if (flag_exceptions && !in_cleanup && !processing_template_decl
+ && !expr_noexcept_p (tmp, tf_none))
{
loop = build2 (TRY_CATCH_EXPR, void_type_node, loop,
unshare_expr (loop));
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array21.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-array21.C
new file mode 100644
index 000..5e37e3de62a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array21.C
@@ -0,0 +1,12 @@
+// PR c++/109899
+// { dg-do compile { target c++11 } }
+
+struct A { A(); ~A(); };
+
+template
+using array = T[42];
+
+template
+void f() {
+ array{};
+}
Re: [PATCH] c++: address of NTTP object as targ [PR113242]
On 1/5/24 11:50, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? -- >8 -- invalid_tparm_referent_p was rejecting using the address of a class NTTP object as a template argument, but this should be fine. Hmm, I suppose so; https://eel.is/c++draft/temp#param-8 saying "No two template parameter objects are template-argument-equivalent" suggests there can be only one. And clang/msvc allow it. PR c++/113242 gcc/cp/ChangeLog: * pt.cc (invalid_tparm_referent_p) : Suppress DECL_ARTIFICIAL rejection test for class NTTP objects. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-class61.C: New test. --- gcc/cp/pt.cc | 3 ++- gcc/testsuite/g++.dg/cpp2a/nontype-class61.C | 27 2 files changed, 29 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class61.C diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc index 154ac76cb65..8c7d178328d 100644 --- a/gcc/cp/pt.cc +++ b/gcc/cp/pt.cc @@ -7219,7 +7219,8 @@ invalid_tparm_referent_p (tree type, tree expr, tsubst_flags_t complain) * a string literal (5.13.5), * the result of a typeid expression (8.2.8), or * a predefined __func__ variable (11.4.1). */ - else if (VAR_P (decl) && DECL_ARTIFICIAL (decl)) + else if (VAR_P (decl) && !DECL_NTTP_OBJECT_P (decl) +&& DECL_ARTIFICIAL (decl)) If now some artificial variables are OK and others are not, perhaps we should enumerate them either way and abort if it's one we haven't specifically considered. Jason
[Bug tree-optimization/113410] New: ICE: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 with _BitInt() used as array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113410 Bug ID: 113410 Summary: ICE: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 with _BitInt() used as array length Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57096=edit reduced testcase This is reduced from gcc.dg/builtin-dynamic-object-size-20.c, when testsuite is run with -Dint=_BitInt($RANDOM) Compiler output: $ x86_64-pc-linux-gnu-gcc testcase.c during GIMPLE pass: waccess testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 4 | foo (int n) | ^~~ 0x783992 maybe_check_access_sizes /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:3423 0x1186c57 check_call_access /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:3644 0x1186c57 check_call /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:4351 0x1186c57 check_block /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:4434 0x1186c57 execute /repo/gcc-trunk/gcc/gimple-ssa-warn-access.cc:4769 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240115 (experimental) (GCC)
[PATCH v3] libstdc++: Implement C++26 std::text_encoding (P1885R12) [PR113318]
I think I'm happy with this now. It has tests for all the new functions, and the performance of the charset alias match algorithm is improved by reusing part of . Tested x86_64-linux. -- >8 -- This is another C++26 change, approved in Varna 2022. We require a new static array of data that is extracted from the IANA Character Sets database. A new Python script to generate a header from the IANA CSV file is added. libstdc++-v3/ChangeLog: PR libstdc++/113318 * acinclude.m4 (GLIBCXX_CONFIGURE): Add c++26 directory. (GLIBCXX_CHECK_TEXT_ENCODING): Define. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_TEXT_ENCODING. * include/Makefile.am: Add new headers. * include/Makefile.in: Regenerate. * include/bits/locale_classes.h (locale::encoding): Declare new member function. * include/bits/unicode.h (__charset_alias_match): New function. * include/bits/text_encoding-data.h: New file. * include/bits/version.def (text_encoding): Define. * include/bits/version.h: Regenerate. * include/std/text_encoding: New file. * src/Makefile.am: Add new subdirectory. * src/Makefile.in: Regenerate. * src/c++26/Makefile.am: New file. * src/c++26/Makefile.in: New file. * src/c++26/text_encoding.cc: New file. * src/experimental/Makefile.am: Include c++26 convenience library. * src/experimental/Makefile.in: Regenerate. * python/libstdcxx/v6/printers.py (StdTextEncodingPrinter): New printer. * scripts/gen_text_encoding_data.py: New file. * testsuite/22_locale/locale/encoding.cc: New test. * testsuite/ext/unicode/charset_alias_match.cc: New test. * testsuite/std/text_encoding/cons.cc: New test. * testsuite/std/text_encoding/members.cc: New test. * testsuite/std/text_encoding/requirements.cc: New test. --- libstdc++-v3/acinclude.m4 | 30 +- libstdc++-v3/config.h.in | 3 + libstdc++-v3/configure| 70 +- libstdc++-v3/configure.ac | 3 + libstdc++-v3/include/Makefile.am | 2 + libstdc++-v3/include/Makefile.in | 2 + libstdc++-v3/include/bits/locale_classes.h| 14 + .../include/bits/text_encoding-data.h | 902 ++ libstdc++-v3/include/bits/unicode.h | 53 +- libstdc++-v3/include/bits/version.def | 10 + libstdc++-v3/include/bits/version.h | 13 +- libstdc++-v3/include/std/text_encoding| 704 ++ libstdc++-v3/python/libstdcxx/v6/printers.py | 17 + .../scripts/gen_text_encoding_data.py | 70 ++ libstdc++-v3/src/Makefile.am | 3 +- libstdc++-v3/src/Makefile.in | 7 +- libstdc++-v3/src/c++26/Makefile.am| 109 +++ libstdc++-v3/src/c++26/Makefile.in| 747 +++ libstdc++-v3/src/c++26/text_encoding.cc | 91 ++ libstdc++-v3/src/experimental/Makefile.am | 2 + libstdc++-v3/src/experimental/Makefile.in | 2 + .../testsuite/22_locale/locale/encoding.cc| 36 + .../ext/unicode/charset_alias_match.cc| 18 + .../testsuite/std/text_encoding/cons.cc | 113 +++ .../testsuite/std/text_encoding/members.cc| 41 + .../std/text_encoding/requirements.cc | 31 + 26 files changed, 3083 insertions(+), 10 deletions(-) create mode 100644 libstdc++-v3/include/bits/text_encoding-data.h create mode 100644 libstdc++-v3/include/std/text_encoding create mode 100755 libstdc++-v3/scripts/gen_text_encoding_data.py create mode 100644 libstdc++-v3/src/c++26/Makefile.am create mode 100644 libstdc++-v3/src/c++26/Makefile.in create mode 100644 libstdc++-v3/src/c++26/text_encoding.cc create mode 100644 libstdc++-v3/testsuite/22_locale/locale/encoding.cc create mode 100644 libstdc++-v3/testsuite/ext/unicode/charset_alias_match.cc create mode 100644 libstdc++-v3/testsuite/std/text_encoding/cons.cc create mode 100644 libstdc++-v3/testsuite/std/text_encoding/members.cc create mode 100644 libstdc++-v3/testsuite/std/text_encoding/requirements.cc diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index e7cbf0fcf96..f9ba7ef744b 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -49,7 +49,7 @@ AC_DEFUN([GLIBCXX_CONFIGURE], [ # Keep these sync'd with the list in Makefile.am. The first provides an # expandable list at autoconf time; the second provides an expandable list # (i.e., shell variable) at configure time. - m4_define([glibcxx_SUBDIRS],[include libsupc++ src src/c++98 src/c++11 src/c++17 src/c++20 src/c++23 src/filesystem src/libbacktrace src/experimental doc po testsuite python]) + m4_define([glibcxx_SUBDIRS],[include libsupc++ src src/c++98 src/c++11 src/c++17 src/c++20 src/c++23 src/c++26 src/filesystem
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #9 from john.harper at vuw dot ac.nz ---
This variant of my test program (now called test4) hangs with gfortran
but not with other compilers if iam is written to output_unit (like the
original version) or to a file with a different positive unit number, but
it does not hang if written to a file with a negative unit number obtained
by opening it with newunit=u. Its user has those 3 choices at run time.
I hope it helps you explore this oddity of gfortran.
program test4
use iso_fortran_env, only: output_unit
! Linux with f2008 (newunit=, execute_command_line, allocatable scalar)
implicit none
integer:: u = output_unit+20
character:: ch*1, line(2)*80
print "(A)",'Output from iam will go to unit u;', &
' u=output_unit if you enter a, or',&
' unit=u (u>0) if you enter b, or',&
' newunit=u (u<0) if you enter anything else.'
read "(A)", ch
if(ch=='a') then
u = output_unit
else if(ch=='b') then
open( unit=u,file='test4.out')
else
open(newunit=u,file='test4.out')
end if
print "(A,I0)",'Output from iam will be written to unit ',u
write(u,"(A,L2)")'I am john',iam('john')
write(u,"(A,L2)")'I am JOHN',iam('JOHN')
if(u/=output_unit) then
rewind u
read(u,"(A)") line
print "(A)", line
close(u,status='delete')
end if
contains
logical function iam( name)
character(*),intent(in)::name
integer estat
character(:),allocatable:: cmd
cmd = 'if [ `whoami` != "'//name//'" ]; then exit 1; else exit 0; fi'
call execute_command_line(cmd,exitstat=estat)
iam = (estat==0)
end function iam
end program test4
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz
[Bug tree-optimization/113409] New: ICE: in omp_extract_for_data, at omp-general.cc:411 with -fopenmp-simd and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113409 Bug ID: 113409 Summary: ICE: in omp_extract_for_data, at omp-general.cc:411 with -fopenmp-simd and _BitInt() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57095=edit reduced testcase This is reduced from gcc.dg/ipa/pr90555.c, when testsuite is run with -Dint=_BitInt($RANDOM) Compiler output: $ x86_64-pc-linux-gnu-gcc -fopenmp-simd testcase.c during GIMPLE pass: omplower testcase.c: In function 'test_simduid2': testcase.c:9:9: internal compiler error: in omp_extract_for_data, at omp-general.cc:411 9 | #pragma omp simd reduction(+: c2) | ^~~ 0x7cb15b omp_extract_for_data(gomp_for*, omp_for_data*, omp_for_data_loop*) /repo/gcc-trunk/gcc/omp-general.cc:411 0x137d0c9 lower_omp_for /repo/gcc-trunk/gcc/omp-low.cc:11782 0x1368804 lower_omp_1 /repo/gcc-trunk/gcc/omp-low.cc:14388 0x1368804 lower_omp /repo/gcc-trunk/gcc/omp-low.cc:14590 0x13681db lower_omp_1 /repo/gcc-trunk/gcc/omp-low.cc:14372 0x13681db lower_omp /repo/gcc-trunk/gcc/omp-low.cc:14590 0x136c420 execute_lower_omp /repo/gcc-trunk/gcc/omp-low.cc:14629 0x136c420 execute /repo/gcc-trunk/gcc/omp-low.cc:14683 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7255-20240115165927-g6c703b4eb68-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240115 (experimental) (GCC)
