[Bug tree-optimization/93262] [10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r10-1985

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Florian Weimer :

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

commit r14-4846-g0e29c6f65523dad20068ba69cd03d8f6f82cab41
Author: Florian Weimer 
Date:   Mon Oct 23 09:23:05 2023 +0200

gcc.c-torture/execute/builtins/pr93262-chk.c: Remove return statement

The main_test function returns void, so return with an expression
is a constraint violation.  The test case still fails with this
change applied before the fix for PR 93262 in r14-4813.

gcc/testsuite/

* gcc.c-torture/execute/builtins/pr93262-chk.c (main_test):
Remove unnecessary return statement.

[Bug libquadmath/111928] New: Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

Bug ID: 111928
   Summary: Build broken for baremetal targets after
r14-4825-g6a6d3817afa02b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitar at gcc dot gnu.org
  Target Milestone: ---

Following configure error is observed for pru-unknown-elf, arm-none-eabi, and
probably other baremetal targets:


Checking multilib configuration for libquadmath...
mkdir -p -- pru/libquadmath
Configuring in pru/libquadmath

checking for cos in -lm... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:13877: configure-target-libquadmath] Error 1


Issue probably started with r14-4825-g6a6d3817afa02b

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #9)
> (In reply to John Paul Adrian Glaubitz from comment #8)
> > 
> > I built gcc-13 natively with the patch applied with a full bootstrap
> > including stage2 and stage3. Full build log available in [1].
> > 
> > > [1] https://people.debian.org/~glaubitz/gcc-13_13.2.0-2+sh4_sh4.build.gz
> 
> Perfect! Thanks!

Do we need anything else before the fix can be merged?

[Bug c++/111929] New: in decompose, at wide-int.h:1049

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111929
   Summary: in decompose, at wide-int.h:1049
   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: ---

Created attachment 56174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56174&action=edit
gzipped C++ source code

The attached C++ code does this:


$ ../results/bin/gcc -c -w bug968.cc 
In file included from main.cpp:32:
../../src/zsolve/LinearSystem.hpp: In function ‘std::ostream&
_4ti2_zsolve_::operator<<(std::ostream&, LinearSystem&)’:
../../src/zsolve/LinearSystem.hpp:162:40: internal compiler error: in
decompose, at wide-int.h:1049
0xd52950 tree_nonzero_bits(tree_node const*)
../../trunk.year/gcc/fold-const.cc:0
0xd519f1 tree_nonzero_bits(tree_node const*)
../../trunk.year/gcc/fold-const.cc:16835

The bug first seems to occur sometime between g:88c27070c253094f
and g:66c26e5cfdf65ae0

[Bug target/111930] New: aarch64: SME is still not supported.

[d_vampile at 163 dot com via Gcc-bugs]

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

Bug ID: 111930
   Summary: aarch64: SME is still not supported.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d_vampile at 163 dot com
  Target Milestone: ---

https://patchwork.ozlabs.org/project/gcc/list/?series=327942
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605906.html

The patch for supporting SME has been submitted, but it has not been merged
into the gcc master branch. Why? What version will support SME?

[Bug middle-end/111925] fail to build qemu when compile with lto

[yancheng.li at foxmail dot com via Gcc-bugs]

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

--- Comment #1 from yancheng.li at foxmail dot com ---
found discussion from openSUSE:
https://bugzilla.opensuse.org/show_bug.cgi?id=1133281

[Bug c++/111923] default argument is not treated as a complete-class context of a class

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #7 from Stas Sergeev  ---
Also I verified your assumption in
comment #5 by this code:

struct A {
struct dummy {
static constexpr const int foo(const int off = offsetof(A, a)) { return
off; }
static constexpr const int operator()() { return foo(); }
};
static constexpr const int (*off_p)() = &dummy::operator();

int t[off_p()];
char a;
};

It says:

error: size of array ‘t’ is not an integral constant-expression
   11 | int t[off_p()];

So it seems, "constexpr const" is not
enough to alter the structure size, so
your fears about that were likely wrong.

So could you please explain why note4 doesn't
apply to the nested closure type? Unless
there is a consistent explanation, the
chances are that the bug is missed. :(

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

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

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

--- Comment #21 from Jonathan Wakely  ---
std::vector should be preferred in C++.

This warning will not drive responsible C++ developers to use alloca, it will
drive them to use std::vector. As Aaron has said, there are cases where people
use a VLA in C++ by mistake without even realising it, just because the code
compiles and they don't notice they're using a non-constant bound.

[Bug target/111889] [14 Regression] 128/256 intrins could not be used with only specifying "no-evex512, avx512vl" in function attribute

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #5 from Haochen Jiang  ---
It is actually a legacy issue from this:

$ cat 2.c
#include 


__attribute__ ((target ("no-avx2")))
void foo ()
{
return _mm_empty ();
}

$ x86_64-pc-linux-gnu-gcc -O2 -mavx512f 2.c

It will also fail.

The main reason is caused by caller's target is higher than callee's.

Previously it will not cause problem since we consider it makes sense and
nobody will write code in such pattern.

But we will introduce avx10.x-256/512 options and function attributes in near
future, the problem might become visible.

[Bug tree-optimization/111894] Missed vectorization opportunity

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Blocks||53947
   Last reconfirmed||2023-10-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

Creating dr for MEM  [(value_type
&)&data]._M_elems[_7]._M_elems[_8]
analyze_innermost: t.C:23:24: missed:  failed: evolution of offset is not
affine.

we have

void init2 ()
{
  long unsigned int SR.100;
  long unsigned int ivtmp_1;
  long unsigned int _4;
  long unsigned int ivtmp_6;
  long unsigned int _7;
  long unsigned int _8;

   [local count: 10737416]:

   [local count: 1063004409]:
  # SR.100_13 = PHI <_4(5), 0(2)>
  # ivtmp_6 = PHI 
  _7 = SR.100_13 / 20;
  _8 = SR.100_13 % 20;
  MEM  [(value_type &)&data]._M_elems[_7]._M_elems[_8] = 123;
  _4 = SR.100_13 + 1;
  ivtmp_1 = ivtmp_6 - 1;
  if (ivtmp_1 != 0)
goto ; [99.00%]
  else
goto ; [1.00%]

   [local count: 1052374367]:
  goto ; [100.00%]

   [local count: 10737416]:
  return;

and the issue is the use of division/modulo for the array accesses, that is,
that this C++ idiom results in a "flattened" loop instead of a nest of
level two.

GCC doesn't support "un-flattening" this.  In general, when we can
see that the number of iterations is so that unrolling the loop
by VF will not cross dimensions we might be able to apply regular loop
vectorization but we currently do not have code doing that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/111898] [12/13/14 Regression][SH] internal compiler error: Segmentation fault when building PostgreSQL 16

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.4.0
   Target Milestone|--- |12.4
   Priority|P3  |P4
Summary|[SH] [12 13 Regression] |[12/13/14 Regression][SH]
   |internal compiler error:|internal compiler error:
   |Segmentation fault when |Segmentation fault when
   |building PostgreSQL 16  |building PostgreSQL 16

[Bug target/111905] -O3 vectorization terribly pessimizes the code for an already unrolled loop

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

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

--- Comment #5 from Richard Biener  ---
For the original testcase and foo we do not perform extra unrolling during
vectorization - we just vectorize the already unrolled loop.  bar isn't
unrolled so we do as part of vectorization.

With -fopt-info you see

t.C:6:26: optimized: loop with 16 iterations completely unrolled (header
execution count 63136016)
t.C:7:14: optimized: basic block part vectorized using 32 byte vectors
t.C:56:14: optimized: loop vectorized using 32 byte vectors
t.C:56:14: optimized:  loop versioned for vectorization because of possible
aliasing
t.C:56:14: optimized: loop vectorized using 16 byte vectors
t.C:56:14: optimized: loop with 2 iterations completely unrolled (header
execution count 57270721)
t.C:51:6: optimized: loop turned into non-loop; it never loops

I'm also not seeing any "terrible" code?

[Bug tree-optimization/111913] [14 Regression] ICE with __builtin_popcount(X) + __builtin_popcount(Y) simplification

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/111914] ICE with function pointer array as argument with non-constant size

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |ipa
   Last reconfirmed||2023-10-23
 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/111915] [14 Regression] ICE in vect with option `-O2 -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-ccp` since r14-2117-gdd86a5a69cbda4

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/111916] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu (the generated code hangs) since r14-4612-g6decda1a35be5764101987c210b5693a0d914e58

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
Version|unknown |14.0
   Priority|P3  |P1

