Re: [PATCH 1/3] loop-invariant: Don't move cold bb instructions to preheader in RTL
On 2021/12/29 20:55, Jan Hubicka wrote: >>> >>> From: Xiong Hu Luo >>> >>> gcc/ChangeLog: >>> >>> * loop-invariant.c (find_invariants_bb): Check profile count >>> before motion. >>> (find_invariants_body): Add argument. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * gcc.dg/loop-invariant-2.c: New. > OK, > thanks! > Honza Thanks, committed to r12-6149. -- Thanks, Xionghu
Re: [PATCH] fixed testcase fail in pr102892-2.c fixed tesccase fail in gcc.dg/pr102892-1.c
On Wed, Dec 29, 2021 at 9:39 PM wrote:
>
> From: LiaoShihua
>
> * gcc.dg/pr102892-2.c: Add definition of function foo() which
> declared in pr102892-1.c
This patch is wrong. The testcase is testing to make sure foo was
optimized out. If it is failing for you can you file a bug with the
specific target and log for that testcase?
Thanks,
Andrew Pinski
> ---
> gcc/testsuite/gcc.dg/pr102892-2.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.dg/pr102892-2.c
> b/gcc/testsuite/gcc.dg/pr102892-2.c
> index b39bd6c97b3..b179b26680c 100644
> --- a/gcc/testsuite/gcc.dg/pr102892-2.c
> +++ b/gcc/testsuite/gcc.dg/pr102892-2.c
> @@ -5,3 +5,8 @@ void
> bar (void)
> {
> }
> +
> +void
> +foo (void)
> +{
> +}
> \ No newline at end of file
> --
> 2.31.1.windows.1
>
[PATCH] fixed testcase fail in pr102892-2.c fixed tesccase fail in gcc.dg/pr102892-1.c
From: LiaoShihua
* gcc.dg/pr102892-2.c: Add definition of function foo() which declared
in pr102892-1.c
---
gcc/testsuite/gcc.dg/pr102892-2.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/pr102892-2.c
b/gcc/testsuite/gcc.dg/pr102892-2.c
index b39bd6c97b3..b179b26680c 100644
--- a/gcc/testsuite/gcc.dg/pr102892-2.c
+++ b/gcc/testsuite/gcc.dg/pr102892-2.c
@@ -5,3 +5,8 @@ void
bar (void)
{
}
+
+void
+foo (void)
+{
+}
\ No newline at end of file
--
2.31.1.windows.1
[PATCH] Testsuite: Add btf-dataset option for RISC-V.
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Format) is the metadata format which encodes the debug info
related to BPF program/map, more details on:
https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target support.
---
gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index dbb236bbda1..d54c8b1f63b 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -13,6 +13,7 @@
/* { dg-options "-O0 -gbtf -dA" } */
/* { dg-options "-O0 -gbtf -dA -msdata=none" { target { { powerpc*-*-* } &&
ilp32 } } } */
/* { dg-options "-O0 -gbtf -dA -G0" { target { nios2-*-* } } } */
+/* { dg-options "-O0 -gbtf -dA -msmall-data-limit=2" { target { riscv*-*-* } }
} */
/* Check for two DATASEC entries with vlen 3, and one with vlen 1. */
/* { dg-final { scan-assembler-times "0xf03\[\t \]+\[^\n\]*btt_info" 2 } }
*/
--
2.25.1
[PATCH] fixed testcase fail gcc.dg/analyzer/pr103526.c leak
From: LiaoShihua following 'false' branch in line 20, 'tmp.word_state' leaks in line 26. So free 'tmp.word_state' before return 'rval'. gcc/testsuite\ChangeLog: * gcc.dg/analyzer/pr103526.c: --- gcc/testsuite/gcc.dg/analyzer/pr103526.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/analyzer/pr103526.c b/gcc/testsuite/gcc.dg/analyzer/pr103526.c index 39d60fd853e..7df2e4e7576 100644 --- a/gcc/testsuite/gcc.dg/analyzer/pr103526.c +++ b/gcc/testsuite/gcc.dg/analyzer/pr103526.c @@ -22,7 +22,8 @@ game_new(void) if ((rval = malloc(sizeof(*rval))) == NULL) goto err; memcpy(rval, &tmp, sizeof(*rval)); - + + free(tmp.word_state); return (rval); err: free(tmp.word_state); -- 2.31.1.windows.1
Re: SV: [commited] jit: Support for global rvalue initialization and constructors
Oh, sorry, I meant when you have an array not in a local variable, and
you try to assign to an index of this array.
Something like:
gcc_jit_rvalue *ctor = gcc_jit_context_new_array_constructor
(ctxt,0,int50arr_type,6,values);
gcc_jit_block_add_assignment (block, 0,
gcc_jit_context_new_array_access(NULL, ctor,
gcc_jit_context_zero(int_type)), some_value);
Le jeudi 30 décembre 2021 à 01:16 +, Petter Tomner a écrit :
> Could you be more specific? I tried the equivalent of:
>
> /* int [50] foobar = {1,2,3,4};
> int [50] foo() { int arr[50];
> arr = (int [50]){-1,-2,-3,-4,-5,-6};
> arr = foobar;
> arr = (int [50]){1,2,3,4,5,6};
> arr[6] = 1234;
> return arr;}
>
> N.B: Not a typo, returning an array.
> */
>
> in test-local-init-rvalue.c with a global and local "arr" and it ran
> fine. (See attachment).
>
> Regards, Petter
>
>
> Från: Antoni Boucher
> Skickat: den 29 december 2021 23:45
> Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> gcc-patches@gcc.gnu.org
> Ämne: Re: [commited] jit: Support for global rvalue initialization
> and constructors
>
> I realized that trying to do an assignment to an array created by the
> new array constructor API will result in a "gimplification failed"
> error:
>
> libgccjit.so: error: gimplification failed
> 0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15964
> 0x7fa3a442b1ab gimplify_modify_expr
> ../../../gcc/gcc/gimplify.c:5975
> 0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:14951
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441bca3 gimplify_statement_list
> ../../../gcc/gcc/gimplify.c:2014
> 0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15396
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441f000 gimplify_bind_expr
> ../../../gcc/gcc/gimplify.c:1427
> 0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15152
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a4420671 gimplify_body(tree_node*, bool)
> ../../../gcc/gcc/gimplify.c:16197
> 0x7fa3a4420b3c gimplify_function_tree(tree_node*)
> ../../../gcc/gcc/gimplify.c:16351
> 0x7fa3a419fe5e gcc::jit::playback::function::postprocess()
> ../../../gcc/gcc/jit/jit-playback.c:1909
> 0x7fa3a41a13dc gcc::jit::playback::context::replay()
> ../../../gcc/gcc/jit/jit-playback.c:3250
>
>
> Should an assignment to such a value be supported?
>
> Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit :
> > Oh ye I accidentally dropped that in the merge thank you.
> >
> > I believe there is an implicit "global:" in the top of each version
> > scope, so it shouldn't
> > matter other than looking a bit deviant.
> >
> > Regards,
> > Petter
> >
> > Från: Antoni Boucher
> > Skickat: den 15 december 2021 15:19
> > Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> > gcc-patches@gcc.gnu.org
> > Ämne: Re: [commited] jit: Support for global rvalue initialization
> > and constructors
> >
> > Hi Petter.
> > I believe you have forgotten the line `global:` in the file
> > `gcc/jit/libgccjit.map`.
> > I'm not sure what this line does, but it is there for all other
> > ABI.
> > David: What do you think?
> > Regards.
> >
> > Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a
> > écrit :
> > > Hi!
> > >
> > > I have pushed the patch for rvalue initialization and ctors for
> > > libgccjit, for ABI 19.
> > >
> > > Please see attached patch.
> > >
> > > Regards,
> > > Petter
> > >
> >
> >
>
>
SV: [commited] jit: Support for global rvalue initialization and constructors
Could you be more specific? I tried the equivalent of:
/*int [50] foobar = {1,2,3,4};
int [50] foo() { int arr[50];
arr = (int [50]){-1,-2,-3,-4,-5,-6};
arr = foobar;
arr = (int [50]){1,2,3,4,5,6};
arr[6] = 1234;
return arr;}
N.B: Not a typo, returning an array.
*/
in test-local-init-rvalue.c with a global and local "arr" and it ran fine. (See
attachment).
Regards, Petter
Från: Antoni Boucher
Skickat: den 29 december 2021 23:45
Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org; gcc-patches@gcc.gnu.org
Ämne: Re: [commited] jit: Support for global rvalue initialization and
constructors
I realized that trying to do an assignment to an array created by the
new array constructor API will result in a "gimplification failed"
error:
libgccjit.so: error: gimplification failed
0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:15964
0x7fa3a442b1ab gimplify_modify_expr
../../../gcc/gcc/gimplify.c:5975
0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:14951
0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7026
0x7fa3a441bca3 gimplify_statement_list
../../../gcc/gcc/gimplify.c:2014
0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:15396
0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7026
0x7fa3a441f000 gimplify_bind_expr
../../../gcc/gcc/gimplify.c:1427
0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:15152
0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7026
0x7fa3a4420671 gimplify_body(tree_node*, bool)
../../../gcc/gcc/gimplify.c:16197
0x7fa3a4420b3c gimplify_function_tree(tree_node*)
../../../gcc/gcc/gimplify.c:16351
0x7fa3a419fe5e gcc::jit::playback::function::postprocess()
../../../gcc/gcc/jit/jit-playback.c:1909
0x7fa3a41a13dc gcc::jit::playback::context::replay()
../../../gcc/gcc/jit/jit-playback.c:3250
Should an assignment to such a value be supported?
Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit :
> Oh ye I accidentally dropped that in the merge thank you.
>
> I believe there is an implicit "global:" in the top of each version
> scope, so it shouldn't
> matter other than looking a bit deviant.
>
> Regards,
> Petter
>
> Från: Antoni Boucher
> Skickat: den 15 december 2021 15:19
> Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> gcc-patches@gcc.gnu.org
> Ämne: Re: [commited] jit: Support for global rvalue initialization
> and constructors
>
> Hi Petter.
> I believe you have forgotten the line `global:` in the file
> `gcc/jit/libgccjit.map`.
> I'm not sure what this line does, but it is there for all other ABI.
> David: What do you think?
> Regards.
>
> Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a
> écrit :
> > Hi!
> >
> > I have pushed the patch for rvalue initialization and ctors for
> > libgccjit, for ABI 19.
> >
> > Please see attached patch.
> >
> > Regards,
> > Petter
> >
>
>
diff --git a/gcc/testsuite/jit.dg/test-local-init-rvalue.c b/gcc/testsuite/jit.dg/test-local-init-rvalue.c
index 1d74679c07c..308f5c39538 100644
--- a/gcc/testsuite/jit.dg/test-local-init-rvalue.c
+++ b/gcc/testsuite/jit.dg/test-local-init-rvalue.c
@@ -456,12 +456,42 @@ create_code (gcc_jit_context *ctxt, void *user_data)
0,
gcc_jit_lvalue_as_rvalue(local));
}
- { /* int[50] foo() { int arr[50];
+ { /* int [50] foobar = {1,2,3,4};
+ int[50] foo() { int arr[50];
+ arr = (int [50]){-1,-2,-3,-4,-5,-6};
+ arr = foobar;
arr = (int [50]){1,2,3,4,5,6};
+ arr[6] = 1234;
return arr;}
N.B: Not a typo, returning an array.
*/
+
+gcc_jit_rvalue *rval_1 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 1);
+gcc_jit_rvalue *rval_2 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 2);
+gcc_jit_rvalue *rval_3 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 3);
+gcc_jit_rvalue *rval_4 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 4);
+
+gcc_jit_rvalue *values4[] = {rval_1, rval_2, rval_3, rval_4};
+
+gcc_jit_rvalue *ctor3 =
+ gcc_jit_context_new_array_constructor (ctxt,
+ 0,
+ int50arr_type,
+ 4,
+ values4);
+gcc_jit_lvalue *global_intarr_1234 =
+ gcc_jit_context_new_global (ctxt, NULL,
+ GCC_JIT_GLOBAL_EXPORTED,
+ int50arr_type,
+ "foobar");
+
+gcc_jit_global_set_initializer_rvalue (global_intarr_1234, ctor3);
+
gc
Go patch committed: Don't pad epollevent on sparc64 GNU/Linux
This patch to the Go frontend, libgo, and the -fgo-dump-spec code
avoids padding incorrectly when a zero-sized field is inserted solely
for alignment. We avoid this by not padding after a "_" field, and by
using "_" fields for padding. This is fine since the padding is only
there in case someone takes the address of the last field, and it's
not possible to take the adress of a field named "_". This was
breaking the use of epoll on sparc64 GNU/Linux, as reported in GCC PR
103847. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu,
bootstrapped and ran relevant tests on sparc64-unknown-linux-gnu.
Committed to mainline.
Ian
PR go/103847
* godump.c (go_force_record_alignment): Name the alignment
field "_".
fff15be41ed94c07c94ca5203b23b60e1b628e5c
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 05e47ec3fa9..2d04f4b01c0 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-3e9f4ee16683883ccfb8661d99318c74bb7a4bef
+d3be41f0a1fca20e241e1db62b4b0f5262caac55
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/types.cc b/gcc/go/gofrontend/types.cc
index 0f1937c..57c02a97ef0 100644
--- a/gcc/go/gofrontend/types.cc
+++ b/gcc/go/gofrontend/types.cc
@@ -6454,9 +6454,18 @@ get_backend_struct_fields(Gogo* gogo, Struct_type* type,
bool use_placeholder,
? p->type()->get_backend_placeholder(gogo)
: p->type()->get_backend(gogo));
(*bfields)[i].location = p->location();
- lastsize = gogo->backend()->type_size((*bfields)[i].btype);
- if (lastsize != 0)
-saw_nonzero = true;
+ int64_t size = gogo->backend()->type_size((*bfields)[i].btype);
+ if (size != 0)
+ saw_nonzero = true;
+
+ if (size > 0 || !Gogo::is_sink_name(p->field_name()))
+ lastsize = size;
+ else
+ {
+ // There is an unreferenceable field of zero size. This
+ // doesn't affect whether we may need zero padding, so leave
+ // lastsize unchanged.
+ }
}
go_assert(i == fields->size());
if (saw_nonzero && lastsize == 0 && !type->is_results_struct())
diff --git a/gcc/godump.c b/gcc/godump.c
index a50aef1f5fa..f016989c93f 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -651,7 +651,7 @@ go_force_record_alignment (struct obstack *ob, const char
*type_string,
unsigned int index, const char *error_string)
{
index = go_append_artificial_name (ob, index);
- obstack_grow (ob, "_align ", 7);
+ obstack_grow (ob, "_ ", 2);
if (type_string == NULL)
obstack_grow (ob, error_string, strlen (error_string));
else
diff --git a/libgo/mkrsysinfo.sh b/libgo/mkrsysinfo.sh
index 18643370645..be150905f91 100755
--- a/libgo/mkrsysinfo.sh
+++ b/libgo/mkrsysinfo.sh
@@ -98,7 +98,7 @@ if grep '^const _epoll_data_offset ' ${OUT} >/dev/null 2>&1;
then
echo 'type epollevent struct { events uint32; data [8]byte }' >> ${OUT}
elif test "$val" = "8"; then
if test "$GOARCH" = "sparc64" -a "$GOOS" = "linux"; then
- echo 'type epollevent struct { events uint32; pad [4]byte; data
[8]byte; _align [0]int64 }' >> ${OUT}
+ echo 'type epollevent struct { events uint32; pad [4]byte; data
[8]byte; _ [0]int64 }' >> ${OUT}
else
echo 'type epollevent struct { events uint32; pad [4]byte; data
[8]byte }' >> ${OUT}
fi
Re: [commited] jit: Support for global rvalue initialization and constructors
I realized that trying to do an assignment to an array created by the new array constructor API will result in a "gimplification failed" error: libgccjit.so: error: gimplification failed 0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:15964 0x7fa3a442b1ab gimplify_modify_expr ../../../gcc/gcc/gimplify.c:5975 0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:14951 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**) ../../../gcc/gcc/gimplify.c:7026 0x7fa3a441bca3 gimplify_statement_list ../../../gcc/gcc/gimplify.c:2014 0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:15396 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**) ../../../gcc/gcc/gimplify.c:7026 0x7fa3a441f000 gimplify_bind_expr ../../../gcc/gcc/gimplify.c:1427 0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:15152 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**) ../../../gcc/gcc/gimplify.c:7026 0x7fa3a4420671 gimplify_body(tree_node*, bool) ../../../gcc/gcc/gimplify.c:16197 0x7fa3a4420b3c gimplify_function_tree(tree_node*) ../../../gcc/gcc/gimplify.c:16351 0x7fa3a419fe5e gcc::jit::playback::function::postprocess() ../../../gcc/gcc/jit/jit-playback.c:1909 0x7fa3a41a13dc gcc::jit::playback::context::replay() ../../../gcc/gcc/jit/jit-playback.c:3250 Should an assignment to such a value be supported? Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit : > Oh ye I accidentally dropped that in the merge thank you. > > I believe there is an implicit "global:" in the top of each version > scope, so it shouldn't > matter other than looking a bit deviant. > > Regards, > Petter > > Från: Antoni Boucher > Skickat: den 15 december 2021 15:19 > Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org; > gcc-patches@gcc.gnu.org > Ämne: Re: [commited] jit: Support for global rvalue initialization > and constructors > > Hi Petter. > I believe you have forgotten the line `global:` in the file > `gcc/jit/libgccjit.map`. > I'm not sure what this line does, but it is there for all other ABI. > David: What do you think? > Regards. > > Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a > écrit : > > Hi! > > > > I have pushed the patch for rvalue initialization and ctors for > > libgccjit, for ABI 19. > > > > Please see attached patch. > > > > Regards, > > Petter > > > >
[pushed] Fortran: keep
Hi, Fortran 2018 added some synonyms to the existing IEEE_CLASS_TYPE values, namely IEEE_NEGATIVE_SUBNORMAL (which is the same as IEEE_NEGATIVE_DENORMAL) and IEEE_POSITIVE_SUBNORMAL (same as IEEE_POSITIVE_DENORMAL). When they were added to the C side, they were not kept in sync with the Fortran part of the library. Thew new values are not used (yet), so it is currently harmless, but better fix it. I’ve pushed on master as obvious after testing on x86_64-pc-gnu-linux. FX 0001-Fortran-keep-values-of-IEEE_CLASS_TYPE-in-sync.patch Description: Binary data
Re: [PATCH] tree-ssa-dce: Fix up -fcompare-debug failures in make_forwarders_with_degenerate_phis [PR103742]
On December 29, 2021 11:11:18 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>make_forwarders_with_degenerate_phis causes a -fcompare-debug failure on the
>following testcase.
>The problem is that on:
> # iftmp.4_8 = PHI <&D.2582(6), &D.2583(4), &D.2582(7), &D.2583(5)>
>the exact DECL_UIDs are different between -g and -g0 (which is ok, with -g
>the decls can have larger gaps in between the uids), which means
>iterative_hash_expr is different and because there are 2 pairs of edges
>with matching phi arguments, the function processes them in different
>orders.
>The following patch fixes it by using the iterative_hash_expr order
>only to determine which arguments are the same, then replaces the hashes
>with the minimum dest_idx in the set of matching arguments and qsorts
>again (which makes it stable for -fcompare-debug) and only splits edges etc.
>on that stable order.
>As a small optimization, if no arguments are equal, it doesn't do the
>second qsort and continues, and if all arguments of the PHI are
>constants or SSA_NAMEs (I think that is a pretty common case for many
>PHIs), then it doesn't do the second qsort either, because in that case
>the hash values will be stable, only computed from the constant values or
>SSA_NAME_VERSIONs.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
>2021-12-28 Jakub Jelinek
>
> PR debug/103742
> * tree-ssa-dce.c (make_forwarders_with_degenerate_phis): If any phi
> argument is not CONSTANT_CLASS_P or SSA_NAME and any arguments are
> equal, change second from hash value to lowest dest_idx from the
> edges which have equal argument and resort to ensure -fcompare-debug
> stability.
>
> * g++.dg/opt/pr103742.C: New test.
>
>--- gcc/tree-ssa-dce.c.jj 2021-11-29 14:24:14.120633762 +0100
>+++ gcc/tree-ssa-dce.c 2021-12-28 17:30:19.983056815 +0100
>@@ -1671,6 +1671,7 @@ make_forwarders_with_degenerate_phis (fu
> continue;
> gphi *phi = gsi.phi ();
> auto_vec, 8> args;
>+ bool need_resort = false;
> for (unsigned i = 0; i < gimple_phi_num_args (phi); ++i)
> {
> edge e = gimple_phi_arg_edge (phi, i);
>@@ -1682,12 +1683,42 @@ make_forwarders_with_degenerate_phis (fu
> if (loops_state_satisfies_p (LOOP_CLOSED_SSA)
> && loop_exit_edge_p (e->src->loop_father, e))
> continue;
>-args.safe_push (std::make_pair (e, iterative_hash_expr
>- (gimple_phi_arg_def (phi, i), 0)));
>+
>+tree arg = gimple_phi_arg_def (phi, i);
>+if (!CONSTANT_CLASS_P (arg) && TREE_CODE (arg) != SSA_NAME)
>+ need_resort = true;
>+args.safe_push (std::make_pair (e, iterative_hash_expr (arg, 0)));
> }
> if (args.length () < 2)
> continue;
> args.qsort (sort_phi_args);
>+ /* The above sorting can be different between -g and -g0, as e.g. decls
>+ can have different uids (-g could have bigger gaps in between them).
>+ So, only use that to determine which args are equal, then change
>+ second from hash value to smallest dest_idx of the edges which have
>+ equal argument and sort again. If all the phi arguments are
>+ constants or SSA_NAME, there is no need for the second sort, the hash
>+ values are stable in that case. */
>+ hashval_t hash = args[0].second;
>+ args[0].second = args[0].first->dest_idx;
>+ bool any_equal = false;
>+ for (unsigned i = 1; i < args.length (); ++i)
>+ if (hash == args[i].second
>+ && operand_equal_p (PHI_ARG_DEF_FROM_EDGE (phi, args[i - 1].first),
>+ PHI_ARG_DEF_FROM_EDGE (phi, args[i].first)))
>+{
>+ args[i].second = args[i - 1].second;
>+ any_equal = true;
>+}
>+ else
>+{
>+ hash = args[i].second;
>+ args[i].second = args[i].first->dest_idx;
>+}
>+ if (!any_equal)
>+ continue;
>+ if (need_resort)
>+ args.qsort (sort_phi_args);
>
> /* From the candidates vector now verify true candidates for
>forwarders and create them. */
>@@ -1697,8 +1728,7 @@ make_forwarders_with_degenerate_phis (fu
> {
> unsigned i;
> for (i = start + 1; i < args.length (); ++i)
>- if (!operand_equal_p (PHI_ARG_DEF_FROM_EDGE (phi,
>args[start].first),
>-PHI_ARG_DEF_FROM_EDGE (phi, args[i].first)))
>+ if (args[start].second != args[i].second)
> break;
> /* args[start]..args[i-1] are equal. */
> if (start != i - 1)
>--- gcc/testsuite/g++.dg/opt/pr103742.C.jj 2021-12-28 17:30:35.788837099
>+0100
>+++ gcc/testsuite/g++.dg/opt/pr103742.C2021-12-28 17:31:22.719184723
>+0100
>@@ -0,0 +1,36 @@
>+// PR debug/103742
>+// { dg-do compile { target c++17 } }
>+// { dg-options "-O2 -fnon-call-exceptions --param=early-inlining-insns=82
>-fc
Re: [PATCH] Prune LTO warnings that some tests fail
On 12/29/2021 2:13 AM, FX wrote: Hi, Did you mean to include the change pruning visibility warnings? I don't think it's necessarily wrong, it just doesn't match the patch description or ChangeLog. Yes, I think they should be applied, and will fix long-standing failures reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 ChangeLog and patch description amended. OK to commit? Yes, OK for the trunk. Thanks, Jeff
Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366
Hi Paul, Am 29.12.21 um 12:45 schrieb Paul Richard Thomas via Fortran: Hi Harald, That is the sort of thing that I had in mind. Is it worth adding the check for CLASS_DATA? I cannot remember if that is made redundant by the test of the class_ok attribute. the macro CLASS_DATA appears to have been introduced by Janus as a shortcut to the data component. Accesses to the data component still may require a protecting prior check when we are confronted with random bad user code, as I sometimes see sym->attr.class_ok == 1 but still sym->ts.u.derived == NULL. Shall we open a PR for tracking issues with (the lack of) canonical checking when CLASS is involved? Where we could collect ideas about macros that make the code more readable and robust? (I believe some PRs involving "associate" need similar treatment in several places.) Of course that would be something for post 12-release. Cheers, Harald Cheers Paul On Tue, 28 Dec 2021 at 21:08, Harald Anlauf wrote: Hi Paul, Am 28.12.21 um 12:56 schrieb Paul Richard Thomas via Fortran: Hi Harald, This looks good to me. OK for mainline and, dare I suggest, 11-branch? From a quick run through resolve.c, there are many places where the extra checks that you introduced in the patch have been implemented. This makes me wonder whether a function or macro might not make the relevant code more concise. I had thought about this in the past, too. Suitably chosen macros could help to make checking not only more concise, but also more robust and (hopefully) readable at the same time. What do you think about e.g. diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index e5d2dd7971e..f3d22b46a75 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -3885,6 +3885,8 @@ bool gfc_is_finalizable (gfc_symbol *, gfc_expr **); && CLASS_DATA (sym) \ && CLASS_DATA (sym)->attr.dimension \ && !CLASS_DATA (sym)->attr.class_pointer) +#define IS_CLASS_OBJ(sym) \ + (sym->ts.type == BT_CLASS && sym->attr.class_ok) /* frontend-passes.c */ to be used to ensure that we are dealing with a CLASS object where attributes should already have been set up? Or use a better name? (IS_CLASS_OBJECT?) Thanks, Harald Thanks for the patch Paul On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran < fort...@gcc.gnu.org> wrote: Dear all, there are a couple of NULL pointer dereferences leading to improper error recovery when trying to handle Gerhard's testcases involving SELECT TYPE and invalid uses of CLASS variables. The fixes look pretty obvious to me, but I'm submitting here to check if there is more that should be done here. (I was surprised to see that there are several different places involved by rather simple variations in the basic test case.) Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
Re: [AArch64] Enable generation of FRINTNZ instructions
"Andre Vieira (lists)" writes:
> On 17/12/2021 12:44, Richard Sandiford wrote:
>>
>>> @@ -3252,16 +3257,31 @@ vectorizable_call (vec_info *vinfo,
>>> rhs_type = unsigned_type_node;
>>> }
>>>
>>> - int mask_opno = -1;
>>> + /* The argument that is not of the same type as the others. */
>>> + int diff_opno = -1;
>>> + bool masked = false;
>>> if (internal_fn_p (cfn))
>>> -mask_opno = internal_fn_mask_index (as_internal_fn (cfn));
>>> +{
>>> + if (cfn == CFN_FTRUNC_INT)
>>> + /* For FTRUNC this represents the argument that carries the type of the
>>> + intermediate signed integer. */
>>> + diff_opno = 1;
>>> + else
>>> + {
>>> + /* For masked operations this represents the argument that carries the
>>> +mask. */
>>> + diff_opno = internal_fn_mask_index (as_internal_fn (cfn));
>>> + masked = diff_opno >= 0;
>>> + }
>>> +}
>> I think it would be cleaner not to process argument 1 at all for
>> CFN_FTRUNC_INT. There's no particular need to vectorise it.
>
> I agree with this, will change the loop to continue for argument 1 when
> dealing with non-masked CFN's.
>
>>> }
>>> […]
>>> diff --git a/gcc/tree.c b/gcc/tree.c
>>> index
>>> 845228a055b2cfac0c9ca8c0cda1b9df4b0095c6..f1e9a1eb48769cb11aa69730e2480ed5522f78c1
>>> 100644
>>> --- a/gcc/tree.c
>>> +++ b/gcc/tree.c
>>> @@ -6645,11 +6645,11 @@ valid_constant_size_p (const_tree size,
>>> cst_size_error *perr /* = NULL */)
>>> return true;
>>> }
>>>
>>> -/* Return the precision of the type, or for a complex or vector type the
>>> - precision of the type of its elements. */
>>> +/* Return the type, or for a complex or vector type the type of its
>>> + elements. */
>>>
>>> -unsigned int
>>> -element_precision (const_tree type)
>>> +tree
>>> +element_type (const_tree type)
>>> {
>>> if (!TYPE_P (type))
>>> type = TREE_TYPE (type);
>>> @@ -6657,7 +6657,16 @@ element_precision (const_tree type)
>>> if (code == COMPLEX_TYPE || code == VECTOR_TYPE)
>>> type = TREE_TYPE (type);
>>>
>>> - return TYPE_PRECISION (type);
>>> + return (tree) type;
>> I think we should stick a const_cast in element_precision and make
>> element_type take a plain “type”. As it stands element_type is an
>> implicit const_cast for many cases.
>>
>> Thanks,
> Was just curious about something here, I thought the purpose of having
> element_precision (before) and element_type (now) take a const_tree as
> an argument was to make it clear we aren't changing the input type. I
> understand that as it stands element_type could be an implicit
> const_cast (which I should be using rather than the '(tree)' cast), but
> that's only if 'type' is a type that isn't complex/vector, either way,
> we are conforming to the promise that we aren't changing the incoming
> type, what the caller then does with the result is up to them no?
>
> I don't mind making the changes, just trying to understand the reasoning
> behind it.
The problem with the above is that functions like the following become
well-typed:
void
foo (const_tree t)
{
TYPE_MODE (element_type (t)) = VOIDmode;
}
even though element_type (t) could well be t.
One of the points of const_tree (and const pointer targets in general)
is to use the type system to enforce the promise that the value isn't
changed.
I guess the above is similar to the traditional problem with functions
like index and strstr, which take a const char * but return a char *.
So for example:
void
foo (const char *x)
{
index (x, '.') = 0;
}
is well-typed. But the equivalent C++ code (using iterators) would be
rejected. If C allowed overloading them the correct prototypes would be:
const char *index (const char *, int);
char *index (char *, int);
And I think the same applies here. Either we should provide two functions:
const_tree element_type (const_tree);
tree element_type (tree);
or just the latter.
Thanks,
Richard
Re: [AArch64] Enable generation of FRINTNZ instructions
Hi Richard,
Thank you for the review, I've adopted all above suggestions downstream,
I am still surprised how many style things I still miss after years of
gcc development :(
On 17/12/2021 12:44, Richard Sandiford wrote:
@@ -3252,16 +3257,31 @@ vectorizable_call (vec_info *vinfo,
rhs_type = unsigned_type_node;
}
- int mask_opno = -1;
+ /* The argument that is not of the same type as the others. */
+ int diff_opno = -1;
+ bool masked = false;
if (internal_fn_p (cfn))
-mask_opno = internal_fn_mask_index (as_internal_fn (cfn));
+{
+ if (cfn == CFN_FTRUNC_INT)
+ /* For FTRUNC this represents the argument that carries the type of the
+ intermediate signed integer. */
+ diff_opno = 1;
+ else
+ {
+ /* For masked operations this represents the argument that carries the
+mask. */
+ diff_opno = internal_fn_mask_index (as_internal_fn (cfn));
+ masked = diff_opno >= 0;
+ }
+}
I think it would be cleaner not to process argument 1 at all for
CFN_FTRUNC_INT. There's no particular need to vectorise it.
I agree with this, will change the loop to continue for argument 1 when
dealing with non-masked CFN's.
}
[…]
diff --git a/gcc/tree.c b/gcc/tree.c
index
845228a055b2cfac0c9ca8c0cda1b9df4b0095c6..f1e9a1eb48769cb11aa69730e2480ed5522f78c1
100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -6645,11 +6645,11 @@ valid_constant_size_p (const_tree size, cst_size_error
*perr /* = NULL */)
return true;
}
-/* Return the precision of the type, or for a complex or vector type the
- precision of the type of its elements. */
+/* Return the type, or for a complex or vector type the type of its
+ elements. */
-unsigned int
-element_precision (const_tree type)
+tree
+element_type (const_tree type)
{
if (!TYPE_P (type))
type = TREE_TYPE (type);
@@ -6657,7 +6657,16 @@ element_precision (const_tree type)
if (code == COMPLEX_TYPE || code == VECTOR_TYPE)
type = TREE_TYPE (type);
- return TYPE_PRECISION (type);
+ return (tree) type;
I think we should stick a const_cast in element_precision and make
element_type take a plain “type”. As it stands element_type is an
implicit const_cast for many cases.
Thanks,
Was just curious about something here, I thought the purpose of having
element_precision (before) and element_type (now) take a const_tree as
an argument was to make it clear we aren't changing the input type. I
understand that as it stands element_type could be an implicit
const_cast (which I should be using rather than the '(tree)' cast), but
that's only if 'type' is a type that isn't complex/vector, either way,
we are conforming to the promise that we aren't changing the incoming
type, what the caller then does with the result is up to them no?
I don't mind making the changes, just trying to understand the reasoning
behind it.
I'll send in a new patch with all the changes after the review on the
match.pd stuff.
Thanks,
Andre
Re: [PATCH 1/3] loop-invariant: Don't move cold bb instructions to preheader in RTL
> > > > From: Xiong Hu Luo > > > > gcc/ChangeLog: > > > > * loop-invariant.c (find_invariants_bb): Check profile count > > before motion. > > (find_invariants_body): Add argument. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/loop-invariant-2.c: New. OK, thanks! Honza
Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366
Hi Harald, That is the sort of thing that I had in mind. Is it worth adding the check for CLASS_DATA? I cannot remember if that is made redundant by the test of the class_ok attribute. Cheers Paul On Tue, 28 Dec 2021 at 21:08, Harald Anlauf wrote: > Hi Paul, > > Am 28.12.21 um 12:56 schrieb Paul Richard Thomas via Fortran: > > Hi Harald, > > > > This looks good to me. OK for mainline and, dare I suggest, 11-branch? > > > > From a quick run through resolve.c, there are many places where the > extra > > checks that you introduced in the patch have been implemented. This makes > > me wonder whether a function or macro might not make the relevant code > more > > concise. > > I had thought about this in the past, too. Suitably chosen macros > could help to make checking not only more concise, but also more > robust and (hopefully) readable at the same time. > > What do you think about e.g. > > > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h > index e5d2dd7971e..f3d22b46a75 100644 > --- a/gcc/fortran/gfortran.h > +++ b/gcc/fortran/gfortran.h > @@ -3885,6 +3885,8 @@ bool gfc_is_finalizable (gfc_symbol *, gfc_expr **); > && CLASS_DATA (sym) \ > && CLASS_DATA (sym)->attr.dimension \ > && !CLASS_DATA (sym)->attr.class_pointer) > +#define IS_CLASS_OBJ(sym) \ > + (sym->ts.type == BT_CLASS && sym->attr.class_ok) > > /* frontend-passes.c */ > > > to be used to ensure that we are dealing with a CLASS object where > attributes should already have been set up? Or use a better name? > (IS_CLASS_OBJECT?) > > Thanks, > Harald > > > Thanks for the patch > > > > Paul > > > > > > On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran < > fort...@gcc.gnu.org> > > wrote: > > > >> Dear all, > >> > >> there are a couple of NULL pointer dereferences leading to improper > >> error recovery when trying to handle Gerhard's testcases involving > >> SELECT TYPE and invalid uses of CLASS variables. > >> > >> The fixes look pretty obvious to me, but I'm submitting here to > >> check if there is more that should be done here. > >> > >> (I was surprised to see that there are several different places > >> involved by rather simple variations in the basic test case.) > >> > >> Regtested on x86_64-pc-linux-gnu. OK for mainline? > >> > >> Thanks, > >> Harald > >> > >> > > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[PATCH] emit-rtl: Fix a -fcompare-debug issue due to var-tracking [PR103808]
Hi!
We get a -fcompare-debug FAIL on the following testcase. The problem is
that during cprop we get when a TImode pseudo holding x is being
constructed:
(debug_insn 111 59 103 7 (var_location:TI D#2 (clobber (const_int 0 [0]))) -1
(nil))
(insn 103 111 110 7 (clobber (reg/v:TI 89 [ x ])) "pr103808.c":8:9 -1
(nil))
(debug_insn 110 103 104 7 (var_location:TI D#2 (subreg:TI (reg:DI 111 [ x ])
0)) -1
(nil))
(insn 104 110 109 7 (set (subreg:DI (reg/v:TI 89 [ x ]) 0)
(reg:DI 111 [ x ])) "pr103808.c":8:9 80 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 111 [ x ])
(nil)))
Now, during RA that paradoxical subreg in a debug insn obviously can't
affect where pseudo 111 is allocated and RA puts it into the bp register,
so we have:
(debug_insn 110 111 109 4 (var_location:TI D#2 (reg:TI 6 bp [orig:111 x ]
[111])) -1
(nil))
Now, during var-tracking when we for:
(debug_insn 25 23 26 3 (var_location:TI x (concatn/v:TI [
(reg:DI 6 bp [orig:111 x ] [111])
(subreg:DI (debug_expr:TI D#2) 8)
])) "pr103808.c":8:9 -1
(nil))
try to simplify the highpart subreg of bp, gen_rtx_REG_offset is called in:
if (HARD_REGISTER_NUM_P (final_regno))
{
rtx x = gen_rtx_REG_offset (op, outermode, final_regno,
subreg_memory_offset (outermode,
innermode, byte));
and that unfortunately sets REG_ATTRS on stack_pointer_rtx, because
gen_rtx_REG_offset uses gen_rtx_REG which for Pmode STACK_POINTER_REGNUM
returns stack_pointer_rtx rather than newly created register.
The clobbering of REG_ATTRS on the shared stack_pointer_rtx then shows up
in the dumps as (reg/f:DI 7 sp [ x+8 ]) instead of (reg/f:DI 7 sp)
that shows up without var-tracking.
Clobbering of REG_ATTRS on the shared *_pointer_rtx looks just wrong.
So, IMHO either simplify_gen_subreg -> gen_rtx_REG_offset should call
gen_raw_REG to make sure we get a new non-shared REG we can set REG_ATTRS
on, or we should make sure that we don't overwrite the REG_ATTRS on the
shared REGs (but then simplify_gen_subreg shouldn't try to overwrite
ORIGINAL_REGNO on those either).
For non-DEBUG_INSNs, I'd hope this never happens, the RA shouldn't allocate
multi-word regs overlapping with stack pointer, hard frame pointer etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-12-28 Jakub Jelinek
PR debug/103808
* emit-rtl.c (gen_rtx_REG_offset): Use gen_raw_REG instead of
gen_rtx_REG.
* gcc.dg/pr103808.c: New test.
--- gcc/emit-rtl.c.jj 2021-09-14 10:29:03.797811501 +0200
+++ gcc/emit-rtl.c 2021-12-28 19:38:34.670129846 +0100
@@ -1261,7 +1261,7 @@ rtx
gen_rtx_REG_offset (rtx reg, machine_mode mode, unsigned int regno,
poly_int64 offset)
{
- rtx new_rtx = gen_rtx_REG (mode, regno);
+ rtx new_rtx = gen_raw_REG (mode, regno);
update_reg_offset (new_rtx, reg, offset);
return new_rtx;
--- gcc/testsuite/gcc.dg/pr103808.c.jj 2021-12-28 19:40:22.446637355 +0100
+++ gcc/testsuite/gcc.dg/pr103808.c 2021-12-28 19:40:04.750882404 +0100
@@ -0,0 +1,23 @@
+/* PR debug/103808 */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-fcompare-debug -O2 -ftrapv" } */
+
+void
+foo (__int128 x, int y)
+{
+ for (;;)
+{
+ __int128 a, b;
+
+ x |= !!y;
+ a = x + 1;
+ b = y ? ++y : ++x;
+ y = a < b;
+ asm ("" : "+r" (y));
+ if (x >> 2)
+y *= 2;
+
+ if (y == b)
+__builtin_unreachable ();
+}
+}
Jakub
[PATCH] regrename: Fix -fcompare-debug issue in find_rename_reg [PR103756]
Hi!
The r12-5978 change caused a -fcompare-debug issue, because without
-g a chain might start with a noop move, but with -g there could be
one or more DEBUG_INSNs in the chain before the noop move and so
regrename could make different decisions between -g and -g0.
Note, I must say I don't really understand the original change much,
if we want to make sure the noop moves are removed, couldn't regrename
during building of those du chains simply remove the noop moves instead?
Anyway, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-12-28 Jakub Jelinek
PR rtl-optimization/103756
* regrename.c (find_rename_reg): Test noop_move_p on the first
non-debug insn in the chain rather than on the first insn.
* g++.dg/opt/pr103756.C: New test.
--- gcc/regrename.c.jj 2021-12-15 10:23:48.214517305 +0100
+++ gcc/regrename.c 2021-12-28 18:53:50.698355505 +0100
@@ -394,10 +394,15 @@ find_rename_reg (du_head_p this_head, en
this_head, *unavailable))
return this_head->tied_chain->regno;
- /* If this insn is a noop move, then do not rename in this chain as doing so
- would inhibit removal of the noop move. */
- if (noop_move_p (this_head->first->insn))
-return best_new_reg;
+ /* If the first non-debug insn is a noop move, then do not rename in this
+ chain as doing so would inhibit removal of the noop move. */
+ for (struct du_chain *tmp = this_head->first; tmp; tmp = tmp->next_use)
+if (DEBUG_INSN_P (tmp->insn))
+ continue;
+else if (noop_move_p (tmp->insn))
+ return best_new_reg;
+else
+ break;
/* If PREFERRED_CLASS is not NO_REGS, we iterate in the first pass
over registers that belong to PREFERRED_CLASS and try to find the
--- gcc/testsuite/g++.dg/opt/pr103756.C.jj 2021-12-28 18:52:35.781397335
+0100
+++ gcc/testsuite/g++.dg/opt/pr103756.C 2021-12-28 18:51:07.285627994 +0100
@@ -0,0 +1,57 @@
+// PR rtl-optimization/103756
+// { dg-do compile }
+// { dg-options "-std=c++17 -O -fcompare-debug -fconserve-stack
-frename-registers -fno-tree-ch -fira-algorithm=priority" }
+
+char __copy_move_b___trans_tmp_9;
+template struct __iterator_traits;
+template struct __iterator_traits<_Tp *> {
+ typedef _Tp &reference;
+};
+template struct reverse_iterator {
+ _Iterator current;
+ reverse_iterator();
+ reverse_iterator(reverse_iterator &__x) : current(__x.current) {}
+ _Iterator base() { return current; }
+ typename __iterator_traits<_Iterator>::reference operator*() {
+return *current;
+ }
+ reverse_iterator operator--() {
+++current;
+return *this;
+ }
+};
+template
+auto operator-(_IteratorL __x, _IteratorR __y) {
+ return __y - __x.base();
+}
+struct __copy_move_backward {
+ template
+ static _BI2 __copy_move_b(_BI1 __first, _BI1 __last, _BI2 __result) {
+typename __n = __last - __first;
+for (; __n > 0; --__n) {
+ reverse_iterator __trans_tmp_8 = --__result;
+ *__trans_tmp_8 = __copy_move_b___trans_tmp_9;
+}
+return __result;
+ }
+};
+template
+inline _BI2 __copy_move_backward_a2(_BI1 __first, _BI1 __last, _BI2 __result) {
+ return __copy_move_backward::__copy_move_b(__first, __last, __result);
+}
+template
+_BI2 __copy_move_backward_a1(_BI1 __last, _BI2 __result) {
+ _BI1 __first;
+ return __copy_move_backward_a2<_IsMove>(__first, __last, __result);
+}
+template
+void __copy_move_backward_a(_II, _OI __result) {
+ reverse_iterator __trans_tmp_7 =
+ __copy_move_backward_a1<_IsMove>(__trans_tmp_7, __result);
+}
+template
+void move_backward(_BI1 __first, _BI2 __result) {
+ __copy_move_backward_a(__first, __result);
+}
+reverse_iterator __rotate___first;
+void __rotate() { move_backward(__rotate___first, __rotate___first); }
Jakub
[PATCH] tree-ssa-dce: Fix up -fcompare-debug failures in make_forwarders_with_degenerate_phis [PR103742]
Hi!
make_forwarders_with_degenerate_phis causes a -fcompare-debug failure on the
following testcase.
The problem is that on:
# iftmp.4_8 = PHI <&D.2582(6), &D.2583(4), &D.2582(7), &D.2583(5)>
the exact DECL_UIDs are different between -g and -g0 (which is ok, with -g
the decls can have larger gaps in between the uids), which means
iterative_hash_expr is different and because there are 2 pairs of edges
with matching phi arguments, the function processes them in different
orders.
The following patch fixes it by using the iterative_hash_expr order
only to determine which arguments are the same, then replaces the hashes
with the minimum dest_idx in the set of matching arguments and qsorts
again (which makes it stable for -fcompare-debug) and only splits edges etc.
on that stable order.
As a small optimization, if no arguments are equal, it doesn't do the
second qsort and continues, and if all arguments of the PHI are
constants or SSA_NAMEs (I think that is a pretty common case for many
PHIs), then it doesn't do the second qsort either, because in that case
the hash values will be stable, only computed from the constant values or
SSA_NAME_VERSIONs.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-12-28 Jakub Jelinek
PR debug/103742
* tree-ssa-dce.c (make_forwarders_with_degenerate_phis): If any phi
argument is not CONSTANT_CLASS_P or SSA_NAME and any arguments are
equal, change second from hash value to lowest dest_idx from the
edges which have equal argument and resort to ensure -fcompare-debug
stability.
* g++.dg/opt/pr103742.C: New test.
--- gcc/tree-ssa-dce.c.jj 2021-11-29 14:24:14.120633762 +0100
+++ gcc/tree-ssa-dce.c 2021-12-28 17:30:19.983056815 +0100
@@ -1671,6 +1671,7 @@ make_forwarders_with_degenerate_phis (fu
continue;
gphi *phi = gsi.phi ();
auto_vec, 8> args;
+ bool need_resort = false;
for (unsigned i = 0; i < gimple_phi_num_args (phi); ++i)
{
edge e = gimple_phi_arg_edge (phi, i);
@@ -1682,12 +1683,42 @@ make_forwarders_with_degenerate_phis (fu
if (loops_state_satisfies_p (LOOP_CLOSED_SSA)
&& loop_exit_edge_p (e->src->loop_father, e))
continue;
- args.safe_push (std::make_pair (e, iterative_hash_expr
-(gimple_phi_arg_def (phi, i), 0)));
+
+ tree arg = gimple_phi_arg_def (phi, i);
+ if (!CONSTANT_CLASS_P (arg) && TREE_CODE (arg) != SSA_NAME)
+ need_resort = true;
+ args.safe_push (std::make_pair (e, iterative_hash_expr (arg, 0)));
}
if (args.length () < 2)
continue;
args.qsort (sort_phi_args);
+ /* The above sorting can be different between -g and -g0, as e.g. decls
+can have different uids (-g could have bigger gaps in between them).
+So, only use that to determine which args are equal, then change
+second from hash value to smallest dest_idx of the edges which have
+equal argument and sort again. If all the phi arguments are
+constants or SSA_NAME, there is no need for the second sort, the hash
+values are stable in that case. */
+ hashval_t hash = args[0].second;
+ args[0].second = args[0].first->dest_idx;
+ bool any_equal = false;
+ for (unsigned i = 1; i < args.length (); ++i)
+ if (hash == args[i].second
+ && operand_equal_p (PHI_ARG_DEF_FROM_EDGE (phi, args[i - 1].first),
+ PHI_ARG_DEF_FROM_EDGE (phi, args[i].first)))
+ {
+ args[i].second = args[i - 1].second;
+ any_equal = true;
+ }
+ else
+ {
+ hash = args[i].second;
+ args[i].second = args[i].first->dest_idx;
+ }
+ if (!any_equal)
+ continue;
+ if (need_resort)
+ args.qsort (sort_phi_args);
/* From the candidates vector now verify true candidates for
forwarders and create them. */
@@ -1697,8 +1728,7 @@ make_forwarders_with_degenerate_phis (fu
{
unsigned i;
for (i = start + 1; i < args.length (); ++i)
- if (!operand_equal_p (PHI_ARG_DEF_FROM_EDGE (phi,
args[start].first),
- PHI_ARG_DEF_FROM_EDGE (phi, args[i].first)))
+ if (args[start].second != args[i].second)
break;
/* args[start]..args[i-1] are equal. */
if (start != i - 1)
--- gcc/testsuite/g++.dg/opt/pr103742.C.jj 2021-12-28 17:30:35.788837099
+0100
+++ gcc/testsuite/g++.dg/opt/pr103742.C 2021-12-28 17:31:22.719184723 +0100
@@ -0,0 +1,36 @@
+// PR debug/103742
+// { dg-do compile { target c++17 } }
+// { dg-options "-O2 -fnon-call-exceptions --param=early-inlining-insns=82
-fcompare-debug" }
+
+template T max(T a, T b) { return a >= b ? a : b; }
+template T abs(T);
+template struct A {
+ long a;
+ A(A &x) { a = x.a; }
+ A(lo
[PATCH] c-family: Use BULTINS_LOCATION for predefined macros changed upon optimize or target pragmas [PR103012]
Hi! The following testcases ICE when an optimize or target pragma is followed by a long line (4096+ chars). This is because on such long lines we can't use columns anymore, but the cpp_define calls performed by c_cpp_builtins_optimize_pragma or from the backend hooks for target pragma are done on temporary buffers and expect to get columns from whatever line they appear on (which happens to be the long line after optimize/target pragma), and we run into: #0 fancy_abort (file=0x3abec67 "../../libcpp/line-map.c", line=502, function=0x3abecfc "linemap_add") at ../../gcc/diagnostic.c:1986 #1 0x02e7c335 in linemap_add (set=0x77fca000, reason=LC_RENAME, sysp=0, to_file=0x41287a0 "pr103012.i", to_line=3) at ../../libcpp/line-map.c:502 #2 0x02e7cc24 in linemap_line_start (set=0x77fca000, to_line=3, max_column_hint=128) at ../../libcpp/line-map.c:827 #3 0x02e7ce2b in linemap_position_for_column (set=0x77fca000, to_column=1) at ../../libcpp/line-map.c:898 #4 0x02e771f9 in _cpp_lex_direct (pfile=0x40c3b60) at ../../libcpp/lex.c:3592 #5 0x02e76c3e in _cpp_lex_token (pfile=0x40c3b60) at ../../libcpp/lex.c:3394 #6 0x02e610ef in lex_macro_node (pfile=0x40c3b60, is_def_or_undef=true) at ../../libcpp/directives.c:601 #7 0x02e61226 in do_define (pfile=0x40c3b60) at ../../libcpp/directives.c:639 #8 0x02e610b2 in run_directive (pfile=0x40c3b60, dir_no=0, buf=0x7fffd430 "__OPTIMIZE__ 1\n", count=14) at ../../libcpp/directives.c:589 #9 0x02e650c1 in cpp_define (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2513 #10 0x02e65100 in cpp_define_unused (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2522 #11 0x00f50685 in c_cpp_builtins_optimize_pragma (pfile=0x40c3b60, prev_tree=, cur_tree=) at ../../gcc/c-family/c-cppbuiltin.c:600 assertion that LC_RENAME doesn't happen first. I think the right fix is emit those predefined macros upon optimize/target pragmas with BUILTINS_LOCATION, like we already do for those macros at the start of the TU, they don't appear in columns of the next line after it. Another possibility would be to force them at the location of the pragma. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2021-12-28 Jakub Jelinek PR c++/103012 gcc/ * config/i386/i386-c.c (ix86_pragma_target_parse): Perform cpp_define/cpp_undef calls with forced token locations BUILTINS_LOCATION. * config/arm/arm-c.c (arm_pragma_target_parse): Likewise. * config/aarch64/aarch64-c.c (aarch64_pragma_target_parse): Likewise. * config/s390/s390-c.c (s390_pragma_target_parse): Likewise. gcc/c-family/ * c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Perform cpp_define_unused/cpp_undef calls with forced token locations BUILTINS_LOCATION. gcc/testsuite/ PR c++/103012 * g++.dg/cpp/pr103012.C: New test. * g++.target/i386/pr103012.C: New test. --- gcc/c-family/c-cppbuiltin.c.jj 2021-11-25 08:35:39.855073852 +0100 +++ gcc/c-family/c-cppbuiltin.c 2021-12-28 12:16:15.774616659 +0100 @@ -589,6 +589,10 @@ c_cpp_builtins_optimize_pragma (cpp_read if (flag_undef) return; + /* Make sure all of the builtins about to be declared have + BUILTINS_LOCATION has their location_t. */ + cpp_force_token_locations (parse_in, BUILTINS_LOCATION); + /* Other target-independent built-ins determined by command-line options. */ if (!prev->x_optimize_size && cur->x_optimize_size) @@ -653,6 +657,8 @@ c_cpp_builtins_optimize_pragma (cpp_read cpp_define_unused (pfile, "__ROUNDING_MATH__"); else if (prev->x_flag_rounding_math && !cur->x_flag_rounding_math) cpp_undef (pfile, "__ROUNDING_MATH__"); + + cpp_stop_forcing_token_locations (parse_in); } --- gcc/config/i386/i386-c.c.jj 2021-09-08 09:55:28.732722638 +0200 +++ gcc/config/i386/i386-c.c2021-12-28 12:26:21.491086880 +0100 @@ -702,12 +702,14 @@ ix86_pragma_target_parse (tree args, tre cur_tune = prev_tune = PROCESSOR_max; /* Undef all of the macros for that are no longer current. */ + cpp_force_token_locations (parse_in, BUILTINS_LOCATION); ix86_target_macros_internal (prev_isa & diff_isa, prev_isa2 & diff_isa2, prev_arch, prev_tune, (enum fpmath_unit) prev_opt->x_ix86_fpmath, cpp_undef); + cpp_stop_forcing_token_locations (parse_in); /* For the definitions, ensure all newly defined macros are considered as used for -Wunused-macros. There is no point warning about the @@ -717,12 +719,14 @@ ix86_pragma_target_parse (tree args, tre cpp_opts->warn_unused_macros = 0; /* Define all of the macros for new options that were just turned on. */ + cpp_force_token_locatio
[PATCH] rs6000: Remove useless code related to -mno-power10
Hi,
Option -mpower10 was made as "WarnRemoved" since commit r11-2318,
so -mno-power10 doesn't take effect any more. This patch is to
remove one line useless code which still respects it.
Bootstrapped and regtested on powerpc64le-linux-gnu P9 and
powerpc64-linux-gnu P8.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_disable_incompatible_switches): Remove
useless related to option -mno-power10.
---
gcc/config/rs6000/rs6000.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index e82a47f4c0e..66b01e589b0 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -24825,7 +24825,6 @@ rs6000_disable_incompatible_switches (void)
const HOST_WIDE_INT dep_flags; /* flags that depend on this option. */
const char *const name;/* name of the switch. */
} flags[] = {
-{ OPTION_MASK_POWER10, OTHER_POWER10_MASKS,"power10" },
{ OPTION_MASK_P9_VECTOR, OTHER_P9_VECTOR_MASKS, "power9-vector" },
{ OPTION_MASK_P8_VECTOR, OTHER_P8_VECTOR_MASKS, "power8-vector" },
{ OPTION_MASK_VSX, OTHER_VSX_VECTOR_MASKS, "vsx" },
--
2.27.0
[PATCH] rs6000: Don't turn off VSX for P9 VECTOR when TARGET_AVOID_XFORM set
Hi,
When TARGET_AVOID_XFORM is set, we turn off VSX. But at least from
ISA3.0 (Power9), we support DQ form vector load/store. This patch
is to make it not clear VSX when P9 VECTOR supported, it also checks
some flags which P9 VECTOR relies on, otherwise those flags could
disable P9 VECTOR later.
Bootstrapped and regtested on powerpc64le-linux-gnu P9 and
powerpc64-linux-gnu P8.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_option_override_internal): Consider
P9 VECTOR when determining to disable VSX for TARGET_AVOID_XFORM.
---
gcc/config/rs6000/rs6000.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 66b01e589b0..c020947abc8 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -3865,7 +3865,10 @@ rs6000_option_override_internal (bool global_init_p)
rs6000_isa_flags_explicit |= OPTION_MASK_VSX;
}
}
- else if (TARGET_AVOID_XFORM > 0)
+ else if (TARGET_AVOID_XFORM > 0
+ /* Exclude P9 VECTOR which supports DQ form, but need to check
+ some flags which are able to disable it as well. */
+ && !(TARGET_ALTIVEC && TARGET_P8_VECTOR && TARGET_P9_VECTOR))
msg = N_("%<-mvsx%> needs indexed addressing");
else if (!TARGET_ALTIVEC && (rs6000_isa_flags_explicit
& OPTION_MASK_ALTIVEC))
--
2.27.0
Re: [PATCH] Prune LTO warnings that some tests fail
Hi, > Did you mean to include the change pruning visibility warnings? I don't > think it's necessarily wrong, it just doesn't match the patch description or > ChangeLog. Yes, I think they should be applied, and will fix long-standing failures reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 ChangeLog and patch description amended. OK to commit? FX 0001-LTO-Prune-some-warnings-in-the-testsuite.patch Description: Binary data
[PATCH] i386: Robustify some expanders w.r.t. paradoxical SUBREGs
lowpart_subreg might fail in some cases when trying to create paradoxical
SUBREGs. Use force_reg on input operand, use new temporary output operand
and emit move into the destination afterwards.
Also, replace simplify_gen_subreg (Mx, op, My, 0)
with equivalent lowpart_subreg (Mx, op, My).
2021-12-29 Uroš Bizjak
gcc/ChangeLog:
* config/i386/sse.md (vec_pack_float_):
Perform gen_avx512dq_floatv2div2sf2 into a
pseudo and emit move insn into operands[0].
(fix_truncv2sfv2di2): Use lowpart_subreg
instead of simplify_gen_subreg.
(trunc2): Perform
gen_avx512vl_truncatevqi2 into a
pseudo and emit move insn into operands[0].
(trunc2): Perform
gen_avx512vl_truncatevhi2 into a
pseudo and emit move insn into operands[0].
(truncv2div2si2): Perform gen_avx512vl_truncatev2div2si2 into a
pseudo and emit move insn into operands[0].
(truncv8div8qi2): Perform gen_avx512f_truncatev8div16qi2 into a
pseudo and emit move insn into operands[0].
(v8qiv8hi2): Use lowpart_subreg
instead of simplify_gen_subreg.
(v8qiv8si2): Ditto.
(v4qiv4si2): Ditto.
(v4hiv4si2): Ditto.
(v8qiv8di2): Ditto.
(v4qiv4di2): Ditto.
(v2qiv2di2): Ditto.
(v4hiv4di2): Ditto.
(v2hiv2di2): Ditto.
(v2siv2di2): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to master.
Uros.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 69c754751a8..0997d9edf9d 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -8115,9 +8115,12 @@
(any_float:V2SF (match_operand:V2DI 1 "nonimmediate_operand")))]
"TARGET_AVX512DQ && TARGET_AVX512VL"
{
- operands[0] = simplify_gen_subreg (V4SFmode, operands[0], V2SFmode, 0);
+ rtx op0 = gen_reg_rtx (V4SFmode);
+
emit_insn (gen_avx512dq_floatv2div2sf2
-(operands[0], operands[1]));
+(op0, operands[1]));
+
+ emit_move_insn (operands[0], lowpart_subreg (V2SFmode, op0, V4SFmode));
DONE;
})
@@ -8547,10 +8550,10 @@
(match_operand:V2SF 1 "register_operand")))]
"TARGET_AVX512DQ && TARGET_AVX512VL"
{
- operands[1] = force_reg (V2SFmode, operands[1]);
- operands[1] = simplify_gen_subreg (V4SFmode, operands[1], V2SFmode, 0);
+ rtx op1 = force_reg (V2SFmode, operands[1]);
+ op1 = lowpart_subreg (V4SFmode, op1, V2SFmode);
emit_insn (gen_avx512dq_fix_truncv2sfv2di2
-(operands[0], operands[1]));
+(operands[0], op1));
DONE;
})
@@ -13631,10 +13634,13 @@
(match_operand:PMOV_SRC_MODE_3 1 "register_operand")))]
"TARGET_AVX512VL"
{
- operands[0] = simplify_gen_subreg (V16QImode, operands[0], mode,
0);
- emit_insn (gen_avx512vl_truncatevqi2 (operands[0],
- operands[1],
- CONST0_RTX
(mode)));
+ rtx op0 = gen_reg_rtx (V16QImode);
+
+ emit_insn (gen_avx512vl_truncatevqi2
+(op0, operands[1], CONST0_RTX (mode)));
+
+ emit_move_insn (operands[0],
+ lowpart_subreg (mode, op0, V16QImode));
DONE;
})
@@ -14006,12 +14012,14 @@
(match_operand:PMOV_SRC_MODE_4 1 "register_operand")))]
"TARGET_AVX512VL"
{
- operands[0] = simplify_gen_subreg (V8HImode, operands[0], mode,
0);
- emit_insn (gen_avx512vl_truncatevhi2 (operands[0],
- operands[1],
- CONST0_RTX
(mode)));
- DONE;
+ rtx op0 = gen_reg_rtx (V8HImode);
+
+ emit_insn (gen_avx512vl_truncatevhi2
+(op0, operands[1], CONST0_RTX (mode)));
+ emit_move_insn (operands[0],
+ lowpart_subreg (mode, op0, V8HImode));
+ DONE;
})
(define_insn "avx512vl_vhi2"
@@ -14251,10 +14259,13 @@
(match_operand:V2DI 1 "register_operand")))]
"TARGET_AVX512VL"
{
- operands[0] = simplify_gen_subreg (V4SImode, operands[0], V2SImode, 0);
- emit_insn (gen_avx512vl_truncatev2div2si2 (operands[0],
-operands[1],
-CONST0_RTX (V2SImode)));
+ rtx op0 = gen_reg_rtx (V4SImode);
+
+ emit_insn (gen_avx512vl_truncatev2div2si2
+(op0, operands[1], CONST0_RTX (V2SImode)));
+
+ emit_move_insn (operands[0],
+ lowpart_subreg (V2SImode, op0, V4SImode));
DONE;
})
@@ -14389,8 +14400,12 @@
(match_operand:V8DI 1 "register_operand")))]
"TARGET_AVX512F"
{
- operands[0] = simplify_gen_subreg (V16QImode, operands[0], V8QImode, 0);
- emit_insn (gen_avx512f_truncatev8div16qi2 (operands[0], operands[1]));
+ rtx op0 = gen_reg_rtx (V16QImode);
+
+ emit_insn (gen_avx512f_truncatev8div16qi2 (op0, operands[1]));
+
+ emit_move_insn (operands[0],
+ lowpart_subreg (V8QImode, op0, V16QImode));
DONE;
})
@@ -21625,9 +21640,9 @@
{
if (!MEM_P (operands[1]))
{
- operands[1] = force_reg (V8QImode, operan
