date:20231123

[Bug c++/112619] [14 regression] ICE when building libcrafter (tree check: expected statement_list, have modify_expr in tsi_start, at tree-iterator.h:57) since r14-5086-gae07265381d934

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

https://gcc.gnu.org/g:1c44bd92a86db3fcdeb4a66ce2f3222d13af0681

commit r14-5814-g1c44bd92a86db3fcdeb4a66ce2f3222d13af0681
Author: Jakub Jelinek 
Date:   Fri Nov 24 08:44:28 2023 +0100

tree: Fix up try_catch_may_fallthru [PR112619]

The following testcase ICEs with -std=c++98 since r14-5086 because
block_may_fallthru is called on a TRY_CATCH_EXPR whose second operand
is a MODIFY_EXPR rather than STATEMENT_LIST, which try_catch_may_fallthru
apparently expects.
I've been wondering whether that isn't some kind of FE bug and whether
there isn't some unwritten rule that second operand of TRY_CATCH_EXPR
must be a STATEMENT_LIST.  Looking at the FEs, the C++ FE uses mostly its
own trees, TRY_BLOCK (TRY_CATCH_EXPR replacement) with HANDLER in it
(CATCH_EXPR
replacement) - but HANDLER can be immediate second operand rather than
nested
in STATEMENT_LIST, EH_SPEC_BLOCK (this one stands for both TRY_CATCH_EXPR
and EH_FILTER_EXPR in its second argument); both of these are only replaced
by the generic trees during gimplification though, so will unlikely be seen
by block_may_fallthru; and then CLEANUP_STMT, which is genericized
into TRY_CATCH_EXPR with non-CATCH_EXPR/EH_FILTER_EXPR in its body (this is
the one that causes the ICE on this testcase).
The Go and Rust FEs create TRY_CATCH_EXPR with CATCH_EXPR immediately in
its
second argument (but either are unlucky that block_may_fallthru isn't
called
or the body can always fallthru, or latent ICE), while the D FE most likely
hit this ICE and attempts to work around it, by checking at TRY_CATCH_EXPR
creation time if the second argument from pop_stmt_list is STATEMENT_LIST
and
if not, forcefully wraps it into a STATEMENT_LIST.

Unfortunately, I don't see an easy way to create an artificial tree
iterator
from just a single tree statement, so the patch duplicates what the loops
later do (after all, it is very simple, just didn't want to duplicate
also the large comments explaning it, so the 3 See below. comments).

2023-11-24  Jakub Jelinek  

PR c++/112619
* tree.cc (try_catch_may_fallthru): If second operand of
TRY_CATCH_EXPR is not a STATEMENT_LIST, handle it as if it was a
STATEMENT_LIST containing a single statement.

* g++.dg/eh/pr112619.C: New test.

[Bug debug/112674] [14 Regression] Compare-debug failure after recent change on c6x

2023-11-23 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/112690] [14 Regression] gcc.dg/Wstringop-overflow-17.c failure

2023-11-23 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

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

[Bug middle-end/112344] [14 Regression] Wrong code at -O2 on x86_64-pc-linux-gnu

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r14-5813-ga7d82b45edeed99a850595eee0e59d16c4df7aff
Author: Richard Biener 
Date:   Thu Nov 23 09:49:59 2023 +0100

tree-optimization/112344 - relax final value-replacement fix

The following tries to reduce the number of cases we use an unsigned
type for the addition when we know the original signed increment was
OK which is when the total unsigned increment computed fits the signed
type as well.

This fixes the observed testsuite fallout.

PR tree-optimization/112344
* tree-chrec.cc (chrec_apply): Only use an unsigned add
when the overall increment doesn't fit the signed type.

[Bug middle-end/112336] fsanitize=address vs _BitInt with a non-mode size (smaller than max mode size)

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||iamanonymous.cs at gmail dot 
com

--- Comment #7 from Andrew Pinski  ---
*** Bug 112695 has been marked as a duplicate of this bug. ***

[Bug target/112695] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -fsanitize=address -c

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed already.  Dup.

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

[Bug middle-end/112336] fsanitize=address vs _BitInt with a non-mode size (smaller than max mode size)

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/112695] New: ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -fsanitize=address -c

2023-11-23 Thread iamanonymous.cs at gmail dot com via Gcc-bugs

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

Bug ID: 112695
   Summary: ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with
-fsanitize=address -c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311021000/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311021000/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311021000
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231102 (experimental) (GCC)

git version: d508a94167c186b2baacc679896e2809554c0b99
***
Program:
$ cat prog.c
_BitInt(33) b33_v;

***
Command Lines:
$ gcc -fsanitize=address -c mutant.c
mutant.c:1:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1208
1 | _BitInt(33) b33_v;
  | ^~~
0x7658cf gen_reg_rtx(machine_mode)
../../gcc/gcc/emit-rtl.cc:1208
0xe9398d maybe_legitimize_operand
../../gcc/gcc/optabs.cc:8044
0xe9398d maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../gcc/gcc/optabs.cc:8199
0xe8ff69 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.cc:8218
0xe99068 expand_binop_directly
../../gcc/gcc/optabs.cc:1457
0xe97460 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../gcc/gcc/optabs.cc:1544
0xbd0f6d expand_shift_1
../../gcc/gcc/expmed.cc:2675
0xbd5359 expand_shift(tree_code, machine_mode, rtx_def*, poly_int<1u, long>,
rtx_def*, int)
../../gcc/gcc/expmed.cc:2701
0xbfb376 reduce_to_bit_field_precision
../../gcc/gcc/expr.cc:12252
0xbf200f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.cc:11005
0xbfb85e expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc/gcc/expr.h:310
0xbfb85e expand_expr_addr_expr_1
../../gcc/gcc/expr.cc:8728
0xbfbed7 expand_expr_addr_expr
../../gcc/gcc/expr.cc:8849
0xbf08ff expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.cc:12163
0x13876bb expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc/gcc/expr.h:310
0x13876bb output_constant
../../gcc/gcc/varasm.cc:5261
0x13863d2 output_constructor_regular_field
../../gcc/gcc/varasm.cc:5612
0x13863d2 output_constructor
../../gcc/gcc/varasm.cc:5878
0x13863d2 output_constructor_regular_field
../../gcc/gcc/varasm.cc:5612
0x13863d2 output_constructor
../../gcc/gcc/varasm.cc:5878
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/112694] RISC-V: zve64d testing expose many ICE on C/C++ testing

2023-11-23 Thread juzhe.zhong at rivai dot ai via Gcc-bugs

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