--- Comment #5 from Richard Biener  ---
I will have a look.

[Bug ipa/111873] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-loop-optimize -fno-tree-pre' since r12-434-g93f8cb4965cebe

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

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

Sam James  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||sjames at gcc dot gnu.org
   Keywords|needs-bisection |
Summary|[12/13/14 Regression]   |[12/13/14 Regression]
   |runtime Segmentation fault  |runtime Segmentation fault
   |with '-O3   |with '-O3
   |-fno-code-hoisting  |-fno-code-hoisting
   |-fno-early-inlining |-fno-early-inlining
   |-fno-tree-fre   |-fno-tree-fre
   |-fno-tree-loop-optimize |-fno-tree-loop-optimize
   |-fno-tree-pre'  |-fno-tree-pre' since
   ||r12-434-g93f8cb4965cebe

--- Comment #4 from Sam James  ---
bisect says:

93f8cb4965cebee125f96376367f05e18ee5749b is the first bad commit
commit 93f8cb4965cebee125f96376367f05e18ee5749b
Author: Eric Botcazou 
Date:   Tue May 4 12:47:11 2021 +0200

Reuse non-gimple_reg variable for inlining

i.e. r12-434-g93f8cb4965cebe

[Bug tree-optimization/111917] [11/12/13/14 Regression] ICE in as_a, at is-a.h:255 since GCC-7

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
We have two outgoing edges for

 [local count: 40157944]:
e:

and

 [local count: 35740570]:
if (b_3 <= 30)
f:

before unswitching starts it looks OK, so we're splitting/inserting things
wrong there.  I'll have a look.

[Bug middle-end/110721] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #4 from Sam James  ---
tip of 11 is broken for me, tip of 12 is ok, bisecting...

[Bug c/111931] New: RISC-V: Trivial optimization of VSETVL PASS

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

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

Bug ID: 111931
   Summary: RISC-V: Trivial optimization of VSETVL PASS
   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 "riscv_vector.h"

void foo9 (int8_t *base, int8_t* out, size_t vl, size_t m)
{
vint8mf8_t v0;
size_t avl = __riscv_vsetvl_e8mf8 (vl);

for (size_t i = 0; i < m; i++)
{
v0 = __riscv_vle8_v_i8mf8 (base + i, avl);
__riscv_vse8_v_i8mf8 (out + i, v0, avl);
}
}

ASM:

vsetvli a2,a2,e8,mf8,ta,ma
beq a3,zero,.L8
add a3,a0,a3
.L3:
vle8.v  v1,0(a0)
addia0,a0,1
vse8.v  v1,0(a1)
addia1,a1,1
bne a0,a3,.L3
.L8:
ret

The vsetvl should be optimized into "vsetvl zero, a2" instead of "vsetvl a2,a2"

The reason we failed to optimize it is because we set the entry block as
unknown block when computing reaching_def. So preds_has_same_avl_p is false.

As long as there are predecessors block before the user vsetvl, we can optimize
it.

This is an trivial issue. I will fix it if I find the time.

[Bug middle-end/111925] fail to build qemu when compile with lto

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-23

--- Comment #2 from Richard Biener  ---
Note GCC 10 is no longer maintained, I suggest to update to a newer version
first.

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Build broken for baremetal  |[14 Regression] Build
   |targets after   |broken for baremetal
   |r14-4825-g6a6d3817afa02b|targets after
   ||r14-4825-g6a6d3817afa02b
   Keywords||build
   Target Milestone|--- |14.0
   Priority|P3  |P1

[Bug c++/111929] in decompose, at wide-int.h:1049

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-10-23
 CC||rguenth at gcc dot gnu.org
Version|unknown |14.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Full backtrace - unfortunately it's no longer easy to spot the
match.pd line from the generated files and it's not possible to force
indirect_line_numbers to false at build time :/

In file included from main.cpp:32:
../../src/zsolve/LinearSystem.hpp: In function 'std::ostream&
_4ti2_zsolve_::operator<<(std::ostream&, LinearSystem&)':
../../src/zsolve/LinearSystem.hpp:162:40: internal compiler error: in
decompose, at wide-int.h:1049
0x12a3366 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
  /space/rguenther/src/gcc/gcc/wide-int.h:1049
0x12ec1a2 wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
  /space/rguenther/src/gcc/gcc/wide-int.h:1099
0x12ec15a generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
  /space/rguenther/src/gcc/gcc/wide-int.h:855
0x131e14d wi::binary_traits,
generic_wide_int,
wi::int_traits >::precision_type,
wi::int_traits
>::precision_type>::result_type wi::bit_and,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
  /space/rguenther/src/gcc/gcc/wide-int.h:2757
0x15c25b2 tree_nonzero_bits(tree_node const*)
  /space/rguenther/src/gcc/gcc/fold-const.cc:16843
0x15c23f2 tree_nonzero_bits(tree_node const*)
  /space/rguenther/src/gcc/gcc/fold-const.cc:16835
0x24a1597 tree_zero_one_valued_p(tree_node*)
  /abuild/rguenther/obj-gcc-g/gcc/generic-match-5.cc:20
0x24c1864 generic_simplify_MULT_EXPR(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*)
  /abuild/rguenther/obj-gcc-g/gcc/generic-match-5.cc:7078
0x245848a generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
  /abuild/rguenther/obj-gcc-g/gcc/generic-match-3.cc:8706
0x15a9727 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
  /space/rguenther/src/gcc/gcc/fold-const.cc:11178
0x15b8b2b fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
  /space/rguenther/src/gcc/gcc/fold-const.cc:14068
0x15a967a fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
  /space/rguenther/src/gcc/gcc/fold-const.cc:11170
0x15b8b2b fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
  /space/rguenther/src/gcc/gcc/fold-const.cc:14068
0x157fec7 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
  /space/rguenther/src/gcc/gcc/fold-const.cc:2079
0xf782e6 build_new_1
  /space/rguenther/src/gcc/gcc/cp/init.cc:3264
0xf7b132 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
  /space/rguenther/src/gcc/gcc/cp/init.cc:4023
0x1063b15 cp_parser_new_expression
  /space/rguenther/src/gcc/gcc/cp/parser.cc:9489
0x10626da cp_parser_unary_expression
  /space/rguenther/src/gcc/gcc/cp/parser.cc:8941
0x106484d cp_parser_cast_expression
  /space/rguenther/src/gcc/gcc/cp/parser.cc:10121
0x1064944 cp_parser_binary_expression
  /space/rguenther/src/gcc/gcc/cp/parser.cc:10223
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 c++/111929] [14 Regression] in decompose, at wide-int.h:1049

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection
Summary|in decompose, at|[14 Regression] in
   |wide-int.h:1049 |decompose, at
   ||wide-int.h:1049
   Target Milestone|--- |14.0

[Bug tree-optimization/111820] [13 Regression] Compiler time hog in the vectorizer with `-O3 -fno-tree-vrp`

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|14.0|
Summary|[13/14 Regression] Compiler |[13 Regression] Compiler
   |time hog in the vectorizer  |time hog in the vectorizer
   |with `-O3 -fno-tree-vrp`|with `-O3 -fno-tree-vrp`
  Known to work||14.0

