[Bug testsuite/110445] [14 Regression] FAIL: gcc.dg/vect/slp-46.c with AVX2

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization,
   ||testsuite-fail
   Target Milestone|--- |14.0

[Bug testsuite/110445] New: [14 Regression] FAIL: gcc.dg/vect/slp-46.c with AVX2

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

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

Bug ID: 110445
   Summary: [14 Regression] FAIL: gcc.dg/vect/slp-46.c with AVX2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

With AVX2 we fail to SLP

double x[1024], y[1024];

void __attribute__((noipa)) foo()
{
  for (int i = 0; i < 512; ++i)
{
  x[2*i] = y[i];
  x[2*i+1] = y[i];
}
}

because we hit the following:

/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/vect/slp-46.c:10:21: note:
  ==> examining statement: _2 = y[i_12];
/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/vect/slp-46.c:10:21:
missed:   peeling for gaps insufficient for access
/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/vect/slp-46.c:12:17:
missed:   not vectorized: relevant stmt not supported: _2 = y[i_12];
/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/vect/slp-46.c:10:21: note:
  removing SLP instance operations starting from: x[_1] = _2;
/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/vect/slp-46.c:10:21:
missed:  unsupported SLP instances
/space/rguenther/src/gcc11queue/gcc/testsuite/gcc.dg/vect/slp-46.c:10:21: note:
 re-trying with SLP disabled

the issue is that in the last vector iteration with VF=2 we are accessing
{ i, i+1, i+2, i+3 }, if we're peeling at least a single scalar iteration
we still access possibly one too much elements.

The simplest solution would be to access { i, i+1 } only which I think
we already can do.  The other solution is to peel N scalar
iterations or apply masking to not access elements in the gap if the ISA
supports that.

[Bug tree-optimization/110440] [14 regression] ICE when building pixman

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

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

--- Comment #3 from Sam James  ---
I've hit it with another package (basis_universal) but the ICE looks identical
and it's C++ so I won't worry about reducing it unless someone asks me to.

```
during GIMPLE pass: vect
/var/tmp/portage/games-util/basis_universal-1.16.3/work/basis_universal-1.16.3/encoder/basisu_etc.cpp:
In member function ‘void basisu::etc1_optimizer::refine_solution(uint32_t)’:
/var/tmp/portage/games-util/basis_universal-1.16.3/work/basis_universal-1.16.3/encoder/basisu_etc.cpp:846:14:
internal compiler error: Segmentation fault
  846 | void etc1_optimizer::refine_solution(uint32_t
max_refinement_trials)
  |  ^~
0xcb821d7f crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/toplev.cc:314
0xcc8834b0 vec<_slp_tree*, va_heap, vl_embed>::operator[](unsigned int)
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/vec.h:890
0xcc8834b0 vec<_slp_tree*, va_heap, vl_ptr>::operator[](unsigned int)
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/vec.h:1505
0xcc8834b0 vect_get_gather_scatter_ops
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-stmts.cc:3109
0xcc89683b vectorizable_load
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-stmts.cc:10254
0xcc8a09c3 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-stmts.cc:12031
0xcbb1aaa7 vect_schedule_slp_node
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9002
0xcbb2e5db vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9197
0xcbb2e57f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xcbb2e57f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xcbb2e57f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xcbb2e57f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xcbb2e57f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xcbb2ec3f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap,
vl_ptr> const&)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9337
0xcbb005c7 vect_transform_loop(_loop_vec_info*, gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-loop.cc:11270
0xcbb3f447 vect_transform_loops
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1004
0xcbb3fb23 try_vectorize_loop_1
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1150
0xcbb3fb23 try_vectorize_loop
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1180
0xcbb4018f execute
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1296
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
```

[Bug rtl-optimization/110202] _mm512_ternarylogic_epi64 generates unnecessary operations

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

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

--- Comment #9 from Alexander Monakov  ---
(In reply to Hongtao.liu from comment #8)
> 
> For this one, we can load *a into %zmm0 to avoid false_dependence.
> 
> vmovdqau ZMMWORD PTR [rdi], zmm0
> vpternlogq  zmm0, zmm0, zmm0, 85

Yes, since ternlog with memory operand needs two fused-domain uops on Intel
CPUs, breaking out the load would be more efficient for both negate1 and
negate2.

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

--- Comment #13 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-2149-gabdf0b6cdff5783b97f35ad61ae31433f0569dfd
Author: Jason Merrill 
Date:   Tue Jun 27 05:15:01 2023 -0400

c++: inherited constructor attributes

Inherited constructors are like constructor clones; they don't exist from
the language perspective, so they should copy the attributes in the same
way.  But it doesn't make sense to copy alias or ifunc attributes in either
case.  Unlike handle_copy_attribute, we do want to copy inlining
attributes.

The discussion of PR110334 pointed out that we weren't copying the
always_inline attribute, leading to poor inlining choices.

PR c++/110334

gcc/cp/ChangeLog:

* cp-tree.h (clone_attrs): Declare.
* method.cc (implicitly_declare_fn): Use it for inherited
constructor.
* optimize.cc (clone_attrs): New.
(maybe_clone_body): Use it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nodiscard-inh1.C: New test.

[Bug c++/110338] Implement C++26 language features

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

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

Bug 110344 Summary: [C++26] P2738R1 - constexpr cast from void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344

   What|Removed |Added

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

[Bug c++/110344] [C++26] P2738R1 - constexpr cast from void*

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Implemented for GCC 14.

[Bug c++/110344] [C++26] P2738R1 - constexpr cast from void*

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-2146-ga1c6e9631ca33990a2b7411060ca4d18db081a7d
Author: Jason Merrill 
Date:   Sat Jun 24 05:15:02 2023 -0400

c++: C++26 constexpr cast from void* [PR110344]

P2768 allows static_cast from void* to ob* in constant evaluation if the
pointer does in fact point to an object of the appropriate type.
cxx_fold_indirect_ref already does the work of finding such an object if it
happens to be a subobject rather than the outermost object at that address,
as in constexpr-voidptr2.C.

P2768
PR c++/110344

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Update __cpp_constexpr.

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_constant_expression): In C++26, allow cast
from void* to the type of a pointed-to object.