--- Comment #2 from JuzheZhong  ---
(In reply to Andrew Pinski from comment #1)
> I am going to do a similar testing with -march=armv9-a+sve on aarch64 to see
> if there is similar ones for the vectorizer.

No, I think ARM SVE won't have those issues since their minimum VLEN of ARM SVE
is 128bit.

For RVV, when minimum VLEN is 128bit, all bugs (execution and ICE) are all
fixed.

This PR is bugs when minimum VLEN = 64bit which never happens on ARM SVE.

[Bug tree-optimization/112694] RISC-V: zve64d testing expose many ICE on C/C++ testing

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||riscv

--- Comment #1 from Andrew Pinski  ---
I am going to do a similar testing with -march=armv9-a+sve on aarch64 to see if
there is similar ones for the vectorizer.

[Bug c/112694] New: RISC-V: zve64d testing expose many ICE on C/C++ testing

2023-11-23 Thread juzhe.zhong at rivai dot ai via Gcc-bugs

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

Bug ID: 112694
   Summary: RISC-V: zve64d testing expose many ICE on C/C++
testing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

--with-arch=rv32gc_zve64d_zvfh_zfh --with-abi=ilp32d:

FAIL: gcc.target/riscv/rvv/autovec/binop/vmul-zvfh-run.c (internal compiler
error: in vectorizable_store, at tree-vect-stmts.cc:9314)
FAIL: gcc.target/riscv/rvv/autovec/binop/vmul-zvfh-run.c (internal compiler
error: in vectorizable_store, at tree-vect-stmts.cc:9314)
FAIL: gcc.target/riscv/rvv/autovec/binop/vmul-zvfh-run.c (test for excess
errors)
FAIL: gcc.target/riscv/rvv/autovec/binop/vmul-zvfh-run.c (test for excess
errors)

--with-arch=rv64gc_zve64d_zvfh_zfh --with-abi=lp64d:

FAIL: g++.dg/vect/pr33834_2.cc  -std=c++14 (internal compiler error: in
vectorizable_store, at tree-vect-stmts.cc:9314)
FAIL: g++.dg/vect/pr33834_2.cc  -std=c++14 (test for excess errors)
FAIL: g++.dg/vect/pr33834_2.cc  -std=c++17 (internal compiler error: in
vectorizable_store, at tree-vect-stmts.cc:9314)
FAIL: g++.dg/vect/pr33834_2.cc  -std=c++17 (test for excess errors)
FAIL: g++.dg/vect/pr33834_2.cc  -std=c++20 (internal compiler error: in
vectorizable_store, at tree-vect-stmts.cc:9314)
FAIL: g++.dg/vect/pr33834_2.cc  -std=c++20 (test for excess errors)
FAIL: g++.dg/vect/pr33834_2.cc  -std=c++98 (internal compiler error: in
vectorizable_store, at tree-vect-stmts.cc:9314)
FAIL: g++.dg/vect/pr33834_2.cc  -std=c++98 (test for excess errors)
FAIL: g++.dg/vect/pr37174.cc  -std=c++14 (internal compiler error: in
SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: g++.dg/vect/pr37174.cc  -std=c++14 (test for excess errors)
FAIL: g++.dg/vect/pr37174.cc  -std=c++17 (internal compiler error: in
SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: g++.dg/vect/pr37174.cc  -std=c++17 (test for excess errors)
FAIL: g++.dg/vect/pr37174.cc  -std=c++20 (internal compiler error: in
SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: g++.dg/vect/pr37174.cc  -std=c++20 (test for excess errors)
FAIL: g++.dg/vect/pr37174.cc  -std=c++98 (internal compiler error: in
SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: g++.dg/vect/pr37174.cc  -std=c++98 (test for excess errors)
FAIL: g++.dg/vect/pr70726.cc  -std=c++14 (internal compiler error: Aborted)
FAIL: g++.dg/vect/pr70726.cc  -std=c++14 (test for excess errors)
FAIL: g++.dg/vect/pr70726.cc  -std=c++17 (internal compiler error: Segmentation
fault)
FAIL: g++.dg/vect/pr70726.cc  -std=c++17 (test for excess errors)
FAIL: g++.dg/vect/pr70726.cc  -std=c++20 (internal compiler error: Aborted)
FAIL: g++.dg/vect/pr70726.cc  -std=c++20 (test for excess errors)
FAIL: g++.dg/vect/pr70726.cc  -std=c++98 (internal compiler error: Segmentation
fault)
FAIL: g++.dg/vect/pr70726.cc  -std=c++98 (test for excess errors)
FAIL: g++.dg/vect/pr87621.cc  -std=c++14 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87621.cc  -std=c++14 (test for excess errors)
FAIL: g++.dg/vect/pr87621.cc  -std=c++17 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87621.cc  -std=c++17 (test for excess errors)
FAIL: g++.dg/vect/pr87621.cc  -std=c++20 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87621.cc  -std=c++20 (test for excess errors)
FAIL: g++.dg/vect/pr87621.cc  -std=c++98 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87621.cc  -std=c++98 (test for excess errors)
FAIL: g++.dg/vect/pr87914.cc  -std=c++14 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87914.cc  -std=c++14 (test for excess errors)
FAIL: g++.dg/vect/pr87914.cc  -std=c++17 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87914.cc  -std=c++17 (test for excess errors)
FAIL: g++.dg/vect/pr87914.cc  -std=c++20 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87914.cc  -std=c++20 (test for excess errors)
FAIL: g++.dg/vect/pr87914.cc  -std=c++98 (internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257)
FAIL: g++.dg/vect/pr87914.cc  -std=c++98 (test for excess errors)
FAIL: g++.dg/vect/pr95487.cc  -std=c++14 (internal compiler error: in
vectorizable_store, at tree-vect-stmts.cc:8979)
FAIL: g++.dg/vect/pr95487.cc  -std=c++14 (test for excess errors)
FAIL: g++.dg/vect/pr95487.cc  -std=c++17 (internal compiler error: in
vectorizable_store, at tree-vect-stmts.cc:8979)
FAIL: g++.dg/vect/pr95487.cc  -std=c++17 (test for excess errors)
FAIL:

[Bug target/112599] RISC-V regression testsuite errors with rv64gcv_zvl1024b

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-5812-gd83013b88b74d1f1f774d94ca950d3b6dba26e5d
Author: Juzhe-Zhong 
Date:   Fri Nov 24 07:18:00 2023 +0800

RISC-V: Optimize a special case of VLA SLP

When working on fixing bugs of zvl1024b. I notice a special VLA SLP case
can be better optimized.

v = vec_perm (op1, op2, { nunits - 1, nunits, nunits + 1, ... })

Before this patch, we are using genriec approach (vrgather):

vid
vadd.vx
vrgather
vmsgeu
vrgather

With this patch, we use vec_extract + slide1up:

scalar = vec_extract (last element of op1)
v = slide1up (op2, scalar)

Tested on zvl128b/zvl256b/zvl512b/zvl1024b of both RV32 and RV64 no
regression.

Ok for trunk ?

PR target/112599

gcc/ChangeLog:

* config/riscv/riscv-v.cc (shuffle_extract_and_slide1up_patterns):
New function.
(expand_vec_perm_const_1): Add new optimization.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr112599-2.c: New test.

[Bug tree-optimization/111457] [14 Regression] Dead Code Elimination Regression since r14-3407-g936a12331a2

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Andrew Pinski  ---
Looks like this one has been fixed.

[Bug tree-optimization/111292] [14 Regression] Missed Dead Code Elimination since r14-2228-g02460c0b8c9

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Looks like this has been fixed on the trunk ...

[Bug tree-optimization/111012] [14 Regression] Dead Code Elimination Regression at -O3 since r14-573-g69f1a8af45d

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Looks like this is fixed on the trunk ...

[Bug tree-optimization/111003] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2161-g237e83e2158

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #3 from Andrew Pinski  ---
This seems to be fixed on the trunk ...

[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #4 from Andrew Pinski  ---
Seems to be fixed on the trunk.

[Bug tree-optimization/110941] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2379-gc496d15954c

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #3 from Andrew Pinski  ---
This seems to be fixed now. We are able to optimize out the call to foo even in
evrp now too.

[Bug tree-optimization/110841] [14 Regression] Dead Code Elimination Regression since r14-2675-gef28aadad6e

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Looks to be fixed now.

[Bug tree-optimization/110450] [14 Regression] Dead Code Elimination Regression at -O2 since r14-261-g0ef3756adf0

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Looks to be fixed on the trunk.

[Bug tree-optimization/110327] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-4790-g4b3a325f07a

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||pinskia at gcc dot gnu.org
   Last reconfirmed||2023-11-24

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/107823] [13/14 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #5 from Andrew Pinski  ---
Looks to be fixed on the trunk.

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

2023-11-23 Thread pan2.li at intel dot com via Gcc-bugs

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

--- Comment #9 from Li Pan  ---
Before tracer
- 
ENTRY
   |
   +---+
   |  B2   |
   +---+
  / \
a < 2a >= 2
/  \ 
   +---+  +---+
   | vec store |->| _3 = b[1] |
   +---+  +---+
  /\
_3 != 1 _3 == 1
/\
+++--+
| abort  || return 0 |
+++--+
After tracer
- 

ENTRY
   |
   +---+
   |  B2   |
   +---+
  / \
a < 2a >= 2
/  \ 
+-+  +---+
| vec store   |  | _3 = b[1] |
| |  +---+
after tracer| |   /\
| |_3 != 1 _3 == 1
| _31 = b[1]  | /\
+-+ +++--+
|-->| abort  || return 0 |<---|
|   +++--+|
| |
|-|

After tracer, the vec store and scalar load will be in the same basic block and
unfortunately referenced to the same memory address. Thus, the sch1 make the
scalar load before vec store cause the failure on memory access sequeneces.

[Bug c++/107398] ICE in maybe_key_decl, at cp/module.cc:18834

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r14-5810-gcff1fa6625d1273fcfaf473e436ba918262d8afa
Author: Nathaniel Shead 
Date:   Mon Nov 13 20:11:15 2023 +1100

c++: Support lambdas in static template member initialisers [PR107398]

The testcase noted in the PR fails because the context of the lambda is
not in namespace scope, but rather in class scope. This patch removes
the assertion that the context must be a namespace and ensures that
lambdas in class scope still get the correct merge_kind.

PR c++/107398

gcc/cp/ChangeLog:

* module.cc (trees_out::get_merge_kind): Handle lambdas in class
scope.
(maybe_key_decl): Remove assertion and fix whitespace.

gcc/testsuite/ChangeLog:

* g++.dg/modules/lambda-6_a.C: New test.
* g++.dg/modules/lambda-6_b.C: New test.

Signed-off-by: Nathaniel Shead

[Bug target/96341] Support mixed element widths for AArch64 "omp declare simd" functions

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-24

--- Comment #1 from Andrew Pinski  ---
.

[Bug tree-optimization/111796] OMP SIMD call vectorization fails for arguments subject to integer promotion rules

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Richard Biener from comment #5)
> On aarch64 I see
> 
> t.c:5:1: warning: GCC does not currently support mixed size types for 'simd'
> functions
> 5 | foo (int a, short b)
>   | ^~~
> 
> simdlen(8) is also not supported, but simdlen(4) isn't diagnosed.  The above
> still remains though.

That is due to PR 96341 .

[Bug target/112643] [14 regression] including x86intrin.h is broken for -march=native (which adds -mno-avx10.1-256 )

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Haochen Jiang :

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

commit r14-5809-ga1f8e65dee2d9e929cd083f36501d08bdc9c8072
Author: Haochen Jiang 
Date:   Thu Nov 23 10:03:17 2023 +0800

i386: Fix AVX512 and AVX10 option issues

gcc/ChangeLog:

PR target/112643
* config/i386/driver-i386.cc (check_avx10_avx512_features):
Renamed to ...
(check_avx512_features): this and remove avx10 check.
(host_detect_local_cpu): Never append -mno-avx10.1-{256,512} to
avoid emitting warnings when building GCC with native arch.
* config/i386/i386-builtin.def (BDESC): Add missing AVX512VL for
128/256 bit builtin for AVX512VP2INTERSECT.
* config/i386/i386-options.cc (ix86_option_override_internal):
Also check whether the AVX512 flags is set when trying to reset.
* config/i386/i386.h
(PTA_SKYLAKE_AVX512): Add missing PTA_EVEX512.
(PTA_ZNVER4): Ditto.

[Bug c++/108321] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|13.0|---
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
Summary|[13 regression] |g++.dg/contracts/contracts-
   |g++.dg/contracts/contracts- |tmpl-spec2.C fails after
   |tmpl-spec2.C fails after|r13-4160-g2efb237ffc68ec
   |r13-4160-g2efb237ffc68ec|
 Status|REOPENED|ASSIGNED

--- Comment #7 from Andrew Pinski  ---
Yes adding -fsigned-char fixes the failure on aarch64. I am going to submit
that.

That is:
```
diff --git a/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C
b/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C
index 82117671b2d..fd3a25bd051 100644
--- a/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C
+++ b/gcc/testsuite/g++.dg/contracts/contracts-tmpl-spec2.C
@@ -1,6 +1,6 @@
 // basic test to ensure contracts work for class and member specializations
 // { dg-do run }
-// { dg-options "-std=c++2a -fcontracts -fcontract-continuation-mode=on" }
+// { dg-options "-std=c++2a -fcontracts -fcontract-continuation-mode=on
-fsigned-char" }
 #include 

 // template specializations can have differing contracts

```

[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
I am almost positive this is due to plain char being unsigned by default on
both powerpc and aarch64.  Maybe the testcase should cheat and just use
-fsigned-char

[Bug middle-end/112693] New: declare-simd-4.f90 fails on aarch64-linux-gnu

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 112693
   Summary: declare-simd-4.f90 fails on aarch64-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

>From the log:
```
FAIL: gfortran.dg/gomp/declare-simd-4.f90   -O  (test for excess errors)
Excess errors:
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gfortran.dg/gomp/declare-simd-4.f90:17:26:
Warning: GCC does not currently support mixed size types for 'simd' functions
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gfortran.dg/gomp/declare-simd-4.f90:9:19:
Warning: GCC does not currently support mixed size types for 'simd' functions
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gfortran.dg/gomp/declare-simd-4.f90:29:28:
Warning: GCC does not currently support mixed size types for 'simd' functions
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gfortran.dg/gomp/declare-simd-4.f90:36:28:
Warning: GCC does not currently support mixed size types for 'simd' functions
```

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2022-09-28 00:00:00 |2023-11-23
 CC||pinskia at gcc dot gnu.org

--- Comment #11 from Andrew Pinski  ---
Still fails.

[Bug c++/98885] [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r14-5808-gd89903ff29473e6e64f032ecee5c72d1584546dc
Author: Nathaniel Shead 
Date:   Sun Nov 12 22:49:45 2023 +1100

c++: check mismatching exports for class tags [PR98885]

Checks for exporting a declaration that was previously declared as not
exported is implemented in 'duplicate_decls', but this doesn't handle
declarations of classes. This patch adds these checks and slightly
adjusts the associated error messages for clarity.

PR c++/98885

gcc/cp/ChangeLog:

* decl.cc (duplicate_decls): Adjust error message.
(xref_tag): Adjust error message. Check exporting decl that is
already declared as non-exporting.

gcc/testsuite/ChangeLog:

* g++.dg/modules/export-1.C: Adjust error messages. Remove
xfails for working case. Add new test case.

Signed-off-by: Nathaniel Shead

[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
   Last reconfirmed||2023-11-24

--- Comment #6 from Andrew Pinski  ---
Confirmed.

I was going through all of the failures on aarch64 today and noticed this one
still fails.

[Bug sanitizer/112692] New: LSAN is not compatiable with qemu user

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 112692
   Summary: LSAN is not compatiable with qemu user
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For an example:
```
spawn qemu-aarch64 ./pr79196.exe
==1949451==LeakSanitizer has encountered a fatal error.
==1949451==HINT: For debugging, try setting environment variable
LSAN_OPTIONS=verbosity=1:log_threads=1
==1949451==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
FAIL: gcc.dg/asan/pr79196.c   -O0  execution test

```

Would be useful not to cause a fatal error like this while running on qemu
user.

This is the failure left from what I sent out back in 2020:
https://inbox.sourceware.org/gcc-patches/CA+=Sn1kH8UpByHo7FKAeZPT=rasjalespsxw9sztze_qg4e...@mail.gmail.com/

The coloring issue I mentioned there has since been fixed, I have not looked
into why though.

[Bug testsuite/112691] [14 Regression] gcc.dg/vla-1.c fails

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-24

[Bug testsuite/112691] [14 Regression] gcc.dg/vla-1.c fails

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |14.0

[Bug testsuite/112691] New: [14 Regression] gcc.dg/vla-1.c fails

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 112691
   Summary: [14 Regression] gcc.dg/vla-1.c fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

So r14-5628-g53ba8d669550d3 added noipa to f1 but really the `-fno-ipa-vrp`
should have been added to the testcase. It is testing about the clone of f1 so
turning off IPA VRP is the correct approach here.

Will submit a patch in the next few days unless someone else gets it before me.

[Bug tree-optimization/112690] [14 Regression] gcc.dg/Wstringop-overflow-17.c failure

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/112690] New: [14 Regression] gcc.dg/Wstringop-overflow-17.c failure

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 112690
   Summary: [14 Regression] gcc.dg/Wstringop-overflow-17.c failure
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

This was introduced with r14-5759-g6bf66276e3e41d .

The difference is:
before:
```
  d_21 =  + 7;
```
after:
```
  _12 = (sizetype) 
  _9 = _12 + 7;
  d_21 = (char *) _9;
```

[Bug testsuite/112689] [14 Regression] gcc.dg/tree-prof/time-profiler-[237].c fail

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||hubicka at gcc dot gnu.org

[Bug testsuite/112689] New: [14 Regression] gcc.dg/tree-prof/time-profiler-[237].c fail

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 112689
   Summary: [14 Regression] gcc.dg/tree-prof/time-profiler-[237].c
fail
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 2
FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1
FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read
tp_first_run: 3" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1

Started to fail after r14-5628-g53ba8d669550d3 .

```
gcc.dg/tree-prof/time-profiler-2.c: pattern found 4 times
FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 2
PASS: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read
tp_first_run: 1" 1
gcc.dg/tree-prof/time-profiler-2.c: pattern found 0 times
FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1
gcc.dg/tree-prof/time-profiler-2.c: pattern found 0 times
FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read
tp_first_run: 3" 1

...
gcc.dg/tree-prof/time-profiler-3.c: pattern found 2 times
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 0" 1
PASS: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 1" 1
gcc.dg/tree-prof/time-profiler-3.c: pattern found 0 times
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read
tp_first_run: 2" 1
```

I am almost positive this is a testsuite issue.

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-23
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
If this is not handled by next week, I will fix it.

[Bug testsuite/112688] New: [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 112688
   Summary: [14 Regression] testcases: gcc.target/aarch64/movk.c
and vmulxd_*_2.c need to updated after
r14-5628-g53ba8d669550d3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

As mentioned in:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637870.html

[Bug jit/108762] Add support for target-dependent builtins in libgccjit

2023-11-23 Thread bouanto at zoho dot com via Gcc-bugs

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

Antoni  changed:

   What|Removed |Added

  Attachment #54452|0   |1
is obsolete||

--- Comment #2 from Antoni  ---
Created attachment 56678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56678=edit
Patch v2

[Bug target/112675] [14 Regression] r14-5385-g0a140730c97087 caused regression on testcases for i386

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |blocker
   Priority|P3  |P1

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

2023-11-23 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-11-23
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #6 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-November/059954.html

[Bug tree-optimization/112677] [14 Regression] ASAN reports stack-buffer-overflow in tree-vect-loop.cc vect_is_simple_use when compiling with -mavx512

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords|needs-bisection |ice-on-valid-code
Summary|ASAN reports|[14 Regression] ASAN
   |stack-buffer-overflow in|reports
   |tree-vect-loop.cc   |stack-buffer-overflow in
   |vect_is_simple_use when |tree-vect-loop.cc
   |compiling with -mavx512 |vect_is_simple_use when
   ||compiling with -mavx512
 CC||rdapp at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-11-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.
We are processing:
  _ifc__35 = .COND_IOR (_23, mask_25, _18, mask_25);

Which has 4 operations but vectype_op is only declared for 3:
```
  tree vectype_op[3] = { NULL_TREE, NULL_TREE, NULL_TREE };
```

And it is accessed by:
```
  for (i = 0; i < (int) op.num_ops; i++)
{
  /* The condition of COND_EXPR is checked in vectorizable_condition().  */
  if (i == 0 && op.code == COND_EXPR)
continue;

  stmt_vec_info def_stmt_info;
  enum vect_def_type dt;
  if (!vect_is_simple_use (loop_vinfo, stmt_info, slp_for_stmt_info,
   i + opno_adjust, [i], _op[i], ,
   _op[i], _stmt_info))

```

We definitely should increase it to at least 4 but I am not sure if it needs to
increased more.

[Bug tree-optimization/112687] New: missed-optimization: switch statement does not simplify to it's expression

2023-11-23 Thread goon.pri.low at gmail dot com via Gcc-bugs

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

Bug ID: 112687
   Summary: missed-optimization: switch statement does not
simplify to it's expression
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This following code:
int unopt(int v) {
switch (v & 3) {
case 0: return 0;
case 1: return 1;
case 2: return 2;
case 3: return 3;
default: __builtin_unreachable();
}
}

unopt:
mov eax, edi
and eax, 3
lea edx, [rax-1]
cmp edx, 3
mov edx, 0
cmovnb  eax, edx
ret

Ought to be optimized to:
int opt(int v) {
return v & 3;
}

opt:
mov eax, edi
and eax, 3
ret

Note: I decided to separate this problem from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112645 since it was unrelated to
the main bug, though Richard offers some initial insight into the problem.

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

2023-11-23 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Potential fix:

Regtests ok.

[Bug target/112686] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -fsplit-stack -mcmodel=large

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89316
   Last reconfirmed||2023-11-23
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
Most likely introduced by r14-5784-g2f3f8952ff1736 .

It is a bit upsetting the testcase from PR 46089 is the same testcase here was
not added back when PR 46089 was fixed in 4.6.

[Bug target/46089] ICE: in gen_reg_rtx, at emit-rtl.c:861 with -mcmodel=large -fsplit-stack

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug tree-optimization/112645] missed-optimization: cswitch optimization missed in nested if-statement

2023-11-23 Thread goon.pri.low at gmail dot com via Gcc-bugs

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

--- Comment #2 from gooncreeper  ---
I am going to move the second problem to it's own bug since I realize it
actually quite a different problem, and deserves it's own thread of discussion.

[Bug target/112686] New: [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -fsplit-stack -mcmodel=large

2023-11-23 Thread zsojka at seznam dot cz via Gcc-bugs

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

Bug ID: 112686
   Summary: [14 Regression] ICE: in gen_reg_rtx, at
emit-rtl.cc:1176 with -fsplit-stack -mcmodel=large
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56677=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fsplit-stack -mcmodel=large testcase.c 
during RTL pass: pro_and_epilogue
testcase.c: In function 'foo':
testcase.c:1:17: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1176
1 | void foo(void) {}
  | ^
0x74c298 gen_reg_rtx(machine_mode)
/repo/gcc-trunk/gcc/emit-rtl.cc:1176
0x107cfae copy_to_mode_reg(machine_mode, rtx_def*)
/repo/gcc-trunk/gcc/explow.cc:650
0x19b175d ix86_expand_call(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
bool)
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:9710
0x18b70da ix86_expand_split_stack_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.cc:10565
0x1dec81a gen_split_stack_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.md:18458
0x1897c75 target_gen_split_stack_prologue
/repo/gcc-trunk/gcc/config/i386/i386.md:18213
0x111a64a make_split_prologue_seq
/repo/gcc-trunk/gcc/function.cc:5795
0x111a64a make_split_prologue_seq
/repo/gcc-trunk/gcc/function.cc:5788
0x111a83a thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.cc:6049
0x111b1b2 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.cc:6553
0x111b1b2 execute
/repo/gcc-trunk/gcc/function.cc:6634
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231123 (experimental) (GCC)

[Bug middle-end/112685] missed-optimization: division / modulo loops

2023-11-23 Thread goon.pri.low at gmail dot com via Gcc-bugs

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

--- Comment #2 from gooncreeper  ---
(In reply to Andrew Pinski from comment #1)
> I thought I had saw this a while back.
> 
> Note the Linux kernel does this kind of loop explicity to avoid the division
> though as the cases where it does is known to be only a few iterations (1 or
> 2) to get the division but the compiler does not have that information. 
> 
> 
> Also I am not 100% sure this is always a win due to how slow the divide
> instruction is on many cores.

This optimization should at least be applied for constant division / modulo.

If the user knows it will only be done for a certain amount of iterations they
could do something like this:

unsigned div(unsigned a) {
if (a > 9) return 3;
if (a > 6) return 2;
if (a > 3) return 1;
return 0;
}

unsigned mod(unsigned a) {
if (a > 9) return a - 9;
if (a > 6) return a - 6;
if (a > 3) return a - 3;
return a;
}

In most cases they probably won't intend on it only being a few iterations.

[Bug middle-end/112683] Optimizing memcpy range by extending to word bounds

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #1 from Andrew Pinski  ---
  # RANGE [irange] long unsigned int [1, 16] MASK 0x1f VALUE 0x0
  _2 = _1 + 1;
  # PT = nonlocal 
  _3 = &__str_5(D)->_M_local_bufD.4676;
  # .MEM_7 = VDEF <.MEM_6>
  memcpyD.1403 (&._M_local_bufD.4676, _3, _2);

The range information is there already for _2.


Note the hugely expanded out instructions is a target issue though.

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

2023-11-23 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Potential fix:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 81a14653a04..962274f5d25 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -986,8 +986,8 @@ resolve_common_vars (gfc_common_head *common_block, bool
named_common)

   /* gfc_add_in_common may have been called before, but the reported
errors
 have been ignored to continue parsing.
-We do the checks again here.  */
-  if (!csym->attr.use_assoc)
+We do the checks again here, unless the symbol is USE associated.  */
+  if (!csym->attr.use_assoc && !csym->attr.used_in_submodule)
{
  gfc_add_in_common (>attr, csym->name, _block->where);
  gfc_notify_std (GFC_STD_F2018_OBS, "COMMON block at %L",

[Bug middle-end/112685] missed-optimization: division / modulo loops

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
I thought I had saw this a while back.

Note the Linux kernel does this kind of loop explicity to avoid the division
though as the cases where it does is known to be only a few iterations (1 or 2)
to get the division but the compiler does not have that information. 


Also I am not 100% sure this is always a win due to how slow the divide
instruction is on many cores.

[Bug middle-end/112685] missed-optimization: division / modulo loops

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/112685] New: missed-optimization: division / modulo loops

2023-11-23 Thread goon.pri.low at gmail dot com via Gcc-bugs

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

Bug ID: 112685
   Summary: missed-optimization: division / modulo loops
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This code here:

unsigned ldiv(unsigned r) {
unsigned d = 0;

while (r >= 3) {
r -= 3;
d++;
}

return d;
}

Could be optimized to a single division and save decades of processing time.
This code here:

unsigned lmod(unsigned r) {
while (r >= 3) r -= 3;
return r;
}

Could be optimized to a single modulo.
Signed integers are a whole other problem, but maybe we could optimize loops
for them also.

[Bug fortran/112609] [F2023] Restrictions on integer arguments to SYSTEM_CLOCK

2023-11-23 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747

2023-11-23 Thread manuel.lauss at googlemail dot com via Gcc-bugs

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

--- Comment #7 from Manuel Lauss  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 56676 [details]
> gcc14-pr112681.patch
> 
> Full untested patch.

Fixes all ICEs I've seen today.
Thank you!

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

2023-11-23 Thread bugdal at aerifal dot cx via Gcc-bugs

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

--- Comment #44 from Rich Felker  ---
My naive expectation is that "if ((uintptr_t)src == 0x400400)" is and should be
UB, but I may be misremembering the details of the formalism by which the spec
for restrict is implemented.

If so, that's kinda a help, but I still think you would want to remove restrict
from the arguments and apply it later, so that the fast-path head/tail copies
can avoid any branch, and the check for equality can be deferred until it's
known that there's a "body remainder" to copy. That's the part where you really
want the benefits of restrict anyway -- without restrict it's not vectorizable
because the compiler has to assume there might be nonexact overlap, in which
case reordering the loads and stores in any way could change the result.

[Bug other/112684] New: ICE: in main, at toplev.cc:2327 with -ftarget-help -fdiagnostics-generate-patch

2023-11-23 Thread zsojka at seznam dot cz via Gcc-bugs

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

Bug ID: 112684
   Summary: ICE: in main, at toplev.cc:2327 with -ftarget-help
-fdiagnostics-generate-patch
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Compiler output:
$ echo '' > testcase.c
$ x86_64-pc-linux-gnu-gcc -ftarget-help -fdiagnostics-generate-patch testcase.c
The following options are target specific:
...
cc1: internal compiler error: in main, at toplev.cc:2327
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231123 (experimental) (GCC)

[Bug target/112672] [14 Regression] wrong code with __builtin_parityl() at -O and above on x86_64

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Uros Bizjak :

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

commit r13-8092-gd035b57d51167af805ccc91ee0492c8b27e22184
Author: Uros Bizjak 
Date:   Thu Nov 23 16:17:57 2023 +0100

i386: Wrong code with __builtin_parityl [PR112672]

gen_parityhi2_cmp instruction clobbers its input operand, so use
a temporary register in the call to gen_parityhi2_cmp.

PR target/112672

gcc/ChangeLog:

* config/i386/i386.md (parityhi2):
Use temporary register in the call to gen_parityhi2_cmp.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112672.c: New test.

(cherry picked from commit b2d17bdd45b582b93e89c00b04763a45f97d7a34)

[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 56676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56676=edit
gcc14-pr112681.patch

Full untested patch.

[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Jakub Jelinek  ---
Or maybe better
--- gcc/config/i386/i386-expand.cc.jj   2023-11-21 09:31:35.792395304 +0100
+++ gcc/config/i386/i386-expand.cc  2023-11-23 20:57:57.128721762 +0100
@@ -2453,7 +2453,8 @@ ix86_expand_branch (enum rtx_code code,
  /* Generate XOR since we can't check that one operand is zero
 vector.  */
  tmp = gen_reg_rtx (mode);
- emit_insn (gen_rtx_SET (tmp, gen_rtx_XOR (mode, op0, op1)));
+ rtx ops[3] = { tmp, op0, op1 };
+ ix86_expand_vector_logical_operator (XOR, mode, ops);
  tmp = gen_lowpart (p_mode, tmp);
  emit_insn (gen_rtx_SET (gen_rtx_REG (CCZmode, FLAGS_REG),
  gen_rtx_UNSPEC (CCZmode,

[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Jakub Jelinek  ---
Flags can be just -O2 -msse4.1 -mno-sse4.2 as well or even -O2 -msse4.2
-mno-avx.
--- gcc/config/i386/i386-expand.cc.jj   2023-11-21 09:31:35.792395304 +0100
+++ gcc/config/i386/i386-expand.cc  2023-11-23 20:43:51.675586034 +0100
@@ -2453,6 +2453,8 @@ ix86_expand_branch (enum rtx_code code,
  /* Generate XOR since we can't check that one operand is zero
 vector.  */
  tmp = gen_reg_rtx (mode);
+ if (!vector_operand (op1, mode))
+   op1 = force_reg (mode, op1);
  emit_insn (gen_rtx_SET (tmp, gen_rtx_XOR (mode, op0, op1)));
  tmp = gen_lowpart (p_mode, tmp);
  emit_insn (gen_rtx_SET (gen_rtx_REG (CCZmode, FLAGS_REG),
seems to fix it.

[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||manuel.lauss at googlemail dot 
com

--- Comment #3 from Andrew Pinski  ---
*** Bug 112676 has been marked as a duplicate of this bug. ***

[Bug target/112676] [14 regression] ICE in extract_insn, at recog.cc:2804

2023-11-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 112681.

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

[Bug target/112676] [14 regression] ICE in extract_insn, at recog.cc:2804

2023-11-23 Thread manuel.lauss at googlemail dot com via Gcc-bugs

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

--- Comment #2 from Manuel Lauss  ---
I think PR112681 is the same issue.

[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Jakub Jelinek  ---
Doesn't need the virtual method nor C++:
struct S { void *c; char d[16]; } a, b;

int
foo (void)
{
  return __builtin_memcmp (a.d, b.d, sizeof (a.d)) != 0;
}

[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
   |extract_insn, at|extract_insn, at
   |recog.cc:2804   |recog.cc:2804
   |(unrecognizable insn) with  |(unrecognizable insn) with
   |-O2 -mfma -mno-sse4.2 and   |-O2 -mfma -mno-sse4.2 and
   |memcmp()|memcmp() since r14-5747
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-23

--- Comment #1 from Jakub Jelinek  ---
Started with r14-5747-g2e51fff7ce02a6105aa1acff57cbbdd8a767a33f

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

2023-11-23 Thread post+gcc at ralfj dot de via Gcc-bugs

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

--- Comment #43 from post+gcc at ralfj dot de ---
That is not my reading of the standard, but absent a proper (formal,
mathematical) spec I guess it is hard to tell.

With your reading, "if ((uintptr_t)src == 0x400400)" is UB, since changing the
"src" argument to a different copy located at that address would change the
execution. I strongly doubt that is the intent of the standard.

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

2023-11-23 Thread bugdal at aerifal dot cx via Gcc-bugs

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

--- Comment #42 from Rich Felker  ---
> I'm not saying that such an implementation will be a good idea, but just a 
> remark: You could, in fact, keep restrict for the arguments in this case, 
> because the object pointed to by src and dest is not accessed at all when 
> src==dest. So this is correct code according to the standard. (The exact 
> semantics of restrict are a bit involved...)

Nope, UB is invoked as soon as you evaluate src==dest, even with no
dereferencing. The semantics of restrict are such that the behavior of the code
must be unchanged if the pointer were replaced to a pointer to a relocated copy
of the pointed-to object. Since this would alter the result of the == operator,
that constraint is not satisfied and thereby the behavior is undefined.

[Bug target/112643] [14 regression] including x86intrin.h is broken for -march=native (which adds -mno-avx10.1-256 )

2023-11-23 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to Urs Janßen from comment #25)
> (In reply to Haochen Jiang from comment #24)
> > Patch aims to fix that:
> > 
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html
> 
> Yes, that solved the issue for me. Thanks.

Works for me, too.  Thanks.

[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:7646b5d88056cf269ff555afe95bc361dcf5e5c0

commit r14-5798-g7646b5d88056cf269ff555afe95bc361dcf5e5c0
Author: Harald Anlauf 
Date:   Wed Nov 22 21:45:46 2023 +0100

testsuite: fortran: fix invalid testcases (missing MOLD argument to NULL)

The Fortran standard requires that NULL() passed to an assumed-rank
dummy argument has a MOLD argument.

gcc/testsuite/ChangeLog:

PR fortran/104819
* gfortran.dg/assumed_rank_10.f90: Add MOLD argument to NULL().
* gfortran.dg/assumed_rank_8.f90: Likewise.

[Bug fortran/112609] [F2023] Restrictions on integer arguments to SYSTEM_CLOCK

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:0c2ecfd4a29161d6c2bd3a83335387f42ff38ffe

commit r14-5797-g0c2ecfd4a29161d6c2bd3a83335387f42ff38ffe
Author: Harald Anlauf 
Date:   Wed Nov 22 20:57:59 2023 +0100

Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK to
have a decimal exponent range at least as large as a default integer,
and that all integer arguments have the same kind type parameter.

gcc/fortran/ChangeLog:

PR fortran/112609
* check.cc (gfc_check_system_clock): Add checks on integer
arguments
to SYSTEM_CLOCK specific to F2023.
* error.cc (notify_std_msg): Adjust to handle new features added
in F2023.
* gfortran.texi (_gfortran_set_options): Document
GFC_STD_F2023_DEL,
remove obsolete option GFC_STD_F2008_TS and fix enumeration values.
* libgfortran.h (GFC_STD_F2023_DEL): Add and use in
GFC_STD_OPT_F23.
* options.cc (set_default_std_flags): Add GFC_STD_F2023_DEL.

gcc/testsuite/ChangeLog:

PR fortran/112609
* gfortran.dg/system_clock_1.f90: Add option -std=f2003.
* gfortran.dg/system_clock_3.f08: Add option -std=f2008.
* gfortran.dg/system_clock_4.f90: New test.

[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753

2023-11-23 Thread gjl at gcc dot gnu.org via Gcc-bugs

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

Bug 86776 Summary: Avr port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/86776] Avr port needs updating for CVE-2017-5753

2023-11-23 Thread gjl at gcc dot gnu.org via Gcc-bugs

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #3 from Georg-Johann Lay  ---
Fixed.

[Bug target/86776] Avr port needs updating for CVE-2017-5753

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:9a3c40af7f7dd218cc2ebaa3a70f3317f7316ceb

commit r14-5796-g9a3c40af7f7dd218cc2ebaa3a70f3317f7316ceb
Author: Georg-Johann Lay 
Date:   Thu Nov 23 19:02:47 2023 +0100

AVR: PR target/86776: Implement CVE-2017-5753.

gcc/
PR target/86776
* config/avr/avr.cc (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define
to speculation_safe_value_not_needed.

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

2023-11-23 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
As the commit log says, I've added the std::ranges::to functions, but not the
new members of the standard containers. I don't have immediate plans to add
those new members, so I'm unassigning myself from this bug for now.

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:7a6a29c455e7755b501c0006e39beb4e56ec2729

commit r14-5794-g7a6a29c455e7755b501c0006e39beb4e56ec2729
Author: Jonathan Wakely 
Date:   Tue Sep 19 13:23:13 2023 +0100

libstdc++: Define std::ranges::to for C++23 (P1206R7) [PR111055]

This adds the std::ranges::to functions for C++23. The rest of P1206R7
is not yet implemented, i.e. the new constructors taking the
std::from_range tag, and the new insert_range, assign_range, etc. member
functions. std::ranges::to works with the standard containers even
without the new constructors, so this is useful immediately.

The __cpp_lib_ranges_to_container feature test macro can be defined now,
because that only indicates support for the changes in , which
are implemented by this patch. The __cpp_lib_containers_ranges macro
will be defined once all containers support the new member functions.

libstdc++-v3/ChangeLog:

PR libstdc++/111055
* include/bits/ranges_base.h (from_range_t): Define new tag
type.
(from_range): Define new tag object.
* include/bits/version.def (ranges_to_container): Define.
* include/bits/version.h: Regenerate.
* include/std/ranges (ranges::to): Define.
* testsuite/std/ranges/conv/1.cc: New test.
* testsuite/std/ranges/conv/2_neg.cc: New test.
* testsuite/std/ranges/conv/version.cc: New test.

[Bug tree-optimization/112673] [14 Regression] ICE verify_gimple failed since r14-5557-g6dd4c703be17fa

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-11-23
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 56675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56675=edit
gcc14-pr112673.patch

Full untested patch.

[Bug tree-optimization/112673] [14 Regression] ICE verify_gimple failed since r14-5557-g6dd4c703be17fa

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC|jakub at redhat dot com|jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think this is a match.pd problem.
First vectorizer vectorizes the
  _18 = VIEW_CONVERT_EXPR(x)[_16];
  bitint.2[_16] = _18;
...
copying loop, before forwprop4 we have
  vect__18.6_34 = VIEW_CONVERT_EXPR(x_35(D));
  _8 = BIT_FIELD_REF ;
...
  _18 = BIT_FIELD_REF ;
...
etc., which I think is valid, but during forwprop4 the
(simplify
 (BIT_FIELD_REF (view_convert @0) @1 @2)
 (BIT_FIELD_REF @0 @1 @2))
simplification kicks in and we create invalid
  _18 = BIT_FIELD_REF ;
out of it, because x has _BitInt(256) type and so doesn't have mode precision.
tree-cfg.cc checking for BIT_FIELD_REF diagnoses:
  if (INTEGRAL_TYPE_P (TREE_TYPE (op))
  && !type_has_mode_precision_p (TREE_TYPE (op)))
{
  error ("%qs of non-mode-precision operand", code_name);
  return true;
}
so maybe
--- gcc/match.pd.jj 2023-11-17 15:10:43.306043972 +0100
+++ gcc/match.pd2023-11-23 18:09:22.538414897 +0100
@@ -8285,7 +8285,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)

 (simplify
  (BIT_FIELD_REF (view_convert @0) @1 @2)
- (BIT_FIELD_REF @0 @1 @2))
+ (if (! INTEGRAL_TYPE_P (TREE_TYPE (@0))
+  || type_has_mode_precision_p (TREE_TYPE (@0)))
+  (BIT_FIELD_REF @0 @1 @2)))

 (simplify
  (BIT_FIELD_REF @0 @1 integer_zerop)

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

2023-11-23 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

   Host|hppa*-*-linux*, |
   |*-*-solaris2.11 |
 Ever confirmed|0   |1
  Build|hppa*-*-linux*, |
   |*-*-solaris2.11 |
 Target|hppa*-*-linux*, |
   |*-*-solaris2.11 |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-23

--- Comment #4 from Jonathan Wakely  ---
Also seen on cris-elf and m68k-linux so not specific to
armv8l-unknown-linux-gnueabihf

It appears that __stacktrace_impl::_S_current returns an empty sequence of
frames.

It's possible that all the lambda frames are inlined, or skip+2 in
stacktrace.cc causes us to skip real frames that we should keep, or maybe
libbacktrace just doesn't work on this target.

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

2023-11-23 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

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

[Bug libstdc++/112541] FAIL: 19_diagnostics/stacktrace/current.cc

2023-11-23 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
dup

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

[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor

2023-11-23 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug middle-end/112679] ICE in expand_float, at optabs.cc:5724 with bitint

2023-11-23 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-23
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 56674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56674=edit
gcc14-pr112679.patch

Untested fix.

[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor

2023-11-23 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Francisco Paisana from comment #4)
> One last thing, I might have misread this as well. 
> 
> > "Zero-initialization is performed in the following situations:
> > ...
> > 2) As part of value-initialization sequence [...] for members of
> > value-initialized class types that have no constructors."
> 
> I was interpreting it as "members that have no ctors of classes are
> zero-init".

I don't even know what that would mean.

> However, this could be also read as "members of classes, where
> the classes have no ctor, are zero-init."

This is the correct reading.

N.B. cppreference is not the standard. It's usually an accurate paraphrasing of
the standard, but it's not gospel.

[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor

2023-11-23 Thread paisanafc at gmail dot com via Gcc-bugs

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

--- Comment #4 from Francisco Paisana  ---
One last thing, I might have misread this as well. 

> "Zero-initialization is performed in the following situations:
> ...
> 2) As part of value-initialization sequence [...] for members of
> value-initialized class types that have no constructors."

I was interpreting it as "members that have no ctors of classes are zero-init".
However, this could be also read as "members of classes, where the classes have
no ctor, are zero-init."

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

2023-11-23 Thread post+gcc at ralfj dot de via Gcc-bugs

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

--- Comment #41 from post+gcc at ralfj dot de ---
> This entitles a compiler to emit asm equivalent to if (src==dest) system("rm 
> -rf /") if it likes.

No it does not. restrict causes UB if the two pointers are used to access the
same memory. It has nothing to do with whether the pointers are equal. So it
would have to be "if (src==dest && n>0)" and the compiler would have to first
prove that "n>0" implies that later accesses through both pointers occur at
offset 0 (and at least one of them is a write).

But it's still UB to call this the way GCC does, that much I agree with.

> Our memcpy is not written in asm but in C, and it has the restrict qualifier 
> on src and dest.

The question is, does that qualifier help? If you remove it, does the generated
assembly change in any way, does the performance change? If not, it clearly
doesn't matter and can just be removed. If yes, then yeah compilers clearly
shouldn't call this with identical ranges.

Basically, compiler devs are claiming that libc can support the src==dest case
"for free", without any noticeable cost to other uses of the function. libc
devs are claiming that compilers can insert a branch that tests for equality,
without any noticeable cost. Both of these are testable hypotheses. I'm not a
compiler dev nor a libc dev, I just want to make sure that my compiler and my
libc use the same contract when talking to each other -- but I hope someone who
is a compiler dev or a libc dev can go and actually test these hypotheses,
rather than just speculating about it as has been happening so far.

[Bug target/89316] ICE with -mforce-indirect-call and -fsplit-stack

2023-11-23 Thread ubizjak at gmail dot com via Gcc-bugs

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #16 from Uroš Bizjak  ---
Fixed for gcc-14.

[Bug target/112672] [14 Regression] wrong code with __builtin_parityl() at -O and above on x86_64

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r14-5785-gb2d17bdd45b582b93e89c00b04763a45f97d7a34
Author: Uros Bizjak 
Date:   Thu Nov 23 16:17:57 2023 +0100

i386: Wrong code with __builtin_parityl [PR112672]

gen_parityhi2_cmp instruction clobbers its input operand, so use
a temporary register in the call to gen_parityhi2_cmp.

PR target/112672

gcc/ChangeLog:

* config/i386/i386.md (parityhi2):
Use temporary register in the call to gen_parityhi2_cmp.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112672.c: New test.

[Bug middle-end/112653] PTA should handle correctly escape information of values returned by a function

2023-11-23 Thread hubicka at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Jan Hubicka  ---
Thanks for explanation.  I think it is quite common pattern that new object is
construted and worked on and later returned, so I think we ought to handle this
correctly.

Another example just came up in
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637878.html

We should gnerate same code for the following two functions:

#include 

auto
f()
{
  std::vector x;
  x.reserve(10);
  for (int i = 0; i < 10; ++i)
x.push_back(0);
  return x;
}

auto
g()
{ return std::vector(10, 0); }


but we don't since we lose track of values stored in x after every call to new.

[Bug target/89316] ICE with -mforce-indirect-call and -fsplit-stack

2023-11-23 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:2f3f8952ff1736dd6a087ddb4106077db3502bb9

commit r14-5784-g2f3f8952ff1736dd6a087ddb4106077db3502bb9
Author: Uros Bizjak 
Date:   Thu Nov 23 15:45:59 2023 +0100

i386: Fix ICE with -mforce-indirect-call and -fsplit-stack [PR89316]

With the above two options, use a temporary register regno (as returned
from split_stack_prologue_scratch_regno) as an indirect call scratch
register to hold __morestack function address.  On 64-bit targets, two
temporary registers are always available, so load the function addres in
%r11 and call __morestack_large_model with its one-argument-register value
rn %r10.  On 32-bit targets, bail out with a "sorry" if the temporary
register can not be obtained.

On 32-bit targets, also emit PIC sequence that re-uses the obtained
indirect
call scratch register before moving the function address to it.  We can
not set up %ebx PIC register in this case, but __morestack is prepared
for this situation and sets it up by itself.

PR target/89316

gcc/ChangeLog:

* config/i386/i386.cc (ix86_expand_split_stack_prologue): Obtain
scratch regno when flag_force_indirect_call is set.  On 64-bit
targets, call __morestack_large_model when 
flag_force_indirect_call
is set and on 32-bit targets with -fpic, manually expand PIC
sequence
to call __morestack.  Move the function address to an indirect
call scratch register.

gcc/testsuite/ChangeLog:

* g++.target/i386/pr89316.C: New test.
* gcc.target/i386/pr112605-1.c: New test.
* gcc.target/i386/pr112605-2.c: New test.
* gcc.target/i386/pr112605.c: New test.

[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor

2023-11-23 Thread paisanafc at gmail dot com via Gcc-bugs

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

Francisco Paisana  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Francisco Paisana  ---
This ended up being a misinterpretation of the C++ standard.

[Bug c++/112680] g++-13 segfault on std::regex_match with c++11 or above -O2 and lto

2023-11-23 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||102445

--- Comment #2 from Jonathan Wakely  ---
It could just be the well known problem of resource exhaustion with our
recursive std::regex implementation.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
[Bug 102445] [meta-bug] std::regex issues

1 2 >

1 - 100 of 153 matches

Mail list logo