--- Comment #13 from Richard Biener  ---
(In reply to Hongtao.liu from comment #12)
> Fixed in GCC14, not sure if we want to backport the patch.
> If so, the patch needs to be adjusted since GCC13 doesn't support auto_mpz.

Yes, we want to backport.

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
(wonder if --with-matchpd-partitions=1 could help)

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

--- Comment #27 from Richard Biener  ---
(In reply to Kewen Lin from comment #26)
> (In reply to Richard Biener from comment #25)
> > (In reply to Kewen Lin from comment #24)
[...]
> > Ah, probably the alias-set is determined from the unmangled ref ...
> > 
> > > Aggressively further hacking with attrs.alias =
> > > 0 can make it pass. Can we make an new alias set for each partition? then
> > > all involved decls in the same partition is aliased. For a particular
> > > involved decl, it's aliased to the previous ones and the new ones in its 
> > > own
> > > partitions.
> > 
> > hmm, no - this won't work.  In fact even attrs.alias = 0 will probably
> > not work reliably since we can coalesce variables that escape and thus
> > the above will only alter accesses via the original decls but not any
> > accesses done via pointers.  So indeed any alias-set mangling is pointless
> > here.
> > 
> > Consider
> > 
> >  {
> >A x;
> >int * volatile p = &x;
> >*p = 1;
> >.. = *p;
> >  }
> >  {
> >B y;
> >float * volatile q = &y;
> >*q = 1;
> >.. = *q;
> >  }
> > 
> > if we coalesce x and y then we are not rewriting any accesses
> > but obviously the accesses still need to conflict - but the
> > indirect accesses will have their original non-conflicting alias-set
> > and thus the scheduler would be free to move the store to *q across
> > the load from *p (the "trick" would be to make an incentive to do so
> > of course).
> 
> Thanks for the clarification! Is it possible to update the alias set for the
> indirect accesses as well? since we know the address is originally taken
> from one coalesced decl (also update its propagated ones).

I suppose we could record a bitmap of all decls participating in any
coalescing, check whether a MEM could possibly refer to any of them
via the points-to API and then force alias-set zero for those.  We
could also try to do sophisticated analysis to make assigning a new
alias-set for each coalesce group work, merging groups when there's
indirect accesses that could alias a member of more than a single
group.

Note that the other bugs linked perform wrong coalescings (for things
which have overlapping life time) while this one performs coalescing
wrong (not properly adjusting accesses so they later conflict).

[Bug ipa/111873] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-loop-optimize -fno-tree-pre' since r12-434-g93f8cb4965cebe

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

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

--- Comment #5 from Eric Botcazou  ---
People really should stop spamming the database with bug reports about random
combinations of switches, this is a waste of time and resources for everyone.

[Bug rtl-optimization/111554] [12/13/14 regression] Timeout with with "-O3 -fno-dse -fno-inline -fno-store-merging -fno-toplevel-reorder -fno-tree-dce -fno-tree-dse" since r12-2097-g9f34b780b0461e

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Most definitely something like

  /* Find the dep_link with consumer CON in producer's forw_deps.  */
  FOR_EACH_DEP (pro, pro_list_type, sd_it, dep)
if (DEP_CON (dep) == con)
  {
found_p = true;
break;
  }

is quite bad engineering.  The LIM change probably just triggered this to be
observable.

git puts the blame on Maxim, but he might just have refactored the code.  Still
he's the remaining scheduler expert, so ... ;)

[Bug ipa/111873] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-loop-optimize -fno-tree-pre' since r12-434-g93f8cb4965cebe

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
Investigating.

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 23 Oct 2023, sjames at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111929
> 
> Sam James  changed:
> 
>What|Removed |Added
> 
>  CC||sjames at gcc dot gnu.org
> 
> --- Comment #2 from Sam James  ---
> (wonder if --with-matchpd-partitions=1 could help)

No, we need a new flag to control indirect_line_numbers I guess.

[Bug target/111908] Port CheriBSD-specific compiler warnings to GCC

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #2 from Alex Coplan  ---
Indeed, you can see an example of the CHERI warnings in the Morello GCC port
here: https://godbolt.org/z/eWPfqYYYo

[Bug target/111927] RISC-V: internal compiler error: in merge, at config/riscv/riscv-vsetvl.cc:1997

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

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

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

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

commit r14-4856-g0c4bd1321a6def5eb44c530e83b01a415633b660
Author: Juzhe-Zhong 
Date:   Mon Oct 23 17:40:34 2023 +0800

RISC-V: Fix ICE for the fusion case from vsetvl to scalar move[PR111927]

ICE:

during RTL pass: vsetvl
: In function 'riscv_lms_f32':
:240:1: internal compiler error: in merge, at
config/riscv/riscv-vsetvl.cc:1997
  240 | }

In general compatible_p (avl_equal_p) has:

if (next.has_vl () && next.vl_used_by_non_rvv_insn_p ())
  return false;

Don't fuse AVL of vsetvl if the VL operand is used by non-RVV instructions.

It is reasonable to add it into 'can_use_next_avl_p' since we don't want to
fuse AVL of vsetvl into a scalar move instruction which doesn't demand AVL.
And after the fusion, we will alway use compatible_p to check whether the
demand
is correct or not.

PR target/111927

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc: Fix bug.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/pr111927.c: New test.

[Bug target/111927] RISC-V: internal compiler error: in merge, at config/riscv/riscv-vsetvl.cc:1997

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

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

--- Comment #4 from JuzheZhong  ---
Fixed on trunk. Plz verify it and close it if it is fixed.

[Bug target/111930] aarch64: SME is still not supported.

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

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

Richard Sandiford  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Richard Sandiford  ---
We're aiming to add SME and SME2 support in GCC 14, hopefully by the end of the
year.

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Reduced test case seems to be:

struct LinearSystem {};
template  void operator<<(int, LinearSystem) {
  long vars = new long[vars + 2];
}

[Bug ipa/111873] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre'

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12/13/14 Regression]
   |runtime Segmentation fault  |runtime Segmentation fault
   |with '-O3   |with '-O3
   |-fno-code-hoisting  |-fno-code-hoisting
   |-fno-early-inlining |-fno-early-inlining
   |-fno-tree-fre   |-fno-tree-fre
   |-fno-tree-loop-optimize |-fno-tree-pre'
   |-fno-tree-pre' since|
   |r12-434-g93f8cb4965cebe |

--- Comment #7 from Eric Botcazou  ---
-fno-tree-loop-optimize is not needed, but the 4 other switches are!

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049

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

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

--- Comment #5 from Andrew Pinski  ---
My bet it was the c++ change
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=dad311874ac3b3cf4eca1c04f67cae80c953f7b8
or the one right after that one which caused it.

Since it looks like template related

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #22 from Martin Uecker  ---

There may be many good reasons to prefer std::vector over VLAs in C++ but
security and safety is not one of them. There are plenty of CVEs caused by
std::vector out-of-bounds accesses. The question is whether in GNU mode one
should warn about a GNU extension. People who want to avoid VLAs for reasons of
standard compliance would also not use a GNU mode.

[Bug target/111927] RISC-V: internal compiler error: in merge, at config/riscv/riscv-vsetvl.cc:1997

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

Huaqi  changed:

   What|Removed |Added

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

--- Comment #5 from Huaqi  ---
Yes, I tried with latest commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0c4bd1321a6def5eb44c530e83b01a415633b660,
it works now.

[Bug tree-optimization/111917] [11/12/13/14 Regression] ICE in as_a, at is-a.h:255 since GCC-7

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

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

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

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

commit r14-4857-gd96bd4aade170fcd86f5f09b68b770dde798e631
Author: Richard Biener 
Date:   Mon Oct 23 11:25:17 2023 +0200

tree-optimization/111917 - bougs IL after guard hoisting

The unswitching code to hoist guards inserts conditions in wrong
places.  The following fixes this, simplifying code.

PR tree-optimization/111917
* tree-ssa-loop-unswitch.cc (hoist_guard): Always insert
new conditional after last stmt.

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

[Bug tree-optimization/111917] [11/12/13 Regression] ICE in as_a, at is-a.h:255 since GCC-7

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE in as_a, at is-a.h:255  |in as_a, at is-a.h:255
   |since GCC-7 |since GCC-7
  Known to work||14.0
   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #1 from Iain Sandoe  ---
I'm trying to reproduce this, (and could be making some mistake) but I seem to
see

checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:13636: configure-target-libstdc++-v3] Error 1

at r14-4820-g11f50716eee812 (which is before the patches I applied at the
weekend)

What was the last revision that you know was working?

[Bug ipa/111873] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre'

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

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

--- Comment #8 from Eric Botcazou  ---
The bug is in the (early) SRA pass though;

void h (const struct a i)
{
  const short int i$b;
  int _1;
  short int _2;
  int _3;
  short int _4;
  int _5;

   :
  i$b_10 = i.b;
  i.b = i$b_10;
  _1 = g (i);
  d = _1;
  _2 = i$b_10;
  _3 = (int) _2;
  f (_3);
  _4 = i$b_10;
  _5 = (int) _4;
  e (_5);
  return;

}

which creates a store to the read-only parameter i:

(gdb) p debug_gimple_stmt(stmt)
# .MEM = VDEF <.MEM>
i.b = i$b;
$2 = void
(gdb) p debug_tree(gimple_get_lhs (stmt))
 
unit-size 
align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x771b6930 precision:16 min  max
>
readonly
arg:0  unit-size 
align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x771b6540 fields >
readonly used read HI pr111873.c:18:24 size  unit-size 
align:16 warn_if_not_align:0 context 
arg-type >
arg:1  unit-size 
align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7702a498 precision:16 min  max
>
HI pr111873.c:5:9 size  unit-size

align:16 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 1
offset 
bit-offset  context >
pr111873.c:21:7 start: pr111873.c:21:6 finish: pr111873.c:21:8>

/* In a VAR_DECL, PARM_DECL or FIELD_DECL, or any kind of ..._REF node,
   nonzero means it may not be the lhs of an assignment.
   Nonzero in a FUNCTION_DECL means this function should be treated
   as "const" function (can only read its arguments).  */
#define TREE_READONLY(NODE) (NON_TYPE_CHECK (NODE)->base.readonly_flag)

[Bug tree-optimization/111873] [12/13/14 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre'

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

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|ipa |tree-optimization
   Assignee|ebotcazou at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW
 CC||jamborm at gcc dot gnu.org

--- Comment #9 from Eric Botcazou  ---
Very similar to PR tree-opt/100453.  Martin, would you mind having a look when
you have some time?  Thanks in advance.

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

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

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

--- Comment #23 from Jonathan Wakely  ---
(In reply to Martin Uecker from comment #20)
> And what alternative do you think is fundamentally safer than VLAs?
> 
> VLAs know their bound. Thus, they integrate with _FORTIFY_SOURCE, and UBSan
> bounds checking. Also UBSan address checking at run-time. At compile-time
> there is -Ws

They don't integrate with idiomatic C++ such as ranges algorithms, and
std::end.

More generally, they simply don't integrate with the C++ type system, so are
unusable with most generic code using templates. Not only does std::is_array
not recognise them as arrays, but even attempting to ask the question with
std::is_array is ill-formed. Variably modified types are not part of the C++
type system, so can't be template arguments.

int n = 2;
int a[n]{};
static_assert(not std::is_array_v); // error

Clang doesn't even allow the {} initializer in the code above, so they're not
portable either, even among compilers that support -std=gnu++17 modes.


> std::vector has some protection, e.g. ASAN finds the out of bounds
> access (at a high run-time cost) and one could activate the GLIBC assertions
> someho:
> 
> https://godbolt.org/z/8zanMG5x4

This will abort with the recommended hardening flags, specifically
-D_GLIBCXX_ASSERTIONS (which is nothing to do with Glibc, and is suitable for
production use, unlike ASan). Those assertions will be enabled by the proposed
-fhardening flag.


> 
> But I would not call it safer and overhead is much worse.
> 
> Fundamentally, VLAs are the dynamic buffer which can be protected most
> easily and should be *preferred*.

Maybe for C, but not for C++.

I know you are a big fan of VLAs, but please don't try to push them into a
language where they do not fit, and are not needed.

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

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

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

--- Comment #24 from Jonathan Wakely  ---
(In reply to Martin Uecker from comment #22)
> There may be many good reasons to prefer std::vector over VLAs in C++ but
> security and safety is not one of them. There are plenty of CVEs caused by
> std::vector out-of-bounds accesses.

There are plenty of CVEs caused by those for arrays too, static and variable
length ones.

The point is that vector carries its length with it properly, in a way that
actually works with the type system (e.g. works with std::span and std::end
etc.)

A VLA has a length that the compiler knows in a limited scope, but you can't
pass that to a function without passing the length explicitly as a separate
argument. The length information is easily lost.

> The question is whether in GNU mode one
> should warn about a GNU extension. People who want to avoid VLAs for reasons
> of standard compliance would also not use a GNU mode.

Yes, I know, and the lack of integration with the type system should show they
are simply inappropriate for general purpose use in idiomatic C++ code.

[Bug c/111903] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:567 with -mno-sse2 and _Float16

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:13c0d052478bb45cc97869f5cc333f269aadb36f

commit r14-4858-g13c0d052478bb45cc97869f5cc333f269aadb36f
Author: Andrew Pinski 
Date:   Fri Oct 20 14:47:55 2023 -0700

convert_to_complex vs invalid_conversion [PR111903]

convert_to_complex when creating a COMPLEX_EXPR does
not currently check if either the real or imag parts
was not error_mark_node. This later on confuses the gimpilfier
when there was a SAVE_EXPR wrapped around that COMPLEX_EXPR.
The simple fix is after calling convert inside convert_to_complex_1,
check that the either result was an error_operand and return
an error_mark_node in that case.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR c/111903

gcc/ChangeLog:

* convert.cc (convert_to_complex_1): Return
error_mark_node if either convert was an error
when converting from a scalar.

gcc/testsuite/ChangeLog:

* gcc.target/i386/float16-8.c: New test.

[Bug c/111903] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:567 with -mno-sse2 and _Float16

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:85e930ac8557c444680b5b29a0a13a14ea6672b5

commit r14-4859-g85e930ac8557c444680b5b29a0a13a14ea6672b5
Author: Andrew Pinski 
Date:   Fri Oct 20 14:49:32 2023 -0700

Use error_mark_node after error in convert

While working on PR c/111903, I Noticed that
convert will convert integer_zero_node to that
type after an error instead of returning error_mark_node.
From what I can tell this was the old way of not having
error recovery since other places in this file does return
error_mark_node and the places I am replacing date from
when the file was imported into the repro (either via a gcc2 merge
or earlier).

I also had to update the objc front-end to allow for the error_mark_node
change, I suspect you could hit the ICE without this change though.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

* convert.cc (convert_to_pointer_1): Return error_mark_node
after an error.
(convert_to_real_1): Likewise.
(convert_to_integer_1): Likewise.
(convert_to_complex_1): Likewise.

gcc/objc/ChangeLog:

* objc-gnu-runtime-abi-01.cc (build_objc_method_call): Allow
for error_operand after call to build_c_cast.
* objc-next-runtime-abi-01.cc (build_objc_method_call): Likewise.
* objc-next-runtime-abi-02.cc (build_v2_build_objc_method_call):
Likewise.

[Bug c/111903] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:567 with -mno-sse2 and _Float16

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #2 from Dimitar Dimitrov  ---
I confirm that build works fine with r14-4820-g11f50716eee812, no maintainer
mode, for pru and arm targets.

I'm using x86_64-pc-linux-gnu build and host machine.

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Dimitar Dimitrov from comment #2)
> I confirm that build works fine with r14-4820-g11f50716eee812, no maintainer
> mode, for pru and arm targets.
> 
> I'm using x86_64-pc-linux-gnu build and host machine.

thanks, please could you post your configure line?

[Bug ada/111932] New: Issue Twitter Viral Video Museum 2021 Ngawi Indonesia Full Terbaru

[irishka2211 at mondaylaura dot com via Gcc-bugs]

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

Bug ID: 111932
   Summary: Issue Twitter Viral Video Museum 2021 Ngawi Indonesia
Full Terbaru
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: irishka2211 at mondaylaura dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Full Video :
Twitter Viral Video Museum 2021 Ngawi Indonesia Full Terbaru

Watch 🔴 ➤ ➤ ➤ 🌐 https://xzc.one/click-here-to-download/

Watch 🔴 ➤ ➤ ➤ 🌐 https://xzc.one/click-here-to-download/

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #4 from Dimitar Dimitrov  ---
If I remove the "AC_CHECK_LIBM" line from libquadmath/configure.ac, and
re-generate autoconf there, then the build passes.

I don't understand why that line was added. Just a few lines below I see checks
for specific functions from libm.

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049

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

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

--- Comment #6 from Andrew Pinski  ---
Better reduced testcase:
```
template 
void f(__SIZE_TYPE__ var) {
  new int[var + 2];
}
```

And yes if you change f into an non-template, there is no crash.

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #5 from Dimitar Dimitrov  ---
> thanks, please could you post your configure line?

  $ /mnt/nvme/dinux/local-workspace/gcc/configure
--prefix=/mnt/nvme/dinux/local-workspace/arm-opt --target=arm-none-eabi
--with-newlib --enable-languages=c,c++ --enable-checking=yes,rtl
--disable-libssp

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Dimitar Dimitrov from comment #4)
> If I remove the "AC_CHECK_LIBM" line from libquadmath/configure.ac, and
> re-generate autoconf there, then the build passes.
> 
> I don't understand why that line was added. Just a few lines below I see
> checks for specific functions from libm.

That was what I was expecting - that line should not be there (it is a rebase
glitch that did not get picked up in either reviews or testing)

I am just trying to reproduce the problem and that fix..

[Bug ipa/111914] ICE with function pointer array as argument with non-constant size

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

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

--- Comment #3 from Richard Biener  ---
The issue is we do

setup_one_parameter (copy_body_data *id, tree p, tree value, tree fn,
 basic_block bb, tree *vars)
...
  /* Make an equivalent VAR_DECL.  Note that we must NOT remap the type
 here since the type of this decl must be visible to the calling
 function.  */
  var = copy_decl_to_var (p, id);
...
  else if (!optimize)
{
  def = make_ssa_name (var);
  init_stmt = gimple_build_assign (def, rhs);

but then

static void
initialize_inlined_parameters (copy_body_data *id, gimple *stmt,
   tree fn, basic_block bb)
...
  /* After remapping parameters remap their types.  This has to be done
 in a second loop over all parameters to appropriately remap
 variable sized arrays when the size is specified in a
 parameter following the array.  */
  for (p = parms, i = 0; p; p = DECL_CHAIN (p), i++)
{
  tree *varp = id->decl_map->get (p);
  if (varp && VAR_P (*varp))
{
  tree def = (gimple_in_ssa_p (cfun) && is_gimple_reg (p)
  ? ssa_default_def (id->src_cfun, p) : NULL);
  tree var = *varp;
  TREE_TYPE (var) = remap_type (TREE_TYPE (var), id);
  /* Also remap the default definition if it was remapped
 to the default definition of the parameter replacement
 by the parameter setup.  */
  if (def)
{
  tree *defp = id->decl_map->get (def);
  if (defp
  && TREE_CODE (*defp) == SSA_NAME
  && SSA_NAME_VAR (*defp) == var)
TREE_TYPE (*defp) = TREE_TYPE (var);

but we never adjust the type of the SSA names we create during initial
parameter setup.  We have special handling for the default def but
not for the (dead?!) stmt we emit when !optimize.  It says

  /* If we are in SSA form properly remap the default definition
 or assign to a dummy SSA name if the parameter is unused and
 we are not optimizing.  */

so that seems to be on purpose but it's broken.

[Bug c/111933] New: memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

[bettio.davide at gmail dot com via Gcc-bugs]

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

Bug ID: 111933
   Summary: memcpy on Xtensa not optimized when n ==
sizeof(uint32_t) or sizeof(uint64_t)
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bettio.davide at gmail dot com
  Target Milestone: ---

This issue is about what I think being a missing optimization on ESP32 Xtensa
GCC compiler. 

I tested the same issue on versions between gcc 8.4.0 and 11.2.0 with Xtensa
ESP32/ESP32-S2/ESP32-S3 GCC. 

I'm writing some functions for unaligned memory access and I've been checking
them with Compiler Explorer (https://godbolt.org/) and I'm getting some (I
think) sub-optimal outputs.

As far as I understood on ESP32 Xtensa a 32-bit unaligned memory access is
faster than 4 8-bit accesses, however I'm getting the following results (using
-O2) and the following snippets of code:

Function that calls the inline from_unaligned_u32:
bool test2(uint32_t *in)
{
uint32_t got = from_unaligned_u32(in);
if (got > 5) {
return true;
}

return false;
}

A:
uint32_t from_unaligned_u32(uint32_t *unaligned)
{
uint32_t tmp;
tmp = *unaligned;
return tmp;
}

generates:
test2(unsigned int*):
entry   sp, 32
l32i.n  a8, a2, 0
movi.n  a2, 1
bgeui   a8, 6, .L2
movi.n  a2, 0
.L2:
extui   a2, a2, 0, 1
retw.n


B:
inline uint32_t from_unaligned_u32(uint32_t *unaligned)
{
uint32_t tmp;
memcpy(&tmp, unaligned, sizeof(tmp));
return tmp;
}

generates:
test2(unsigned int*):
entry   sp, 48
l8uia8, a2, 2
l8uia10, a2, 0
l8uia9, a2, 1
l8uia2, a2, 3
s8i a10, sp, 0
s8i a2, sp, 3
s8i a9, sp, 1
s8i a8, sp, 2
l32i.n  a8, sp, 0
movi.n  a2, 1
bgeui   a8, 6, .L2
movi.n  a2, 0
.L2:
extui   a2, a2, 0, 1
retw.n

My assumption here is that unaligned access on Xtensa ESP32 is faster than
calling memcpy or multiple 1-byte loads (please let me know if I am wrong), so
from my point of view is a missing optimization.

I would expect both A and B generating the same assembly code like on other
archs.

Also interstingly the uint64_t "B" version (that is similar to the previous),
generates a call to memcpy instead of some inline code.

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049

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

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

--- Comment #7 from Andrew Pinski  ---
So the C++ front-end produces:

(gdb) p debug_generic_expr(t)
VIEW_CONVERT_EXPR(var) + NON_LVALUE_EXPR <2>
(gdb) p debug_tree(t)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x778267e0 precision:64 min  max 
pointer_to_this >

arg:0 
public
arg:0 
used unsigned read DI t.cc:2:23 size  unit-size 
align:64 warn_if_not_align:0 context  arg-type >
t.cc:3:11 start: t.cc:3:11 finish: t.cc:3:13>
arg:1 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x778265e8 precision:32 min  max

pointer_to_this >
constant public
arg:0 
t.cc:3:17 start: t.cc:3:17 finish: t.cc:3:17>
t.cc:3:15 start: t.cc:3:11 finish: t.cc:3:17>



But the type of NON_LVALUE_EXPR/2 is int:
(gdb) p debug_tree((tree)0x779a6bc0)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x778265e8 precision:32 min  max

pointer_to_this >
constant public
arg:0 
constant 2>
t.cc:3:17 start: t.cc:3:17 finish: t.cc:3:17>


Which breaks the type system for generic.

[Bug ipa/111914] ICE with function pointer array as argument with non-constant size

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

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

--- Comment #4 from Richard Biener  ---
Caused by r0-116946-g27eb31c9de20cd I guess.  The easiest is to not perform
the load of the unused parameter for VLA types, but we can also perform this
extra load after remapping types.

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #25 from Martin Uecker  ---

I agree that they are not idiomatic C++ and that there exist good reasons why a
programmer may want to  avoid them (including standards compliance). But code
not being idiomatic is not a terrible good reason for having a warning. As a
matter of principle, we should not warn about our own extensions without a very
good reason with -std=gnu modes and neither should clang IMHO.

But the idea that VLAs are inherently very dangerous is incorrect, so let's not
perpetuate that myth.  There are many useful things a compiler could do to
improve security for VLAs and also for std::vector or elsewhere by having
better static analysis and more efficient options for bounds checking.  Neither
clang nor GCC will currently give any compile-time warning about a problem here
with -Wall -Wextra nor will there be a run-error with UBSan:

https://godbolt.org/z/7vhGMn3E5

And yes, -D_GLIBXX_DEBUG which will detect the out-of-bounds access but not the
memset. Maybe -D_FORTIFY_SOURCE=3 will do this (as it does for VLAs), but it
does not seem to work on godbolt for both cases, so I can't check.  Asan will
catch both.

For comparison, with VLAs we have this:

https://godbolt.org/z/hGxGrc569

[Bug tree-optimization/111916] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu (the generated code hangs) since r14-4612-g6decda1a35be5764101987c210b5693a0d914e58

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
ESRA does

 int main ()
 {
+  unsigned char g;
   struct A g;
   unsigned char _1;
   unsigned char _2;

:
   g = *.LC0;
+  g_6 = BIT_FIELD_REF <*.LC0, 8, 0>;
   goto ; [INV]

:
+  BIT_FIELD_REF  = g_6;
   f = g;

:
-  _1 = BIT_FIELD_REF ;
+  _1 = g_6;
   _2 = _1 & 15;
   if (_2 == 0)
 goto ; [INV]

which looks OK, but then SRA does

+  unsigned char SR.5;
+  unsigned char g;
   unsigned char g;
   struct A g;
   unsigned char _1;
   unsigned char _11;

[local count: 118111600]:
+  SR.5_10 = SR.5_2(D);
   g = *.LC0;
-  g_5 = BIT_FIELD_REF <*.LC0, 8, 0>;
+  g_14 = SR.5_10;
+  g_5 = SR.5_10;
   _11 = g_5 & 15;
   if (_11 == 0)
 goto ; [0.00%]
@@ -19,6 +33,8 @@

[local count: 955630224]:
   BIT_FIELD_REF  = g_5;
+  g_16 = MEM  [(struct A *)&g];
+  MEM  [(struct A *)&g] = g_16;
   f = g;
   _1 = g_5 & 15;
   goto ; [100.00%]

which looks weird.  First initialize_constant_pool_replacements inserts

SR.5 = BIT_FIELD_REF <*.LC0, 8, 0>;

which loosk OK, but then sra_modify_assign wrecks this, replacing the RHS
with 'SR.5', yielding

SR.5 = SR.5

this happens before the

  /* Avoid modifying initializations of constant-pool replacements.  */
  if (racc && (racc->replacement_decl == lhs))
return SRA_AM_NONE; 

code.

I can paper over with the following, but I wonder if sra_modify_expr needs
that very same check for constant-pool replacements?

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index f8dff8b27d7..efb52453250 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -4275,7 +4275,8 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator
*gsi)

   if (TREE_CODE (rhs) == REALPART_EXPR || TREE_CODE (lhs) == REALPART_EXPR
   || TREE_CODE (rhs) == IMAGPART_EXPR || TREE_CODE (lhs) == IMAGPART_EXPR
-  || TREE_CODE (rhs) == BIT_FIELD_REF || TREE_CODE (lhs) == BIT_FIELD_REF)
+  || (TREE_CODE (rhs) == BIT_FIELD_REF && !sra_handled_bf_read_p (rhs))
+  || TREE_CODE (lhs) == BIT_FIELD_REF)
 {
   modify_this_stmt = sra_modify_expr (gimple_assign_rhs1_ptr (stmt),
  gsi, false);

I will test this now.

[Bug c++/111934] New: ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

Bug ID: 111934
   Summary: ICE  internal compiler error: in
discriminator_for_local_entity, at cp/mangle.cc:2065
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

#ifdef ICE
#include 
#endif

struct  Me {

  static Me & me() {
thread_local auto me = std::make_unique_ptr();
return *me;
  }

};


int main() {
  return 0;
}

c++ -O3 -Wall -pthread ice13.cpp
ice13.cpp: In static member function 'static Me& Me::me()':
ice13.cpp:8:33: error: 'make_unique_ptr' is not a member of 'std'
8 | thread_local auto me = std::make_unique_ptr();
  | ^~~
ice13.cpp:8:51: error: expected primary-expression before '>' token
8 | thread_local auto me = std::make_unique_ptr();
  |   ^
ice13.cpp:8:53: error: expected primary-expression before ')' token
8 | thread_local auto me = std::make_unique_ptr();
  | ^


==


ctest]$ c++ -O3 -Wall -pthread ice13.cpp -DICE
ice13.cpp: In static member function 'static Me& Me::me()':
ice13.cpp:8:33: error: 'make_unique_ptr' is not a member of 'std'
8 | thread_local auto me = std::make_unique_ptr();
  | ^~~
ice13.cpp:8:51: error: expected primary-expression before '>' token
8 | thread_local auto me = std::make_unique_ptr();
  |   ^
ice13.cpp:8:53: error: expected primary-expression before ')' token
8 | thread_local auto me = std::make_unique_ptr();
  | ^
ice13.cpp: At global scope:
ice13.cpp:8:23: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.cc:2065
8 | thread_local auto me = std::make_unique_ptr();
  |   ^~
0x7de25d discriminator_for_local_entity
../../gcc_src/gcc/cp/mangle.cc:2065
0xb92a4a write_local_name
../../gcc_src/gcc/cp/mangle.cc:2164
0xb92a4a write_name
../../gcc_src/gcc/cp/mangle.cc:1071
0xb94e46 write_encoding
../../gcc_src/gcc/cp/mangle.cc:864
0xb94f5b write_mangled_name
../../gcc_src/gcc/cp/mangle.cc:810
0xb95740 mangle_decl_string
../../gcc_src/gcc/cp/mangle.cc:4092
0xb9592a get_mangled_id
../../gcc_src/gcc/cp/mangle.cc:4113
0xb9592a mangle_decl(tree_node*)
../../gcc_src/gcc/cp/mangle.cc:4151
0x16512bd decl_assembler_name(tree_node*)
../../gcc_src/gcc/tree.cc:715
0xe4a329 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc_src/gcc/symtab.cc:175
0xe4a48c symbol_table::symtab_initialize_asm_name_hash()
../../gcc_src/gcc/symtab.cc:267
0xe4ae84 symbol_table::symtab_initialize_asm_name_hash()
../../gcc_src/gcc/symtab.cc:1078
0xe4ae84 symtab_node::get_for_asmname(tree_node const*)
../../gcc_src/gcc/symtab.cc:1066
0xe5fc61 handle_alias_pairs
../../gcc_src/gcc/cgraphunit.cc:1528
0xe64fa7 symbol_table::finalize_compilation_unit()
../../gcc_src/gcc/cgraphunit.cc:2541
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 c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #1 from vincenzo Innocente  ---
sorry missed the version

gcc version 14.0.0 20231021 (experimental) [master r14-4817-g405a4140fc3] (GCC)

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #28 from Michael Matz  ---
(In reply to Richard Biener from comment #27)
> (In reply to Kewen Lin from comment #26)
> > Thanks for the clarification! Is it possible to update the alias set for the
> > indirect accesses as well? since we know the address is originally taken
> > from one coalesced decl (also update its propagated ones).

That's not generally possible, the address-taking and the actual access might
be
separated by arbitrary obfuscating code:

   char *p = &x;
   char *p2 = get_some_pointer(p);
   *p2 = ...

Here p2 may, or may not, point to x.  So we'd need to be fairly conservative
here ...

> I suppose we could record a bitmap of all decls participating in any
> coalescing, check whether a MEM could possibly refer to any of them
> via the points-to API

... which the points-to API of course will be.

> and then force alias-set zero for those.

So that will work.  But I wonder if the result then won't be that essentially
all of the mem accesses will get alias set zero, at least if there was any
coalescing.  At that point we may also bite the bullet and just do away
with any TBAA alias sets in RTL at all.

> We
> could also try to do sophisticated analysis to make assigning a new
> alias-set for each coalesce group work, merging groups when there's
> indirect accesses that could alias a member of more than a single
> group.

Question is if the sophistication is worth it.

[Bug target/111930] aarch64: SME is still not supported.

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug c/111935] New: gcc ICE with risc-v vector intrinsics

[julienpommier at free dot fr via Gcc-bugs]

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

Bug ID: 111935
   Summary: gcc ICE with risc-v vector intrinsics
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julienpommier at free dot fr
  Target Milestone: ---

The following code (test.c) crashes the riscv gcc 13.2.0 compiler of ubuntu
23.10:

#include 

inline vuint32m4_t __attribute__((__always_inline__)) transpose_indexes() {
  static const uint32_t idx_[16] = {0, 4, 8, 12,
  1, 5, 9, 13,
  2, 6, 10, 14,
  3, 7, 11, 15};
  return __riscv_vle32_v_u32m4(idx_, 16);
}

void pffft_real_preprocess_4x4(const float *in) {
  vfloat32m1_t r0=__riscv_vle32_v_f32m1(in,4);
  vfloat32m4_t tmp = __riscv_vundefined_f32m4();
  tmp = __riscv_vset_v_f32m1_f32m4(tmp, 0, r0);
  tmp = __riscv_vset_v_f32m1_f32m4(tmp, 1, r0);
  tmp = __riscv_vset_v_f32m1_f32m4(tmp, 2, r0);
  tmp = __riscv_vset_v_f32m1_f32m4(tmp, 3, r0);
  tmp = __riscv_vrgather_vv_f32m4(tmp, transpose_indexes(), 16);
  r0 = __riscv_vget_v_f32m4_f32m1(tmp, 0);
}



when compiled with:

riscv64-linux-gnu-gcc-13 -O1 -march=rv64gcv -c testcase.c

the output is:

during RTL pass: expand
test.c: In function ‘pffft_real_preprocess_4x4’:
test.c:19:8: internal compiler error: Segmentation fault
   19 |   r0 = __riscv_vget_v_f32m4_f32m1(tmp, 0);
  |^~
0xae3a7583 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0xae3a7657 __libc_start_main_impl
../csu/libc-start.c:360
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/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

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

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

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r14-4861-g9ed6b22eb4188c57bb3f5cdba5a7effa95395186
Author: Tamar Christina 
Date:   Mon Oct 23 14:07:20 2023 +0100

middle-end: don't keep .MEM guard nodes for PHI nodes who dominate loop
[PR111860]

The previous patch tried to remove PHI nodes that dominated the first loop,
however the correct fix is to only remove .MEM nodes.

This patch thus makes the condition a bit stricter and only tries to remove
MEM phi nodes.

I couldn't figure out a way to easily determine if a particular PHI is vUSE
related, so the patch does:

1. check if the definition is a vDEF and not defined in main loop.
2. check if the definition is a PHI and not defined in main loop.
3. check if the definition is a default definition.

For no 2 and 3 we may misidentify the PHI, in both cases the value is
defined
outside of the loop version block which also makes it ok to remove.

gcc/ChangeLog:

PR tree-optimization/111860
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Drop .MEM nodes only.

gcc/testsuite/ChangeLog:

PR tree-optimization/111860
* gcc.dg/vect/pr111860-2.c: New test.
* gcc.dg/vect/pr111860-3.c: New test.

[Bug libstdc++/111936] New: std::stacktrace cannot be used in a shared library

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

Bug ID: 111936
   Summary: std::stacktrace cannot be used in a shared library
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

I would like to use std::stacktrace in a shared library to be preloaded...

when I try to build the library even for this minimal example
cat getStacktrace.cc
#include 

  std::string get_stacktrace() {
 std::string trace;
 for (auto & entry : std::stacktrace::current() ) trace +=
entry.description() + '#';
 return trace;
  }

it fails
 c++ -O3 -Wall -pthread -fPIC -shared getStacktrace.cc -std=c++23 -lstdc++exp
/usr/bin/ld:
/afs/cern.ch/work/i/innocent/public/w5/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../lib64/libstdc++exp.a(std_stacktrace-fileline.o):
relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/afs/cern.ch/work/i/innocent/public/w5/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../lib64/libstdc++exp.a(std_stacktrace-posix.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/afs/cern.ch/work/i/innocent/public/w5/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../lib64/libstdc++exp.a(std_stacktrace-simple.o):
relocation R_X86_64_32 against `.text' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld:
/afs/cern.ch/work/i/innocent/public/w5/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../lib64/libstdc++exp.a(std_stacktrace-elf.o):
relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/afs/cern.ch/work/i/innocent/public/w5/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../lib64/libstdc++exp.a(std_stacktrace-mmap.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/afs/cern.ch/work/i/innocent/public/w5/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../lib64/libstdc++exp.a(std_stacktrace-mmapio.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/afs/cern.ch/work/i/innocent/public/w5/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../lib64/libstdc++exp.a(std_stacktrace-dwarf.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status


it silently compiles with
[innocent@patatrack01 ctest]$ c++ -O3 -Wall -pthread -fPIC -shared -std=c++23
-lstdc++exp getStacktrace.cc

but the symbols are undefined

[innocent@patatrack01 ctest]$ ldd ./a.out
linux-vdso.so.1 (0x7ffd50f73000)
libstdc++.so.6 => /afs/cern.ch/user/i/innocent/w5/lib64/libstdc++.so.6
(0x7fa9437f8000)
libm.so.6 => /usr/lib64/libm.so.6 (0x7fa943476000)
libgcc_s.so.1 => /afs/cern.ch/user/i/innocent/w5/lib64/libgcc_s.so.1
(0x7fa94324b000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x7fa94302b000)
libc.so.6 => /usr/lib64/libc.so.6 (0x7fa942c66000)
/lib64/ld-linux-x86-64.so.2 (0x7fa943e68000)
[innocent@patatrack01 ctest]$ nm -C ./a.out | grep stack
0db0 T get_stacktrace[abi:cxx11]()
0be0 t get_stacktrace[abi:cxx11]() [clone .cold]
0d20 t std::basic_stacktrace
>::current(std::allocator const&) [clone .isra.0]
 U std::stacktrace_entry::_Info::_M_populate(unsigned long)
1430 W std::stacktrace_entry::_Info::_S_set[abi:cxx11](void*, char
const*)
 U std::__stacktrace_impl::_S_current(int (*)(void*, unsigned
long), void*, int)
1310 W std::basic_stacktrace
>::_M_prepare(unsigned short)::{lambda(void*, unsigned long)#1}::_FUN(void*,
unsigned long)


and at run time (not this example, my full application that invoke the
staketrace from a malloc hook) it (obviously fail)

[innocent@patatrack01 ctest]$ c++ -O3 -Wall -pthread -fPIC -shared -std=c++23
-lstdc++exp mallocWrapper.cc
[innocent@patatrack01 ctest]$ setenv LD_PRELOAD ./a.out ; ls ; unsetenv
LD_PRELOAD
Recoding structure constructed in a thread
ls: symbol lookup error: ./a.out: undefined symbol:
_ZNSt17__stacktrace_impl10_S_currentEPFiPvmES0_i

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Oleg Endo :

https://gcc.gnu.org/g:267e369afbb963d8d84d7a9f0cb9fb18672d99a8

commit r14-4862-g267e369afbb963d8d84d7a9f0cb9fb18672d99a8
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

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

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

Tamar Christina  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #24 from Tamar Christina  ---
ok, should be actually fixed now

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Oleg Endo
:

https://gcc.gnu.org/g:4e1320e4af413b7126f3b998096f60f8b7d5cb32

commit r13-7976-g4e1320e4af413b7126f3b998096f60f8b7d5cb32
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:538dcde872abba589b3c8a57181bd7f91018c67a

commit r14-4863-g538dcde872abba589b3c8a57181bd7f91018c67a
Author: Iain Sandoe 
Date:   Mon Oct 23 13:07:50 2023 +0100

configure, libquadmath: Remove unintended AC_CHECK_LIBM [PR111928]

This was a rebase error, that managed to pass testing on Darwin and
Linux (but fails on bare metal).

PR libquadmath/111928

libquadmath/ChangeLog:

* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove AC_CHECK_LIBM.

Signed-off-by: Iain Sandoe 

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #8 from Iain Sandoe  ---
so, should be fixed on trunk.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Oleg Endo
:

https://gcc.gnu.org/g:4414818f4e5de54ea3c353e2ebb2e79a89ae211b

commit r12-9938-g4414818f4e5de54ea3c353e2ebb2e79a89ae211b
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #1 from vincenzo Innocente  ---
here is a minimal malloc hook that I would like to use
[innocent@patatrack01 ctest]$ cat getStacktrace.cc
#include 

  std::string get_stacktrace() {
 std::string trace;
 for (auto & entry : std::stacktrace::current() ) trace +=
entry.description() + '#';
 return trace;
  }


#include 
#include 
#include 

extern "C"
void * myMallocHook(size_t size, void const * caller) {
  __malloc_hook = nullptr;
  auto p = malloc(size);
  std::cout << "asked " << size
<< " at " << get_stacktrace()
<< std::endl;
  __malloc_hook = myMallocHook;
  return p;
}

namespace {
struct Hook {
  Hook() {
  __malloc_hook = myMallocHook;
  }
};

  Hook hook;

}

compiled as
c++ -O3 -Wall -pthread -fPIC -shared -std=c++23 -lstdc++exp getStacktrace.cc

gives the undefined symbol

 setenv LD_PRELOAD ./a.out ; ls ; unsetenv LD_PRELOAD
ls: symbol lookup error: ./a.out: undefined symbol:
_ZNSt17__stacktrace_impl10_S_currentEPFiPvmES0_i

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Oleg Endo
:

https://gcc.gnu.org/g:626bb2e165daa88f5c7cd66b9db49f03921474a9

commit r11-11075-g626bb2e165daa88f5c7cd66b9db49f03921474a9
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #15 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> 
> Do we need anything else before the fix can be merged?

No, should be fine.  I'll leave this PR open for a while in case anything else
related pops up.  Thanks for testing.

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|linkw at gcc dot gnu.org   |rguenth at gcc dot 
gnu.org

--- Comment #29 from Richard Biener  ---
I will try to implement the simple approach.

[Bug tree-optimization/111916] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu (the generated code hangs) since r14-4612-g6decda1a35be5764101987c210b5693a0d914e58

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

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

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

https://gcc.gnu.org/g:458db9b6149b2e9bef94ab76909eb914ed9f675a

commit r14-4866-g458db9b6149b2e9bef94ab76909eb914ed9f675a
Author: Richard Biener 
Date:   Mon Oct 23 14:08:41 2023 +0200

tree-optimization/111916 - SRA of BIT_FIELD_REF of constant pool entries

The following adjusts a leftover BIT_FIELD_REF special-casing to only
cover the cases general code doesn't handle.

PR tree-optimization/111916
* tree-sra.cc (sra_modify_assign): Do not lower all
BIT_FIELD_REF reads that are sra_handled_bf_read_p.

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

[Bug ipa/111914] ICE with function pointer array as argument with non-constant size

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Richard Biener  ---
Fixed on trunk, not worth backporting.

[Bug ipa/111914] ICE with function pointer array as argument with non-constant size

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

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

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

https://gcc.gnu.org/g:738d44348e7392a9f8e370afa3a9d8c24ee080cd

commit r14-4864-g738d44348e7392a9f8e370afa3a9d8c24ee080cd
Author: Richard Biener 
Date:   Mon Oct 23 13:29:30 2023 +0200

ipa/111914 - perform parameter init after remapping types

The following addresses a mismatch in SSA name vs. symbol when
we emit a dummy assignment when not optimizing.  The temporary
we create is not remapped by initialize_inlined_parameters because
we have no easy way to get at it.  The following instead emits
the additional statement after we have remapped the type of
the replacement variable.

PR ipa/111914
* tree-inline.cc (setup_one_parameter): Move code emitting
a dummy load when not optimizing ...
(initialize_inlined_parameters): ... here to after when
we remapped the parameter type.

* gcc.dg/pr111914.c: New testcase.

[Bug tree-optimization/111915] [14 Regression] ICE in vect with option `-O2 -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-ccp` since r14-2117-gdd86a5a69cbda4

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

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

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

https://gcc.gnu.org/g:00eb0812e6464307f9f971d2a743d720015e70cf

commit r14-4865-g00eb0812e6464307f9f971d2a743d720015e70cf
Author: Richard Biener 
Date:   Mon Oct 23 13:42:53 2023 +0200

tree-optimization/111915 - mixing grouped and non-grouped accesses

The change to allow SLP of non-grouped accesses failed to check
for the case of mixing with grouped accesses.

PR tree-optimization/111915
* tree-vect-slp.cc (vect_build_slp_tree_1): Check all
accesses are either grouped or not.

* gcc.dg/vect/pr111915.c: New testcase.

[Bug tree-optimization/111916] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu (the generated code hangs) since r14-4612-g6decda1a35be5764101987c210b5693a0d914e58

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/111915] [14 Regression] ICE in vect with option `-O2 -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-ccp` since r14-2117-gdd86a5a69cbda4

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/111933] memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

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

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

--- Comment #1 from Richard Biener  ---
uint32_t from_unaligned_u32(uint32_t *unaligned)
{
uint32_t tmp;
tmp = *unaligned;

note this isn't an unaligned access since you dereference a uint32_t pointer

[Bug middle-end/111933] memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

[bettio.davide at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Davide Bettio  ---
(In reply to Richard Biener from comment #1)
> uint32_t from_unaligned_u32(uint32_t *unaligned)
> {
> uint32_t tmp;
> tmp = *unaligned;
> 
> note this isn't an unaligned access since you dereference a uint32_t pointer

Let me explain better my purpose: I was writing a function for reading uint32_t
and uint64_t values at any address, including odd ones such as 0x2345.

So as far as I know the only generic way to do this is either casting them to
uint8_t and reading them as 4 or 8 bytes, or using memcpy.
My expectation is that memcpy is always replaced with a load instruction when
fast unaligned memory access is available.

Let me know if I am making any wrong assumptiom.

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

--- Comment #30 from Richard Biener  ---
Created attachment 56175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56175&action=edit
prototype patch

This is an (untested) fix, API wise needs some cleanup still.  It's the most
simple fix that doesn't completely give up on TBAA.

[Bug target/111937] New: [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data.

[mxlol233 at outlook dot com via Gcc-bugs]

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

Bug ID: 111937
   Summary: [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1,
the `poly_xxx`  made `lto_input_mode_table` unable to
parse binary gimple data.
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mxlol233 at outlook dot com
  Target Milestone: ---

Recently, I wanted to port an open source gpgpu target (a custom modification
of RISCV) to GCC/openmp (Following the approach of gcu and nvptx, using
offloading (https://gcc.gnu.org/wiki/Offloading)). However, the upstream after
this patch
(https://github.com/mxlol233-ventus/gcc/commit/3496ca4e6566fc3c5f1093a0290bb88c34d368f8#diff-98b71abedd6e59eb80cb43e75ebb507ffa8bf540ee88aa099c6c7fe7cf90ae3e),
NUM_POLY_INT_COEFFS became greater than 1, while for the x86-64-*-* target,
NUM_POLY_INT_COEFFS=1. This makes it impossible for a RISC-V*-*-* lto1 to parse
the data in the LTO sections (e.g. gnu.offload_lto_*) of the object files
generated by x86-64-*-*.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #16 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #15)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> > 
> > Do we need anything else before the fix can be merged?
> 
> No, should be fine.  I'll leave this PR open for a while in case anything
> else related pops up.  Thanks for testing.

Just saw the branch updates, thanks! FWIW, I did observe this issue in gcc-13
only but not gcc-11 or gcc-12. But that might be owed to the fact that Debian's
gcc-11 and gcc-12 packages had not received the latest branch updates yet.

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to vincenzo Innocente from comment #0)
> it silently compiles with
> [innocent@patatrack01 ctest]$ c++ -O3 -Wall -pthread -fPIC -shared
> -std=c++23 -lstdc++exp getStacktrace.cc
> 
> but the symbols are undefined

This is simply because you need to list libraries after the files that depend
on them:
https://c-faq.com/lib/libsearch.html

When the linker sees -lstdc++exp there are no undefined references to any of
the symbols it provides, so the linker ignores it. Then it sees getStacktrace.o
which has undefined refs but it's too late, the archive has already been
processed.

The library should be compiled as PIC though, which is a separate issue.

[Bug target/96265] building nvptx-none on aarch64-linux-gnu

[mxlol233 at outlook dot com via Gcc-bugs]

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

Xiao Ma  changed:

   What|Removed |Added

 CC||mxlol233 at outlook dot com

--- Comment #3 from Xiao Ma  ---
I think this issue and #111937
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937) have the same root cause: 
aarch64 also sets NUM_POLY_INT_COEFFS to 2, which makes it incompatible with
the default value for nvptx (which is 1).

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

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

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

--- Comment #3 from Jonathan Wakely  ---
The problem is that libstdc++_libbacktrace.a is not compiled with -fPIC

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||link-failure
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Target Milestone|--- |13.3
   Last reconfirmed||2023-10-23

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #17 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #16)

> Just saw the branch updates, thanks! FWIW, I did observe this issue in
> gcc-13 only but not gcc-11 or gcc-12. But that might be owed to the fact
> that Debian's gcc-11 and gcc-12 packages had not received the latest branch
> updates yet.

Yes, I know it has been observed on the latest GCC-13 only.  It was an
oversight in the code from the beginning, which got triggered by another change
in the compiler.  I haven't checked which change exactly, but I guess it must
have been some backported change. So if the same/similar thing gets backported
to GCC-11 or GCC-12 it might trigger this bug there, too.  Hence the preventive
measure.  It's a rather obvious bug/fix, so should be safe.

[Bug c++/111919] [14 Regression] ICE: tree check: did not expect class 'type', have 'type' (integer_type) in contains_placeholder_p, at tree.cc:4144 on valid code

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Created attachment 56176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56176&action=edit
partially reduced C++ source code

I have another test case.

[Bug fortran/110644] Error in gfc_format_decoder

[aluaces at udc dot es via Gcc-bugs]

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

--- Comment #12 from Alberto Luaces  ---
It seems to be slightly different:

(gdb) p expr->ts.type
$7 = BT_PROCEDURE
(gdb) p expr->symtree->name
$8 = 0x770244e8 "@1179"

(gdb) p expr->where
$9 = {nextc = 0x0, lb = 0x0}

Maybe it will be clearer if I manage to write the example.

[Bug tree-optimization/64450] Optimize 0>=p-q to q>=p for char*p,*q;

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/110721] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

Sam James  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #5 from Sam James  ---
the bisect indicates r12-248-gb58dc0b803057c was the fix:

b58dc0b803057c0e6032e0d9bd92cd834f72c75c is the first bad commit
commit b58dc0b803057c0e6032e0d9bd92cd834f72c75c
Author: Richard Biener 
Date:   Tue Apr 27 14:32:27 2021 +0200

tree-optimization/99912 - delete trivially dead stmts during DSE

DSE performs a backwards walk over stmts removing stores but it
leaves removing resulting dead SSA defs to later passes.  This
eats into its own alias walking budget if the removed stores kept
loads live.  The following patch adds removal of trivially dead
SSA defs which helps in this situation and reduces the amount of
garbage followup passes need to deal with.