[Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #8 from Hongtao.liu  ---
Fixed in GCC14.

[Bug tree-optimization/102383] Missing optimization for PRE after enable O2 vectorization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
It's fixed in GCC12.1

[Bug target/105034] [11/12/13/14 regression]Suboptimal codegen for min/max with -Os

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #8 from Hongtao.liu  ---
Looks like it's fixed in latest trunk.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[crazylht at gmail dot com via Gcc-bugs]

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

Bug 101956 Summary: Miss vectorization from v4hi to v4df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101956

   What|Removed |Added

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

[Bug tree-optimization/101956] Miss vectorization from v4hi to v4df

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #4 from Hongtao.liu  ---
Fixed by r14-2007-g6f19cf7526168f

[Bug c/112326] New: Redundant vsetvl in fixed-vlmax autovectorization codes

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 112326
   Summary: Redundant vsetvl in fixed-vlmax autovectorization
codes
   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: ---

#include 

void
f (int *__restrict y, int *__restrict x, int *__restrict z, int n)
{
  for (int i = 0; i < n; ++i)
x[i] = y[i] + x[i];
}

--param=riscv-autovec-preference=scalable -fno-vect-cost-model:


vsetvli a5,a3,e32,m1,ta,ma
sllia2,a5,2
vle32.v v1,0(a1)
vle32.v v2,0(a0)
sub a3,a3,a5
vadd.vv v1,v1,v2
vse32.v v1,0(a4)
add a0,a0,a2
add a1,a1,a2
add a4,a4,a2
bne a3,zero,.L3

However, with --param=riscv-autovec-preference=fixed-vlmax:

vsetvli a5,a3,e8,mf4,ta,ma -> should be changed into e32m1
vle32.v v1,0(a1)
vle32.v v2,0(a0)
vsetivlizero,4,e32,m1,ta,ma -> redundant
sllia2,a5,2
vadd.vv v1,v1,v2
sub a3,a3,a5
vsetvli zero,a5,e32,m1,ta,ma -> redundant
vse32.v v1,0(a4)
add a0,a0,a2
add a1,a1,a2
add a4,a4,a2
bne a3,zero,.L3

[Bug tree-optimization/112325] Missed vectorization after cunrolli

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Seems like there is a missing SLP ...

Confirmed.

[Bug tree-optimization/112325] New: Missed vectorization after cunrolli

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

Bug ID: 112325
   Summary: Missed vectorization after cunrolli
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

testcase:

#include 
#include 

typedef struct {
float s;
int8_t qs[32];
} block;

void foo (const int n, float * restrict s, const int8_t q[4], const block *
restrict y) {
const int qk = 32;
const int nb = n / qk;

float sumf = 0.0;
int sumi = 0;

for (int i = 0; i < nb; i++) {
uint32_t qh;
memcpy(, q, 4);

for (int j = 0; j < qk/2; ++j) {
sumi += (qh >> j) * y[i].qs[j];
}
sumf += (y[i].s * (float) sumi);
}
*s = sumf;
}

This can be vectorized under -O2 -mavx512vl but not -O3 -mavx512vl, see
https://godbolt.org/z/csPr4cPen

Under -O3 -mavx512vl -fdisable-tree-cunrolli the loop can also be vectorized.

[Bug tree-optimization/111794] RISC-V: Missed SLP optimization due to mask mode precision

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #12 from JuzheZhong  ---
Fixed

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #29 from JuzheZhong  ---
insn-output.cc still has over 1.7 Million lines codes.

Is it possible split this file into 10 files too ?

It seems that it is also an issue for compile time ?

[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||64700

--- Comment #2 from Andrew Pinski  ---
PR 64700 (and others).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64700
[Bug 64700] Sink common code through PHI

[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1
  Component|middle-end  |tree-optimization
 Status|UNCONFIRMED |ASSIGNED
   Severity|normal  |enhancement
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-11-01

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

There is another bug which is very much similar to this but:
  max_19 = MAX_EXPR <_4, max_6>;
  goto ; [INV]

   :
  _8 = MAX_EXPR ;

   :
  # max_5 = PHI 

Basically we need to pull MAX_EXPR out of the if and then the ABS will be
recognized and all.

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
> So here we have a reduction for MAX_EXPR, but there's 2 MAX_EXPR which can
> be merge together with MAX_EXPR >
> 
Create pr112324.

[Bug middle-end/112324] New: phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 112324
   Summary: phiopt fail to recog if (b < 0) max = MAX(-b, max);
else max = MAX (b, max) into max = MAX (ABS(b), max)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

#define MAX(a, b) ((a) > (b) ? (a) : (b)) 
int
foo (int n, int* a)
{
int max = 0;
for (int i = 0; i != n; i++)
{
int tmp = a[i];
if (tmp < 0)
  max = MAX (-tmp, max);
else
  max = MAX (tmp, max);
}
return max;
}

int
foo1 (int n, int* a)
{
int max = 0;
for (int i = 0; i != n; i++)
{
int tmp = a[i];
max = MAX ((tmp < 0 ? -tmp : tmp), max);
}
return max;
}

foo should be same as foo1, but gcc failed to recognize ABS_EXPR in foo.
It's from pr110015(originally from source code in openjpeg).

[Bug target/112323] aarch64: C-operator support with ARM SVE intrinsic type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/533558.html

So the answer is no as far as I can tell. In fact:
(5) It makes it easier to ensure that (with default options) code is
portable between compilers without the GNU vector extensions having
to become an official part of the SVE intrinsics spec.

Is one of the big reasons.
Though (1) might be even better reason.

It is a bit odd that clang decided to go and implement it but this was a
conscious decision to reject it and gave reasons why.

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
169test.c:85:23: note:   vect_is_simple_use: operand max_38 = PHI , type of def: unknown
170test.c:85:23: missed:   Unsupported pattern.
171test.c:62:24: missed:   not vectorized: unsupported use in stmt.
172test.c:85:23: missed:  unexpected pattern.
173test.c:85:23: note:  * Analysis  failed with vector mode V8SI
174test.c:85:23: note:  * The result for vector mode V32QI would be the
same
175test.c:85:23: missed: couldn't vectorize loop
176test.c:65:13: note: vectorized 0 loops in function.
177Removing basic block 5
178;; basic block 5, loop depth 2
179;;  pred:   16
180;;  43
181# max_38 = PHI 
182# i_42 = PHI 
183# datap_44 = PHI 
184tmp_24 = *datap_44;
185_35 = tmp_24 < 0;
186_56 = (unsigned int) tmp_24;
187_51 = -_56;
188_1 = (int) _51;
189_25 = MAX_EXPR <_1, max_38>;
190_31 = _1 | -2147483648;
191iftmp.0_27 = (unsigned int) _31;
192.MASK_STORE (datap_44, 8B, _35, iftmp.0_27);
193_26 = MAX_EXPR ;
194max_5 = _35 ? _25 : _26;
195i_29 = i_42 + 1;
196datap_30 = datap_44 + 4;
197if (w_22 > i_29)
198  goto ; [89.00%]
199else
200  goto ; [11.00%]
201;;  succ:   16

So here we have a reduction for MAX_EXPR, but there's 2 MAX_EXPR which can be
merge together with MAX_EXPR >

manually change the loop to below, then it can be vectorized.

for (j = 0; j < t1->h; ++j) {
const OPJ_UINT32 w = t1->w;
for (i = 0; i < w; ++i, ++datap) {
OPJ_INT32 tmp = *datap;
if (tmp < 0)
  {
OPJ_UINT32 tmp_unsigned;
tmp_unsigned = opj_to_smr(tmp);
memcpy(datap, _unsigned, sizeof(OPJ_INT32));
tmp = -tmp;
  }
max = opj_int_max(max, tmp);
}
}

maybe it's related to phiopt?

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8

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

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

--- Comment #6 from Jeffrey A. Law  ---
Created attachment 56480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56480=edit
Testcase for fr30-elf -Os -g

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
I've bisected a failure on fr30-elf to the same commit.  The failure mode is
different, but given it's the same commit, I'm attaching the testcase to this
BZ.

0xba6a67 phi_nodes_ptr(basic_block_def*)
/home/jlaw/test/gcc/gcc/gimple.h:4700
0xba6a67 gsi_start_phis(basic_block_def*)
/home/jlaw/test/gcc/gcc/gimple-iterator.cc:935
0xba6a67 gsi_for_stmt(gimple*)
/home/jlaw/test/gcc/gcc/gimple-iterator.cc:620
0xf477c1 replace_uses_by(tree_node*, tree_node*)
/home/jlaw/test/gcc/gcc/tree-cfg.cc:2055
0x111b731 clean_up_loop_closed_phi(function*)
/home/jlaw/test/gcc/gcc/tree-ssa-propagate.cc:1296
0xd23348 loop_optimizer_finalize(function*, bool)
/home/jlaw/test/gcc/gcc/loop-init.cc:146
0x10e1448 tree_ssa_loop_done
/home/jlaw/test/gcc/gcc/tree-ssa-loop.cc:478
0x10e1498 execute
/home/jlaw/test/gcc/gcc/tree-ssa-loop.cc:507

Compile with -Os -g

[Bug c/112323] New: aarch64: Missed operator support on ARM SVE intrinsic type

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 112323
   Summary: aarch64: Missed operator support on ARM SVE intrinsic
type
   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: ---

Consider this following case:
#include "arm_sve.h"

svint8_t foo (svint8_t a, svint8_t b)
{
return a + b;
}

https://godbolt.org/z/nMMxWcE4E

Clang is able to recognize "+" of svint8_t wheras GCC is not.

Any plan to support operator on ARM SVE type?

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Keywords||build
 CC||hp at gcc dot gnu.org
 Target||cris-elf

--- Comment #4 from Hans-Peter Nilsson  ---
What target?

Anyway, cris-elf too, where build of newlib fails.  (Same revision pin-pointed,
and the apparently-minimal posted test-case exposes the bug there too.  It
could theoretically be a different bug from the same commit, but I think
horses.)

[Bug rtl-optimization/104387] aarch64: Redundant SXTH for “bag of bits” moves

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

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

--- Comment #3 from Andrew Pinski  ---
Some analysis about this is recorded at
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=111835#c1 .

[Bug rtl-optimization/104387] aarch64: Redundant SXTH for “bag of bits” moves

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lis8215 at gmail dot com

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

[Bug rtl-optimization/111835] Suboptimal codegen: zero extended load instead of sign extended one

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 104387.

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

[Bug middle-end/111921] [11/12/13/14 Regression] ICE with nested function after an error

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
This is the effect of --enable-checking=release.

[Bug middle-end/111921] [11/12/13/14 Regression] ICE with nested function after an error

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
gcc 6 to 13 have "confused by earlier errors, bailing out".

The segfault starts occuring in gcc-14.

[Bug libbacktrace/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||josopait at goopax dot com

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

[Bug libbacktrace/112322] std::stacktrace fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug libbacktrace/112322] New: std::stacktrace fails

[josopait at goopax dot com via Gcc-bugs]

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

Bug ID: 112322
   Summary: std::stacktrace fails
   Product: gcc
   Version: 12.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josopait at goopax dot com
CC: ian at gcc dot gnu.org
  Target Milestone: ---

I installed gcc on gentoo linux:

EXTRA_ECONF="--enable-libstdcxx-backtrace=yes" emerge gcc

and compiled the following program:



#include 
#include 

int main()
{
  std::cout << std::stacktrace::current() << std::endl;
}

$ g++-13 -g -std=c++23 a.cpp -o a  -lstdc++_libbacktrace



When compiled with GCC 13 or GCC 14, the program output is weird:

$ ./a 
   0#  at :32764
   1#  at :32764
   2#  at :32764
   3#  at :32764
   4# 

The number 32764 changes randomly between program calls, in the range 32764 ..
32767.


When compiled with GCC 12, the program crashes with a segmentation fault:

(gdb) bt
#0  0x in ?? ()
#1  0xad41 in elf_nodebug (state=, pc=, callback=, data=, error_callback=) at elf.c:585
#2  elf_nodebug (state=, pc=, callback=, error_callback=, data=) at elf.c:565
#3  0x7c0f in std::stacktrace_entry::_M_get_info
(this=0x5557e2b0, __desc=0x7fffdb60, __file=0x7fffdb80,
__line=0x7fffdb5c) at
/usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12/stacktrace:191
#4  0x7db2 in std::operator<< (__os=..., __f=...) at
/usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12/stacktrace:722
#5  0x85ce in std::operator<<
 > (__os=..., __st=...) at
/usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12/stacktrace:737
#6  0x7492 in main () at a.cpp:8

Here, parameter `state` of function elf_nodebug points to:
(gdb) p *__state
$10 = {filename = 0x0, threaded = 1, lock = 0x0, fileline_fn = 0xa5f0
, fileline_data = 0x0, syminfo_fn = 0xa5d0 ,
syminfo_data = 0x0, fileline_initialization_failed = 0, lock_alloc = 0,
freelist = 0x77fc4048}

and error_callback is NULL, which causes the segmentation fault.

[Bug target/107481] bpf: add __builtin_preserve_enum_value

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #2 from Jose E. Marchesi  ---
fixed.

[Bug target/107480] bpf: add __builtin_preserve_type_info

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #2 from Jose E. Marchesi  ---
Fixed.

[Bug target/107479] bpf: add __builtin_btf_type_id

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

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

--- Comment #2 from Jose E. Marchesi  ---
The patch above fixes this.

[Bug middle-end/112321] [14 Regression] ICE during GIMPLE pass: dse: : Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

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

[Bug middle-end/112321] New: [14 Regression] ICE during GIMPLE pass: dse: : Segmentation fault

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

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

Bug ID: 112321
   Summary: [14 Regression] ICE during GIMPLE pass: dse: :
Segmentation fault
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed ICE on today's gcc-master at r14-5043-g2b19c387696b0d. There it fails
to build binutils' gold. Extracted sample:

// $ cat bug.cc

void writeval(unsigned char *, long);
unsigned do_write_count;
void do_write() {
  unsigned char *pov;
  int limit(do_write_count > 8 ? true : do_write_count);
  for (int i = 0; i < limit; ++i)
pov += 2;
  int ext_cnt = do_write_count - 8;
  for (; 0 < ext_cnt;) {
writeval(pov, 0);
pov += 4;
ext_cnt--;
  }
}

Crashing:

$ gcc/xg++ -B./gcc -g -O1 -c bug.cc -o a.o
during GIMPLE pass: dse
bug.cc: In function ‘void do_write()’:
bug.cc:3:6: internal compiler error: Segmentation fault
3 | void do_write() {
  |  ^~~~
0x8ebef5a crash_signal
gcc/toplev.cc:315
0x8b42800 phi_nodes_ptr(basic_block_def*)
gcc/gimple.h:4700
0x8b42800 gsi_start_phis(basic_block_def*)
gcc/gimple-iterator.cc:935
0x8b42800 gsi_for_stmt(gimple*)
gcc/gimple-iterator.cc:620
0x9121a03 insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*)
gcc/tree-ssa.cc:471
0x9121f2e insert_debug_temps_for_defs(gimple_stmt_iterator*)
gcc/tree-ssa.cc:506
0x8b42690 gsi_remove(gimple_stmt_iterator*, bool)
gcc/gimple-iterator.cc:567
0x8ffe08b execute
gcc/tree-ssa-dse.cc:1685

$ gcc/xg++ -Bgcc -v
Reading specs from ./gcc/specs
COLLECT_GCC=./gcc/xg++
COLLECT_LTO_WRAPPER=./gcc/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231031 (experimental) (GCC)

[Bug tree-optimization/112312] -O3 produces worse code than -O2 for std::ranges::lower_bound in some cases, not marking a loop as finite

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-31
 Ever confirmed|0   |1
Summary|-O3 produces worse code |-O3 produces worse code
   |than -O2 for|than -O2 for
   |std::ranges::lower_bound in |std::ranges::lower_bound in
   |some cases, not removing an |some cases, not marking a
   |empty loop  |loop as finite
 Status|UNCONFIRMED |NEW

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

So further difference is the loop seems not to be marked as finite while with
-O2 (or the non-lamdba version) is.

Someone will need to figure out if and where we lose the idea of the finite
loopness.

[Bug tree-optimization/112312] GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization

--- Comment #2 from Andrew Pinski  ---
The difference is when inlining happens of specific functions.
at -O3, more functions are inlined during the early inlining phase while they
happen at -O2 during later on.

[Bug middle-end/112312] GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda

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

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

--- Comment #1 from Andrew Pinski  ---
-O2 produces good code while -O3 does not ...

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
As expected:

$ git bisect good 1cf5dc05c678232b
e3da1d7bb288c8c864f0284bc4bc5877b466a2f7 is the first bad commit
commit e3da1d7bb288c8c864f0284bc4bc5877b466a2f7
Author: Richard Biener 
Date:   Tue Oct 31 10:13:13 2023 +0100

tree-optimization/112305 - SCEV cprop and conditional undefined overflow

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #1 from David Binderman  ---
I have a reduction running. Current range is g:711d703d07c8e924
to g:e3da1d7bb288c8c8.

Reviewing those 4 revisions, I suspect Richard's commit
g:e3da1d7bb288c8c864f0284bc4bc5877b466a2f7

Adding Richard for their opinion.

[Bug pch/112319] [14 Regression] segfault with pch and #pragma GCC diagnostic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|segfault with pch and   |[14 Regression] segfault
   |#pragma GCC diagnostic  |with pch and #pragma GCC
   ||diagnostic
   Keywords||ice-on-valid-code

[Bug pch/112319] segfault with pch and #pragma GCC diagnostic

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org
   Last reconfirmed||2023-10-31
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Lewis Hyatt  ---
Thanks, I see it (with u.h containing a #pragma GCC diagnostic as its first
line). Will sort that out.

[Bug c++/111703] [11/12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work|11.4.0  |10.5.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Keywords|needs-bisection,|
   |needs-reduction |
  Known to fail||11.4.0
   Target Milestone|12.4|11.5
 Status|NEW |ASSIGNED
Summary|[12/13/14 Regression]   |[11/12/13/14 Regression]
   |[C++20]Compiler fails when  |[C++20]Compiler fails when
   |using generic lambda in |using generic lambda in
   |specific situation  |specific situation since
   ||r11-550-gf65a3299a521a4

--- Comment #4 from Patrick Palka  ---
Reduced testcase exhibitng an 11 regression:

template
constexpr bool always_true() { return true; }

struct P {
  P() = default;

  template
requires (always_true())
  constexpr P(const T&) { }

  int n, m;
};

void (*f)(P);

template
constexpr bool h() {
  P x;
  f(x);
  return true;
}

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|crash from  |[14 Regression] crash from
   |insert_debug_temp_for_var_d |insert_debug_temp_for_var_d
   |ef  |ef

[Bug c/112320] New: crash from insert_debug_temp_for_var_def

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 112320
   Summary: crash from insert_debug_temp_for_var_def
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C code:

unsigned void0_effective_addr2;
void0_i, void0_m, void0_p2;
void0() {
  void0_m = 800 - (void0_effective_addr2 & 5);
  int b1;
  void0_i = 0;
  for (; void0_i < void0_m; void0_i++)
b1++;
  void0_p2 = b1++;
}

when compiled by recent gcc trunk, does this:

$ ~/gcc/results/bin/gcc -c -w -g -O1 bug972.c
during GIMPLE pass: dse
bug972.c: In function ‘void0’:
bug972.c:3:1: internal compiler error: Segmentation fault
3 | void0() {
  | ^
0xebbce9 crash_signal(int)
../../trunk.year/gcc/toplev.cc:315
0xaa2308 gsi_for_stmt(gimple*)
../../trunk.year/gcc/gimple-iterator.cc:0
0x11364ea insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*)
../../trunk.year/gcc/tree-ssa.cc:471

The bug first seems to occur sometime between g:8c40b72036c967fb
and g:9119b008b4195e06, which is 35 commits.

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

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

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

--- Comment #3 from Jonathan Wakely  ---
As this bug points out, we probably want to warn for any uses of deprecated
entities declared in user code, whether used in system headers or in user code.

And for something like std::auto_ptr which is declared in a system header, we
want to warn if it's used in user code.

So I think we should only suppress the warning when the declaration *and* the
use are both in system headers.

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-10-31

--- Comment #2 from Jonathan Wakely  ---
Yes, the use of the deprecated function occurs in a system header, so it's
suppressed. There's not really anything libstdc++ can do here.

It seems to me that the front-end should consider the context where the
deprecated function is declared as well as where it's used. If the declaration
is not in a system header, then the use in a system header is probably a
template instantiation involving a user's type. In which case, it's not
"system" code, and should trigger the deprecated warning.

[Bug fortran/98458] ICE in gfc_conv_array_initializer due to array expressions within implied do-loop

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #11 from Paul Thomas  ---
I am closing this as fixed, as I should have done a long time ago. Thanks for
the report.

Best regards

Paul

[Bug pch/112319] New: segfault with pch and #pragma GCC diagnostic

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

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

Bug ID: 112319
   Summary: segfault with pch and #pragma GCC diagnostic
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

touch s.h
touch u.h

main.cpp:
#include "s.h"
#include "u.h"

g++ s.h
g++ -c main.cpp --save-temps
In file included from main.cpp:2:
u.h:1:9: internal compiler error: Segmentation fault
1 | #pragma GCC diagnostic
  | ^~~
0x1764fbf crash_signal
/home/andreas/build/../gcc/gcc/toplev.cc:314
0x10201cd maybe_read_tokens_for_pragma_lex
/home/andreas/build/../gcc/gcc/cp/parser.cc:49713
0x10201cd pragma_lex(tree_node**, unsigned int*)
/home/andreas/build/../gcc/gcc/cp/parser.cc:49735
0x11a962c pragma_diagnostic_lex
/home/andreas/build/../gcc/gcc/c-family/c-pragma.cc:851
0x11a9d78 handle_pragma_diagnostic_impl
/home/andreas/build/../gcc/gcc/c-family/c-pragma.cc:879
0x11a9d78 handle_pragma_diagnostic_early_pp
/home/andreas/build/../gcc/gcc/c-family/c-pragma.cc:1039
0x11abdbd c_pp_invoke_early_pragma_handler(unsigned int)
/home/andreas/build/../gcc/gcc/c-family/c-pragma.cc:1769
0x11a8180 token_streamer::stream(cpp_reader*, cpp_token const*, unsigned int)
/home/andreas/build/../gcc/gcc/c-family/c-ppoutput.cc:293
0x11a8461 scan_translation_unit
/home/andreas/build/../gcc/gcc/c-family/c-ppoutput.cc:351
0x11a8461 preprocess_file(cpp_reader*)
/home/andreas/build/../gcc/gcc/c-family/c-ppoutput.cc:106
0x11a693d c_common_init()
/home/andreas/build/../gcc/gcc/c-family/c-opts.cc:1236
0xfa35be cxx_init()
/home/andreas/build/../gcc/gcc/cp/lex.cc:338
0xe94153 lang_dependent_init
/home/andreas/build/../gcc/gcc/toplev.cc:1816
0xe94153 do_compile
/home/andreas/build/../gcc/gcc/toplev.cc:2111
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.

Can be reproduced on x86 and s390x since:

e664ea960a200aac88ffc3c7fb9fe55ea4df2011 is the first bad commit
commit e664ea960a200aac88ffc3c7fb9fe55ea4df2011 
Author: Lewis Hyatt   
Date:   Fri Jun 30 18:23:24 2023 -0400  

c-family: Implement pragma_lex () for preprocess-only mode

[Bug fortran/103854] ICE in generate_finalization_wrapper, at fortran/class.c:1618 since r8-4344-gaea5e9327a49bc73

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
Fixed on 13-branch, which is as far back as I go these day.

Closing

Thanks for the report

Paul

[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

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

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

Sam James  changed:

   What|Removed |Added

  Build|s390-ibm-linux-gnu  |s390-ibm-linux-gnu,
   ||s390x-ibm-linux-gnu
   Host|s390-ibm-linux-gnu  |s390-ibm-linux-gnu,
   ||s390x-ibm-linux-gnu
 Target|s390-ibm-linux-gnu  |s390-ibm-linux-gnu,
   ||s390x-ibm-linux-gnu

--- Comment #5 from Sam James  ---
same on s390x, but slightly different bt:

```
during GIMPLE pass: ccp
/tmp/foo.c:12:6: internal compiler error: Segmentation fault
   12 | void cipher_bulk_ops_t() {
  |  ^
0x2aa184f30c9 crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/toplev.cc:315
0x2aa17e02af2 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned
long>)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/emit-rtl.cc:1031
0x2aa18ab2d43 expand_perm_as_a_vlbr_vstbr_candidate
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/config/s390/s390.cc:17744
0x2aa18ab2d43 vectorize_vec_perm_const_1
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/config/s390/s390.cc:17782
0x2aa18ab2d43 s390_vectorize_vec_perm_const(machine_mode, machine_mode,
rtx_def*, rtx_def*, rtx_def*, vec_perm_indices const&)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/config/s390/s390.cc:17835
0x2aa18ab2d43 s390_vectorize_vec_perm_const(machine_mode, machine_mode,
rtx_def*, rtx_def*, rtx_def*, vec_perm_indices const&)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/config/s390/s390.cc:17793
0x2aa182bc58b can_vec_perm_const_p(machine_mode, machine_mode, vec_perm_indices
const&, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/optabs-query.cc:451
0x2aa18c0572b gimple_simplify_VEC_PERM_EXPR(gimple_match_op*, gimple**,
tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*,
tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/build/gcc/gimple-match-6.cc:16580
0x2aa18d45359 gimple_simplify(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/build/gcc/gimple-match-10.cc:16772
0x2aa18d49b31 gimple_resimplify3
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/gimple-match-exports.cc:1077
0x2aa18d4cd39 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/gimple-match-exports.cc:868
0x2aa17f5780f gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/gimple-fold.cc:7543
0x2aa186a3cfd ccp_fold
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-ccp.cc:1288
0x2aa186a3cfd evaluate_stmt
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-ccp.cc:2226
0x2aa186a6013 visit_assignment
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-ccp.cc:2860
0x2aa187b3fe3 ssa_propagation_engine::simulate_stmt(gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-propagate.cc:221
0x2aa187b43ad ssa_propagation_engine::simulate_block(basic_block_def*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-propagate.cc:328
0x2aa187b4a1d ssa_propagation_engine::ssa_propagate()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-propagate.cc:478
0x2aa1869953f do_ssa_ccp
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-ccp.cc:2979
0x2aa1869953f execute
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231029/gcc-14-20231029/gcc/tree-ssa-ccp.cc:3025
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/112296] __builtin_constant_p doesn't propagate through member functions

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #12 from joseph at codesourcery dot com  ---
I agree that the side effects of an argument to __builtin_constant_p must 
be discarded, for the original macro use case to work properly.

There are various constructs with __builtin_* names that, although they 
look like function calls, in fact have syntactic or semantic differences 
from what can be done with a normal function call.  In the cases of 
syntactic differences, they are actually keywords and handled specially in 
the parsers.  That's probably not relevant here, because the issue is 
semantics of the call (argument not evaluated) rather than the syntax, but 
it does illustrate how it's reasonable to have special handling for some 
__builtin_* construct when needed for its semantics.

[Bug target/111416] [Armv7/v8 Mixing Bug]: 64-bit Sequentially Consistent Load can be Reordered before Store of RMW when v7 and v8 Implementations are Mixed

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/111416] [Armv7/v8 Mixing Bug]: 64-bit Sequentially Consistent Load can be Reordered before Store of RMW when v7 and v8 Implementations are Mixed

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

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

Wilco  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111235

--- Comment #3 from Wilco  ---
Fixed by commit r14-4365-g0731889c026bfe8d55c4851422ca5ec9d037f7a0 

#include 
#include 

int64_t f (_Atomic int64_t *p)
{
  return atomic_load (p);
}

now generates with -O2 -mcpu=cortex-a15:

dmb ish
ldrdr0, r1, [r0]
dmb ish
bx  lr

[Bug target/111416] [Armv7/v8 Mixing Bug]: 64-bit Sequentially Consistent Load can be Reordered before Store of RMW when v7 and v8 Implementations are Mixed

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #2 from Wilco  ---
Fixed by commit r14-4365-g0731889c026bfe8d55c4851422ca5ec9d037f7a0 

#include 
#include 

int64_t f (_Atomic int64_t *p)
{
  return atomic_load (p);
}

now generates with -O2 -mcpu=cortex-a15:

dmb ish
ldrdr0, r1, [r0]
dmb ish
bx  lr

[Bug target/111235] [Armv7-a]: Control-dependency between atomic accesses removed by -O1.

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/111235] [Armv7-a]: Control-dependency between atomic accesses removed by -O1.

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #6 from Wilco  ---
Fixed

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Andrew Pinski  ---
-Wsystem-headers enables the warning. Front-end issue ...

[Bug libstdc++/112318] New: Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[enolan at alumni dot cmu.edu via Gcc-bugs]

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

Bug ID: 112318
   Summary: Deprecated move ctor does not trigger
-Wdeprecated-declarations when creating a
std::optional
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enolan at alumni dot cmu.edu
  Target Milestone: ---

When constructing a std::optional value for a type whose move ctor is marked
deprecated that invokes its move ctor, -Wdeprecated-declarations is not
triggered.

Compiler explorer link: https://godbolt.org/z/EPveeoEfn

Minimal reproduction:

#include 

struct foo {
foo() {}
[[deprecated]] foo(foo&&);
};

void bar() {
std::optional quux{foo{}};
}

> the exact version of gcc

g++ (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4)

> the system type

Fedora release 38 (Thirty Eight)

> the options given when GCC was configured/built

Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.2.1-20231011/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1

> the complete command line that triggers the bug

g++ -c -Werror=deprecated-declarations poc.cpp

> the compiler output

[Bug analyzer/112317] New: Latest set of clang warnings

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 112317
   Summary: Latest set of clang warnings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

>From a clang build of gcc trunk, I get

$ grep /analyzer/ mk.out
../../trunk.year/gcc/analyzer/access-diagram.cc:976:26: warning: private field
'm_col_widths' is not used [-Wunused-private-field]
../../trunk.year/gcc/analyzer/region-model.cc:1914:20: warning: unused variable
'limited_sval' [-Wunused-variable]
../../trunk.year/gcc/analyzer/region-model.cc:1884:16: warning: unused variable
'strlen_sval' [-Wunused-variable]
../../trunk.year/gcc/analyzer/region-model.h:892:8: warning: 'warn' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
$ 

Given that these have been hanging around for weeks, it might be worth fixing
them.

[Bug tree-optimization/110501] Invalid use-after-free / realloc with a store/load happening

[jhb at FreeBSD dot org via Gcc-bugs]

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

John Baldwin  changed:

   What|Removed |Added

 CC||jhb at FreeBSD dot org

--- Comment #7 from John Baldwin  ---
I believe I am hitting this same issue using GCC 13 to compile FreeBSD's
userland. (I looked through several of the other bugs for the Wuse-after-free
metabug and this one seems the closest to what I'm encountering).  The code in
question does not trigger the -Wuse-after-free warning when using GCC 12, but
now triggers the warning with GCC 13.  It is just calling free on the old value
after realloc fails which should be safe.  The simplest version I've
encountered so far in FreeBSD's tree is this:

static int
group_resize(void)
{
char *buf;

if (gbufsize == 0)
gbufsize = 1024;
else
gbufsize *= 2;

buf = gbuffer;
gbuffer = realloc(buf, gbufsize);
if (gbuffer == NULL) {
free(buf);
gbufsize = 0;
return (ENOMEM);
}
memset(gbuffer, 0, gbufsize);

return (0);
}

The warning triggers on the call to free:

lib/libcasper/services/cap_grp/cap_grp.c: In function 'group_resize':
lib/libcasper/services/cap_grp/cap_grp.c:65:17: error: pointer 'buf' may be
used after 'realloc' [-Werror=use-after-free]
   65 | free(buf);
  | ^
lib/libcasper/services/cap_grp/cap_grp.c:63:19: note: call to 'realloc'
here
   63 | gbuffer = realloc(buf, gbufsize);
  |   ^~

[Bug tree-optimization/112310] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-1161-g5476de2618f

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

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

--- Comment #2 from Richard Biener  ---
So this really asks for the change to be reverted which requires us to
"properly" handle virtual operands in the expression sets.  Namely in
compute_avail populate EXP_GEN with reference expressions with the
virtual operand live at the start of the block.  And in prune_clobbered_mems
rewrite them as well.

[Bug rtl-optimization/111971] [12/13/14 regression] ICE: maximum number of generated reload insns per insn achieved (90) since r12-6803-g85419ac59724b7

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

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

--- Comment #7 from CVS Commits  ---
The trunk branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:9119b008b4195e06012a485ec01a8bb0e43266be

commit r14-5037-g9119b008b4195e06012a485ec01a8bb0e43266be
Author: Vladimir N. Makarov 
Date:   Tue Oct 31 10:54:43 2023 -0400

[RA]: Fixing LRA cycling for multi-reg variable containing a fixed reg

PR111971 test case uses a multi-reg variable containing a fixed reg.  LRA
rejects such multi-reg because of this when matching the constraint for
an asm insn.  The rejection results in LRA cycling.  The patch fixes this
issue.

gcc/ChangeLog:

PR rtl-optimization/111971
* lra-constraints.cc: (process_alt_operands): Don't check start
hard regs for regs originated from register variables.

gcc/testsuite/ChangeLog:

PR rtl-optimization/111971
* gcc.target/powerpc/pr111971.c: New test.

[Bug c++/112315] 32-bit numeric conversion functions missing - only wstring versions defined

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Jonathan Wakely  ---
Let's close as MOVED.

[Bug c++/112315] 32-bit numeric conversion functions missing - only wstring versions defined

[mccannd at uk dot ibm.com via Gcc-bugs]

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

--- Comment #2 from mccannd at uk dot ibm.com ---
OK, thanks. I had just started using Fedora 39. I assume this bug can be closed
then.

[Bug libstdc++/112314] Missing index assertions in basic_string_view

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-31
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  ---
For the first problem:

--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -301,7 +301,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   constexpr void
   remove_suffix(size_type __n) noexcept
-  { this->_M_len -= __n; }
+  {
+   __glibcxx_assert(this->_M_len >= __n);
+   this->_M_len -= __n;
+  }

   constexpr void
   swap(basic_string_view& __sv) noexcept


For the second one, I did start work on a patch that attempts to verify that
the provided length is not more than __builtin_object_size. I can't remember
why I stopped working on that. There's no way to make that check 100% reliable,
because __builtin_object_size depends on optimizations and whether the compiler
can see enough data.

[Bug c++/112315] 32-bit numeric conversion functions missing - only wstring versions defined

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=2246731

--- Comment #1 from Jonathan Wakely  ---
I think this is a Fedora packaging problem:
https://bugzilla.redhat.com/show_bug.cgi?id=2246731

My builds of upstream GCC 13 work correctly.

[Bug fortran/112316] New: [13 Regression] Fix for PR87477 rejects valid code with a bogus error about pointer assignment and causes an ICE

[trnka at scm dot com via Gcc-bugs]

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

Bug ID: 112316
   Summary: [13 Regression] Fix for PR87477 rejects valid code
with a bogus error about pointer assignment and causes
an ICE
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trnka at scm dot com
  Target Milestone: ---

Current releases/gcc-13 rejects the following testcase (compiled simply using
gfortran -c test-bogus-pointer-arg-error.f90):

= test-bogus-pointer-arg-error.f90 =
module BogusPointerArgError
   implicit none

   type :: AType
   end type

contains

   subroutine A ()

  class(AType), allocatable :: x

  allocate(x)
  call B (x)
   end subroutine

   subroutine B (y)
  class(AType), intent(in):: y
   end subroutine

   subroutine C (z)
  class(AType), intent(in) :: z(:)

  associate (xxx => z(1))
  end associate

   end subroutine

end module
==

   14 |   call B (x)
  |  1
Error: Actual argument for ‘y’ at (1) must be a pointer or a valid target for
the dummy pointer in a pointer assignment statement

Apparently, both the associate block in C (which is never called) and routines
A and B need to be present to trigger the issue. It also seems to only happen
when "x" is polymorphic (class(AType)).

A related testcase is also rejected, this time with an ICE:

= test-ICE-get_descriptor_field.f90 =
module AModule
   implicit none
   private

   public AType

   type, abstract :: AType
   contains
  generic, public :: assignment(=) => Assign

  procedure, private :: Assign
   end type AType

contains

   subroutine Assign(lhs, rhs)
  class(AType), intent(inout) :: lhs
  class(AType), intent(in):: rhs
   end subroutine

end module AModule



module ICEGetDescriptorField
   use AModule
   implicit none

contains

   subroutine Foo (x)
  class(AType), intent(in):: x(:)

  class(AType), allocatable :: y

  associate (xxx => x(1))
 y = xxx
  end associate
   end subroutine

end module ICEGetDescriptorField
==

test-ICE-get_descriptor_field.f90:38:16:

   38 |  y = xxx
  |1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.cc:245

This time, AType needs to be in a separate module and have a defined assignment
to trigger the bug.

Both issues bisect to the following commit. Reverting this change on top of
current releases/gcc-13 makes both issues go away. (GCC 14 is likely also
affected, not tested.)

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

commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540
Author: Paul Thomas 
Date:   Sun Aug 27 09:51:32 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

[Bug tree-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #11 from John David Anglin  ---
Fixed in gcc-7 and later.

[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #4 from Zdenek Sojka  ---
(In reply to Sam James from comment #3)
> I was confused at first until I realised rebuild_frequencies-all got turned
> into a proper pass in r14-2524-gaa6741ef2e0c31, so no bisection needed imo.

Even if -fdump-tree-all-all is used instead, the above is the first failing
commit.

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534' since r14-4796-g3e3d73ed5e85e7

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Thanks a lot, I can reproduce it now.  It turns out this PR and PR111703 can be
partially resolved by the same fix.

[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
So as for the original description of this bug - it's a feature then (unless it
gets clarified in another way).  Sorry.  I agree it's highly unintuitive and I
would hope we can eventually add diagnostics for __builtin_constant_p with
arguments that have side-effects.

At least the documentation should be amended.  Waiting for C/C++ frontend
maintainers to give an ACK, then I'll propose some wording for the
documentation.

Btw, clang also implements the weird semantics.

int g;
int bar () { if (!g) abort (); return 1; }

int main()
{
  return __builtin_constant_p (bar());
}

returns 0 and doesn't abort().

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #29 from Paul Thomas  ---
This was completely fixed way back when :-)

Thanks for the report, Damian.

Closing

Paul

[Bug c++/112315] New: 32-bit numeric conversion functions missing - only wstring versions defined

[mccannd at uk dot ibm.com via Gcc-bugs]

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

Bug ID: 112315
   Summary: 32-bit numeric conversion functions missing - only
wstring versions defined
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mccannd at uk dot ibm.com
  Target Milestone: ---

I created the following test program:


#include 

int main(int argc, char* argv[])
{
  std::string X = "my string";
  unsigned long long Y = std::stoull(X);
}


Using g++ 13.2.1, running the following fails:
$ g++ -m32 cpptest.cpp
cpptest.cpp: In function 'int main(int, char**)':
cpptest.cpp:6:38: error: invalid initialization of reference of type 'const
std::wstring&' {aka 'const std::__cxx11::basic_string&'} from
expression of type 'std::string' {aka 'std::__cxx11::basic_string'}
6 |   unsigned long long Y = std::stoull(X);
  |  ^
In file included from /usr/include/c++/13/string:54,
 from cpptest.cpp:1:
/usr/include/c++/13/bits/basic_string.h:4280:25: note: in passing argument 1 of
'long long unsigned int std::__cxx11::stoull(const std::wstring&, std::size_t*,
int)'
 4280 |   stoull(const wstring& __str, size_t* __idx = 0, int __base = 10)
  |  ~~~^

This appears to be because _GLIBCXX11_USE_C99_STDLIB is no longer defined in
/usr/include/c++/13/x86_64-redhat-linux/32/bits/c++config.h.

The same compilation using g++ 13.0.1 works fine.

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #8 from Li Pan  ---
Still fail in upstream.

../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc -march=rv64imafdcv
-mabi=lp64d \
  -ftree-vectorize -O3 --param riscv-autovec-preference=fixed-vlmax \
  --param riscv-autovec-lmul=dynamic --param vect-epilogues-nomask=0 \
  -ffast-math -lm
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
\
  -o test.elf

../build-qemu/qemu-riscv64 -cpu rv64,v=true,vlen=128,elen=64,vext_spec=v1.0
test.elf
assertion "dest_int32_t_int8_t[i * 2] == (src_int32_t_int8_t
[index_int32_t_int8_t[i * 2]] + 1)"
  failed: file
"gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c",
line 45, function: main

../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (GCC) 14.0.0 20231021 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

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

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

--- Comment #10 from Richard Biener  ---
Some history shows r0-31250-gb0b3afb2f34492 splitting this to the folding
code from RTL expansion of __builtin_constant_p where it previously was.
Even before r0-17364-gcff48d8f76463f we were simply doing

@@ -8566,10 +8579,34 @@ expand_builtin (exp, target, subtarget, mode, ignore)
  tree arg = TREE_VALUE (arglist);

  STRIP_NOPS (arg);
- return (TREE_CODE_CLASS (TREE_CODE (arg)) == 'c'
- || (TREE_CODE (arg) == ADDR_EXPR
- && TREE_CODE (TREE_OPERAND (arg, 0)) == STRING_CST)
- ? const1_rtx : const0_rtx);

and that dates back to r0-384-gbbf6f052d786c2, "Initial revision" of expr.c
from Kenner :/

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #7 from Li Pan  ---
Seems no luck when --param vect-epilogues-nomask=0. I will have a try with the
newest upstream for this issue if everything look OK, and keep you posted.

../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc -march=rv64imafdcv
-mabi=lp64d \
  -ftree-vectorize -O3 --param riscv-autovec-preference=fixed-vlmax \
  --param riscv-autovec-lmul=dynamic --param vect-epilogues-nomask=0 \
  -ffast-math -lm
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c
\
  -o test.elf

../build-qemu/qemu-riscv64 -cpu rv64,v=true,vlen=128,elen=64,vext_spec=v1.0
test.elf
assertion "dest_int32_t_int8_t[i * 2] == (src_int32_t_int8_t
[index_int32_t_int8_t[i * 2]] + 1)" failed: \
  file
"gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/gather_load_run-12.c",
line 45, function: main

../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (GCC) 14.0.0 20231019 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

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

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

--- Comment #9 from Richard Henderson  ---
> Thanks.  So yes,
> 
> macro(x++);
> 
> incrementing x twice would have been odd - but that's the usual bug
> in this kind of macro definition.  Fixing it by throwing away
> side-effects (and always going the out_of_line_function (x) path!)
> for the __builtin_constant_p argument is an odd choice.

In the beginning __builtin_constant_p was resolved immediately,
so formulating this as

#define macro(x) \
  ({ __typeof(x) _x = (x); \
 __builtin_constant_p(_x) })

would always return false, defeating the purpose.

> The execute.exp testcase suggests the intention but the testcases
> verification is somewhat incomplete (it lacks verifying the side-effects
> are gone).

That's probably my omission.  ;-)

[Bug target/112092] RISC-V: Suboptimal RVV code produced for vsetvl-11.c and vsetvlmax-8.c

[macro at orcam dot me.uk via Gcc-bugs]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

   Keywords|wrong-code  |missed-optimization
   Severity|normal  |enhancement
Summary|RISC-V: Wrong RVV code  |RISC-V: Suboptimal RVV code
   |produced for vsetvl-11.c|produced for vsetvl-11.c
   |and vsetvlmax-8.c   |and vsetvlmax-8.c

--- Comment #10 from Maciej W. Rozycki  ---
I see what you mean, thanks for straightening me out.  I've updated bug
summary and parameters accordingly.

[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Richard Henderson from comment #7)
> (In reply to Richard Biener from comment #5)
> > int bad1(void) { return __builtin_constant_p(global++); }
> ...
> > Joseph, Richard, do you have anything to add or remember discussions about
> > this semantic detail of __builtin_constant_p?
> 
> Since it has been 25 years, I don't recall any specific discussions.
> 
> The intended use-case at the time was more like
> 
> #define macro(x) \
>   (__builtin_constant_p(x) \
>? inline_expression(x)  \
>: out_of_line_function(x))
> 
> So I would have expected side effects to have been ignored for
> the builtin and expanded via one of the two arms.

Thanks.  So yes,

macro(x++);

incrementing x twice would have been odd - but that's the usual bug
in this kind of macro definition.  Fixing it by throwing away
side-effects (and always going the out_of_line_function (x) path!)
for the __builtin_constant_p argument is an odd choice.

As said, I wondered if that was deliberate or simply an omission of

   return omit_one_operand (integer_type_node, integer_zero_node, arg);

...

The execute.exp testcase suggests the intention but the testcases
verification is somewhat incomplete (it lacks verifying the side-effects
are gone).

[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

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

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

--- Comment #7 from Richard Henderson  ---
(In reply to Richard Biener from comment #5)
> int bad1(void) { return __builtin_constant_p(global++); }
...
> Joseph, Richard, do you have anything to add or remember discussions about
> this semantic detail of __builtin_constant_p?

Since it has been 25 years, I don't recall any specific discussions.

The intended use-case at the time was more like

#define macro(x) \
  (__builtin_constant_p(x) \
   ? inline_expression(x)  \
   : out_of_line_function(x))

So I would have expected side effects to have been ignored for
the builtin and expanded via one of the two arms.

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

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

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

--- Comment #6 from Richard Biener  ---
So I can see we don't recognize a gather IFN during pattern recog here.

t.c:15:1: note:   Final SLP tree for instance 0x502e9a0:
t.c:15:1: note:   node 0x4f84700 (max_nunits=128, refcnt=2) vector(32) float
t.c:15:1: note:   op template: *_10 = _11;
t.c:15:1: note: stmt 0 *_10 = _11;
t.c:15:1: note: stmt 1 *_20 = _21;
t.c:15:1: note: children 0x4f84790
t.c:15:1: note:   node 0x4f84790 (max_nunits=128, refcnt=2) vector(32) float
t.c:15:1: note:   op template: _11 = _8 + 1.0e+0;
t.c:15:1: note: stmt 0 _11 = _8 + 1.0e+0;
t.c:15:1: note: stmt 1 _21 = _18 + 2.0e+0;
t.c:15:1: note: children 0x4f84820 0x4f84940
t.c:15:1: note:   node 0x4f84820 (max_nunits=128, refcnt=2) vector(32) float
t.c:15:1: note:   op template: _8 = *_7;
t.c:15:1: note: stmt 0 _8 = *_7;
t.c:15:1: note: stmt 1 _18 = *_17;
t.c:15:1: note: children 0x4f848b0
t.c:15:1: note:   node 0x4f848b0 (max_nunits=128, refcnt=2) vector(128)
unsigned char
t.c:15:1: note:   op template: _4 = *_3;
t.c:15:1: note: stmt 0 _4 = *_3;
t.c:15:1: note: stmt 1 _14 = *_13;
t.c:15:1: note: load permutation { 0 1 }
t.c:15:1: note:   node (constant) 0x4f84940 (max_nunits=1, refcnt=1)
t.c:15:1: note: { 1.0e+0, 2.0e+0 }
t.c:15:1: note:=== vect_match_slp_patterns ===
t.c:15:1: note:Analyzing SLP tree 0x4f84700 for patterns
t.c:15:1: note:   === vect_make_slp_decision ===
t.c:15:1: note:   Decided to SLP 1 instances. Unrolling factor 64

it tries a few other modes, one even having .MASK_LEN_GATHER_LOAD but that
fails to build SLP.  In the end we choose

t.c:15:1: note:  * Choosing vector mode RVVM4QI
t.c:15:1: note:  * Choosing epilogue vector mode RVVMF4QI

the main loop instance is

t.c:15:1: note:   Vectorizing SLP tree:
t.c:15:1: note:   node 0x4f849d0 (max_nunits=64, refcnt=1) vector(32) float
t.c:15:1: note:   op template: *_10 = _11;
t.c:15:1: note: stmt 0 *_10 = _11;
t.c:15:1: note: stmt 1 *_20 = _21;
t.c:15:1: note: children 0x4f84a60
t.c:15:1: note:   node 0x4f84a60 (max_nunits=64, refcnt=1) vector(32) float
t.c:15:1: note:   op template: _11 = _8 + 1.0e+0;
t.c:15:1: note: stmt 0 _11 = _8 + 1.0e+0;
t.c:15:1: note: stmt 1 _21 = _18 + 2.0e+0;
t.c:15:1: note: children 0x4f84af0 0x4f84c10
t.c:15:1: note:   node 0x4f84af0 (max_nunits=64, refcnt=1) vector(32) float
t.c:15:1: note:   op template: _8 = *_7;
t.c:15:1: note: stmt 0 _8 = *_7;
t.c:15:1: note: stmt 1 _18 = *_17;
t.c:15:1: note: children 0x4f84b80
t.c:15:1: note:   node 0x4f84b80 (max_nunits=64, refcnt=1) vector(64) unsigned
char
t.c:15:1: note:   op template: _4 = *_3;
t.c:15:1: note: stmt 0 _4 = *_3;
t.c:15:1: note: stmt 1 _14 = *_13;
t.c:15:1: note:   node (constant) 0x4f84c10 (max_nunits=1, refcnt=1) vector(32)
float
t.c:15:1: note: { 1.0e+0, 2.0e+0 }

so the main loop uses emulated gather but the epilog uses non-SLP but
gathers here.

  # vectp_index.6_209 = PHI 
  # vectp_y.12_601 = PHI 
  vect__4.8_211 = MEM  [(uint8_t
*)vectp_index.6_209];
...
  MEM  [(float *)vectp_y.12_601] = vect__11.11_599;
  vectp_y.12_604 = vectp_y.12_601 + 128;
  MEM  [(float *)vectp_y.12_604] = vect__11.11_599;
...
  vectp_index.6_210 = vectp_index.6_209 + 64;
  vectp_y.12_602 = vectp_y.12_604 + 128;
  ivtmp_607 = ivtmp_606 + 1;
  if (ivtmp_607 < 3)

that IV updates look OK to me.

So not sure what to do?  Does the testcase execute correctly with
--param vect-epilogues-nomask=0 ?

[Bug bootstrap/54179] please split insn-emit.c !

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #35 from Sam James  ---
Done in

commit 184378027e92f51e02d3649e0ca523f487fd2810
Author: Robin Dapp 
Date:   Thu Oct 12 11:23:26 2023 +0200

genemit: Split insn-emit.cc into several partitions.

On riscv insn-emit.cc has grown to over 1.2 mio lines of code and
compiling it takes considerable time.
Therefore, this patch adjust genemit to create several partitions
(insn-emit-1.cc to insn-emit-n.cc).  The available patterns are
written to the given files in a sequential fashion.

Similar to match.pd a configure option --with-emitinsn-partitions=num
is introduced that makes the number of partition configurable.

gcc/ChangeLog:

PR bootstrap/84402
PR target/111600

* Makefile.in: Handle split insn-emit.cc.
* configure: Regenerate.
* configure.ac: Add --with-insnemit-partitions.
* genemit.cc (output_peephole2_scratches): Print to file instead
of stdout.
(print_code): Ditto.
(gen_rtx_scratch): Ditto.
(gen_exp): Ditto.
(gen_emit_seq): Ditto.
(emit_c_code): Ditto.
(gen_insn): Ditto.
(gen_expand): Ditto.
(gen_split): Ditto.
(output_add_clobbers): Ditto.
(output_added_clobbers_hard_reg_p): Ditto.
(print_overload_arguments): Ditto.
(print_overload_test): Ditto.
(handle_overloaded_code_for): Ditto.
(handle_overloaded_gen): Ditto.
(print_header): New function.
(handle_arg): New function.
(main): Split output into 10 files.
* gensupport.cc (count_patterns): New function.
* gensupport.h (count_patterns): Define.
* read-md.cc (md_reader::print_md_ptr_loc): Add file argument.
* read-md.h (class md_reader): Change definition.

for 14.

14 will therefore have both split insn-emit as well as *-match from tamar
earlier in the year, which makes life a lot easier with constrained resources.

I've also backported it downstream as well. I don't think anyone plans on doing
it upstream.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

Bug 54179 Summary: please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179

   What|Removed |Added

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

[Bug tree-optimization/111943] ICE in gimple_split_edge, at tree-cfg.cc:3019 on 20050510-1.c with new -fharden-control-flow-redundancy with computed gotos

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

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Fixed

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

--- Comment #71 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:184378027e92f51e02d3649e0ca523f487fd2810

commit r14-5034-g184378027e92f51e02d3649e0ca523f487fd2810
Author: Robin Dapp 
Date:   Thu Oct 12 11:23:26 2023 +0200

genemit: Split insn-emit.cc into several partitions.

On riscv insn-emit.cc has grown to over 1.2 mio lines of code and
compiling it takes considerable time.
Therefore, this patch adjust genemit to create several partitions
(insn-emit-1.cc to insn-emit-n.cc).  The available patterns are
written to the given files in a sequential fashion.

Similar to match.pd a configure option --with-emitinsn-partitions=num
is introduced that makes the number of partition configurable.

gcc/ChangeLog:

PR bootstrap/84402
PR target/111600

* Makefile.in: Handle split insn-emit.cc.
* configure: Regenerate.
* configure.ac: Add --with-insnemit-partitions.
* genemit.cc (output_peephole2_scratches): Print to file instead
of stdout.
(print_code): Ditto.
(gen_rtx_scratch): Ditto.
(gen_exp): Ditto.
(gen_emit_seq): Ditto.
(emit_c_code): Ditto.
(gen_insn): Ditto.
(gen_expand): Ditto.
(gen_split): Ditto.
(output_add_clobbers): Ditto.
(output_added_clobbers_hard_reg_p): Ditto.
(print_overload_arguments): Ditto.
(print_overload_test): Ditto.
(handle_overloaded_code_for): Ditto.
(handle_overloaded_gen): Ditto.
(print_header): New function.
(handle_arg): New function.
(main): Split output into 10 files.
* gensupport.cc (count_patterns): New function.
* gensupport.h (count_patterns): Define.
* read-md.cc (md_reader::print_md_ptr_loc): Add file argument.
* read-md.h (class md_reader): Change definition.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

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

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

--- Comment #28 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:184378027e92f51e02d3649e0ca523f487fd2810

commit r14-5034-g184378027e92f51e02d3649e0ca523f487fd2810
Author: Robin Dapp 
Date:   Thu Oct 12 11:23:26 2023 +0200

genemit: Split insn-emit.cc into several partitions.

On riscv insn-emit.cc has grown to over 1.2 mio lines of code and
compiling it takes considerable time.
Therefore, this patch adjust genemit to create several partitions
(insn-emit-1.cc to insn-emit-n.cc).  The available patterns are
written to the given files in a sequential fashion.

Similar to match.pd a configure option --with-emitinsn-partitions=num
is introduced that makes the number of partition configurable.

gcc/ChangeLog:

PR bootstrap/84402
PR target/111600

* Makefile.in: Handle split insn-emit.cc.
* configure: Regenerate.
* configure.ac: Add --with-insnemit-partitions.
* genemit.cc (output_peephole2_scratches): Print to file instead
of stdout.
(print_code): Ditto.
(gen_rtx_scratch): Ditto.
(gen_exp): Ditto.
(gen_emit_seq): Ditto.
(emit_c_code): Ditto.
(gen_insn): Ditto.
(gen_expand): Ditto.
(gen_split): Ditto.
(output_add_clobbers): Ditto.
(output_added_clobbers_hard_reg_p): Ditto.
(print_overload_arguments): Ditto.
(print_overload_test): Ditto.
(handle_overloaded_code_for): Ditto.
(handle_overloaded_gen): Ditto.
(print_header): New function.
(handle_arg): New function.
(main): Split output into 10 files.
* gensupport.cc (count_patterns): New function.
* gensupport.h (count_patterns): Define.
* read-md.cc (md_reader::print_md_ptr_loc): Add file argument.
* read-md.h (class md_reader): Change definition.

[Bug tree-optimization/111943] ICE in gimple_split_edge, at tree-cfg.cc:3019 on 20050510-1.c with new -fharden-control-flow-redundancy with computed gotos

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:15404016d96dca9132b952980cda24cae33b3ee0

commit r14-5033-g15404016d96dca9132b952980cda24cae33b3ee0
Author: Alexandre Oliva 
Date:   Tue Oct 31 09:32:08 2023 -0300

hardcfr: support checking at abnormal edges [PR111943]

Control flow redundancy may choose abnormal edges for early checking,
but that breaks because we can't insert checks on such edges.

Introduce conditional checking on the dest block of abnormal edges,
and leave it for the optimizer to drop the conditional.


for  gcc/ChangeLog

PR tree-optimization/111943
* gimple-harden-control-flow.cc: Adjust copyright year.
(rt_bb_visited): Add vfalse and vtrue data members.
Zero-initialize them in the ctor.
(rt_bb_visited::insert_exit_check_on_edge): Upon encountering
abnormal edges, insert initializers for vfalse and vtrue on
entry, and insert the check sequence guarded by a conditional
in the dest block.

for  libgcc/ChangeLog

* hardcfr.c: Adjust copyright year.

for  gcc/testsuite/ChangeLog

PR tree-optimization/111943
* gcc.dg/harden-cfr-pr111943.c: New.

[Bug middle-end/112305] [11/12/13 Regression] Wrong code at -O1/2/3/s on x86_64-pc-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
   Priority|P3  |P2
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Wrong
   |Wrong code at -O1/2/3/s on  |code at -O1/2/3/s on
   |x86_64-pc-linux-gnu |x86_64-pc-linux-gnu

[Bug middle-end/112305] [11/12/13/14 Regression] Wrong code at -O1/2/3/s on x86_64-pc-linux-gnu

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

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

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

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

commit r14-5032-ge3da1d7bb288c8c864f0284bc4bc5877b466a2f7
Author: Richard Biener 
Date:   Tue Oct 31 10:13:13 2023 +0100

tree-optimization/112305 - SCEV cprop and conditional undefined overflow

The following adjusts final value replacement to also rewrite the
replacement to defined overflow behavior if there's conditionally
evaluated stmts (with possibly undefined overflow), not only when
we "folded casts".  The patch hooks into expression_expensive for
this.

PR tree-optimization/112305
* tree-scalar-evolution.h (expression_expensive): Adjust.
* tree-scalar-evolution.cc (expression_expensive): Record
when we see a COND_EXPR.
(final_value_replacement_loop): When the replacement contains
a COND_EXPR, rewrite it to defined overflow.
* tree-ssa-loop-ivopts.cc (may_eliminate_iv): Adjust.

* gcc.dg/torture/pr112305.c: New testcase.

[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16

[zhangjungcc at gmail dot com via Gcc-bugs]

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

jun zhang  changed:

   What|Removed |Added

 CC||zhangjungcc at gmail dot com

--- Comment #2 from jun zhang  ---
  The following loop couldn't vectorize in gcc, but could in llvm. it has 3%
improvement.
more info, please refer: https://godbolt.org/z/zMbjq41h5

#include
typedef signed int  OPJ_INT32;
typedef unsigned int OPJ_UINT32;
typedef int OPJ_BOOL;
#define OPJ_TRUE 1
#define OPJ_FALSE 0
typedef char  OPJ_CHAR;
typedef float OPJ_FLOAT32;
typedef doubleOPJ_FLOAT64;
typedef unsigned char OPJ_BYTE;
#define T1_NMSEDEC_FRACBITS 6
#define OPJ_RESTRICT restrict
#define OPJ_TLS_KEY_T1  0
#include 
typedef size_t   OPJ_SIZE_T;

typedef struct opj_tcd_cblk_enc {
OPJ_BYTE* data;   /* Data */
//opj_tcd_layer_t* layers;  /* layer information */
//opj_tcd_pass_t* passes;   /* information about the passes */
OPJ_INT32 x0, y0, x1,
  y1; /* dimension of the code-blocks : left upper corner (x0,
y0) right low corner (x1,y1) */
OPJ_UINT32 numbps;
OPJ_UINT32 numlenbits;
OPJ_UINT32 data_size; /* Size of allocated data buffer */
OPJ_UINT32
numpasses; /* number of pass already done for the code-blocks */
OPJ_UINT32 numpassesinlayers; /* number of passes in the layer */
OPJ_UINT32 totalpasses;   /* total number of passes */
} opj_tcd_cblk_enc_t;
typedef struct opj_t1 {

/** MQC component */
//opj_mqc_t mqc;

OPJ_INT32  *data;
/** Flags used by decoder and encoder.
 * Such that flags[1+0] is for state of col=0,row=0..3,
   flags[1+1] for col=1, row=0..3, flags[1+flags_stride] for
col=0,row=4..7, ...
   This array avoids too much cache trashing when processing by 4 vertical
samples
   as done in the various decoding steps. */
//opj_flag_t *flags;

OPJ_UINT32 w;
OPJ_UINT32 h;
OPJ_UINT32 datasize;
OPJ_UINT32 flagssize;
OPJ_BOOL   encoder;

/* Thre 3 variables below are only used by the decoder */
/* set to TRUE in multithreaded context */
OPJ_BOOL mustuse_cblkdatabuffer;
/* Temporary buffer to concatenate all chunks of a codebock */
OPJ_BYTE*cblkdatabuffer;
/* Maximum size available in cblkdatabuffer */
OPJ_UINT32   cblkdatabuffersize;
} opj_t1_t;

#define INLINE __inline__
static INLINE OPJ_INT32 opj_int_max(OPJ_INT32 a, OPJ_INT32 b)
{
return (a > b) ? a : b;
}
#define opj_to_smr(x)   ((x) >= 0 ? (OPJ_UINT32)(x) : ((OPJ_UINT32)(-x) |
0x8000U))
OPJ_FLOAT64 opj_t1_encode_cblk(opj_t1_t *t1,
  opj_tcd_cblk_enc_t* cblk,
  OPJ_UINT32 orient,
  OPJ_UINT32 compno,
  OPJ_UINT32 level,
  OPJ_UINT32 qmfbid,
  OPJ_FLOAT64 stepsize,
  OPJ_UINT32 cblksty,
  OPJ_UINT32 numcomps,
  const OPJ_FLOAT64 * mct_norms,
  OPJ_UINT32 mct_numcomps)
{
OPJ_INT32 max;
OPJ_UINT32 i, j;
OPJ_INT32* datap;

max = 0;
datap = t1->data;
for (j = 0; j < t1->h; ++j) {
const OPJ_UINT32 w = t1->w;
for (i = 0; i < w; ++i, ++datap) {
OPJ_INT32 tmp = *datap;
if (tmp < 0) {
OPJ_UINT32 tmp_unsigned;
max = opj_int_max(max, -tmp);
tmp_unsigned = opj_to_smr(tmp);
memcpy(datap, _unsigned, sizeof(OPJ_INT32));
} else {
max = opj_int_max(max, tmp);
}
}
}
cblk->numbps = max ? 6 : 0;
}

[Bug libstdc++/112314] New: Missing index assertions in basic_string_view

[jdapena at igalia dot com via Gcc-bugs]

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

Bug ID: 112314
   Summary: Missing index assertions in basic_string_view
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

While testing Chromium base unit tests with _GLIBCXX_ASSERTIONS=1, that include
checks for base::StringPiece, that wraps nowadays std::string_view, two unit
tests are failing because they are expected to assert and they don't.

One failing tests is:
  {
StringPiece piece;
ASSERT_DEATH_IF_SUPPORTED(piece.remove_suffix(1), "");
  }

In this case, std::basic_string_view::remove_suffix should check if the index
provided is valid.

Another failing test is:

  int length = -1;
  ASSERT_DEATH_IF_SUPPORTED({ StringPiece piece("hello", length); }, "");

In this case, std::basic_string_view::basic_string_view(const _CharT* __str,
size_type __len) is not validating that __len is a valid index for __str.

[Bug target/112308] [14 Regression] GCN: 'error: literal operands are not supported' for 'v_add_co_u32'

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/112310] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-1161-g5476de2618f

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/112310] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-1161-g5476de2618f

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |14.0
   Last reconfirmed||2023-10-31
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed.  We hoist _4 * 2022160547, which is the signed representation.

_4 = *h.4_3;
if (_4 >= -1)
  goto ; [50.00%]
else
  goto ; [50.00%]

 [local count: 477815112]:
iftmp.1_43 = _4 * 2022160547;
p.5_51 = (unsigned int) iftmp.1_43;
_52 = p.5_51 * 2022160547;
_53 = b_lsm.36_24;
_54 = (short int) _52;
_55 = _53 ^ _54;

 [local count: 477815112]:
p.5_7 = (unsigned int) _4;
_36 = p.5_7 * 2022160547;
_45 = b_lsm.36_24;
_46 = (short int) _36;
_47 = _45 ^ _46;
goto ; [100.00%]

[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

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

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

--- Comment #3 from Sam James  ---
I was confused at first until I realised rebuild_frequencies-all got turned
into a proper pass in r14-2524-gaa6741ef2e0c31, so no bisection needed imo.

[Bug target/112313] New: [14 Regression] GCN target 'gcc.dg/pr111082.c' ICE, 'during RTL pass: vregs': 'error: unrecognizable insn'

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

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

Bug ID: 112313
   Summary: [14 Regression] GCN target 'gcc.dg/pr111082.c' ICE,
'during RTL pass: vregs': 'error: unrecognizable insn'
   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: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

(Assuming my tacking is to be believed) something in Git commit
r14-2060-gad5ab848cc487b3f7fd82c7cb3c408747bd10422..r14-3575-g7f2ed06ddc825e8a4e0edfd1d66b5156e6dc1d34
triggers a new GCN target ICE (tested '-march=gfx90a'):

[...]/gcc/testsuite/gcc.dg/pr111082.c: In function 'minarray2':
[...]/gcc/testsuite/gcc.dg/pr111082.c:10:1: error: unrecognizable insn:
(insn 10 9 11 2 (set (reg:V2DI 433)
(smin:V2DI (reg:V2DI 434)
(reg:V2DI 430))) -1
 (nil))
during RTL pass: vregs
[...]/gcc/testsuite/gcc.dg/pr111082.c:10:1: internal compiler error: in
extract_insn, at recog.cc:2791
0x74b91f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
[...]/gcc/rtl-error.cc:108
0x74b9a0 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
[...]/gcc/rtl-error.cc:116
0xed182e extract_insn(rtx_insn*)
[...]/gcc/recog.cc:2791
0xb42cfc instantiate_virtual_regs_in_insn
[...]/gcc/function.cc:1610
0xb42cfc instantiate_virtual_regs
[...]/gcc/function.cc:1983
0xb42cfc execute
[...]/gcc/function.cc:2030

[Bug target/112311] GCN: occasional 'WARNING: gcc.dg/pr82274-1.c execution test program timed out.'

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

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

--- Comment #1 from Richard Biener  ---
Does GCN even have the libgcc parts for mulv?  Note that's going to call
abort(), maybe that's how it gets stuck in the runtime somehow?

[Bug middle-end/112312] New: GCC fails to optimize a C++ algorithm with a function passed in as well as with a lambda

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

Bug ID: 112312
   Summary: GCC fails to optimize a C++ algorithm with a function
passed in as well as with a lambda
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

See 
https://godbolt.org/z/s8dWGzb9r

When passing a (pointer to) function as a predicate argument for a C++ stdlib
algorithm, various people hope that it optimizes as well as passing a lambda
that does exactly the same thing. And with clang, it does. With gcc, the
generated
code is much worse for the function case, even though the function definition
is nearby and visible.

The test code used on godbolt pasted for convenience:

#include 
#include 
#include 

static bool pred1(const std::string& a, const std::string& b)
{
return false;
}

auto pred2 = [](const std::string& a, const std::string& b)
{
return false;
};

bool func1(const std::vector& vec, const std::string& needle)
{
return std::ranges::lower_bound(vec, needle, pred1) != vec.end();
}

bool func2(const std::vector& vec, const std::string& needle)
{
return std::ranges::lower_bound(vec, needle, pred2) != vec.end();
}

[Bug target/112311] New: GCN: occasional 'WARNING: gcc.dg/pr82274-1.c execution test program timed out.'

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

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

Bug ID: 112311
   Summary: GCN: occasional 'WARNING: gcc.dg/pr82274-1.c execution
test program timed out.'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

In GCN target testing, occasionally I see:

 PASS: gcc.dg/pr82274-1.c (test for excess errors)
+WARNING: gcc.dg/pr82274-1.c execution test program timed out.
 PASS: gcc.dg/pr82274-1.c execution test

This is a 'dg-shouldfail' test case that normally terminates instantly. 
Sometimes, however, it times out.

[Bug tree-optimization/112310] New: [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-1161-g5476de2618f

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 112310
   Summary: [14 Regression] Wrong code at -O2/3 on
x86_64-linux-gnu since r14-1161-g5476de2618f
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc at -O2/3 produces the wrong code.

Bisected to r14-1161-g5476de2618f

Compiler explorer: https://godbolt.org/z/Kb4qMKE9K

$ cat a.c
int printf(const char *, ...);
short a, b;
static int c, d, e, f = -7;
char g;
int *h = 
int **i = 
int j;
short(k)(int l) { return l >= 2 ? 0 : l; }
int(m)(int l, int n) { return l < -2147483647 / n ? l : l * n; }
void o() {  }
int main() {
  {
int p;
for (; g <= 3; g++) {
  for (; c; c++)
;
  a = 2;
  for (; a <= 7; a++) {
short *r = 
p = m(*h, 2022160547);
unsigned q = 2022160547;
e = p * q;
*r ^= e;
j = k(c + 3);
**i = 0;
  }
  *i = 
}
  }
  printf("%d\n", b);
}
$
$ gcc -O0 a.c && ./a.out
-3189
$ gcc -O2 a.c && ./a.out
0
$