gcc/testsuite/ChangeLog:

* g++.dg/cpp26/constexpr-voidptr1.C: New test.
* g++.dg/cpp26/constexpr-voidptr2.C: New test.
* g++.dg/cpp26/feat-cxx26.C: New test.

[Bug target/110144] cris-unknown-elf cross build fails with ICE if RTL checking is enabled

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-28
 CC||hp at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hp at gcc dot gnu.org

--- Comment #1 from Hans-Peter Nilsson  ---
Thanks for the report.  Confirmed.  I'm on it; testing a first patch candidate.

[Bug rtl-optimization/110202] _mm512_ternarylogic_epi64 generates unnecessary operations

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to Alexander Monakov from comment #7)
> Note that vpxor serves as a dependency-breaking instruction (see PR 110438).
> So in negate1 we do the right thing for the wrong reasons, and in negate2 we
> can cause a substantial stall if the previous computation of xmm0 has a
> non-trivial dependency chain.

For this one, we can load *a into %zmm0 to avoid false_dependence.

vmovdqau ZMMWORD PTR [rdi], zmm0
vpternlogq  zmm0, zmm0, zmm0, 85

[Bug target/110438] generating all-ones zmm needs dep-breaking pxor before ternlog

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from Hongtao.liu  ---
(In reply to Alexander Monakov from comment #1)
> We might want to omit PXOR when optimizing for size.

indeed.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #16 from H.J. Lu  ---
Created attachment 55409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55409&action=edit
A patch

I am stilling trying to find a small testcase.

[Bug middle-end/110444] [14 Regression] ice in real_can_shorten_arithmetic, at real.cc:1398

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

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

--- Comment #5 from Andrew Pinski  ---
Note this might be already fixed by:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622984.html
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d915762ea9043da858d388b60b2d8093ff77eeab

Once I reduce the testcase, I will retest it to see if it has been fixed or
not.

[Bug middle-end/110443] [14 Regression] ICE on a52dec-0.7.4: GIMPLE pass: vect SIGSEGV in vect_get_gather_scatter_ops()

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

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

--- Comment #3 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #2)
> I wonder if it's a r14-2117-gdd86a5a69cbda4 "tree-optimization/96208 - SLP
> of non-grouped loads".

Reverting r14-2117-gdd86a5a69cbda4 fixes a52dec-0.7.4 for me.

[Bug middle-end/110443] [14 Regression] ICE on a52dec-0.7.4: GIMPLE pass: vect SIGSEGV in vect_get_gather_scatter_ops()

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Sergei Trofimovich  ---
I wonder if it's a r14-2117-gdd86a5a69cbda4 "tree-optimization/96208 - SLP of
non-grouped loads".

[Bug middle-end/110444] [14 Regression] ice in real_can_shorten_arithmetic, at real.cc:1398

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Target||x86_64-linux-gnu
Summary|ice in  |[14 Regression] ice in
   |real_can_shorten_arithmetic |real_can_shorten_arithmetic
   |, at real.cc:1398   |, at real.cc:1398
Version|unknown |14.0

[Bug middle-end/110444] ice in real_can_shorten_arithmetic, at real.cc:1398

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
The bug seems to appear sometime between g:f10a4ce044a62c92
and g:319e6fe96027f537, which is 173 commits.

[Bug middle-end/110444] ice in real_can_shorten_arithmetic, at real.cc:1398

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

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

--- Comment #3 from Andrew Pinski  ---
r14-2041

[Bug middle-end/110444] ice in real_can_shorten_arithmetic, at real.cc:1398

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

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

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

[Bug middle-end/110444] ice in real_can_shorten_arithmetic, at real.cc:1398

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
0x8df39f real_can_shorten_arithmetic(machine_mode, machine_mode)
/home/apinski/src/upstream-gcc-git/gcc/gcc/real.cc:1398
0x216236b gimple_simplify_123(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node*, tree_node**, tree_code)
   
/home/apinski/src/upstream-gcc-git/gcc/objdir/gcc/gimple-match-2.cc:1071
0x215a036 gimple_simplify_CONVERT_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*)
   
/home/apinski/src/upstream-gcc-git/gcc/objdir/gcc/gimple-match-1.cc:4814
0x186c971 gimple_resimplify1
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-match-exports.cc:890
0x186d427 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-match-exports.cc:834
0xf67c6e gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-fold.cc:7472
0x149bbb4 try_to_simplify
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-sccvn.cc:6096
0x149bbb4 visit_stmt
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-sccvn.cc:6139
0x149c6b5 process_bb
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-sccvn.cc:7945
0x149e1c9 do_rpo_vn_1
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-sccvn.cc:8544
0x149fb38 execute
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-sccvn.cc:8702
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++/110444] New: ice in real_can_shorten_arithmetic, at real.cc:1398

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 110444
   Summary: ice in real_can_shorten_arithmetic, at real.cc:1398
   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 55408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55408&action=edit
gzipped C++ source code

