[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Richard Biener  ---
VRP does intentionally not insert PHIs, let me have a look (and yes, both
bisections just make the bug change from latent to not latent or vice versa).

[Bug tree-optimization/102852] [12 Regression] Compile time hog since r12-4421-g0bd68793921ecf3b

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Aldy Hernandez  ---
This is actually the same thing as 102814.

*** This bug has been marked as a duplicate of bug 102814 ***

[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814

Aldy Hernandez  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez  ---
*** Bug 102852 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
Bug 102814 depends on bug 102852, which changed state.

Bug 102852 Summary: [12 Regression] Compile time hog since 
r12-4421-g0bd68793921ecf3b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/102852] [12 Regression] Compile time hog since r12-4421-g0bd68793921ecf3b

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852

--- Comment #3 from Martin Liška  ---
Thanks for the fix, it's really gone now.

[Bug rtl-optimization/102850] [10/11/12 Regression] ICE in begin_move_insn, at sched-ebb.c:196 since r10-3502-g2e2c6df346ab70ed

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102850

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |10.4

[Bug tree-optimization/102852] [12 Regression] Compile time hog since r12-4421-g0bd68793921ecf3b

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852

--- Comment #4 from Aldy Hernandez  ---
(In reply to Martin Liška from comment #3)
> Thanks for the fix, it's really gone now.

Heh.  Actually the bug is still latent, but I'm testing a fix ;-).

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:c7abdf46fb7ac9a0c37f120feff3fcc3a752584f

commit r12-4529-gc7abdf46fb7ac9a0c37f120feff3fcc3a752584f
Author: Jakub Jelinek 
Date:   Wed Oct 20 09:34:51 2021 +0200

openmp: Fix up struct gomp_work_share handling [PR102838]

If GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is not defined, the intent was to
treat the split of the structure between first cacheline (64 bytes)
as mostly write-once, use afterwards and second cacheline as rw just
as an optimization.  But as has been reported, with vectorization enabled
at -O2 it can now result in aligned vector 16-byte or larger stores.
When not having posix_memalign/aligned_alloc/memalign or other similar API,
alloc.c emulates it but it needs to allocate extra memory for the dynamic
realignment.
So, for the GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC not defined case, this patch
stops using aligned (64) attribute in the middle of the structure and
instead
inserts padding that puts the second half of the structure at offset 64
bytes.

And when GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is defined, usually it was
allocated
as aligned, but for the orphaned case it could still be allocated just with
gomp_malloc without guaranteed proper alignment.

2021-10-20  Jakub Jelinek  

PR libgomp/102838
* libgomp.h (struct gomp_work_share_1st_cacheline): New type.
(struct gomp_work_share): Only use aligned(64) attribute if
GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is defined, otherwise just
add padding before lock to ensure lock is at offset 64 bytes
into the structure.
(gomp_workshare_struct_check1, gomp_workshare_struct_check2):
New poor man's static assertions.
* work.c (gomp_work_share_start): Use gomp_aligned_alloc instead of
gomp_malloc if GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC.

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #6 from Richard Biener  ---
So the issue is that the SSA form is invalid at the start of VRP2 - we have

 [local count: 25270028]:
_45 = (signed char) nd_5;
if (_45 < 0)
  goto ; [33.33%]
else
  goto ; [66.67%]

 [local count: 25267450]:
:
ta = 0;
goto ; [100.00%]

 [local count: 25265782]:
:
nd.7_10 = _45;
_11 = _45 + -128;
_12 = (unsigned char) _11;
dic = _12;
goto ; [100.00%]

but there's a PHI missing for _45 - the definition site does not dominate the
use.

(gdb) p verify_ssa (true, true)
t.c: In function 'snod.constprop':
t.c:18:22: error: definition in block 16 does not dominate use in block 13
   18 | static unsigned char snod(unsigned char cd, unsigned char *tl, unsigned
char *ic)
  |  ^~~~
for SSA_NAME: _45 in statement:
nd.7_10 = _45;

and the issue pops up after DOM3.

It would be nice to bisect with checking enabled or -fchecking - Martin?

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #7 from Richard Biener  ---
Btw, the ICE also reproduces on native x86_64, not just with a cross to arm and
both GCC 8 and GCC 10 look fine in this regard.

[Bug target/102375] [aarch64] Should allow space in target attribute

[clyon at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
Hi, it seems you forgot to update gcc.target/aarch64/pr89093.c, which now
fails:
FAIL: gcc.target/aarch64/pr89093.c  (test for errors, line 4)  
FAIL: gcc.target/aarch64/pr89093.c 
(test for errors, line 5)  
FAIL: gcc.target/aarch64/pr89093.c  (test for errors, line 6) 

However there was a long discussion in PR89093, among which a small patch
"Don't skip whitespace at the start of target attribute string"

[Bug tree-optimization/102853] New: [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853

Bug ID: 102853
   Summary: [12 Regression] ICE in compute_distributive_range, at
tree-data-ref.c:593 since
r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64-linux-gnu

The following ICEs:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33846.c
-O1 -ftree-vectorize -mmodulo -ftrapv
during GIMPLE pass: pcom
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33846.c: In function
‘_mix_some_samples’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33846.c:12:6: internal
compiler error: in compute_distributive_range, at tree-data-ref.c:593
   12 | void _mix_some_samples (intptr_t buf, int *mix_buffer, int mix_size)
  |  ^
0x22f4a05 compute_distributive_range
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:593
0x22f551c split_constant_offset_1
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:794
0x22f5a26 split_constant_offset_1
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:895
0x22f61b0 split_constant_offset
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:1043
0x22f538f split_constant_offset_1
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:779
0x22f5a26 split_constant_offset_1
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:895
0x22f61b0 split_constant_offset
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:1043
0x22f6376 split_constant_offset(tree_node*, tree_node**, tree_node**)
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:1070
0x22f73b0 dr_analyze_indices
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:1381
0x22f7c1d create_data_ref(edge_def*, loop*, tree_node*, gimple*, bool, bool)
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:1500
0x2304459 find_data_references_in_stmt(loop*, gimple*, vec*)
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:5934
0x2304677 find_data_references_in_bb(loop*, basic_block_def*,
vec*)
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:5986
0x2304749 find_data_references_in_loop(loop*, vec*)
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:6019
0x2304d89 compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
/home/marxin/Programming/gcc/gcc/tree-data-ref.c:6194
0x146a2dd pcom_worker::tree_predictive_commoning_loop(bool)
/home/marxin/Programming/gcc/gcc/tree-predcom.c:3320
0x146a87c tree_predictive_commoning(bool)
/home/marxin/Programming/gcc/gcc/tree-predcom.c:3428
0x146a938 run_tree_predictive_commoning
/home/marxin/Programming/gcc/gcc/tree-predcom.c:3460
0x146a9df execute
/home/marxin/Programming/gcc/gcc/tree-predcom.c:3505
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||12.0
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Last reconfirmed||2021-10-20
  Known to work||11.2.0

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #8 from Martin Liška  ---
Using x86_64 compiler, the issue is fixed on master after
r10-1420-g744fd446c321f78f and started with r9-6384-g1a438d160e1dc845.

[Bug target/102375] [aarch64] Should allow space in target attribute

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||jakub at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #5 from Martin Liška  ---
(In reply to Christophe Lyon from comment #4)
> Hi, it seems you forgot to update gcc.target/aarch64/pr89093.c, which now
> fails:
> FAIL: gcc.target/aarch64/pr89093.c  (test for errors, line 4)   
> FAIL: gcc.target/aarch64/pr89093.c  (test for errors, line 5)   
> FAIL: gcc.target/aarch64/pr89093.c  (test for errors, line 6) 

Sorry about that.

> 
> However there was a long discussion in PR89093, among which a small patch
> "Don't skip whitespace at the start of target attribute string"

Oh, you are right, there's Jakub's patch that removed skipping of the spaces
(g:d7b0896b2392b803679ac5ca88087b5c3ecede7e).

Well, I believe it's better to strip the whitespaces.
Or?

[Bug target/102812] Unoptimal (and wrong) code for _Float16 insert

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812

--- Comment #2 from Uroš Bizjak  ---
Please note that the code above should compile via ix86_expand_vector_set,
similar to:

--cut here--
typedef short v8hi __attribute__((__vector_size__(16)));

v8hi foo (short a)
{
  return (v8hi) {a, 0, 0, 0, 0, 0, 0, 0 };
}
--cut here--

that results in:

vpxor   %xmm0, %xmm0, %xmm0
vpinsrw $0, %edi, %xmm0, %xmm0
ret

[Bug middle-end/102764] [12 Regression] -fcompare-debug failure (length) at -O3

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102764

Eric Botcazou  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|[12 Regression] |[12 Regression]
   |-fcompare-debug failure |-fcompare-debug failure
   |(length) at -O3 since   |(length) at -O3
   |r12-630-g7c4c9fcc0de86587   |
 CC|ebotcazou at gcc dot gnu.org   |
 Status|NEW |ASSIGNED

--- Comment #5 from Eric Botcazou  ---
Fixing.

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #9 from Richard Biener  ---
(In reply to Martin Liška from comment #8)
> Using x86_64 compiler, the issue is fixed on master after
> r10-1420-g744fd446c321f78f and started with r9-6384-g1a438d160e1dc845.

Can you continue searching for a fix with -fdisable-tree-fre4 (r10-1420
added FRE4 before DOM3).

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed|2021-10-19 00:00:00 |2021-10-20
 Status|UNCONFIRMED |NEW
Summary|[10/11/12 Regression] ICE   |[10 Regression] ICE in
   |in cselib_record_set at -O2 |cselib_record_set at -O2 or
   |or greater  |greater
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
All right, now I can reproduce it with the cross compiler. Apparently, it's
fixed with r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126.

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #10 from Martin Liška  ---
(In reply to Richard Biener from comment #9)
> (In reply to Martin Liška from comment #8)
> > Using x86_64 compiler, the issue is fixed on master after
> > r10-1420-g744fd446c321f78f and started with r9-6384-g1a438d160e1dc845.
> 
> Can you continue searching for a fix with -fdisable-tree-fre4 (r10-1420
> added FRE4 before DOM3).

Sure, then it gets fixed with r11-408-g84935c9822183ce4.

[Bug ada/100486] Ada build fails for 32bit Windows

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486

--- Comment #68 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:8fe93cc664ded8cc1952da28b23f3fc68504a73e

commit r12-4530-g8fe93cc664ded8cc1952da28b23f3fc68504a73e
Author: Arnaud Charlet 
Date:   Wed Oct 20 10:23:40 2021 +0200

Avoid exception propagation during bootstrap

This addresses PR ada/100486, which is the bootstrap failure of GCC 11 for
32-bit Windows in the MSYS setup.  The PR shows that we cannot rely on
exception propagation being operational during the bootstrap, at least on
the 11 branch, so fix this by removing the problematic raise statement.

gcc/ada/
PR ada/100486
* sem_prag.adb (Check_Valid_Library_Unit_Pragma): Do not raise an
exception as part of the bootstrap.

[Bug middle-end/102764] [12 Regression] -fcompare-debug failure (length) at -O3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102764

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:972ee845f54839e9bd2e4611bb268d75440f3845

commit r12-4531-g972ee845f54839e9bd2e4611bb268d75440f3845
Author: Eric Botcazou 
Date:   Wed Oct 20 10:42:56 2021 +0200

Fix PR middle-end/102764

This is a regression present on the mainline in the form of -fcompare-debug
failure at -O3 on a compiler-generated testcase.  Fixed by disregarding a
debug statement in the last position of a basic block to reset the current
location for the outgoing edges.

gcc/
PR middle-end/102764
* cfgexpand.c (expand_gimple_basic_block): Disregard a final debug
statement to reset the current location for the outgoing edges.

gcc/testsuite/
* gcc.dg/pr102764.c: New test.

[Bug ada/100486] Ada build fails for 32bit Windows

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486

--- Comment #69 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:40b209e340b610248f9b1eec082f6b1ff734a2d0

commit r11-9177-g40b209e340b610248f9b1eec082f6b1ff734a2d0
Author: Arnaud Charlet 
Date:   Wed Oct 20 10:23:40 2021 +0200

Avoid exception propagation during bootstrap

This addresses PR ada/100486, which is the bootstrap failure of GCC 11 for
32-bit Windows in the MSYS setup.  The PR shows that we cannot rely on
exception propagation being operational during the bootstrap, at least on
the 11 branch, so fix this by removing the problematic raise statement.

gcc/ada/
PR ada/100486
* sem_prag.adb (Check_Valid_Library_Unit_Pragma): Do not raise an
exception as part of the bootstrap.

[Bug middle-end/102764] [12 Regression] -fcompare-debug failure (length) at -O3

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102764

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Eric Botcazou  ---
.

[Bug ada/100486] Ada build fails for 32bit Windows

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |11.3

--- Comment #70 from Eric Botcazou  ---
Tentatively fixed, reopen if not.

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
OK, so the issue is that we are doing a jump threading that violates SSA form
since it bypasses the definition used by the merge block.  There's likely
validation that this cannot happen but since we're forward-threading it's
probably happening too early and the SSA definition is only apperaring when
visiting a block we thread through where we change

   if (nd_5 >= 128)

to

   _46 = (singed char) nd_6;
   if (_46 < 0)

and the merge had

   L4:
nd.7_11 = (signed char) nd_5;

where we now realize the CSE opportunity to _46.

The r9-6384-g1a438d160e1dc845 change makes us enter the new _46 = (signed char)
nd_6 expression into the hashtable (it was skipped before).

Somebody more familiar with the (old) threading code needs to debug this
further or provide hints as to where the designed point is to avoid this issue.
 Jeff?

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #12 from Richard Biener  ---
(In reply to Martin Liška from comment #10)
> (In reply to Richard Biener from comment #9)
> > (In reply to Martin Liška from comment #8)
> > > Using x86_64 compiler, the issue is fixed on master after
> > > r10-1420-g744fd446c321f78f and started with r9-6384-g1a438d160e1dc845.
> > 
> > Can you continue searching for a fix with -fdisable-tree-fre4 (r10-1420
> > added FRE4 before DOM3).
> 
> Sure, then it gets fixed with r11-408-g84935c9822183ce4.

-fno-tree-sink?

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #13 from Richard Biener  ---
Aldyh might also have stumbled over code avoiding to thread across a SSA
definition.

Ah - I guess the block is recorded as "forwarder" (block with just a condition
we are able to thread through) but it becomes a non-"forwarder" because later
a SSA definition is inserted but the actual threading code will not copy
those stmts (or verify they impose no problem)?

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #14 from Richard Biener  ---
  Registering jump thread: (10, 16) incoming edge;  (16, 17) normal; (17, 13)
nocopy;

   [local count: 75809931]:
  if (nd_5 >= 128)
goto ; [40.00%]
  else
goto ; [60.00%]

   [local count: 25267450]:
:
  ta = 0;
  goto ; [100.00%]

   [local count: 50537478]:
  if (nd_5 > 130)
goto ; [25.00%]
  else
goto ; [75.00%]

   [local count: 50537478]:
  if (nd_5 >= 128)
goto ; [66.67%]
  else
goto ; [33.33%]

   [local count: 25265782]:
:
  nd.7_11 = (signed char) nd_5;
  _12 = nd.7_11 + -128;
  _13 = (unsigned char) _12;
  dic = _13;
  goto ; [100.00%]

and bb 17 is where we later insert the stmt and it is indeed marked as
'nocopy'.

[Bug target/102812] Unoptimal (and wrong) code for _Float16 insert

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812

--- Comment #3 from Hongyu Wang  ---
(In reply to Uroš Bizjak from comment #2)
> Please note that the code above should compile via ix86_expand_vector_set,
> similar to:
> 
> --cut here--
> typedef short v8hi __attribute__((__vector_size__(16)));
> 
> v8hi foo (short a)
> {
>   return (v8hi) {a, 0, 0, 0, 0, 0, 0, 0 };
> }
> --cut here--
> 
> that results in:
> 
> vpxor   %xmm0, %xmm0, %xmm0
> vpinsrw $0, %edi, %xmm0, %xmm0
> ret

Currently we have

if (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
  return true;

in ix86_vector_mode_supported_p, so for SSE2 target V8HFmode would be returned
in BLKmode.

After I put V8HFmode to VALID_SSE2_REG_MODE the code would be like

vmovss  %xmm0, %xmm0, %xmm1
vpxor   %xmm0, %xmm0, %xmm0
pextrw  $0, %xmm1, -10(%rsp)   
vpinsrw $0, -10(%rsp), %xmm0, %xmm0

Seems IRA spills the HF reg to memory..

I wonder whether we should move vector mode support to sse2 for now, as we
don't have sufficient HF vector arithmetic emulation for non-avx512fp16 target.

[Bug target/102375] [aarch64] Should allow space in target attribute

[clyon at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

--- Comment #6 from Christophe Lyon  ---
I think it's better too, so this essentially means removing
gcc.target/aarch64/pr89093.c, but since Jakub's patch was specifically about
leading spaces, I was wondering whether I was missing something.

[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:82cd78f2c31db1664ca154d7fcd24e9eaee1427f

commit r12-4532-g82cd78f2c31db1664ca154d7fcd24e9eaee1427f
Author: Aldy Hernandez 
Date:   Wed Oct 20 09:05:23 2021 +0200

Restore --param=max-fsm-thread-length

The removal of --param=max-fsm-thread-length is causing code
explosion.  I thought that --param=max-fsm-thread-path-insns was a
better gague for path profitability than raw BB length, but it turns
out that we don't take into account PHIs when estimating the number of
statements.

In this PR, we have a sequence of very large PHIs that have us
traversing extremely large paths that blow up the compilation.

We could fix this a couple of different ways.  We could avoid
traversing more than a certain number of PHI arguments, or ignore
large PHIs altogether.  The old implementation certainly had this
knob, and we could cut things off before we even got to the ranger.
We could also adjust the instruction estimation to take into account
PHIs, but I'm sure we'll mess something else in the process ;-).

The easiest thing to do is just restore the knob.

At a later time we could tweak this further, for instance,
disregarding empty blocks in the count.  BTW, this is the reason I
didn't chop things off in the lowlevel registry for all threaders: the
forward threader can't really explore too deep paths, but it could
theoretically get there while threading over empty blocks.

This fixes 102814, 102852, and I bet it solves the Linux kernel cross
compile issue.

Tested on x86-64 Linux.

gcc/ChangeLog:

PR tree-optimization/102814
* doc/invoke.texi: Document --param=max-fsm-thread-length.
* params.opt: Add --param=max-fsm-thread-length.
* tree-ssa-threadbackward.c
(back_threader_profitability::profitable_path_p): Fail on paths
longer than max-fsm-thread-length.

[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #15 from Richard Biener  ---
The following removes the premature optimization(?) using
EDGE_NO_COPY_SRC_BLOCK
in case the block contained a condition we could thread through.  That fixes
the testcase.

diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index c3ea2d680d8..2005e30322b 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -989,8 +989,11 @@ thread_around_empty_blocks (edge taken_edge,
return false;
   bitmap_set_bit (visited, taken_edge->dest->index);

+  /* We may not use EDGE_NO_COPY_SRC_BLOCK since the condition
+might later be simplified to something needing a temporary
+SSA definition.  See PR102844.  */
   jump_thread_edge *x
-   = new jump_thread_edge (taken_edge, EDGE_NO_COPY_SRC_BLOCK);
+   = new jump_thread_edge (taken_edge, EDGE_COPY_SRC_BLOCK);
   path->safe_push (x);

   thread_around_empty_blocks (taken_edge,

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #16 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #13)
> Aldyh might also have stumbled over code avoiding to thread across a SSA
> definition.
> 
> Ah - I guess the block is recorded as "forwarder" (block with just a
> condition
> we are able to thread through) but it becomes a non-"forwarder" because later
> a SSA definition is inserted but the actual threading code will not copy
> those stmts (or verify they impose no problem)?

I haven't run into this in the forward threader, but I have run into something
similar in the new path solver (which I fixed).  But that's unlikely to help
you here.

Silly question, why is the SSA form invalid on entry to VRP2?  That's just
asking for trouble.  Is this related to how asserts work?

[Bug target/102375] [aarch64] Should allow space in target attribute

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

--- Comment #7 from Jakub Jelinek  ---
Not allowing spaces there was intentional and has been discussed, please see
the
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-04/msg00680.html
and surrounding threads.
As I wrote, if we accept whitespace, it should be done in all places and for
all targets, consistency is even more important than whether we allow it or
disallow it.  So, from this point of view, the r12-4503 change is wrong.

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #17 from rguenther at suse dot de  ---
On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844
> 
> --- Comment #16 from Aldy Hernandez  ---
> (In reply to Richard Biener from comment #13)
> > Aldyh might also have stumbled over code avoiding to thread across a SSA
> > definition.
> > 
> > Ah - I guess the block is recorded as "forwarder" (block with just a
> > condition
> > we are able to thread through) but it becomes a non-"forwarder" because 
> > later
> > a SSA definition is inserted but the actual threading code will not copy
> > those stmts (or verify they impose no problem)?
> 
> I haven't run into this in the forward threader, but I have run into something
> similar in the new path solver (which I fixed).  But that's unlikely to help
> you here.
> 
> Silly question, why is the SSA form invalid on entry to VRP2?  That's just
> asking for trouble.  Is this related to how asserts work?

Well, DOM threading creates invalid SSA (definition not dominating use).
Doesn't have to do anything with VRP or asserts.

[Bug target/102375] [aarch64] Should allow space in target attribute

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

--- Comment #8 from Jakub Jelinek  ---
Or yet another variant is only allow whitespace after , separator and not
anywhere else, so
"+sve, +sve2"
is ok, but
"+sve,   +sve2"
is not.  But again, if we decide to do that, it should be done on all targets
and not just on one of them, should be done for both target attribute, optimize
attribute and pragmas and should be documented.

[Bug c++/102854] New: [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102854

Bug ID: 102854
   Summary: [OpenMP] Bogus "initializer expression refers to
iteration variable" when using templates
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openmp, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The following code compiles with the "typedef" but fails when used as
"template" with:

fooc.c:9:3: error: initializer expression refers to iteration variable ‘i’
9 |   for (IndexType i = 0; i < N; ++i)
  |   ^~~

Long version:
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/application_kernels/lsms_triangular_packing.cpp

[Side note: According to the notes in the Pull Request #225, it works with LLVM
13 but fails with LLVM 11 and 12.]

Reduceted testcase:

// typedef IndexType int;  // < works:
template   // < fails
void
foo (IndexType N, IndexType M)
{
  #pragma omp target teams distribute parallel for collapse(2)
  for (IndexType i = 0; i < N; ++i)
for (IndexType k = i; k < M; ++k)
  ;
}

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

Aldy Hernandez  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #18 from Aldy Hernandez  ---
(In reply to rguent...@suse.de from comment #17)
> On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote:

> > Silly question, why is the SSA form invalid on entry to VRP2?  That's just
> > asking for trouble.  Is this related to how asserts work?
> 
> Well, DOM threading creates invalid SSA (definition not dominating use).
> Doesn't have to do anything with VRP or asserts.

Ah, I see.

BTW, if this is still the case in mainline, this is bound to be a problem for
the ranger.  Andrew, won't we get an UNDEFINED / unreachable if we query the
non dominating use at this point?

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Status|ASSIGNED|NEW
   Priority|P3  |P2
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #19 from Richard Biener  ---
(In reply to Richard Biener from comment #15)
> The following removes the premature optimization(?) using
> EDGE_NO_COPY_SRC_BLOCK
> in case the block contained a condition we could thread through.  That fixes
> the testcase.
> 
> diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
> index c3ea2d680d8..2005e30322b 100644
> --- a/gcc/tree-ssa-threadedge.c
> +++ b/gcc/tree-ssa-threadedge.c
> @@ -989,8 +989,11 @@ thread_around_empty_blocks (edge taken_edge,
> return false;
>bitmap_set_bit (visited, taken_edge->dest->index);
>  
> +  /* We may not use EDGE_NO_COPY_SRC_BLOCK since the condition
> +might later be simplified to something needing a temporary
> +SSA definition.  See PR102844.  */
>jump_thread_edge *x
> -   = new jump_thread_edge (taken_edge, EDGE_NO_COPY_SRC_BLOCK);
> +   = new jump_thread_edge (taken_edge, EDGE_COPY_SRC_BLOCK);
>path->safe_push (x);
>  
>thread_around_empty_blocks (taken_edge,

OK, it isn't that easy - we overrun redirection_data::dup_blocks that way
causing random crashes later on.  So the change needs adjustments to how
we account thread_around_empty_blocks stuff, I couldn't find the code
that avoids this for non-empty blocks.

The issue is definitely latent everywhere even trunk as long as we keep
the DOM forward threader there.

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #20 from Richard Biener  ---
(In reply to Aldy Hernandez from comment #18)
> (In reply to rguent...@suse.de from comment #17)
> > On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote:
> 
> > > Silly question, why is the SSA form invalid on entry to VRP2?  That's just
> > > asking for trouble.  Is this related to how asserts work?
> > 
> > Well, DOM threading creates invalid SSA (definition not dominating use).
> > Doesn't have to do anything with VRP or asserts.
> 
> Ah, I see.
> 
> BTW, if this is still the case in mainline, this is bound to be a problem
> for the ranger.  Andrew, won't we get an UNDEFINED / unreachable if we query
> the non dominating use at this point?

Well, invalid IL is invalid - there's no need to "cope" with it.  We have to
fix the (forward) threading code.

[Bug target/102375] [aarch64] Should allow space in target attribute

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

--- Comment #9 from Jakub Jelinek  ---
And note we already do support target ("+sve", "+sve2"), so there is not much
point in allowing whitespace inside of the string literals.

[Bug c++/102855] New: #pragma GCC unroll n should support n being a template parameter

[bernhardmgruber at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102855

Bug ID: 102855
   Summary: #pragma GCC unroll n should support n being a template
parameter
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernhardmgruber at gmail dot com
  Target Milestone: ---

Using `#pragma GCC unroll n` for a loop fails to compile when `n` is a template
parameter. Given the following code:

```c++
void f(int);

template 
void g() {
#pragma GCC unroll n
for (int i = 0; i < n; i++)
f(i);
}

int main() {
constexpr auto n = 100;
g();
}
```
g++-11.2 produces the following diagnostic:
```
source>: In function 'void g()':
:5:24: error: '#pragma GCC unroll' requires an assignment-expression
that evaluates to a non-negative integral constant less than 65535
5 | #pragma GCC unroll n
  |^
```
If `g` is turned into a normal function and the variable `n` is moved form
`main` to `g`, the example compiles fine and produces the expected behavior.

Allowing `n` inside the pragma to be a template parameter helps temendously in
optimizing hot loops in templated numeric codes. Such a feature is also
supported by clang, icc and nvcc. I want to kindly ask you to provide this
additional functionality.

Thank you!

Example on godbolt:
https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:8,positionColumn:2,positionLineNumber:8,selectionStartColumn:2,selectionStartLineNumber:8,startColumn:2,startLineNumber:8),source:'void+f(int)%3B%0A%0Atemplate+%3Cint+n%3E%0Avoid+g()+%7B%0A%23pragma+GCC+unroll+n%0Afor+(int+i+%3D+0%3B+i+%3C+n%3B+i%2B%2B)%0Af(i)%3B%0A%7D%0A%0Aint+main()+%7B%0Aconstexpr+auto+n+%3D+100%3B%0Ag%3Cn%3E()%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:54.105263157894754,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((g:!((h:compiler,i:(compiler:g112,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:4,lang:c%2B%2B,libs:!(),options:'-O3+-Wall+-Wextra',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1,tree:'1'),l:'5',n:'0',o:'x86-64+gcc+11.2+(C%2B%2B,+Editor+%231,+Compiler+%234)',t:'0')),k:20.004,l:'4',m:50,n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compiler:4,editor:1,fontScale:14,fontUsePx:'0',tree:'1',wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+gcc+11.2+(Compiler+%234)',t:'0')),header:(),l:'4',m:50,n:'0',o:'',s:0,t:'0')),k:45.894736842105274,l:'3',n:'0',o:'',t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Target|ppc64-linux-gnu |ppc64-linux-gnu,
   ||powerpc64le-linux-gnu
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Also on LE, even without -mmodulo.  Richard inserted the assert with the last
refactoring of split_constant_offset.

We are splitting the initial value of the IV tmp.9_69 here which is

niters_vector_mult_vf.8_68 = bnd.7_67 << 3;
_70 = (long int) niters_vector_mult_vf.8_68;
_71 = _70 * 2;
tmp.9_69 = buf_12(D) + _71;

and the operation we're asserting on is _70 * 2.

Note the IV is

(short int *) buf_53

with

# buf_53 = PHI <..., tmp9_69>

so the trigger for the ICE is the added

1373  STRIP_NOPS (access_fn);

in dr_analyze_indices.  That was necessary to avoid regressions when IVs
are demoted to uintptr_t by if-conversion.

split_constant_offset makes sure to not look through conversions to
trapping types - maybe that check should also be on the individual operations
in case we start analyzing with an expression in trapping types (as done
here)?  Immediate mitigation would of course be to restrict the STRIP_NOPS
to not expose an IV that evolves in a trapping type.

For example the following would fix it:

diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index 57bac06242f..2cae2528e41 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -775,6 +775,9 @@ split_constant_offset_1 (tree type, tree op0, enum
tree_code code, tree op1,

 case PLUS_EXPR:
 case MINUS_EXPR:
+  if (TYPE_OVERFLOW_TRAPS (type))
+   return false;
+
   split_constant_offset (op0, &var0, &off0, &op0_range, cache, limit);
   split_constant_offset (op1, &var1, &off1, &op1_range, cache, limit);
   *off = size_binop (code, off0, off1);
@@ -785,7 +788,7 @@ split_constant_offset_1 (tree type, tree op0, enum
tree_code code, tree op1,
   return true;

 case MULT_EXPR:
-  if (TREE_CODE (op1) != INTEGER_CST)
+  if (TREE_CODE (op1) != INTEGER_CST || TYPE_OVERFLOW_TRAPS (type))
return false;

   split_constant_offset (op0, &var0, &off0, &op0_range, cache, limit);

of course (after more work already done), compute_distributive_range could
return false itself.

Richard?

[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10

[vvinayag at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757

vvinayag at arm dot com changed:

   What|Removed |Added

 CC||vvinayag at arm dot com

--- Comment #14 from vvinayag at arm dot com ---
(In reply to Christophe Lyon from comment #12)
> Yes, I've been working on it for a while, it's proving to be a bit tricky
> when switching to HImode as suggested by Richard. I have something working,
> now checking I haven't broken Neon.

Hi Christophe, if you are working on this, just wondering whether we are close
to getting a patch for this, thank you.

[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

[rsandifo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Maybe it's much of a muchness, but would it work instead to bail
out for wrapping types at the top of split_constant_offset_1
and remove the check for trapping from the CASE_CONVERT code?
It seems that in practice split_constant_offset_1 can't handle
any trapping types.

[Bug target/102375] [aarch64] Should allow space in target attribute

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

--- Comment #10 from Jonathan Wakely  ---
You can also use string literal concatenation:

target("foo," "bar," "baz") which is identical to target("foo,bar,baz")

Although target("foo", "bar", "baz") seems easier to read anyway.

[Bug middle-end/64888] ubsan doesn't work with openmp

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Created attachment 51636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51636&action=edit
gcc12-pr64888.patch

Untested fix.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #5 from Martin Liška  ---
And reduced test-case looks like this:

struct Plane {
  using T = float;
  T *Row();
};
using ImageF = Plane;
long long Mirror_x;
struct EnsurePaddingInPlaceRowByRow {
  void Process() {
switch (strategy_) {
case kSlow:
  float *row = img_.Row();
  long long xsize = x1_;
  while (Mirror_x >= xsize)
if (Mirror_x)
  Mirror_x = 2 * xsize - 1;
  *row = Mirror_x;
}
  }
  ImageF img_;
  unsigned x1_;
  enum { kSlow } strategy_;
};
void FinalizeImageRect() {
  EnsurePaddingInPlaceRowByRow ensure_padding;
  ensure_padding.Process();
}

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Martin Liška  ---
Closing as fixed.

[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 20 Oct 2021, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853
> 
> --- Comment #2 from rsandifo at gcc dot gnu.org  
> ---
> Maybe it's much of a muchness, but would it work instead to bail
> out for wrapping types at the top of split_constant_offset_1
> and remove the check for trapping from the CASE_CONVERT code?
> It seems that in practice split_constant_offset_1 can't handle
> any trapping types.

Yeah, that makes sense.

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #21 from Martin Liška  ---
(In reply to Richard Biener from comment #12)
> (In reply to Martin Liška from comment #10)
> > (In reply to Richard Biener from comment #9)
> > > (In reply to Martin Liška from comment #8)
> > > > Using x86_64 compiler, the issue is fixed on master after
> > > > r10-1420-g744fd446c321f78f and started with r9-6384-g1a438d160e1dc845.
> > > 
> > > Can you continue searching for a fix with -fdisable-tree-fre4 (r10-1420
> > > added FRE4 before DOM3).
> > 
> > Sure, then it gets fixed with r11-408-g84935c9822183ce4.
> 
> -fno-tree-sink?

This is fixed with r11-4637-gf5e18dd9c7dacc96.

[Bug c++/102855] #pragma GCC unroll n should support n being a template parameter

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102855

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-20
   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10

[clyon at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757

--- Comment #15 from Christophe Lyon  ---
Hi, yes this is close to completion.
The patch series was approved last week by Richard Sandiford:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581778.html

but I have found a bug with more validations, I'm discussing the fix with him,
should be ready shortly.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

[herrtimson at yahoo dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #7 from tt_1  ---
hey, thanks for the messages. I just finished to compile firefox with patched
cross-gcc-10.3.0, the ice is fixed with the patch from
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=74dc179a6da33cd00f6d4a93fbb97dc84f610126
applied to it. 

So can you please tell me if this has already been backported to the gcc-10
branch? I just browsed through the git dirs, and I'm not certain. Also no hint
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92807 that its been fixed for
the gcc-10 branch. 

Is it queued to be backported? Sorry if I'm asking dumb questions, I'm just a
regular user, not a gentoo dev.

[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102854

--- Comment #1 from Tobias Burnus  ---
For the non-template case (with int / IndexType reversed, (ups!)):

finish_omp_for's vec *orig_inits is an empty vector

but for the template, it isn't (it contains '0' and 'i'); thus, the following
check is run and fails:

  FOR_EACH_VEC_ELT (*orig_inits, i, orig_init)
if (orig_init
&& !c_omp_check_loop_iv_exprs (locus,

The reason is that  type_dependent_expression_p (decl) == true in
cp_parser_omp_for_loop_init.

[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:ac5e46563817f4f1bd786be1d21b85d18e61bc0c

commit r12-4558-gac5e46563817f4f1bd786be1d21b85d18e61bc0c
Author: Richard Biener 
Date:   Wed Oct 20 12:54:59 2021 +0200

tree-optimization/102853 - avoid trapping types in split_constant_offset

This avoids running into the assert in compute_distributive_range when
starting the analysis with operations in a trapping type.

2021-10-20  Richard Biener  

PR tree-optimization/102853
* tree-data-ref.c (split_constant_offset_1): Bail out
immediately if the expression traps on overflow.

[Bug tree-optimization/102853] [12 Regression] ICE in compute_distributive_range, at tree-data-ref.c:593 since r12-4398-g9b2ad21ab3ebc21a3408108327fa1a7cbedaf217

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102853

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #8 from Martin Liška  ---
(In reply to tt_1 from comment #7)
> hey, thanks for the messages. I just finished to compile firefox with
> patched cross-gcc-10.3.0, the ice is fixed with the patch from
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=74dc179a6da33cd00f6d4a93fbb97dc84f610126 applied to it. 

Great!

> 
> So can you please tell me if this has already been backported to the gcc-10
> branch?

No, it wasn't.

> I just browsed through the git dirs, and I'm not certain. Also no
> hint in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92807 that its been
> fixed for the gcc-10 branch. 
> 
> Is it queued to be backported?

Apparently, the commit does not fix a regression so the author decided not to
backport it.

So I would recommend updating to GCC 11.2.0, which is the latest support
release.

> Sorry if I'm asking dumb questions, I'm just
> a regular user, not a gentoo dev.

No, your questions are very reasonable and we thank you reporting the issue you
deal with.

[Bug target/102856] New: [nvptx] Misaligned accesses with cheap vectorization enabled

[jules at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102856

Bug ID: 102856
   Summary: [nvptx] Misaligned accesses with cheap vectorization
enabled
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jules at gcc dot gnu.org
  Target Milestone: ---

Since revision 2b8453c401b699ed93c085d0413ab4b5030bcdb8 I am seeing several
OpenMP tests fail with misaligned access errors:

PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-11.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-12.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-16.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-3.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-5.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-6.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-9.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-11.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-12.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-16.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-3.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-5.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-6.c
execution test
PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-9.c
execution test

These look like, e.g.:

$ ./for-11.exe 

libgomp: cuCtxSynchronize error: misaligned address

libgomp: cuMemFree_v2 error: misaligned address

libgomp: device finalization failed

I suspect the reason is that an operation that is now being vectorized (e.g.
"st.v2.u64 [%frame], %r28;") requires higher alignment than the original scalar
accesses it replaces.

I haven't spotted an obvious culprit for the problem in the nvptx backend. This
is OpenMP, so it could be the soft stack handling -- or it could be something
else.

[Bug testsuite/102841] [12 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs

[ro at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102841

Rainer Orth  changed:

   What|Removed |Added

Summary|libgomp.oacc-c++/../libgomp |[12 regression]
   |.oacc-c-c++-common/host_dat |libgomp.oacc-c++/../libgomp
   |a-7.c FAILs |.oacc-c-c++-common/host_dat
   ||a-7.c FAILs
 Target|i?86-pc-solaris2.11,|*-*-solaris2.11,
   |x86_64-pc-solaris2.11,  |i?86-apple-darwin*,
   |i?86-apple-darwin*, |x86_64-apple-darwin*
   |x86_64-apple-darwin*|

--- Comment #2 from Rainer Orth  ---
(In reply to Thomas Schwinge from comment #1)

> (In reply to Rainer Orth from comment #0)
> > The libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c has been
> > FAILing
> > on Solaris and Darwin since it was installed.
> 
> Probably not since it was originally added in commit
> d5c23c6ceacf666f218676b648801379044e326a 'OpenACC – support "if" +
> "if_present" clauses with "host_data"', but rather in my more recentish
> commit 11b8286a83289f5b54e813f14ff56d730c3f3185 "[OpenACC privatization]
> Largely extend diagnostics and corresponding testsuite coverage [PR90115]". 
> (Or, if it indeed has been FAILing before, then it must be a different
> problem.)

Right, I didn't look closely enough.  In fact, the test is PASSing on the
gcc-11 branch,so this is even a regression.

Besides, it affects Solaris/SPARC and x86 alike, so is not x86-specific.

> > On Solaris, the excess errors are
> 
> > [...]: note: variable 'iftmp.3' declared in block isn't candidate for 
> > adjusting OpenACC privatization level: not addressable
> 
> > while Darwin shows
> 
> > [...]: note: variable 'D.3648' declared in block isn't candidate for 
> > adjusting OpenACC privatization level: not addressable
> 
> Please do tell if there are further such "[is/isn't] candidate for adjusting
> OpenACC privatization level" diagnostic mismatches (excess errors, or
> FAILs), in other testcases.  (But indeed per a quick scan of
>  posts, it's just
> 'libgomp.oacc-c-c++-common/host_data-7.c', and it PASSed before my
> "diagnostics" commit.)

No, this is the only instance.

[Bug target/100966] [AArch64] __builtin_roundeven[f] is not inlined

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100966

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:16ce822ed14e6635ee2ffcba394bba8e934bc6dd

commit r12-4567-g16ce822ed14e6635ee2ffcba394bba8e934bc6dd
Author: Wilco Dijkstra 
Date:   Wed Oct 20 13:09:30 2021 +0100

AArch64: Add support for __builtin_roundeven[f] (PR100966)

Enable __builtin_roundeven[f] by changing existing frintn to roundeven.

2021-10-20  Wilco Dijkstra  

gcc/
PR target/100966
* config/aarch64/aarch64.md (frint_pattern): Update comment.
* config/aarch64/aarch64-simd-builtins.def: Change frintn to
roundeven.
* config/aarch64/arm_fp16.h: Change frintn to roundeven.
* config/aarch64/arm_neon.h: Likewise.
* config/aarch64/iterators.md (frint_pattern): Use roundeven for
FRINTN.

gcc/testsuite/
PR target/100966
* gcc.target/aarch64/frint.x: Add roundeven tests.
* gcc.target/aarch64/frint_double.c: Likewise.
* gcc.target/aarch64/frint_float.c: Likewise.

[Bug middle-end/102857] New: [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c

[clyon at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857

Bug ID: 102857
   Summary: [12 regression] r12-4526 caused regressions on
vect/bb-slp-16.c and ssa-dom-thread-7.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

r12-4526 (g:d8edfadfc7a9795b65177a50ce44fd348858e844) caused regressions.

On aarch64 and arm-none-linux-gnueabihf with-arch armv7-a+mp+sec+neon-fp16
FAIL: gcc.dg/vect/bb-slp-16.c execution test

On both aarch64/arm
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps
threaded: 12"

On arm-none-linux-gnueabihf --with-arch armv7-a+mp+sec+neon-fp16
FAIL: gcc.target/arm/ivopts-4.c object-size text <= 36

The last one is very fragile and depends on the actual target/flags.

[Bug target/100966] [AArch64] __builtin_roundeven[f] is not inlined

[wilco at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100966

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #2 from Wilco  ---
Fixed

[Bug target/102375] [aarch64] Should allow space in target attribute

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

--- Comment #11 from Jakub Jelinek  ---
BTW, if we want to use strip_whitespaces, it should use ISBLANK or ISSPACE
instead of using == ' ' or == '\t' etc. comparisons.
But I really find it not a good idea to support "\t\t+sve\t\t 
"
(or similarly on x86).

[Bug target/102375] [aarch64] Should allow space in target attribute

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Martin Liška  ---
All right, let me revert my patches then..

[Bug tree-optimization/102844] [9/10/11/12 Regression] DOM jump threading not copying block that became non-empty

[amacleod at redhat dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #22 from Andrew Macleod  ---
(In reply to Richard Biener from comment #20)
> (In reply to Aldy Hernandez from comment #18)
> > (In reply to rguent...@suse.de from comment #17)
> > > On Wed, 20 Oct 2021, aldyh at gcc dot gnu.org wrote:
> > 
> > > > Silly question, why is the SSA form invalid on entry to VRP2?  That's 
> > > > just
> > > > asking for trouble.  Is this related to how asserts work?
> > > 
> > > Well, DOM threading creates invalid SSA (definition not dominating use).
> > > Doesn't have to do anything with VRP or asserts.
> > 
> > Ah, I see.
> > 
> > BTW, if this is still the case in mainline, this is bound to be a problem
> > for the ranger.  Andrew, won't we get an UNDEFINED / unreachable if we query
> > the non dominating use at this point?
> 
> Well, invalid IL is invalid - there's no need to "cope" with it.  We have to
> fix the (forward) threading code.

Indeed, invalid is invalid.

And it depends. Any on-entry range is the union of all incoming blocks. If we
query a use that has no def anywhere in the dominator tree , then you will get
UNDEFINED. If the def is on at least one incoming path, then you will get the
def or some derivative of it.

[Bug target/102374] [x86_64] Should ignore spaces in target attribute

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102374

Martin Liška  changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

--- Comment #4 from Martin Liška  ---
Reverted based on the discussion in PR102375.

[Bug c++/91118] ubsan does not work with openmp default (none) directive

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91118

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/98005] FAIL: std/ranges/adaptors/sizeof.cc (test for excess errors)

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98005

--- Comment #7 from Patrick Palka  ---
Looks like after r12-4517 the test now compiles successfully on m68k according
to

  https://gcc.gnu.org/pipermail/gcc-testresults/2021-October/729689.html

Though the test presumably still fails on the 11 branch.

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838

--- Comment #5 from Jakub Jelinek  ---
Does the committed patch fix the issue on Solaris?

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Jakub Jelinek  ---
> Does the committed patch fix the issue on Solaris?

I'll see after tonight's bootstrap.  The original one attached to the PR
fixed only a few of the failures:

-FAIL: libgomp.c/../libgomp.c-c++-common/for-1.c execution test

-FAIL: libgomp.c/../libgomp.c-c++-common/for-2.c execution test

-FAIL: libgomp.c/../libgomp.c-c++-common/for-7.c execution test
-FAIL: libgomp.c/../libgomp.c-c++-common/for-8.c execution test

[Bug middle-end/102857] [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs

[gaiusmod2 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344

--- Comment #3 from Gaius Mulley  ---
"ro at gcc dot gnu.org"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344
>
> Bug ID: 102344
>Summary: gm2/pim/fail/TestLong4.mod FAILs
>Product: gcc
>Version: 12.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: modula2
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: ro at gcc dot gnu.org
> CC: gaiusmod2 at gmail dot com
>   Target Milestone: ---
>
> The gm2/pim/fail/TestLong4.mod test FAILs everywhere, it seems (seen on
> i386-pc-solaris2.11 and x86_64-pc-linux-gnu, both 32 and 64-bit):
>
> FAIL: gm2/pim/fail/TestLong4.mod,  -g  
> FAIL: gm2/pim/fail/TestLong4.mod,  -O  
> FAIL: gm2/pim/fail/TestLong4.mod,  -O -g  
> FAIL: gm2/pim/fail/TestLong4.mod,  -Os  
> FAIL: gm2/pim/fail/TestLong4.mod,  -O3 -fomit-frame-pointer  
> FAIL: gm2/pim/fail/TestLong4.mod,  -O3 -fomit-frame-pointer -finline-functions
>
> The test is expected to FAIL, it seems, but actually compilation completes
> without error.  So this should actually be an XPASS instead.

apologies if this is the wrong way to mention a status change.  (Is this
done on bugzilla?  I've looked and cannot see how to change its status
:-).
I'd like to confirm the bug and report that it is now fixed (I believe) in the
git repro.  I've moved TestLong4.mod to the pass directory,

regards,
Gaius

regards,
Gaius

[Bug modula2/102339] gm2 testsuite leaves many files behind

[gaiusmod2 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339

--- Comment #2 from Gaius Mulley  ---
"ro at gcc dot gnu.org"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339
>
> Bug ID: 102339
>Summary: gm2 testsuite leaves many files behind
>Product: gcc
>Version: 12.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: modula2
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: ro at gcc dot gnu.org
> CC: gaiusmod2 at gmail dot com
>   Target Milestone: ---
>
> After running the gm2 testsuite, there are almost 2000 files left behind in
> gcc/testsuite/gm2.  All but a handful follow the same pattern, e.g.
>
> wr.x0-wr_m2.o
>
> I suspect this is a driver issue: m2-link-support.h has
>
> #define SCAFFOLDNAME "%b_m2"
>
> Since those files are purely temporary, I suspect (but haven't tried) that 
> they
> should be marked as such using %d.
>
> There are only a few more:
>
> * remaining objects:
>
> cpp.o
> cvararg.o
> fileio.o
> hello.o
> mycpp.o
> rangesupport.o
> sys.o
> testiotransfer.o
> wr.o
>
> * also:
>
> integer.x0-integer_m2.cpp
> integer.x1-integer_m2.cpp
> integer.x2-integer_m2.cpp
> integer.x3-integer_m2.cpp
> integer.x4-integer_m2.cpp
> integer.x5-integer_m2.cpp
>
> results.dat
>
> second.txt
>
> test.txt
>
> testiotransfer.x2*
> testiotransfer.x5*
> testtime.x3*

[again apologies if this is the wrong way to mention a status change.]

I'd like to confirm the bug and report that it is now fixed (I believe)
in the git repro.

regards,
Gaius

regards,
Gaius

[Bug modula2/102325] gm2 testsuite drivers should be unique

[gaiusmod2 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325

--- Comment #3 from Gaius Mulley  ---
"rguenth at gcc dot gnu.org"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325
>
> Richard Biener  changed:
>
>What|Removed |Added
> 
>Last reconfirmed||2021-09-14
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |NEW
>
> --- Comment #1 from Richard Biener  ---
> Confirmed.

[again apologies if this is the wrong way to mention a status change.]

now fixed in the git repro.

regards,
Gaius

regards,
Gaius

[Bug target/102847] [12 regression] r12-4504 breaks powerpc64 build on power 7

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102847

--- Comment #3 from seurer at gcc dot gnu.org ---
I reran my bisects on two different systems and both resolved to 

g:793d2549b173a0a2da6dd20ffc27acb9fd2de73e, r12-4501

as when the builds started failing.  r12-4500 worked on both systems.

[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Gaius Mulley  ---
> apologies if this is the wrong way to mention a status change.  (Is this
> done on bugzilla?  I've looked and cannot see how to change its status
> :-).

The customary way is to change the Status to CONFIRMED once you've
verified the report is correct.   Once you start working on a fix (or
intend to), assign the PR to yourself.  When the fix is done and has
been committed, change the Status to RESOLVED.  Please add a PR
reference for the fix to the ChangeLog entry as described in

https://gcc.gnu.org/codingconventions.html#ChangeLogs
e.g
PR modula2/102344

This way, the PR is automatically updated with a reference to the commit.

> I'd like to confirm the bug and report that it is now fixed (I believe) in the
> git repro.  I've moved TestLong4.mod to the pass directory,

Thanks.  I'll try another build of the branch once I get around to it.

[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs

[dje at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102344

David Edelsohn  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||dje at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from David Edelsohn  ---
Gaius reports fixed.

[Bug modula2/102339] gm2 testsuite leaves many files behind

[dje at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102339

David Edelsohn  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||dje at gcc dot gnu.org

--- Comment #3 from David Edelsohn  ---
Gaius reports fixed.

[Bug modula2/102323] gm2 testsuite needs to be parallelized

[dje at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102323

David Edelsohn  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||dje at gcc dot gnu.org

--- Comment #2 from David Edelsohn  ---
Gaius reports fixed.

[Bug modula2/102325] gm2 testsuite drivers should be unique

[dje at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325

David Edelsohn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dje at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from David Edelsohn  ---
Gaius reports fixed.

[Bug c++/102858] New: ICE when compiling to "thread.gcm"

[niancw29 at 163 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102858

Bug ID: 102858
   Summary: ICE when compiling  to "thread.gcm"
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niancw29 at 163 dot com
  Target Milestone: ---

Created attachment 51637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51637&action=edit
preprocessed file

Target: x86_64-pc-linux-gnu
Configured with: ../gcc-11.2.0/configure --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC) 

command: g++ -std=c++20 -fmodules-ts -c -x c++-system-header thread
the compiler output: 

In file included from /usr/local/include/c++/11.2.0/bits/atomic_base.h:38,
 from /usr/local/include/c++/11.2.0/atomic:41,
of module /usr/local/include/c++/11.2.0/atomic, imported at
/usr/local/include/c++/11.2.0/stop_token:34,
included from /usr/local/include/c++/11.2.0/thread:40:
/usr/local/include/c++/11.2.0/bits/move.h: In instantiation of ‘constexpr
std::_Require >,
std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&,
_Tp&) [with _Tp = std::thread::id;
std::_Require >,
std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > = void]’:
/usr/local/include/c++/11.2.0/bits/std_thread.h:172:16:   required from here
/usr/local/include/c++/11.2.0/bits/move.h:204:19: internal compiler error: in
tsubst_copy, at cp/pt.c:16621
  204 |   _Tp __tmp = _GLIBCXX_MOVE(__a);
  |   ^
0x62699c tsubst_copy
../../gcc-11.2.0/gcc/cp/pt.c:16621
0x7c15ce tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-11.2.0/gcc/cp/pt.c:20782
0x7c1dbb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-11.2.0/gcc/cp/pt.c:19548
0x7c1dbb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-11.2.0/gcc/cp/pt.c:19680
0x7c19bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-11.2.0/gcc/cp/pt.c:19548
0x7c19bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-11.2.0/gcc/cp/pt.c:20206
0x7d3124 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-11.2.0/gcc/cp/pt.c:19548
0x7d3124 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:19159
0x7d923c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:16527
0x7d923c tsubst_init
../../gcc-11.2.0/gcc/cp/pt.c:16531
0x7d6121 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:18368
0x7d4d6a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:18184
0x7d4d6a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:18199
0x7d3c5f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:18184
0x7d3c5f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:18550
0x7c7749 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-11.2.0/gcc/cp/pt.c:25876
0x7c7749 instantiate_body
../../gcc-11.2.0/gcc/cp/pt.c:25876
0x7c809f instantiate_decl(tree_node*, bool, bool)
../../gcc-11.2.0/gcc/cp/pt.c:26170
0x7e3cfb instantiate_pending_templates(int)
../../gcc-11.2.0/gcc/cp/pt.c:26249
0x6f5fa8 c_parse_final_cleanups()
../../gcc-11.2.0/gcc/cp/decl2.c:4962

[Bug c++/102820] [DR2351] Failure to compile void{}

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 51638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51638&action=edit
gcc12-pr102820.patch

Untested fix.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

[herrtimson at yahoo dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102842

--- Comment #9 from tt_1  ---
So, I did a little bit of research. pr92807 has indeed been backported to the
gcc-10 branch and is included in the gcc-10.3.0 release - it touches
gcc/config/i386/i386.c and adds a testcase. 

There is another fixup on top of that, which is the real fix the here reported
ICE:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=74dc179a6da33cd00f6d4a93fbb97dc84f610126
or r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126 , to which you pointed me
as the most likely fix. But that fixup (commited by Vladimir Makarov) doesn't
have any bug number in the description. I wrote him an email, maybe he will
comment here later.

Hint: its not an option to upgrade to gcc-11.2.0, since the cross compile
bootstrap is fundamentally broken by missing fenv header in the gcc-11 branch.
Mixing up host and target compiler versions is nothing to desire, its a place
where there will be dragons.

[Bug c++/102858] ICE when compiling to "thread.gcm"

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102858

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
This is a duplicate.

*** This bug has been marked as a duplicate of bug 99244 ***

[Bug c++/99244] [modules] ICE in tsubst_copy, at cp/pt.c:16581

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99244

Jonathan Wakely  changed:

   What|Removed |Added

 CC||niancw29 at 163 dot com

--- Comment #1 from Jonathan Wakely  ---
*** Bug 102858 has been marked as a duplicate of this bug. ***

[Bug c++/99244] [modules] ICE in tsubst_copy, at cp/pt.c:16581

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99244

--- Comment #2 from Jonathan Wakely  ---
This seems to be fixed on trunk.

[Bug c++/99244] [modules] ICE in tsubst_copy, at cp/pt.c:16581

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99244

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-20
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> This seems to be fixed on trunk.

Oops, no it isn't.

[Bug tree-optimization/102844] [9/10/11/12 Regression] DOM jump threading not copying block that became non-empty

[law at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844

--- Comment #23 from Jeffrey A. Law  ---
Invalid is invalid.  Full stop.

I'll have to put it under a debugger, but I would have expected the nocopy
block to turn into a forwarder -- why do we end up putting statements in here?

[Bug libgomp/100753] Implement in_reduction clause on target construct

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100753

--- Comment #3 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #2)
> Additionally missing: Fortran support.
Fortran support was implemented in
r12-4574-gd98626bf451dea6a28a42d953f7d0bd7659ad4d5

Still to do: Proper nowait support as described above.

[Bug fortran/102859] New: [OpenMP] Missing testsuite coverage for Fortran task reductions

[burnus at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102859

Bug ID: 102859
   Summary: [OpenMP] Missing testsuite coverage for Fortran task
reductions
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

From: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579694.html for
PR100753 (Fortran part), follow up was
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582015.html (committed)
– that added some lightweight test coverage, but still:

> If this was missing, then I'm afraid we lack a lot of testsuite coverage for
> Fortran task reductions.  It doesn't need to be covered in this patch, but 
> would be
> good to cover it incrementally.  Because the above means nothing with
> taskgroup with task_reduction clause(s) could work properly at runtime.

Additionally missing: Array sections in reductions appear to be still
not supported by the Fortran FE in general → testcase (for target in_reduction
and in general).

[Bug target/102860] New: [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860

Bug ID: 102860
   Summary: [12 regression] libgomp.fortran/simd2.f90 ICEs after
r12-4526
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d8edfadfc7a9795b65177a50ce44fd348858e844, r12-4526

I am only seeing this on a power 10 machine.

make  -k check-target-libgomp
RUNTESTFLAGS="fortran.exp=libgomp.fortran/simd2.f90"
FAIL: libgomp.fortran/simd2.f90   -O2  (internal compiler error)
FAIL: libgomp.fortran/simd2.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/simd2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: libgomp.fortran/simd2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/simd2.f90   -O3 -g  (internal compiler error)
FAIL: libgomp.fortran/simd2.f90   -O3 -g  (test for excess errors)
# of expected passes6
# of unexpected failures6
# of unresolved testcases   3


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.fortran/simd2.f90
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-fintrinsic-modules-path=/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libquadmath/.libs/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs
-lgfortran -foffload=-lgfortran -lquadmath -lm -o ./simd2.exe
during RTL pass: expand
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.fortran/simd2.f90:11:30:
internal compiler error: in prepare_cmp_insn, at optabs.c:4532
0x10ad438b prepare_cmp_insn
/home/seurer/gcc/git/gcc-test/gcc/optabs.c:4532
0x10ad4507 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
/home/seurer/gcc/git/gcc-test/gcc/optabs.c:4677
0x106346a7 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
/home/seurer/gcc/git/gcc-test/gcc/dojump.c:1220
0x10712eff do_cmp_and_jump
/home/seurer/gcc/git/gcc-test/gcc/expmed.c:6346
0x10712eff expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
/home/seurer/gcc/git/gcc-test/gcc/expmed.c:4865
0x10716dbb expand_expr_divmod
/home/seurer/gcc/git/gcc-test/gcc/expr.c:8945
0x1074094b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/seurer/gcc/git/gcc-test/gcc/expr.c:9582
0x105686a7 expand_gimple_stmt_1
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:3979
0x105686a7 expand_gimple_stmt
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:4040
0x105717db expand_gimple_basic_block
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6082
0x1057476b execute
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6808


commit d8edfadfc7a9795b65177a50ce44fd348858e844 (HEAD, refs/bisect/bad)
Author: Aldy Hernandez 
Date:   Mon Oct 4 09:47:02 2021 +0200

Disallow loop rotation and loop header crossing in jump threaders.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486

--- Comment #71 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #70)
> Tentatively fixed, reopen if not.

The bootstrap works.

Thank you.

[Bug testsuite/102861] New: [12 regression] gcc.dg/vect/bb-slp-16.c fails after r12-4526

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861

Bug ID: 102861
   Summary: [12 regression] gcc.dg/vect/bb-slp-16.c fails after
r12-4526
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d8edfadfc7a9795b65177a50ce44fd348858e844, r12-4526

make  -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-16.c"
FAIL: gcc.dg/vect/bb-slp-16.c execution test
# of expected passes5
# of unexpected failures1


No messages from the failure:

Running /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp ...
FAIL: gcc.dg/vect/bb-slp-16.c execution test

=== gcc Summary ===

# of expected passes5
# of unexpected failures1


Hmmm.  Looks like this used to be xfailed.

commit d8edfadfc7a9795b65177a50ce44fd348858e844 (HEAD, refs/bisect/bad)
Author: Aldy Hernandez 
Date:   Mon Oct 4 09:47:02 2021 +0200

Disallow loop rotation and loop header crossing in jump threaders.

[Bug target/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860

--- Comment #1 from Aldy Hernandez  ---
The referenced patch reduces the amount of threaded paths, not increase them. 
This actually looks like another pass hiccuping because it was expecting a
threaded path that is no longer there.

[Bug testsuite/102861] [12 regression] gcc.dg/vect/bb-slp-16.c fails after r12-4526

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861

--- Comment #1 from Aldy Hernandez  ---
Similarly to 102860.

The referenced patch reduces the amount of threaded paths, not increase them. 
This actually looks like another pass hiccuping because it was expecting a
threaded path that is no longer there.

[Bug fortran/102815] gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb

[clyon at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815

Christophe Lyon  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Christophe Lyon  ---
I confirm it is now fixed, thanks!

[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703

--- Comment #16 from Andrew Pinski  ---
I have a new patch in testing that replaces patch 4 and uses
simple_dce_from_worklist instead which moves of the detection of dead code to
already common code.