The attached C++ code does this with recent gcc trunk:

$ ~/gcc/results/bin/gcc -c -w -O2 -std=c++11 bug934.cc 
during GIMPLE pass: fre
In file included from
/home/dcb38/rpmbuild/BUILD/vigra-1.11.1/vigranumpy/src/cor
e/non_local_mean.cxx:41:
/home/dcb38/rpmbuild/BUILD/vigra-1.11.1/include/vigra/non_local_mean.hxx: In
fun
ction ‘void vigra::gaussianMeanAndVariance(const MultiArrayView&, double, MultiArrayView&, MultiArrayView&, MultiArrayView&) [with int DIM = 2;
PIXEL_TYPE_IN
 = TinyVector; SMOOTH_POLICY = TinyVector; PIXEL_TYPE_OUT = 
TinyVector]’:
/home/dcb38/rpmbuild/BUILD/vigra-1.11.1/include/vigra/non_local_mean.hxx:799:13:
 internal compiler error: in real_can_shorten_arithmetic, at real.cc:1398
  799 | inline void gaussianMeanAndVariance(
  | ^~~
0x107bebe real_can_shorten_arithmetic(machine_mode, machine_mode)
../../trunk.year/gcc/real.cc:1398

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
Created attachment 55407
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55407&action=edit
Third patch set

Here's a lightly tested 3rd patch that tries to handle the chaos I created...

Can you have a look?

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #19 from Mikael Morin  ---
(In reply to Mikael Morin from comment #18)
> There is the "obvious" problem that gfc_build_wide_string_const creates a
> bare array, whereas gfc_string_to_single_character expects a pointer
> wrapping around it.
> I was wrong saying above that "A" is a pointer.  It is converted to a
> pointer if passed as argument in C, but the middle-end clearly distinguishes
> between arrays and pointers, and "A" is an array, not a pointer to an array.

Sorry, you can scratch that, the failing case is the NON-constant case.

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #18 from Mikael Morin  ---
(In reply to Mikael Morin from comment #15)
> I have asked for an account on the compile farm (see
> https://gcc.gnu.org/wiki/CompileFarm) to have access to a powerpc machine.

It was pretty fast to get the green light, but then the machines have to see
the change of configuration to accept my logging in.  It's not working yet.

(In reply to anlauf from comment #17)
> Running under gdb seems to tell that gfc_string_to_single_character returns
> a NULL_TREE for yet unknown reason.

There is the "obvious" problem that gfc_build_wide_string_const creates a bare
array, whereas gfc_string_to_single_character expects a pointer wrapping around
it.
I was wrong saying above that "A" is a pointer.  It is converted to a pointer
if passed as argument in C, but the middle-end clearly distinguishes between
arrays and pointers, and "A" is an array, not a pointer to an array.

[Bug analyzer/110433] ASAN reports mismatching new/delete when compiling analyzer testcases

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

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

--- Comment #1 from David Malcolm  ---
I haven't reproduced this yet, but I notice that I forgot to give class
spatial_item a virtual dtor, which looking at the backtrace may be the root
cause.

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

[jan.zizka at nokia dot com via Gcc-bugs]

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

--- Comment #10 from Jan Žižka  ---
Ah I didn't really complain, this is fine by me and I'm happy we can catch
these. The code 
 and build configuration, which hit this, was not touched for 20 years :-) so
any help is welcome for us at least.

For me it is enough that this is not possible to catch by compilation error. I
agree -Werror should be used, but for such old code base as ours noone is
really going to modify the flags :-) ... so then crashing is better then
invisibility.

[Bug middle-end/110430] Fail to CSE for LEN_MASK_STORE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-27
 Ever confirmed|0   |1

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

[Bug middle-end/110430] Fail to CSE for LEN_MASK_STORE

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Target|riscv   |riscv, aarch64

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

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

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

--- Comment #9 from Jonathan Wakely  ---
The trap was added for PR 104642 because people keep ignoring the -Wreturn-type
warning and then complaining that the code misbehaves.

Of course now people complain that they prefer the unpredictable undefined
behaviour instead of predictable trapping.

You can't please everybody.

[Bug middle-end/110443] [14 Regression] ICE on a52dec-0.7.4:

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

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

--- Comment #1 from Andrew Pinski  ---
This is related to PR 110440 but the reduced testcases look almost the same but
the ICE is different in both cases.

[Bug middle-end/110443] [14 Regression] ICE on a52dec-0.7.4:

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

[Bug tree-optimization/110436] [14 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:10170

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/110443] New: [14 Regression] ICE on a52dec-0.7.4:

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

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

Bug ID: 110443
   Summary: [14 Regression] ICE on a52dec-0.7.4:
   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: ---

Noticerd ICE on a52dec-0.7.4 against gcc r14-2134-g231f6b56c77c50. Extracted
minimal example is:

Extracted reproducer:

// $ cat bug.c.c
typedef struct {
  float real;
  float imag;
} complex_t;
char fftorder[] = {};
float *a52_imdct_256_data;
int a52_imdct_256_i, a52_imdct_256_k;
float a52_imdct_256_b_r;
void a52_imdct_256() {
  complex_t buf1[64];
  a52_imdct_256_i = 0;
  for (; a52_imdct_256_i < 64; a52_imdct_256_i++) {
a52_imdct_256_k = fftorder[a52_imdct_256_i];
buf1[a52_imdct_256_i].real = buf1[a52_imdct_256_i].imag =
a52_imdct_256_data[a52_imdct_256_k];
  }
  a52_imdct_256_b_r = buf1[0].real * buf1[0].imag;
}

$ gcc -O2 -c bug.c.c -o bug.o
during GIMPLE pass: vect
bug.c.c: In function 'a52_imdct_256':
bug.c.c:9:6: internal compiler error: Segmentation fault
9 | void a52_imdct_256() {
  |  ^
0x1bc5d04 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1bc6277 internal_error(char const*, ...)
???:0
0xcca64f crash_signal(int)
???:0
0x1a84a18 vect_get_gather_scatter_ops(_loop_vec_info*, loop*, _stmt_vec_info*,
_slp_tree*, gather_scatter_info*, tree_node**, vec*)
???:0
0x1a92fb2 vectorizable_load(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
gimple**, _slp_tree*, vec*)
???:0
0x1aa01d8 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
???:0
0xf2ab57 vect_schedule_slp_node(vec_info*, _slp_tree*, _slp_instance*)
???:0
0xf3abcb vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0xf3a812 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*,
hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_info> >&, int&,
vec<_slp_tree*, va_heap, vl_ptr>&)
???:0
0xf3b166 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
???:0
0xf0f23b vect_transform_loop(_loop_vec_info*, gimple*)
???:0
0xf4833b vect_transform_loops(hash_table*&,
loop*, gimple*, function*)
???:0
0xf489db try_vectorize_loop(hash_table*&,
unsigned int*, loop*, function*)
???:0
0xf48f34 (anonymous namespace)::pass_vectorize::execute(function*)
???:0

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug tree-optimization/110440] [14 regression] ICE when building pixman

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

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

--- Comment #2 from Sam James  ---
Created attachment 55406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55406&action=edit
reduced.i

[Bug c/110442] New: IFUNC resolvers which use __builtin_cpu_supports crash with -fsanitize=address

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

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

Bug ID: 110442
   Summary: IFUNC resolvers which use __builtin_cpu_supports crash
with -fsanitize=address
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

With -O2 -fsanitize=address, this code:

“
#include 

void
f1 (void)
{
  puts ("f1");
}

void
f2 (void)
{
  puts ("f2");
}

void *
resolve (void)
{
  __builtin_cpu_init ();
  if (__builtin_cpu_supports ("f16c"))
return f1;
  else
return f2;
}

void f (void) __attribute__ ((ifunc ("resolve")));

int
main (void)
{
  f ();
}
”

In the store to the shadow mapping:

Dump of assembler code for function resolve:
   0x00402320 <+0>: sub$0x8,%rsp
   0x00402324 <+4>: call   0x4010f0 <__cpu_indicator_init>
   0x00402329 <+9>: mov$0x4050f0,%eax
   0x0040232e <+14>:shr$0x3,%rax
=> 0x00402332 <+18>:movzbl 0x7fff8000(%rax),%eax
   0x00402339 <+25>:test   %al,%al
   0x0040233b <+27>:je 0x402341 
   0x0040233d <+29>:cmp$0x3,%al
[…]

This happens because with IRELATIVE relocations (or BIND_NOW), IFUNC resolvers
run early, before libasan had a chance to set up the shadow mapping.

Setting the component to the C front-end because the ifunc function attribute
probably needs to be changed to imply no_sanitize_address. IFUNC resolvers are
not supposed to call functions (although it works in some cases on x86), so I
think this would really help building random code with -fsanitize=address.

(In theory, if libasan were an audit module, it would be possible to set up the
mapping before relocation, but that's a change that seems unlikely to happen.)

[Bug c++/110344] [C++26] P2738R1 - constexpr cast from void*

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/110440] [14 regression] ICE when building pixman

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

[Bug c++/110441] New: c++17 deferred materialization of temporaries fails when calling class static with member syntax

[eric.niebler at gmail dot com via Gcc-bugs]

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

Bug ID: 110441
   Summary: c++17 deferred materialization of temporaries fails
when calling class static with member syntax
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

struct immovable {
  immovable() = default;
  immovable(immovable &&) = delete;
};

struct S {
  static immovable f() {
return {};
  }
};

immovable g() { 
  return S().f();
}

compile with -std=c++17. Result:

: In function 'immovable g()':
:14:15: error: use of deleted function
'immovable::immovable(immovable&&)'
   14 |   return S().f();
  |  ~^~
:4:3: note: declared here
4 |   immovable(immovable &&) = delete;
  |   ^


https://godbolt.org/z/Y1h9bPrf3

[Bug c++/110440] [14 regression] ICE when building pixman

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

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

--- Comment #1 from Sam James  ---
gcc -O3 -c ... is enough to repro.

[Bug c++/110440] New: [14 regression] ICE when building pixman

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

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

Bug ID: 110440
   Summary: [14 regression] ICE when building pixman
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55405&action=edit
pixman-bits-image.c.i

```
FAILED: pixman/libpixman-1.so.0.42.2.p/pixman-bits-image.c.o
aarch64-unknown-linux-gnu-gcc -Ipixman/libpixman-1.so.0.42.2.p -Ipixman
-I../pixman-0.42.2/pixman -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64
-Wall -Winvalid-pch -std=gnu99 -Wdeclaration-after-statement
 -fno-strict-aliasing -fvisibility=hidden -Wundef -ftrapping-math
-Wno-unused-local-typedefs -DHAVE_CONFIG_H -O3 -pipe -mcpu=native
-fdiagnostics-color=always -fPIC -pthread -MD -MQ pixman/libpixman-1.so.0.42
.2.p/pixman-bits-image.c.o -MF
pixman/libpixman-1.so.0.42.2.p/pixman-bits-image.c.o.d -o
pixman/libpixman-1.so.0.42.2.p/pixman-bits-image.c.o -c
../pixman-0.42.2/pixman/pixman-bits-image.c
during GIMPLE pass: vect
../pixman-0.42.2/pixman/pixman-bits-image.c: In function
‘dest_write_back_wide’:
../pixman-0.42.2/pixman/pixman-bits-image.c:1172:1: internal compiler error:
Segmentation fault
 1172 | dest_write_back_wide (pixman_iter_t *iter)
  | ^~~~
0xafb19b1f crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/toplev.cc:314
0xb0c0b7b0 vec<_slp_tree*, va_heap, vl_embed>::operator[](unsigned int)
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/vec.h:890
0xb0c0b7b0 vec<_slp_tree*, va_heap, vl_ptr>::operator[](unsigned int)
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/vec.h:1505
0xb0c0b7b0 vect_get_gather_scatter_ops
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-stmts.cc:3109
0xb0c1eb3b vectorizable_load
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-stmts.cc:10254
0xb0c28cc3 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-stmts.cc:12031
0xafe12a47 vect_schedule_slp_node
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9002
0xafe2657b vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9197
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe2651f vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9178
0xafe26bdf vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap,
vl_ptr> const&)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-slp.cc:9337
0xafdf8567 vect_transform_loop(_loop_vec_info*, gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vect-loop.cc:11270
0xafe373e7 vect_transform_loops
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-vectorizer.cc:1004
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

```
gcc (Gentoo 14.0.0 p, commit 6cb33e2f39e289ec4f25f845d8153053147c5c49) 14.0.0
20230627 (experimental) 3c52dff792878306515056ecd94c8aa909f388fb
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 target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

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

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

--- Comment #15 from Xi Ruoyao  ---
attachment 54666 from PR109093 seems able to fix this.  Could we make it into
trunk and the release branches?

[Bug debug/110439] Missing DW_TAG_typedef for variable with attribute of typedef'd type

[david.faust at oracle dot com via Gcc-bugs]

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

David Faust  changed:

   What|Removed |Added

 CC||jemarch at gcc dot gnu.org

--- Comment #2 from David Faust  ---
(In reply to Andrew Pinski from comment #1)
> The may_alias does not apply directly to variables nor their types 

I use may_alias here as a placeholder, since it persists in the TREE
representation through this point.  I found this while implementing a new
attribute (btf_type_tag, a BPF feature) which does apply directly to types with
a similar representation in the TREE, which triggered the same behavior.

[Bug debug/110439] Missing DW_TAG_typedef for variable with attribute of typedef'd type

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

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

--- Comment #1 from Andrew Pinski  ---
The may_alias does not apply directly to variables nor their types 

[Bug debug/110439] New: Missing DW_TAG_typedef for variable with attribute of typedef'd type

[david.faust at oracle dot com via Gcc-bugs]

db) 
13706 if (mod_type_die
(gdb) p mod_type_die
$1 = 

Then recurses with

  return modified_type_die (DECL_ORIGINAL_TYPE (name), cv_quals,
  reverse, context_die);

Where DECL_ORIGINAL_TYPE (name) is a plain integer type:

  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:-142864960 alias-set -1 canonical-type
0x776215e8 precision:32 min  max

pointer_to_this >


I am not 100% sure whether the GCC output is "strictly incorrect" DWARF, but at
the least
it is an inconsistency between clang and GCC.

Observed with gcc (Debian 12.2.0-14) 12.2.0 and git master (GCC) 14.0.0
20230627 (experimental) on x86_64

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

[jan.zizka at nokia dot com via Gcc-bugs]

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

--- Comment #8 from Jan Žižka  ---
Well then I apologize for stealing your time. I did try to search both BZ and
Internet and didn't hit any hints as what is happening and why exactly with gcc
13 if gcc 12 didn't "catch" these. I need to work on my search skills.

[Bug rtl-optimization/110202] _mm512_ternarylogic_epi64 generates unnecessary operations

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

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

--- Comment #7 from Alexander Monakov  ---
Note that vpxor serves as a dependency-breaking instruction (see PR 110438). So
in negate1 we do the right thing for the wrong reasons, and in negate2 we can
cause a substantial stall if the previous computation of xmm0 has a non-trivial
dependency chain.

[Bug target/110438] generating all-ones zmm needs dep-breaking pxor before ternlog

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

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

--- Comment #1 from Alexander Monakov  ---
We might want to omit PXOR when optimizing for size.

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
It appears that gfc_string_to_single_character does not fulfill my expectation.
The following ICEs now:

subroutine s
  implicit none
  interface
 subroutine ref (c)
   character:: c
 end
 subroutine val (c)
   character, value :: c
 end
  end interface
  character(len=1)  :: c = "A"
  character(len=10) :: d = "D"
  call ref (c)
  call ref (d)
  call ref (c // d)
  call val (c // d) ! OK
  call val (c)  ! bad (ok for 13-branch)
  call val (d)  ! bad
end

The tree-dump shows that 13-branch generates correct code only for the
indicated call val (c), while the other two are wrong.
Current 14-branch is correct for the case with the temporary e.g. for the
string concatenation, and the other two are a complete fail...

Running under gdb seems to tell that gfc_string_to_single_character returns
a NULL_TREE for yet unknown reason.

[Bug target/110438] New: generating all-ones zmm needs dep-breaking pxor before ternlog

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

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

Bug ID: 110438
   Summary: generating all-ones zmm needs dep-breaking pxor before
ternlog
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

VPTERNLOG is never a dependency-breaking instruction on existing x86
implementations, so generating a vector of all-ones via bare ternlog can stall
waiting on destination register. GCC should emit a dependency-breaking PXOR,
otherwise it will be a false-dependency-on-popcnt-lzcnt debacle all over again.

#include 

__m512i g(void)
{
return (__m512i){ 0 } - 1;
}

g:
# waits until previous computation
# of zmm0 has completed
vpternlogd  zmm0, zmm0, zmm0, 0xFF
ret

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jan.zizka at nokia dot com

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

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||xvladsoft at yahoo dot com

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

[Bug c++/109554] Compiler generates incorrect code when the function declared with returned parameterm but no 'return' in its body

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

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

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

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ldv at sourceware dot org

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

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
(In reply to Jan Žižka from comment #6)
> Thanks ;-) hope this BZ will at least help others if they hit the same thing
> to understand the reasoning.

Not really ...

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

[Bug c++/89218] [8/9 Regression] g++ miscompiles functions returning non-void without return statements

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

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

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

[Bug c++/106696] Fallthrough between functions without proper return statement when optimizing

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

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

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

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||stefan.kneifel at bluewin dot 
ch

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

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sboisvert at gydle dot com

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

[Bug c++/91215] Compiled program loops endlessly because of -O2 with g++ 8.3.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

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

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

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jaydee at email dot cz

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

[Bug c++/86761] Code corruption with missing pointer return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||arturo.laurenzi at gmail dot 
com

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

[Bug c++/96181] Missing return statement now leads to crashes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

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

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

[Bug c++/87515] "no return statement in function returning non-void" miscompiles with optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
.

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

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

[jan.zizka at nokia dot com via Gcc-bugs]

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

--- Comment #6 from Jan Žižka  ---
Thanks ;-) hope this BZ will at least help others if they hit the same thing to
understand the reasoning.

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jan Žižka from comment #3)
> Good thanks for pointer and clarification.
> 
> Is there some reason this cannot be caught during compile time already? I
> mean the warning should be an error maybe? It would be much easier to fix in
> legacy code.

Well it is undefined behavior at runtime (not at compile time) so rejecting it
would not be a valid thing to do.

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

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

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

--- Comment #4 from Andrew Pinski  ---
-Werror=return-type

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

[jan.zizka at nokia dot com via Gcc-bugs]

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

--- Comment #3 from Jan Žižka  ---
Good thanks for pointer and clarification.

Is there some reason this cannot be caught during compile time already? I mean
the warning should be an error maybe? It would be much easier to fix in legacy
code.

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed) with asm goto with output and same block and two labels

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||12.3.1, 13.1.1
   Target Milestone|--- |12.4
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
  Known to work||12.3.1, 13.1.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/110420] [12/13 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|13.2|12.4
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||12.3.1, 13.1.1

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

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed) with asm goto with output and same block and two labels

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:

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

commit r12-9732-gee3bb7cb5d2ecfc64adcfd61afb390e72cc08661
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

(cherry picked from commit 478840a2ca491fbff44371caee4983d1e7b7b7cf)

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:

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

commit r12-9732-gee3bb7cb5d2ecfc64adcfd61afb390e72cc08661
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

(cherry picked from commit 478840a2ca491fbff44371caee4983d1e7b7b7cf)

[Bug tree-optimization/110420] [12/13 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:

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

commit r12-9732-gee3bb7cb5d2ecfc64adcfd61afb390e72cc08661
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

(cherry picked from commit 478840a2ca491fbff44371caee4983d1e7b7b7cf)

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

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

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

--- Comment #2 from Andrew Pinski  ---
>With gcc 12.2 at least the same code doesn't trigger SIGILL.

Well in GCC 13+ at -O0 and -Og, GCC behavior changed from being fully undefined
to be trapping for folks to try to catch instead of saying they were seeing odd
behavior.

GCC 8+ changed the behavior to become unreachable:
https://gcc.gnu.org/gcc-8/porting_to.html

[Bug c++/110437] SIGILL when return missing in a C++ function with a condition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
>reproduce.cpp:10:1: warning: no return statement in function returning 
>non-void [-Wreturn-type]


Yes it is undefined code (at runtime) if the code falls through from a function
which has a non-void return type for C++. The rules for C is slightly
different, it is only undefined if the return value from the function is tried
to be used.

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
In the meantime Bill opened pr110419 and posted:

spawn [open ...]
 by value(kind=1): B
 by value(kind=1): A

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xf7ba03f3 in ???
#1  0x1d34 in val
at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/value_9.f90:47
#2  0x19db in p
at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/value_9.f90:20
#3  0x19db in main
at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/value_9.f90:45
FAIL: gfortran.dg/value_9.f90   -O3 -g  execution test


Line 20 corresponds to

  call val  ("A",char(65))

which means that there should be a temporary holding the result of char(65)
which should be passed by value.

[Bug c++/110437] New: SIGILL when return missing in a C++ function with a condition

[jan.zizka at nokia dot com via Gcc-bugs]

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

Bug ID: 110437
   Summary: SIGILL when return missing in a C++ function with a
condition
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.zizka at nokia dot com
  Target Milestone: ---

Created attachment 55404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55404&action=edit
Reproducer fails with g++

With gcc 13 following code triggers SIGILL:

#include

int func1() {
int value = 1;
if (value == 1) {
std::cout << "ONE" << std::endl;
} else {
std::cout << "ZERO" << std::endl;
}
}

int main() {
func1();
}

To reproduce:

g++ -o reproduce reproduce.cpp
./reproduce

Resulting with:

ONE
[1]19714 illegal hardware instruction (core dumped)  ./reproduce

Warning is generated by compiler:

reproduce.cpp: In function ‘int func1()’:
reproduce.cpp:10:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   10 | }
  | ^

With similar C code the SIGILL is not triggered:

#include

int func1() {
int value = 1;
if (value == 1) {
printf("ONE\n");
} else {
printf("ZERO\n");
}
}

int main() {
func1();
}

Warning is still generated with -Wall.

Is there some reason this behaves differently in C and C++? And shouldn't
rather compiler throw error instead of warning if this will crash in runtime?
We have caught this on some very old legacy code which just had missing return
statement and with upgrade to gcc 13.1.1 we have started to see SIGILL in
runtime.

Based on disassembled code the compiler emits ud2 instruction triggering
SIGILL.

With gcc 12.2 at least the same code doesn't trigger SIGILL. I didn't check the
disassembly.

I have run this on Fedora 38 and I didn't try to bisect which exact commit
triggers this. If it would be useful I can run bisect.

[Bug target/110435] ICE in in convert_move, at expr.cc:297 on Aarch64 with -Ofast

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

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

Martin Jambor  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

[Bug target/110435] ICE in in convert_move, at expr.cc:297 on Aarch64 with -Ofast

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

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

Martin Jambor  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Jambor  ---
Indeed, on a newer git checkout, the issue cannot be reproduced any longer. 
But I swear it was there in the morning.  Sorry for the noise.

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed) with asm goto with output and same block and two labels

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:81fa6dfe1691e93664ef3b4fa66c1e057acea281

commit r13-7484-g81fa6dfe1691e93664ef3b4fa66c1e057acea281
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

(cherry picked from commit 478840a2ca491fbff44371caee4983d1e7b7b7cf)

[Bug tree-optimization/110420] [12/13 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:81fa6dfe1691e93664ef3b4fa66c1e057acea281

commit r13-7484-g81fa6dfe1691e93664ef3b4fa66c1e057acea281
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

(cherry picked from commit 478840a2ca491fbff44371caee4983d1e7b7b7cf)

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:81fa6dfe1691e93664ef3b4fa66c1e057acea281

commit r13-7484-g81fa6dfe1691e93664ef3b4fa66c1e057acea281
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

(cherry picked from commit 478840a2ca491fbff44371caee4983d1e7b7b7cf)

[Bug tree-optimization/110420] [12/13 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12/13 Regression] internal
   |internal compiler error: in |compiler error: in
   |gimple_redirect_edge_and_br |gimple_redirect_edge_and_br
   |anch due to |anch due to
   |simple_dce_from_worklist|simple_dce_from_worklist
   |removing `asm goto` |removing `asm goto`
  Known to work||14.0

--- Comment #9 from Andrew Pinski  ---
Fixed in GCC 14 and will be backporting to GCC 12.x and 13.x.

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||14.0

--- Comment #10 from Andrew Pinski  ---
Fixed in GCC 14 and will be backporting to GCC 12.x and 13.x.

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed) with asm goto with output and same block and two labels

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||14.0

--- Comment #6 from Andrew Pinski  ---
Fixed in GCC 14 and will be backporting to GCC 12.x and 13.x.

[Bug rtl-optimization/98619] aarch64: ICE (verify_flow_info failed) with asm goto with output and same block and two labels

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

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

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

https://gcc.gnu.org/g:478840a2ca491fbff44371caee4983d1e7b7b7cf

commit r14-2133-g478840a2ca491fbff44371caee4983d1e7b7b7cf
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

[Bug middle-end/103979] asm goto is not considered volatile with output operands

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

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

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

https://gcc.gnu.org/g:478840a2ca491fbff44371caee4983d1e7b7b7cf

commit r14-2133-g478840a2ca491fbff44371caee4983d1e7b7b7cf
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

[Bug tree-optimization/110420] [12/13/14 Regression] internal compiler error: in gimple_redirect_edge_and_branch due to simple_dce_from_worklist removing `asm goto`

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

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

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

https://gcc.gnu.org/g:478840a2ca491fbff44371caee4983d1e7b7b7cf

commit r14-2133-g478840a2ca491fbff44371caee4983d1e7b7b7cf
Author: Andrew Pinski 
Date:   Mon Jun 26 17:14:06 2023 -0700

Mark asm goto with outputs as volatile

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm
goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR middle-end/110420
PR middle-end/103979
PR middle-end/98619

gcc/ChangeLog:

* gimplify.cc (gimplify_asm_expr): Mark asm with labels as
volatile.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/asmgoto-6.c: New test.

[Bug ipa/110276] [13/14 Regression] ICE building efibootguard on x86_64-linux-gnu

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Jambor  ---
Fixed on both master and the 13 branch.

[Bug ipa/110276] [13/14 Regression] ICE building efibootguard on x86_64-linux-gnu

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:7085905d7842e71af7a59c7d20d050716dd22e9b

commit r13-7483-g7085905d7842e71af7a59c7d20d050716dd22e9b
Author: Martin Jambor 
Date:   Tue Jun 27 18:01:13 2023 +0200

ipa-sra: Disable candidates with no known callers (PR 110276)

In IPA-SRA we use can_be_local_p () predicate rather than just plain
local call graph flag in order to figure out whether the node is a
part of an external API that we cannot change.  Although there are
cases where this can allow more transformations, it also means we can
analyze functions which have no callers at all, which is pointless.

Moreover, it makes an assert of hint propagation trigger, which checks
that we have looked at callers before processing hints that come from
them.  This has been reported as PR 110276.

This patch simply adds a check that a node has at least one caller
into the early checks and makes the node a non-candidate for any
transformation if it does not.

gcc/ChangeLog:

2023-06-16  Martin Jambor  

PR ipa/110276
* ipa-sra.cc (struct caller_issues): New field there_is_one.
(check_for_caller_issues): Set it.
(check_all_callers_for_issues): Check it.

gcc/testsuite/ChangeLog:

2023-06-16  Martin Jambor  

PR ipa/110276
* gcc.dg/ipa/pr110276.c: New test.

(cherry picked from commit 8a665a8d3b45c947d5793e2c9c3df8a1c0302f03)

[Bug tree-optimization/110436] [14 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:10170

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

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

--- Comment #4 from avieira at gcc dot gnu.org ---
Meant to say I'll look at it ;)

[Bug tree-optimization/110436] [14 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:10170

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from avieira at gcc dot gnu.org ---
I

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #11)
> Yes, it was fixed by r11-4187 but the problem is still present on the gcc-10
> branch.

I think that commit simply makes it possible to use oneTBB, which doesn't give
a warning. But if you use TBB 2020.3 or older, then you still get a warning.

[Bug c/77650] struct with a nested flexible array followed by another member accepted

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
for record purpose, the code in glibc has already been fixed. 
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611220.html

[Bug tree-optimization/110436] [14 Regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:10170

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org
Summary|ICE in  |[14 Regression] ICE in
   |vectorizable_live_operation |vectorizable_live_operation
   |, at|, at
   |tree-vect-loop.cc:10170 |tree-vect-loop.cc:10170

--- Comment #2 from Alex Coplan  ---
Seems to have started with r14-1551-g2f482a07365d9f4a94a56edd13b7f01b8f78b5a0 :

commit 2f482a07365d9f4a94a56edd13b7f01b8f78b5a0 
Author: Andre Vieira
Date:   Mon Jun 5 17:53:10 2023 +0100   

internal-fn,vect: Refactor widen_plus as internal_fn

[Bug tree-optimization/110436] ICE in vectorizable_live_operation, at tree-vect-loop.cc:10170

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

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

Alex Coplan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
 CC||acoplan at gcc dot gnu.org
   Last reconfirmed||2023-06-27
  Known to fail||14.0

--- Comment #1 from Alex Coplan  ---
Confirmed.

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

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

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

--- Comment #12 from Surya Kumari Jangala  ---
(In reply to Peter Bergner from comment #10)
> (In reply to Peter Bergner from comment #9)
> > Yes, you'll need to factor in the BB frequency.  Since the save/restore code
> > will go into (at this point modulo shrink-wrapping later) the prologue and
> > epilogue, you'll want something like:  * 2 *
> > "ira_memory_move_cost".
> 
> Thinking more, depending on the allocno/mode, you might also need to factor
> in calculate_saved_nregs(), in case the allocno represents a register pair
> or larger.

Yes, I am taking calculate_saved_nregs() into consideration.

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

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

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

--- Comment #11 from Surya Kumari Jangala  ---
(In reply to Peter Bergner from comment #9)
> (In reply to Surya Kumari Jangala from comment #8)
> > However, while computing the save/restore cost, we are considering only the
> > memory move cost but not the BB frequency. I think it is important to
> > consider the frequency too. 
> 
> Yes, you'll need to factor in the BB frequency.  Since the save/restore code
> will go into (at this point modulo shrink-wrapping later) the prologue and
> epilogue, you'll want something like:  * 2 *
> "ira_memory_move_cost".

Thanks for confirming that we have to factor in the BB frequency. 

> I think the issue here, is that the "frequency" of the entry block isn't
> '1', but some larger value.  I'm not 100% sure, but maybe you can use:
>   REG_FREQ_FROM_BB (ENTRY_BLOCK_PTR_FOR_FN (cfun))

This works. It gives the frequency of the entry block.

> for the BB frequency of the prologue/epilogue?
> 
> 
> > We factor in the frequency when we compute the
> > savings on removed copies in allocno_copy_cost_saving(). In this routine, we
> > multiply the frequency with ira_register_move_cost. So why not factor in the
> > frequency for memory move cost?
> 
> allocno_copy_cost_saving() is dealing with an actual copy instruction(s), so
> a real instruction in a specific BB, so it knows the frequency of the
> copy(ies).  The ira_memory_move_cost is more of a HW cost of a generic
> load/store and it isn't tied to a specific instruction, so there is no
> frequency to scale by, so you'll need to do that manually here.

[Bug target/110435] ICE in in convert_move, at expr.cc:297 on Aarch64 with -Ofast

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #1 from Alex Coplan  ---
FWIW I can't seem to reproduce this with
r14-2132-g4a48a38fa99f067b8f3a3d1a5dc7a1e602db351f (tried both cross and native
configurations).

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Sascha Scandella from comment #2)
> I think this would also be a solution. Would this then be included in a
> future GCC 13.2?

Yes

(In reply to Iain Sandoe from comment #3)
> @Jonathan is there a patch for that proposed solution?

No

Thinking further about this, maybe we should just do:

#if !__has_attribute(__init_priority__) || defined __APPLE__

Because checking in the configure script would still give the wrong answer if
libstdc++ is built on macOS using Clang (which is unsupported, but people do
the darndest things). So maybe keep it simple and just don't try to use the
feature on macOS at all, ever.

(In reply to Iain Sandoe from comment #5)
> in slower time, we might consider the option of following clang's behaviour
> for Darwin (possibly with a warning about the does-not-work-between-tus).

I don't understand why one would want to use the attribute only within a single
TU, that doesn't seem useful.