[Bug tree-optimization/115766] [12/13/14 Regression] wrong code at optimization levels -O2, -O3

[bic60176 at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Bi6c  ---
Sorry I pasted the wrong link.
It should be this one https://godbolt.org/z/GM13fhWbb

[Bug target/115978] [x86] GCC issues an error when using -m32 -march=native on APX available machine

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

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

--- Comment #5 from H.J. Lu  ---
(In reply to Hongtao Liu from comment #4)
> To clarify, the question originally came from whether or not to report error
> for -m32,-march=native, and then LLVM folks said it's diffcult for LLVM not
> issuing error for -march=native -m32, but issuing error for explicit -mapxf
> -m32. So they want to just not issue error at all, and then comipler
> silently disables the 64-bit only features(plus adding documents to mention
> -m32 will disable those features).

This is no different from PR 101395.  I don't believe LLVM can't work like GCC.

[Bug c/106800] Expose more vector extensions in C

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

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

--- Comment #3 from Richard Biener  ---
Created attachment 58699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58699&action=edit
patches in progress

I've come up with this sofar, it's a bit difficult to navigate the current
behavior wrt. truthvalue conversion and I am not too happy with the required
"hacks".

A C FE expert might provide guidance.

[Bug fortran/82904] [11/12/13/14/15 Regression][Coarray] ICE in make_ssa_name_fn, at tree-ssanames.c:261

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

https://gcc.gnu.org/g:0231b076dc98eb02e3289b21ace1757782e3917b

commit r15-2131-g0231b076dc98eb02e3289b21ace1757782e3917b
Author: Andre Vehreschild 
Date:   Wed Jul 10 14:37:37 2024 +0200

Fortran: Use char* for deferred length character arrays [PR82904]

Randomly during compiling the pass IPA: inline would ICE.  This was
caused by a saved deferred length string.  The length variable was not
set, but the variable was used in the array's declaration.  Now using a
character pointer to prevent this.

PR fortran/82904

gcc/fortran/ChangeLog:

* trans-types.cc (gfc_sym_type): Use type `char*` for saved
deferred length char arrays.
* trans.cc (get_array_span): Get `.span` also for `char*` typed
arrays, i.e. for those that have INTEGER_TYPE instead of
ARRAY_TYPE.

gcc/testsuite/ChangeLog:

* gfortran.dg/deferred_character_38.f90: New test.

[Bug middle-end/106805] Undue optimisation of floating-point comparisons

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:030186cabe8128e752619e101768cf8823a42c38

commit r15-2132-g030186cabe8128e752619e101768cf8823a42c38
Author: Roger Sayle 
Date:   Thu Jul 18 08:27:36 2024 +0100

Implement a -ftrapping-math/-fsignaling-nans TODO in match.pd.

I've been investigating some (float)i == CST optimizations for match.pd,
and noticed there's already a TODO comment in match.pd that's relatively
easy to implement.  When CST is a NaN, we only need to worry about
exceptions with flag_trapping_math, and equality/inequality tests for
sNaN only behave differently to qNaN with -fsignaling-nans.  These
issues are related to PR 57371 and PR 106805 in bugzilla.

2024-07-18  Roger Sayle  

gcc/ChangeLog
* match.pd ((FTYPE) N CMP CST): Only worry about exceptions with
flag_trapping_math, and about signaling NaNs with HONOR_SNANS.

gcc/testsuite/ChangeLog
* c-c++-common/pr57371-4.c: Update comment.
* c-c++-common/pr57371-5.c: Add missing testcases from pr57371-4.c
and update for -fno-signaling-nans -fno-trapping-math.

[Bug tree-optimization/57371] Simplify (double)i != 0

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:030186cabe8128e752619e101768cf8823a42c38

commit r15-2132-g030186cabe8128e752619e101768cf8823a42c38
Author: Roger Sayle 
Date:   Thu Jul 18 08:27:36 2024 +0100

Implement a -ftrapping-math/-fsignaling-nans TODO in match.pd.

I've been investigating some (float)i == CST optimizations for match.pd,
and noticed there's already a TODO comment in match.pd that's relatively
easy to implement.  When CST is a NaN, we only need to worry about
exceptions with flag_trapping_math, and equality/inequality tests for
sNaN only behave differently to qNaN with -fsignaling-nans.  These
issues are related to PR 57371 and PR 106805 in bugzilla.

2024-07-18  Roger Sayle  

gcc/ChangeLog
* match.pd ((FTYPE) N CMP CST): Only worry about exceptions with
flag_trapping_math, and about signaling NaNs with HONOR_SNANS.

gcc/testsuite/ChangeLog
* c-c++-common/pr57371-4.c: Update comment.
* c-c++-common/pr57371-5.c: Add missing testcases from pr57371-4.c
and update for -fno-signaling-nans -fno-trapping-math.

[Bug c++/115897] [14/15 Regression] vector_size attribute on alias template has no effect when used in a dependent variable template-id

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

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

Matthias Kretz (Vir)  changed:

   What|Removed |Added

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

--- Comment #7 from Matthias Kretz (Vir)  ---
Thank you! Sadly, that doesn't seem to be enough.
Here's another variation reduced from the original source after rebuilding
trunk (https://compiler-explorer.com/z/vzeab64Td):

---
namespace std
{
  template 
inline constexpr bool is_same_v = __is_same(_Tp, _Up);
}

namespace simd
{
  template 
inline constexpr int __width_of = 1;

  template 
requires requires { _Tp{}[0]; }
inline constexpr int __width_of<_Tp> = sizeof(_Tp) / sizeof(_Tp{}[0]);

  template 
using _Vp [[gnu::vector_size(16)]] = _Tp;

  static_assert(__width_of<_Vp> == 4); // OK
  static_assert(not std::is_same_v>); // OK

  template 
struct __traits
{
  using _SimdMember = _Vp<_Tp>;
  static_assert(sizeof(_SimdMember) == sizeof(_Vp<_Tp>)); // OK
  static_assert(std::is_same_v<_SimdMember, _Vp<_Tp>>, "wrong1");
  static_assert(__width_of<_Vp<_Tp>> == 4); // OK
  static_assert(__width_of<_SimdMember> == 4, "wrong2");

  template 
static constexpr bool _S_is_simd_ctor_arg = std::is_same_v<_Arg,
_SimdMember>;

  static_assert(not _S_is_simd_ctor_arg<_Tp>, "wrong3");
};

  __traits test = {};
}  // namespace simd
---

The three 'static_assert' printing 'wrong[123]' should not fail. They don't
fail with GCC 13.

[Bug target/115978] [x86] GCC issues an error when using -m32 -march=native on APX available machine

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

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

--- Comment #6 from Hongtao Liu  ---
(In reply to H.J. Lu from comment #5)
> (In reply to Hongtao Liu from comment #4)
> > To clarify, the question originally came from whether or not to report error
> > for -m32,-march=native, and then LLVM folks said it's diffcult for LLVM not
> > issuing error for -march=native -m32, but issuing error for explicit -mapxf
> > -m32. So they want to just not issue error at all, and then comipler
> > silently disables the 64-bit only features(plus adding documents to mention
> > -m32 will disable those features).
> 
> This is no different from PR 101395.  I don't believe LLVM can't work like
> GCC.

I prefer your fix, I'll bring this to LLVM folks to rediscuss.

[Bug tree-optimization/104515] [11/12/13/14/15 Regression] trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-2133-g8c67dc40459e3d72e8169b099cc8c5dbdb759da3
Author: Richard Biener 
Date:   Wed Jul 17 10:22:47 2024 +0200

tree-optimization/104515 - store motion and clobbers

The following addresses an old regression when end-of-object/storage
clobbers were introduced.  In particular when there's an end-of-object
clobber in a loop but no corresponding begin-of-object we can still
perform store motion of may-aliased refs when we re-issue the
end-of-object/storage on the exits but elide it from the loop.  This
should be the safest way to deal with this considering stack-slot
sharing and it should not cause missed dead store eliminations given
DSE can now follow multiple paths in case there are multiple exits.

Note when the clobber is re-materialized only on one exit but not
on anther we are erroring on the side of removing the clobber on
such path.  This should be OK (removing clobbers is always OK).

Note there's no corresponding code to handle begin-of-object/storage
during the hoisting part of loads that are part of a store motion
optimization, so this only enables stored-only store motion or cases
without such clobber inside the loop.

PR tree-optimization/104515
* tree-ssa-loop-im.cc (execute_sm_exit): Add clobbers_to_prune
parameter and handle re-materializing of clobbers.
(sm_seq_valid_bb): end-of-storage/object clobbers are OK inside
an ordered sequence of stores.
(sm_seq_push_down): Refuse to push down clobbers.
(hoist_memory_references): Prune clobbers from the loop body
we re-materialized on an exit.

* g++.dg/opt/pr104515.C: New testcase.

[Bug c++/115897] [14/15 Regression] vector_size attribute on alias template has no effect when used in a dependent variable template-id

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

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

--- Comment #8 from Matthias Kretz (Vir)  ---
I can work around 'wrong1' and 'wrong3' by replacing std::is_same_v<...> with
__is_same(...).

[Bug tree-optimization/104515] [11/12/13/14 Regression] trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||15.0
Summary|[11/12/13/14/15 Regression] |[11/12/13/14 Regression]
   |trivially-destructible  |trivially-destructible
   |destructors interfere with  |destructors interfere with
   |loop optimization - maybe   |loop optimization - maybe
   |related to lifetime-dse.|related to lifetime-dse.

--- Comment #12 from Richard Biener  ---
This has been fixed for GCC 15, it's unlikely backported but I'll leave this
open for tracking purposes.

[Bug fortran/108889] [12/13/14/15 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r15-2135-gc3aa339ea50f050caf7ed2e497f5499ec2d7b9cc
Author: Paul Thomas 
Date:   Thu Jul 18 08:51:35 2024 +0100

Fortran: Suppress bogus used uninitialized warnings [PR108889].

2024-07-18  Paul Thomas  

gcc/fortran
PR fortran/108889
* gfortran.h: Add bit field 'allocated_in_scope' to gfc_symbol.
* trans-array.cc (gfc_array_allocate): Set 'allocated_in_scope'
after allocation if not a component reference.
(gfc_alloc_allocatable_for_assignment): If 'allocated_in_scope'
not set, not a component ref and not allocated, set the array
bounds and offset to give zero length in all dimensions. Then
set allocated_in_scope.

gcc/testsuite/
PR fortran/108889
* gfortran.dg/pr108889.f90: New test.

[Bug tree-optimization/115979] Implicitly generated C++ calls stop musttail search early

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

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

--- Comment #1 from Richard Biener  ---
I'd say the frontend should diagnose [[gnu::musttail]] in such a case because
it can use appropriate C++ wording?

[Bug tree-optimization/115979] Implicitly generated C++ calls stop musttail search early

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

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

--- Comment #2 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> I'd say the frontend should diagnose [[gnu::musttail]] in such a case
> because it can use appropriate C++ wording?

A possible point could be genericization/gimplification.

[Bug c++/57437] [4.7/4.8/4.9 Regression] C++11: mutable lambdas

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James 
Date:   Thu Jul 18 10:00:17 2024 +0200

testsuite: Add dg-do run to more tests

All of these are for wrong-code bugs.  Confirmed to be used before but
with no execution.

2024-07-18  Sam James  

PR c++/53288
PR c++/57437
PR c/65345
PR libstdc++/88101
PR tree-optimization/96369
PR tree-optimization/102124
PR tree-optimization/108692
* c-c++-common/pr96369.c: Add dg-do run directive.
* gcc.dg/torture/pr102124.c: Ditto.
* gcc.dg/pr108692.c: Ditto.
* gcc.dg/atomic/pr65345-4.c: Ditto.
* g++.dg/cpp0x/lambda/lambda-return1.C: Ditto.
* g++.dg/init/lifetime4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-1.C: Ditto.
* g++.dg/torture/builtin-clear-padding-2.C: Ditto.
* g++.dg/torture/builtin-clear-padding-3.C: Ditto.
* g++.dg/torture/builtin-clear-padding-4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-5.C: Ditto.

[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits

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

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

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James 
Date:   Thu Jul 18 10:00:17 2024 +0200

testsuite: Add dg-do run to more tests

All of these are for wrong-code bugs.  Confirmed to be used before but
with no execution.

2024-07-18  Sam James  

PR c++/53288
PR c++/57437
PR c/65345
PR libstdc++/88101
PR tree-optimization/96369
PR tree-optimization/102124
PR tree-optimization/108692
* c-c++-common/pr96369.c: Add dg-do run directive.
* gcc.dg/torture/pr102124.c: Ditto.
* gcc.dg/pr108692.c: Ditto.
* gcc.dg/atomic/pr65345-4.c: Ditto.
* g++.dg/cpp0x/lambda/lambda-return1.C: Ditto.
* g++.dg/init/lifetime4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-1.C: Ditto.
* g++.dg/torture/builtin-clear-padding-2.C: Ditto.
* g++.dg/torture/builtin-clear-padding-3.C: Ditto.
* g++.dg/torture/builtin-clear-padding-4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-5.C: Ditto.

[Bug c/65345] ICE with _Generic selection on _Atomic int

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

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

--- Comment #31 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James 
Date:   Thu Jul 18 10:00:17 2024 +0200

testsuite: Add dg-do run to more tests

All of these are for wrong-code bugs.  Confirmed to be used before but
with no execution.

2024-07-18  Sam James  

PR c++/53288
PR c++/57437
PR c/65345
PR libstdc++/88101
PR tree-optimization/96369
PR tree-optimization/102124
PR tree-optimization/108692
* c-c++-common/pr96369.c: Add dg-do run directive.
* gcc.dg/torture/pr102124.c: Ditto.
* gcc.dg/pr108692.c: Ditto.
* gcc.dg/atomic/pr65345-4.c: Ditto.
* g++.dg/cpp0x/lambda/lambda-return1.C: Ditto.
* g++.dg/init/lifetime4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-1.C: Ditto.
* g++.dg/torture/builtin-clear-padding-2.C: Ditto.
* g++.dg/torture/builtin-clear-padding-3.C: Ditto.
* g++.dg/torture/builtin-clear-padding-4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-5.C: Ditto.

[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James 
Date:   Thu Jul 18 10:00:17 2024 +0200

testsuite: Add dg-do run to more tests

All of these are for wrong-code bugs.  Confirmed to be used before but
with no execution.

2024-07-18  Sam James  

PR c++/53288
PR c++/57437
PR c/65345
PR libstdc++/88101
PR tree-optimization/96369
PR tree-optimization/102124
PR tree-optimization/108692
* c-c++-common/pr96369.c: Add dg-do run directive.
* gcc.dg/torture/pr102124.c: Ditto.
* gcc.dg/pr108692.c: Ditto.
* gcc.dg/atomic/pr65345-4.c: Ditto.
* g++.dg/cpp0x/lambda/lambda-return1.C: Ditto.
* g++.dg/init/lifetime4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-1.C: Ditto.
* g++.dg/torture/builtin-clear-padding-2.C: Ditto.
* g++.dg/torture/builtin-clear-padding-3.C: Ditto.
* g++.dg/torture/builtin-clear-padding-4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-5.C: Ditto.

[Bug tree-optimization/96369] [8 Regression] Wrong evaluation order of || operator

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James 
Date:   Thu Jul 18 10:00:17 2024 +0200

testsuite: Add dg-do run to more tests

All of these are for wrong-code bugs.  Confirmed to be used before but
with no execution.

2024-07-18  Sam James  

PR c++/53288
PR c++/57437
PR c/65345
PR libstdc++/88101
PR tree-optimization/96369
PR tree-optimization/102124
PR tree-optimization/108692
* c-c++-common/pr96369.c: Add dg-do run directive.
* gcc.dg/torture/pr102124.c: Ditto.
* gcc.dg/pr108692.c: Ditto.
* gcc.dg/atomic/pr65345-4.c: Ditto.
* g++.dg/cpp0x/lambda/lambda-return1.C: Ditto.
* g++.dg/init/lifetime4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-1.C: Ditto.
* g++.dg/torture/builtin-clear-padding-2.C: Ditto.
* g++.dg/torture/builtin-clear-padding-3.C: Ditto.
* g++.dg/torture/builtin-clear-padding-4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-5.C: Ditto.

[Bug tree-optimization/108692] [11 Regression] Miscompilation of orc_test.c since r11-5160

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James 
Date:   Thu Jul 18 10:00:17 2024 +0200

testsuite: Add dg-do run to more tests

All of these are for wrong-code bugs.  Confirmed to be used before but
with no execution.

2024-07-18  Sam James  

PR c++/53288
PR c++/57437
PR c/65345
PR libstdc++/88101
PR tree-optimization/96369
PR tree-optimization/102124
PR tree-optimization/108692
* c-c++-common/pr96369.c: Add dg-do run directive.
* gcc.dg/torture/pr102124.c: Ditto.
* gcc.dg/pr108692.c: Ditto.
* gcc.dg/atomic/pr65345-4.c: Ditto.
* g++.dg/cpp0x/lambda/lambda-return1.C: Ditto.
* g++.dg/init/lifetime4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-1.C: Ditto.
* g++.dg/torture/builtin-clear-padding-2.C: Ditto.
* g++.dg/torture/builtin-clear-padding-3.C: Ditto.
* g++.dg/torture/builtin-clear-padding-4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-5.C: Ditto.

[Bug tree-optimization/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James 
Date:   Thu Jul 18 10:00:17 2024 +0200

testsuite: Add dg-do run to more tests

All of these are for wrong-code bugs.  Confirmed to be used before but
with no execution.

2024-07-18  Sam James  

PR c++/53288
PR c++/57437
PR c/65345
PR libstdc++/88101
PR tree-optimization/96369
PR tree-optimization/102124
PR tree-optimization/108692
* c-c++-common/pr96369.c: Add dg-do run directive.
* gcc.dg/torture/pr102124.c: Ditto.
* gcc.dg/pr108692.c: Ditto.
* gcc.dg/atomic/pr65345-4.c: Ditto.
* g++.dg/cpp0x/lambda/lambda-return1.C: Ditto.
* g++.dg/init/lifetime4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-1.C: Ditto.
* g++.dg/torture/builtin-clear-padding-2.C: Ditto.
* g++.dg/torture/builtin-clear-padding-3.C: Ditto.
* g++.dg/torture/builtin-clear-padding-4.C: Ditto.
* g++.dg/torture/builtin-clear-padding-5.C: Ditto.

[Bug fortran/78466] [coarray] Explicit cobounds of a procedures parameter not respected

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

https://gcc.gnu.org/g:18f3b223b97011c2eab71c8e48c3a38a12ff8f65

commit r15-2137-g18f3b223b97011c2eab71c8e48c3a38a12ff8f65
Author: Andre Vehreschild 
Date:   Thu Dec 31 10:40:30 2020 +0100

Fortran: Fix Explicit cobounds of a procedures parameter not respected
[PR78466]

Explicit cobounds of class array procedure parameters were not taken
into account.  Furthermore were different cobounds in distinct
procedure parameter lists mixed up, i.e. the last definition was taken
for all.  The bounds are now regenerated when tree's and expr's bounds
do not match.

PR fortran/78466
PR fortran/80774

gcc/fortran/ChangeLog:

* array.cc (gfc_compare_array_spec): Take cotype into account.
* class.cc (gfc_build_class_symbol): Coarrays are also arrays.
* gfortran.h (IS_CLASS_COARRAY_OR_ARRAY): New macro to detect
regular and coarray class arrays.
* interface.cc (compare_components): Take codimension into
account.
* resolve.cc (resolve_symbol): Improve error message.
* simplify.cc (simplify_bound_dim): Remove duplicate.
* trans-array.cc (gfc_trans_array_cobounds): Coarrays are also
arrays.
(gfc_trans_array_bounds): Same.
(gfc_trans_dummy_array_bias): Same.
(get_coarray_as): Get the as having a non-zero codim.
(is_explicit_coarray): Detect explicit coarrays.
(gfc_conv_expr_descriptor): Create a new descriptor for explicit
coarrays.
* trans-decl.cc (gfc_build_qualified_array): Coarrays are also
arrays.
(gfc_build_dummy_array_decl): Same.
(gfc_get_symbol_decl): Same.
(gfc_trans_deferred_vars): Same.
* trans-expr.cc (class_scalar_coarray_to_class): Get the
descriptor from the correct location.
(gfc_conv_variable): Pick up the descriptor when needed.
* trans-types.cc (gfc_is_nodesc_array): Coarrays are also
arrays.
(gfc_get_nodesc_array_type): Indentation fix only.
(cobounds_match_decl): Match a tree's bounds to the expr's
bounds and return true, when they match.
(gfc_get_derived_type): Create a new type tree/descriptor, when
the cobounds of the existing declaration and expr to not
match.  This happends for class arrays in parameter list, when
there are different cobound declarations.

gcc/testsuite/ChangeLog:

* gfortran.dg/coarray/poly_run_1.f90: Activate old test code.
* gfortran.dg/coarray/poly_run_2.f90: Activate test.  It was
stopping before and passing without an error.

[Bug fortran/80774] [11/12/13/14/15 Regression][Coarray] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

https://gcc.gnu.org/g:18f3b223b97011c2eab71c8e48c3a38a12ff8f65

commit r15-2137-g18f3b223b97011c2eab71c8e48c3a38a12ff8f65
Author: Andre Vehreschild 
Date:   Thu Dec 31 10:40:30 2020 +0100

Fortran: Fix Explicit cobounds of a procedures parameter not respected
[PR78466]

Explicit cobounds of class array procedure parameters were not taken
into account.  Furthermore were different cobounds in distinct
procedure parameter lists mixed up, i.e. the last definition was taken
for all.  The bounds are now regenerated when tree's and expr's bounds
do not match.

PR fortran/78466
PR fortran/80774

gcc/fortran/ChangeLog:

* array.cc (gfc_compare_array_spec): Take cotype into account.
* class.cc (gfc_build_class_symbol): Coarrays are also arrays.
* gfortran.h (IS_CLASS_COARRAY_OR_ARRAY): New macro to detect
regular and coarray class arrays.
* interface.cc (compare_components): Take codimension into
account.
* resolve.cc (resolve_symbol): Improve error message.
* simplify.cc (simplify_bound_dim): Remove duplicate.
* trans-array.cc (gfc_trans_array_cobounds): Coarrays are also
arrays.
(gfc_trans_array_bounds): Same.
(gfc_trans_dummy_array_bias): Same.
(get_coarray_as): Get the as having a non-zero codim.
(is_explicit_coarray): Detect explicit coarrays.
(gfc_conv_expr_descriptor): Create a new descriptor for explicit
coarrays.
* trans-decl.cc (gfc_build_qualified_array): Coarrays are also
arrays.
(gfc_build_dummy_array_decl): Same.
(gfc_get_symbol_decl): Same.
(gfc_trans_deferred_vars): Same.
* trans-expr.cc (class_scalar_coarray_to_class): Get the
descriptor from the correct location.
(gfc_conv_variable): Pick up the descriptor when needed.
* trans-types.cc (gfc_is_nodesc_array): Coarrays are also
arrays.
(gfc_get_nodesc_array_type): Indentation fix only.
(cobounds_match_decl): Match a tree's bounds to the expr's
bounds and return true, when they match.
(gfc_get_derived_type): Create a new type tree/descriptor, when
the cobounds of the existing declaration and expr to not
match.  This happends for class arrays in parameter list, when
there are different cobound declarations.

gcc/testsuite/ChangeLog:

* gfortran.dg/coarray/poly_run_1.f90: Activate old test code.
* gfortran.dg/coarray/poly_run_2.f90: Activate test.  It was
stopping before and passing without an error.

[Bug c++/110855] std::source_location doesn't work with C++20 coroutine

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

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

--- Comment #5 from Arsen Arsenović  ---
agreed, but note that it still gives us the name of the actor function:

  pr110855.C:51:1ReturnObject bar(int)
  pr110855.C:51:1void bar(bar(int)::_Z3bari.Frame*)

(the latter print is from initial_suspend)

this is probably not ideal, but I'm unsure what that'd be expected to be anyway
(given that it's in a bunch of synthesized code)

[Bug target/115950] Missed SVE fold to INCP

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

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

Richard Sandiford  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Richard Sandiford  ---
I'd rather not double up the patterns for this equivalence.  Seems like one of
those cases where being able to define target-specific unspec simplification
rules would help.

[Bug rtl-optimization/115981] New: Redundant vmovaps to itself after vmovups

[user202729 at protonmail dot com via Gcc-bugs]

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

Bug ID: 115981
   Summary: Redundant vmovaps to itself after vmovups
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: user202729 at protonmail dot com
  Target Milestone: ---

Code: (this is in gcc/testsuite/gcc.target/i386/avx512dq-pr90991-1.c)

#include 
__m512
f4 (void *a)
{
  return _mm512_insertf32x4 (_mm512_set1_ps (0.0f), _mm_loadu_ps (a), 0);
}

Assembly:

vmovups (%rdi), %xmm0
vmovaps %xmm0, %xmm0
ret

The second instruction (vmovaps %xmm0, %xmm0) looks redundant to me?

Introduced somewhere between 13.3 and 14.1.

https://godbolt.org/z/6qqdc1nK8

[Bug target/115950] Missed SVE fold to INCP

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

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

--- Comment #5 from Richard Sandiford  ---
Alternatively, I suppose we could say that svcntp_bN(svptrue_bN(), pg) etc.
should be folded to svcntp_bN(pg, pg) in gimple/expand, and then make the
INCP/DECP wrappers only match the equal-predicate version.

[no subject]

[ozin uawz via Gcc-bugs]

📢 เรียนท่านเจ้าของกิจการ
📢 หากท่านกำลังมองหาทุนหมุนเวียนระยะสั้น
📢 ดอกเบี้ยเริ่มต้น 1.5%
ถ้าท่านสนใจบริการของเรา สอบถามเพิ่มเติมได้เลยครับ
Line ID : esc.credit
โทร : 093-6782499 คุณตะวัน
โทร : 082-5928519 คุณเอก
📢 ไม่ต้องเดินทางเราไปทำสัญญาถึงที่
❌ ทางเราไม่มี นโยบายให้ก่อนทำสัญญาทั้งสิ้น ❌
ขออภัยหากข้อความนี้เป็นการรบกวนท่านครับ

[Bug rtl-optimization/115982] New: ICE: unrecognizable insn in ira_remove_insn_scratches with -mavx512vl

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

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

Bug ID: 115982
   Summary: ICE: unrecognizable insn in ira_remove_insn_scratches
with -mavx512vl
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Compiling the following code (it comes from llvm testsuite)

```
// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck
%s 

typedef __attribute__((__vector_size__(16))) float float4;
typedef __attribute__((__vector_size__(16))) int int4;
typedef __attribute__((__vector_size__(16))) unsigned int uint4;

// CHECK: @_Z5test1Dv4_j
int4 test1(uint4 V0) {
  // CHECK: [[CMP0:%.*]] = icmp eq <4 x i32> [[V0:%.*]], zeroinitializer
  // CHECK-NEXT: [[V1:%.*]] = sext <4 x i1> [[CMP0]] to <4 x i32>
  int4 V = !V0;
  return V;
}

// CHECK: @_Z5test2Dv4_fS_
int4 test2(float4 V0, float4 V1) {
  // CHECK: [[CMP0:%.*]] = fcmp oeq <4 x float> [[V0:%.*]], zeroinitializer
  // CHECK-NEXT: [[V1:%.*]] = sext <4 x i1> [[CMP0]] to <4 x i32>
  int4 V = !V0;
  return V;
}
```

with options -mavx512vl -O2 (-O1 also works) results in an ICE

g++ /home/worker/llvm/src/clang/test/CodeGen/vector.cpp -mavx512vl -O2

/home/worker/llvm/src/clang/test/CodeGen/vector.cpp: In function ‘int4
test2(float4, float4)’:
/home/worker/llvm/src/clang/test/CodeGen/vector.cpp:21:1: error: unrecognizable
insn:
   21 | }
  | ^
(insn 19 18 15 2 (set (reg/i:V4SI 20 xmm0)
(subreg:V4SI (reg:V4SF 107) 0))
"/home/worker/llvm/src/clang/test/CodeGen/vector.cpp":21:1 -1
 (expr_list:REG_DEAD (reg:V4SF 107)
(nil)))
during RTL pass: ira
/home/worker/llvm/src/clang/test/CodeGen/vector.cpp:21:1: internal compiler
error: in extract_insn, at recog.cc:2848
0x1fffbae internal_error(char const*, ...)
   
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/diagnostic-global-context.cc:491
0x78154d fancy_abort(char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/diagnostic.cc:1725
0x7590c6 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/rtl-error.cc:108
0x7590e2 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/rtl-error.cc:116
0x7581be extract_insn(rtx_insn*)
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/recog.cc:2848
0xd0b980 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/ira.cc:5381
0xd0c2d7 remove_scratches
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/ira.cc:5425
0xd0c2d7 ira
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/ira.cc:5757
0xd0c2d7 execute
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/gcc/ira.cc:6117
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.


Observed on AMD Zen2 machine. Compiler configuration:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/g++
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-x86_64/build/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--disable-multilib --enable-checking=release --prefix=/home/worker/cross
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240717 (experimental)
3bbc8ea2e38d194fb5f2f52ab3f75301d4f84f06 (GCC)

[Bug ipa/110057] Missed devirtualization opportunities

[user202729 at protonmail dot com via Gcc-bugs]

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

--- Comment #20 from user202729  ---
(In reply to Jonathan Wakely from comment #19)
> That's easily solved by accessing the new object through the pointer
> returned by the new expression:
> 
> std::vector v(1);
> Base* p = v.data();
> p->~Base();
> p = ::new((void*)p) Derived();
> p->f();
> p->~Base();
> ::new((void*)p) Base();
> 
> By the time anything is accessed through the vector's internal pointers, an
> object of the original type has been restored at that location, which meets
> all the requirements of [basic.life] p7.


Trying codes related to it, do you think the following is valid C++?

void k(){
Base b;
b.~Base();
Base* p=new (&b) Derived;
p->~Base(); // this cannot be devirtualized to Base::~Base()
new (p) Base;
}

Currently gcc devirtualize the commented function to Base::~Base() anyway.
https://godbolt.org/z/bsnEdxMeK

[Bug target/115981] [14/15 Regression] Redundant vmovaps to itself after vmovups

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Redundant vmovaps to itself |[14/15 Regression]
   |after vmovups   |Redundant vmovaps to itself
   ||after vmovups
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-07-18
   Target Milestone|--- |14.2
 Target|X86_64  |x86_64-*-*
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
(insn 7 3 11 2 (set (reg:V4SF 103 [ _3 ])
(mem:V4SF (reg:DI 108) [0 MEM[(__m128_u * {ref-all})a_2(D)]+0 S16 A8]))
"/spc/space/rguenther/install/gcc-14.1.1/usr/local/lib64/gcc/x86_64-pc-linux-gnu/14.1.1/include/xmmintrin.h":940:10
2036 {movv4sf_internal}
 (expr_list:REG_DEAD (reg:DI 108)
(nil)))
(insn 11 7 16 2 (set (reg:V16SF 101)
(vec_merge:V16SF (const_vector:V16SF [
(const_double:SF 0.0 [0x0.0p+0]) repeated x16
])
(vec_duplicate:V16SF (reg:V4SF 103 [ _3 ]))
(const_int 65520 [0xfff0])))
"/spc/space/rguenther/install/gcc-14.1.1/usr/local/lib64/gcc/x86_64-pc-linux-gnu/14.1.1/include/avx512fintrin.h":9206:19
7429 {*avx512f_vinsertf32x4_0}
 (expr_list:REG_DEAD (reg:V4SF 103 [ _3 ])
(nil)))

confirmed.  Somehow the fact that movups zero-fills isn't seen.  On the 13
branch we have combined these:

(insn 11 7 16 2 (set (reg:V16SF 85)
(vec_merge:V16SF (const_vector:V16SF [
(const_double:SF 0.0 [0x0.0p+0]) repeated x16
])
(vec_duplicate:V16SF (mem:V4SF (reg:DI 92) [0 MEM[(__m128_u *
{ref-all})a_2(D)]+0 S16 A8]))
(const_int 65520 [0xfff0])))
"/spc/space/rguenther/install/gcc-13.3/lib64/gcc/x86_64-pc-linux-gnu/13.3.0/include/avx512fintrin.h":6172:19
7123 {*avx512f_vinsertf32x4_0}
 (expr_list:REG_DEAD (reg:DI 92)
(nil)))

[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)

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

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||115403

--- Comment #21 from Richard Biener  ---
PR115403 needs to be addressed before backporting?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115403
[Bug 115403] [15 Regression]  highway build from git fails with 'target
specific option mismatch'  (templates) since r15-902-geff00046409a72

[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Biener  ---
So fixed I call it.

[Bug middle-end/115459] [14 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||14.1.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug c++/115754] [14 Regression] C++26 ICE on constexpr new

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/115645] [11/12/13/14 Regression] new S[1][1]() requires non-explicit default ctor since r11-3092

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||15.0
  Known to fail|15.0|

[Bug middle-end/115527] incorrect folding of __builtin_clear_padding()

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

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

--- Comment #14 from Jakub Jelinek  ---
Should be fixed for 15.1+, 14.2+ and 11.5 for now, 13 and 12 backports to be
done later.

[Bug middle-end/115887] ICE: in gsi_insert_on_edge_immediate, at gimple-iterator.cc:849 with -O -fnon-call-exceptions -finstrument-functions and _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Should be fixed now for 15.1+ and 14.2+.

[Bug ipa/115815] [13/14/15 Regression] ICE: in purge_all_uses, at ipa-param-manipulation.cc:632 with -O2 -flto and incorrect usage of attribute destructor

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
#1  0x012b2089 in purge_all_uses (name=, 
killed_ssas=0x49329a0)
at /space/rguenther/src/gcc/gcc/ipa-param-manipulation.cc:632
632   gcc_assert (lhs
633   && (TREE_CODE (lhs) == SSA_NAME)
634   && !gimple_vdef (stmt));
(gdb) p stmt
$1 = 

we're having

__attribute__((destructor))
void b.isra ()
{
  int D.5155;
  int _1;
  int _2;
  int _3;

   [local count: 1073741824]:

   [local count: 966367642]:
  _1 = b ();
  _2 = 0;
  _3 = _1 + _2;
  return;

and purging uses of _1.  But then we do the same on the original function
which is

__attribute__((destructor))
int b ()
{
  int _1;
  int _2;
  int _4;

   [local count: 966367642]:
  _1 = b ();
  _2 = a;
  _4 = _1 + _2;
  return _4;

and that doesn't make sense.  I suppose the IPA transform got recursion
wrong somehow.  Of course this is an endless recursion but it computes
Inf * a.

Summary for node b/1:
  Returns value
  No parameter information.

  Summary for edge b/1->b/1:
return value used only to compute caller return value

...

Evaluating analysis results for b/1
  Will remove return value.

  Created adjustments:
m_always_copy_start: 0
Will SKIP return.
Accounting size:2.00, time:9.90 on predicate exec:(true)
  Created new node b.isra/3

which looks weird.

When I add a caller of 'b' then
this decision is no longer made, nor when I add a 'used' attribute.
The 'constructor' attribute makes the function prevail ('used')
(but it doesn't use the return value).

Modifying the testcase to

int a;
int  b() { return a + b(); }
int main()
{
  b ();
  return 0;
}

makes the same transform but since the original 'b' is elided the bug
doesn't trigger.

It seems that IPA doesn't consider the (recursive) call to 'b' from the
prevailing original function which does use the return value.

[Bug tree-optimization/115753] [15 Regression] ICE: tree check: expected ssa_name, have integer_cst in supportable_indirect_convert_operation, at tree-vect-stmts.cc:14680

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Should be fixed.

[Bug target/115671] [15 Regression] wrong code at -O1 with "-fgcse -fno-inline -fschedule-insns" on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Assuming fixed.

[Bug c++/115960] gcc throws an error when I use Optional in c++17.

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Noah Williams from comment #5)
> > It isn't? The library I was trying to compile included the "optional"
> > header, and I had looked it up and found it was part of C++ 17, so I thought
> > it was part of the standard.
> 
> std::optional is part of C++17 but Optional is not.

And names in C++ are case sensitive. optional != Optional.

[Bug rtl-optimization/115982] ICE: unrecognizable insn in ira_remove_insn_scratches with -mavx512vl

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

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

Filip Kastl  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug middle-end/115641] [11/12/13/14/15 Regression] GCC crashes on function has const attribute since r10-3830

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I think that

arg:0 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76e4f2a0>
readonly
arg:0 
readonly
fn 
readonly constant arg:0 
t.c:25:7 start: t.c:25:7 finish: t.c:25:7>
t.c:25:7 start: t.c:25:7 finish: t.c:25:10>>

aka &f () is invalid GENERIC.  That call needs to be wrapped in a TARGET_EXPR
or something similar.  That ADDR_EXPR is built from

#0  0x0121075e in make_bit_field_ref (loc=2147483940, 
inner=, 
orig_inner=, 
type=, bitsize=16, 
bitpos=..., unsignedp=0, reversep=0)
at /space/rguenther/src/gcc/gcc/fold-const.cc:4718
#1  0x01219fef in fold_truth_andor_1 (loc=2147483940, 
code=TRUTH_OR_EXPR, truth_type=, 
lhs=, rhs=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:6934
#2  0x01228073 in fold_truth_andor (loc=2147483940, 
code=TRUTH_ORIF_EXPR, type=, 
arg0=, arg1=, 
op0=, op1=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:9983
#3  0x01235b31 in fold_binary_loc (loc=2147483940, 
code=TRUTH_ORIF_EXPR, type=, 
op0=, op1=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:12543
#4  0x0123cbad in fold_build2_loc (loc=2147483940, 
code=TRUTH_ORIF_EXPR, type=, 
op0=, op1=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:14222
#5  0x00e9d19b in c_fully_fold_internal (
expr=, in_init=false, 
maybe_const_operands=0x7fffd367, maybe_const_itself=0x7fffd364, 
for_int_const=false, lval=false)
at /space/rguenther/src/gcc/gcc/c/c-fold.cc:552

the f ().day GENERIC tree is border-line with no decl visible.  At least
we don't want to introduce that via a TARGET_EXPR during folding.  I have
a patch to simply reject it.

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/115406] [15 Regression] wrong code with vector compare at -O0 with -mavx512f since r15-920-gb6c6d5abf0d31c

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2024-06-10 00:00:00 |2024-7-18
 CC||rsandifo at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
IIRC Richard S. had a patch to native_encode_vector_part to fix this by making
it set all bits instead of just the LSB?

[Bug c++/115403] [15 Regression] highway build from git fails with 'target specific option mismatch' (templates) since r15-902-geff00046409a72

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Sergei Trofimovich from comment #2)
> `cvise` came up with this example:
> 
> //$ cat float_test.cc.cc
> template  __attribute__((always_inline)) inline void
> AssertEqual() {}
> void TestAllF16FromF32() { AssertEqual(); }
> #pragma GCC target "sse4.1"

I think it's valid.  Looks like the C++ FE picks a wrong point of
instantiation for AssertEqual()?

> Looks valid?
> 
> gcc-14 can handle it, gcc-15 can't:
> 
> $ g++-14 -O2 -std=c++17 -c float_test.cc.cc
> 
> $ g++-15 -O2 -std=c++17 -c float_test.cc.cc
> float_test.cc.cc: In function 'void TestAllF16FromF32()':
> float_test.cc.cc:1:64: error: inlining failed in call to 'always_inline'
> 'void AssertEqual() [with  = float]': target
> specific option mismatch
> 1 | template  __attribute__((always_inline)) inline void
> AssertEqual() {}
>   |   
> ^~~
> float_test.cc.cc:2:46: note: called from here
> 2 | void TestAllF16FromF32() { AssertEqual(); }
>   |~~^~

[Bug tree-optimization/113673] [12/13/14 Regression] ICE: verify_flow_info failed: BB 5 cannot throw but has an EH edge with -Os -finstrument-functions -fnon-call-exceptions -ftrapv

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10455-g0f593e4cd82eeced5d7666ae6752f238c7dbd7f6
Author: Roger Sayle 
Date:   Mon Jun 24 15:34:03 2024 +0100

PR tree-optimization/113673: Avoid load merging when potentially trapping.

This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
caused by load merging of (ptr[0]<<8)+ptr[1] when -ftrapv has been
specified.  When the operator is | or ^ this is safe, but for addition
of signed integer types, a trap may be generated/required, so merging this
idiom into a single non-trapping instruction is inappropriate, confusing
the compiler by transforming a basic block with an exception edge into one
without.

This revision implements Richard Biener's feedback to add an early check
for stmt_can_throw_internal (cfun, stmt) to prevent transforming in the
presence of any statement that could trap, not just overflow on addition.
The one other tweak included in this patch is to mark the local function
find_bswap_or_nop_load as static ensuring that it isn't called from outside
this file, and guaranteeing that it is dominated by stmt_can_throw_internal
checking.

2024-06-24  Roger Sayle  
Richard Biener  

gcc/ChangeLog
PR tree-optimization/113673
* gimple-ssa-store-merging.cc (find_bswap_or_nop_load): Make
static.
(find_bswap_or_nop_1): Avoid transformations (load merging) when
stmt_can_throw_internal indicates that a statement can trap.

gcc/testsuite/ChangeLog
PR tree-optimization/113673
* g++.dg/pr113673.C: New test case.

(cherry picked from commit d8b05aef77443e1d3d8f3f5d2c56ac49a503fee3)

[Bug analyzer/114899] [14 regression] Segmentation fault with -fsanitize=undefined and -fanalyzer since r14-2029-g0e466e978c7

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10457-gb0452ed2fdc8bd9d5e911b6ea3166e4cd4be5256
Author: David Malcolm 
Date:   Wed May 15 18:40:56 2024 -0400

analyzer: fix ICE seen with -fsanitize=undefined [PR114899]

gcc/analyzer/ChangeLog:
PR analyzer/114899
* access-diagram.cc
(written_svalue_spatial_item::get_label_string): Bulletproof
against SSA_NAME_VAR being null.

gcc/testsuite/ChangeLog:
PR analyzer/114899
* c-c++-common/analyzer/out-of-bounds-diagram-pr114899.c: New test.

Signed-off-by: David Malcolm 
(cherry picked from commit 1779e22150b917e28e959623c819ef943fab02df)

[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #24 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10456-g0b7ec50ae2959153650c0b3dc134c8872ff9fcfc
Author: Jan Hubicka 
Date:   Thu May 16 15:33:55 2024 +0200

Fix points_to_local_or_readonly_memory_p wrt TARGET_MEM_REF

TARGET_MEM_REF can be used to offset constant base into a memory object (to
produce lea instruction).  This confuses
points_to_local_or_readonly_memory_p
which treats the constant address as a base of the access.

Bootstrapped/regtsted x86_64-linux, comitted.
Honza

gcc/ChangeLog:

PR ipa/113787
* ipa-fnsummary.cc (points_to_local_or_readonly_memory_p): Do not
look into TARGET_MEM_REFS with constant opreand 0.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/pr113787.c: New test.

(cherry picked from commit 96d53252aefcbc2fe419c4c3b4bcd3fc03d4d187)

[Bug target/115351] [14 regression] pointless movs when passing by value on x86-64

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10458-ga4c9ade72885f9cf72c873d110545e4e3c2c7805
Author: Roger Sayle 
Date:   Fri Jun 7 14:03:20 2024 +0100

i386: PR target/115351: RTX costs for *concatditi3 and *insvti_highpart.

This patch addresses PR target/115351, which is a code quality regression
on x86 when passing floating point complex numbers.  The ABI considers
these arguments to have TImode, requiring interunit moves to place the
FP values (which are actually passed in SSE registers) into the upper
and lower parts of a TImode pseudo, and then similar moves back again
before they can be used.

The cause of the regression is that changes in how TImode initialization
is represented in RTL now prevents the RTL optimizers from eliminating
these redundant moves.  The specific cause is that the *concatditi3
pattern, (zext(hi)<<64)|zext(lo), has an inappropriately high (default)
rtx_cost, preventing fwprop1 from propagating it.  This pattern just
sets the hipart and lopart of a double-word register, typically two
instructions (less if reload can allocate things appropriately) but
the current ix86_rtx_costs actually returns INSN_COSTS(13), i.e. 52.

propagating insn 5 into insn 6, replacing:
(set (reg:TI 110)
(ior:TI (and:TI (reg:TI 110)
(const_wide_int 0x0))
(ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ])
0))
(const_int 64 [0x40]
successfully matched this instruction to *concatditi3_3:
(set (reg:TI 110)
(ior:TI (ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8
]) 0))
(const_int 64 [0x40]))
(zero_extend:TI (subreg:DI (reg:DF 111 [ zD.2796 ]) 0
change not profitable (cost 50 -> cost 52)

This issue is resolved by having ix86_rtx_costs return more reasonable
values for these (place-holder) patterns.

2024-06-07  Roger Sayle  

gcc/ChangeLog
PR target/115351
* config/i386/i386.cc (ix86_rtx_costs): Provide estimates for
the *concatditi3 and *insvti_highpart patterns, about two insns.

gcc/testsuite/ChangeLog
PR target/115351
* g++.target/i386/pr115351.C: New test case.

(cherry picked from commit fb3e4c549d16d5050e10114439ad77149f33c597)

[Bug c++/115476] [13/14 Regression] __has_unique_object_representation ICE with array of uninstantiated type of unknown bound

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10459-gc314867fc06d475e3c2ace32032e0d72e3915b55
Author: Marek Polacek 
Date:   Mon Jun 17 17:53:12 2024 -0400

c++: ICE with __has_unique_object_representations [PR115476]

Here we started to ICE with r13-25: in check_trait_type, for "X[]" we
return true here:

  if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
return true; // Array of unknown bound. Don't care about completeness.

and then end up crashing in record_has_unique_obj_representations:

4836  if (cur != wi::to_offset (sz))

because sz is null.

   
https://eel.is/c++draft/type.traits#tab:meta.unary.prop-row-47-column-3-sentence-1
says that the preconditions for __has_unique_object_representations are:
"T shall be a complete type, cv void, or an array of unknown bound" and
that "For an array type T, the same result as
has_unique_object_representations_v>" so T[]
should be treated as T.  So we should use kind==2 for the trait.

PR c++/115476

gcc/cp/ChangeLog:

* semantics.cc (finish_trait_expr)
: Move below to call
check_trait_type with kind==2.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/has-unique-obj-representations4.C: New test.

(cherry picked from commit fc382a373e6824bb998007d1dcb0805b0cf4b8e8)

[Bug tree-optimization/115175] [15 Regression] GCC fails to bootstrap with --with-build-config='bootstrap-O3 bootstrap-lto' at r15-698-g38d1761c0c94b7

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I think there's a later duplicate that's now fixed (but still open).

[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved

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

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

Bug 115351 Summary: [14 regression] pointless movs when passing by value on 
x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351

   What|Removed |Added

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

[Bug analyzer/114899] [14 regression] Segmentation fault with -fsanitize=undefined and -fanalyzer since r14-2029-g0e466e978c7

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||14.1.0

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

[Bug target/115351] [14 regression] pointless movs when passing by value on x86-64

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||14.1.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug c++/102217] co_awaiting a temporary produced by ternary operator crashes (double-free)

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #8 from Arsen Arsenović  ---
hm, I see an ICE in 14.1 still:

~$ g++ -std=c++23 max-ice.cc
max-ice.cc: In function ‘Co::Task FooC(bool)’:
max-ice.cc:171:1: internal compiler error: in flatten_await_stmt, at
cp/coroutines.cc:2875
  171 | }
  | ^
0x5578f31eb661 flatten_await_stmt
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:2875
0x5578f31eb804 flatten_await_stmt
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:2904
0x5578f31eb804 flatten_await_stmt
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:2904
0x5578f31f4281 maybe_promote_temps
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3087
0x5578f31f4281 await_statement_walker
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3726
0x5578f3d042cb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11468
0x5578f31f2df8 await_statement_walker
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3397
0x5578f3d042cb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11468
0x5578f31f3f59 await_statement_walker
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3674
0x5578f3d042cb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11468
0x5578f31f2d8c await_statement_walker
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3386
0x5578f3d042cb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11468
0x5578f31f2df8 await_statement_walker
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3397
0x5578f3d042cb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11468
0x5578f3d043d7 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11702
0x5578f31f2df8 await_statement_walker
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3397
0x5578f3d042cb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11468
0x5578f31f2d8c await_statement_walker
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:3386
0x5578f3d042cb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/tree.cc:11468
0x5578f32269b1 morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240713/gcc-14-20240713/gcc/cp/coroutines.cc:4477
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.
~ 1 $ 

(I have checking enabled on the system compiler)

that line is: gcc_checking_assert (TREE_CODE (inner) != COND_EXPR);

... so, not too surprising ternaries crash it :-)

[Bug target/115969] [15 regression] ICE when building clang-16.0.6 on arm64 (output_operand: invalid expression as operand)

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Sandiford  ---
Yeah, agree that's where the problem is.

[Bug fortran/115983] New: ICE on valid code in gfc_is_nodesc_array, at fortran/trans-types.cc:

[juergen.reuter at desy dot de via Gcc-bugs]

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

Bug ID: 115983
   Summary: ICE on valid code in gfc_is_nodesc_array, at
fortran/trans-types.cc:
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following ICE appear in gfortran 14.1. and goes back to at least gfortran
9.4. The reproducer is somne 80 lines.

[Bug middle-end/115641] [11/12/13/14/15 Regression] GCC crashes on function has const attribute since r10-3830

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

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

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

https://gcc.gnu.org/g:3670c70c561656a19f6bff36dd229f18120af127

commit r15-2139-g3670c70c561656a19f6bff36dd229f18120af127
Author: Richard Biener 
Date:   Thu Jul 18 13:35:33 2024 +0200

middle-end/115641 - invalid address construction

fold_truth_andor_1 via make_bit_field_ref builds an address of
a CALL_EXPR which isn't valid GENERIC and later causes an ICE.
The following simply avoids the folding for f ().a != 1 || f ().b != 2
as it is a premature optimization anyway.  The alternative would
have been to build a TARGET_EXPR around the call.  To get this far
f () has to be const as otherwise the two calls are not semantically
equivalent for the optimization.

PR middle-end/115641
* fold-const.cc (decode_field_reference): If the inner
reference isn't something we can take the address of, fail.

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

[Bug middle-end/115641] [11/12/13/14 Regression] GCC crashes on function has const attribute since r10-3830

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||15.0
Summary|[11/12/13/14/15 Regression] |[11/12/13/14 Regression]
   |GCC crashes on function has |GCC crashes on function has
   |const attribute since   |const attribute since
   |r10-3830|r10-3830

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

[Bug rtl-optimization/115984] New: Missed optimization: unnecessary register copies

[nick.hudson at broadcom dot com via Gcc-bugs]

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

Bug ID: 115984
   Summary: Missed optimization: unnecessary register copies
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nick.hudson at broadcom dot com
  Target Milestone: ---

This code produces assembly output with unnecessary register copies

void
write128(volatile void *addr, uint128_t val)
{
   volatile uint128_t *ptr = addr;
   asm volatile ("stp %[val], %H[val], %[ptr]"
  : [ptr] "=Q" (*ptr)
  : [val] "r" (val));
}


write128:
mov x4, x2
mov x5, x3
stp x4, x5, [x0]
ret

Obviously it could be

write128:
stp x2, x3, [x0]
ret

[Bug rtl-optimization/115049] [14/15 Regression] Silent severe miscompilation around inline functions

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Jonathan Yong :

https://gcc.gnu.org/g:5080840d8fbf25a321dd27543a1462d393d338bc

commit r15-2140-g5080840d8fbf25a321dd27543a1462d393d338bc
Author: LIU Hao 
Date:   Mon Jul 15 16:55:52 2024 +0800

Do not use caller-saved registers for COMDAT functions

A reference to a COMDAT function may be resolved to another definition
outside the current translation unit, so it's not eligible for `-fipa-ra`.

In `decl_binds_to_current_def_p()` there is already a check for weak
symbols. This commit checks for COMDAT functions that are not implemented
as weak symbols, for example, on *-*-mingw32.

gcc/ChangeLog:

PR rtl-optimization/115049
* varasm.cc (decl_binds_to_current_def_p): Add a check for COMDAT
declarations too, like weak ones.

[Bug fortran/77518] [11/12/13/14/15 Regression] [Coarray] [OOP] ICE in gfc_advance_chain, at fortran/trans.c:58

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #11 from Andre Vehreschild  ---
Patch at https://gcc.gnu.org/pipermail/fortran/2024-July/060701.html
Waiting for review.

[Bug c++/115985] New: anoymous struct with base class rejected by gcc

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 115985
   Summary: anoymous struct with base class rejected by gcc
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

The following code is rejected by GCC but accepted by other compilers including
clang, MSVC and EDG:

~~
struct empty{

};

struct outer{ 
struct : public empty{ int x; }; 
};

int main(){
int res=outer().x;
}
~~

C++ standard says little about anonymous struct, so I'm unsure which side is
correct.

https://godbolt.org/z/4aKfKvdzb

Note that the code can be accepted if the unnamed struct has an instantiation: 

https://godbolt.org/z/M8q3raWW8

[Bug rtl-optimization/115049] [14/15 Regression] Silent severe miscompilation around inline functions

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jonathan Yong
:

https://gcc.gnu.org/g:747c4b58573ea00419f64293a61537eb69f43307

commit r14-10460-g747c4b58573ea00419f64293a61537eb69f43307
Author: LIU Hao 
Date:   Mon Jul 15 16:55:52 2024 +0800

Do not use caller-saved registers for COMDAT functions

A reference to a COMDAT function may be resolved to another definition
outside the current translation unit, so it's not eligible for `-fipa-ra`.

In `decl_binds_to_current_def_p()` there is already a check for weak
symbols. This commit checks for COMDAT functions that are not implemented
as weak symbols, for example, on *-*-mingw32.

gcc/ChangeLog:

PR rtl-optimization/115049
* varasm.cc (decl_binds_to_current_def_p): Add a check for COMDAT
declarations too, like weak ones.

(cherry picked from commit 5080840d8fbf25a321dd27543a1462d393d338bc)

[Bug c++/101232] Bad error message with stray semicolon in initializer

[franek.witt at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Franciszek Witt  ---
Created attachment 58700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58700&action=edit
[patchv2] improvements to the previous patch

[Bug c++/101232] Bad error message with stray semicolon in initializer

[franek.witt at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Franciszek Witt  ---
I have implemented the improvement mentioned by Jason and also added the hint
about missing comma or operator.
This patch fails testsuite/g++.dg/parse/error59.C but it was intended to check
for ICE (see PR c++/84493) so I think it is fine to accept a different error
message?

[Bug c++/103963] Coroutine return type needs not be copy- or move-constructible

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

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

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #2 from Arsen Arsenović  ---
indeed - went back and double checked, seems to match pretty exactly

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

[Bug c++/99575] [coroutines] unexpected move when co_awaiting a nonmoveable object

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

--- Comment #5 from Arsen Arsenović  ---
*** Bug 103963 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/115984] Missed optimization: unnecessary register copies

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||aarch64

--- Comment #1 from Richard Biener  ---
That's ... arm code?

[Bug c++/105475] coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #2 from Arsen Arsenović  ---
unsure if this code is valid..

anyway, the crash reason is the lack of default in coroutine_handle.  we pass a
NULL_TREE promise type to instantiate_coro_handle_for_promise_type in order to
instantiate the type-erased coro handle and the compiler gets confused:

  /*  We can also instantiate the void coroutine_handle<>  */
  void_coro_handle_type =
instantiate_coro_handle_for_promise_type (loc, NULL_TREE);
  if (void_coro_handle_type == NULL_TREE)
return false;

passing void_type_note there fixes that crash and reveals another in
fold_builtin_call_array (so, it could be something else, I'll get back to that
later - I suspect (not too confidently) that it might be unrelated)

[Bug c++/114104] nodiscard not diagnosed on synthesized operator!=

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |15.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 15

[Bug target/58416] Incorrect x87-based union copying code

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

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

akrl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||akrl at gcc dot gnu.org

--- Comment #9 from akrl at gcc dot gnu.org ---
Hello,

this is apparently affecting Emacs build as well [1].
I there a suggested way we could work around this bug? Maybe a flag to prevent
the optimization which we could use on affected systems?

Thanks

  Andrea

[1] 

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

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

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

--- Comment #26 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

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

commit r12-10623-gc5a26fc24b0af61498fae65ccad69d51d63d2a8b
Author: Uros Bizjak 
Date:   Wed Jul 17 18:11:26 2024 +0200

alpha: Fix duplicate !tlsgd!62 assemble error [PR115526]

Add missing "cannot_copy" attribute to instructions that have to
stay in 1-1 correspondence with another insn.

PR target/115526

gcc/ChangeLog:

* config/alpha/alpha.md (movdi_er_high_g): Add cannot_copy
attribute.
(movdi_er_tlsgd): Ditto.
(movdi_er_tlsldm): Ditto.
(call_value_osf_): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/alpha/pr115526.c: New test.

(cherry picked from commit 0841fd4c42ab053be951b7418233f0478282d020)

[Bug c++/115865] [14/15 Regression] ICE with auto/std::initializer_list variable definition with -fsanitize=address

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

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

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r15-2141-g1e60a6abfece40c7bf55d6ca0a439078d3f5159a
Author: Marek Polacek 
Date:   Thu Jul 11 15:57:43 2024 -0400

eh: ICE with std::initializer_list and ASan [PR115865]

Here we ICE with -fsanitize=address on

  std::initializer_list x = { 1, 2, 3 };

since r14-8681, which removed .ASAN_MARK calls on TREE_STATIC variables.
That means that lower_try_finally now instead of

  try
{
  .ASAN_MARK (UNPOISON, &C.0, 12);
  x = {};
  x._M_len = 3;
  x._M_array = &C.0;
}
  finally
{
  .ASAN_MARK (POISON, &C.0, 12);
}

gets:

  try
{
  x = {};
  x._M_len = 3;
  x._M_array = &C.0;
}
  finally
{

}

and we ICE on the empty finally in lower_try_finally_onedest while
getting get_eh_else.

PR c++/115865

gcc/ChangeLog:

* tree-eh.cc (get_eh_else): Check that the result of
gimple_seq_first_stmt is non-null.

gcc/testsuite/ChangeLog:

* g++.dg/asan/initlist2.C: New test.

Co-authored-by: Jakub Jelinek  

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Build|alpha-unknown-linux-gnu |
   Host|alpha-unknown-linux-gnu |
   Target Milestone|14.2|12.5

--- Comment #27 from Uroš Bizjak  ---
Fixed for gcc-12.5+.

[Bug c++/115986] New: [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving user-defined uint128 literals

[valentin at tolmer dot fr via Gcc-bugs]

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

Bug ID: 115986
   Summary: [14/15 Regression] ICE in fold_convert_loc, at
fold-const.cc:2644 involving user-defined uint128
literals
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valentin at tolmer dot fr
  Target Milestone: ---

$ cat reduced.cpp
template 
constexpr int b(T) {
  return 0;
}
consteval __uint128_t operator"" _c(const char*) { return 0; }
constexpr char e() {
  long f = true ? 0 : b(long(1));
  return b(f);
}
template 
void d() {
  0_c;
  static_assert(e());
}

$ g++ -std=c++2b -march=x86-64-v2 reduced.cpp
reduced.cpp: In function ‘void d()’:
reduced.cpp:12:3: internal compiler error: in fold_convert_loc, at
fold-const.cc:2633
   12 |   0_c;
  |   ^~~
0x6cca93 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/fold-const.cc:2633
0x78c6ec cp_fold_convert(tree_node*, tree_node*)
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/cvt.cc:627
0x74b23d cxx_bind_parameters_in_call
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/constexpr.cc:1922
0x74b23d cxx_eval_call_expression
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/constexpr.cc:3044
0x742f7c cxx_eval_constant_expression
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/constexpr.cc:7559
0x75d7f5 cxx_eval_outermost_constant_expr
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/constexpr.cc:8857
0x77289f cxx_constant_value(tree_node*, tree_node*, int)
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/constexpr.cc:9013
0x77289f cxx_constant_value(tree_node*, int)
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/cp-tree.h:8686
0x77289f cp_fold_immediate_r
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/cp-gimplify.cc:1255
0x11e4d52 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/tree.cc:11429
0x11e5173 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/tree.cc:11545
0x11e4ada walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/tree.cc:11689
0x75a3d5 cp_fold_immediate(tree_node**, mce_value, tree_node*)
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/cp-gimplify.cc:517
0x75c336 process_and_check_pending_immediate_escalating_fns()
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/cp-gimplify.cc:1520
0x7c3d24 c_parse_final_cleanups()
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/cp/decl2.cc:5403
0x9a6d14 c_common_parse_file()
/tmp/tmpihnyo_jq/gcc-14.1.0/gcc/c-family/c-opts.cc:1329

Compilation works with 13.3, fails on 14.1 and trunk.

[Bug middle-end/114661] Bit operations not optimized to multiplication

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Status|NEW |RESOLVED
 CC||roger at nextmovesoftware dot 
com
 Resolution|--- |FIXED
  Known to work||15.0

--- Comment #4 from Roger Sayle  ---
This should now be fixed/implemented on mainline.

[Bug tree-optimization/115979] Implicitly generated C++ calls stop musttail search early

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #3 from Andi Kleen  ---
Doing it in the frontend would require some duplication between C/C++ at least?

I was thinking to just keep searching if has_mustail is set, but was wary of
endless loops walking single basic block precessors. But I presume if they
could happen they could already happen.

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #19 from Andi Kleen  ---
Middle/back-end parts are in, still need acks for the C/C++ frontend parts

[Bug c++/115987] New: False "possibly dangling reference" false positive when having an extra template parameter

[durosu at yahoo dot com via Gcc-bugs]

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

Bug ID: 115987
   Summary: False "possibly dangling reference" false positive
when having an extra template parameter
   Product: gcc
   Version: 13.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: durosu at yahoo dot com
  Target Milestone: ---

Created attachment 58701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58701&action=edit
C++ Source code demonstrating the error

Attached sample code to demonstrate.
Comments about the behavior are in the code.

[Bug c++/115865] [14/15 Regression] ICE with auto/std::initializer_list variable definition with -fsanitize=address

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:493035c8780cd510a680a791d0c7f94368164352

commit r14-10461-g493035c8780cd510a680a791d0c7f94368164352
Author: Marek Polacek 
Date:   Thu Jul 11 15:57:43 2024 -0400

eh: ICE with std::initializer_list and ASan [PR115865]

Here we ICE with -fsanitize=address on

  std::initializer_list x = { 1, 2, 3 };

since r14-8681, which removed .ASAN_MARK calls on TREE_STATIC variables.
That means that lower_try_finally now instead of

  try
{
  .ASAN_MARK (UNPOISON, &C.0, 12);
  x = {};
  x._M_len = 3;
  x._M_array = &C.0;
}
  finally
{
  .ASAN_MARK (POISON, &C.0, 12);
}

gets:

  try
{
  x = {};
  x._M_len = 3;
  x._M_array = &C.0;
}
  finally
{

}

and we ICE on the empty finally in lower_try_finally_onedest while
getting get_eh_else.

PR c++/115865

gcc/ChangeLog:

* tree-eh.cc (get_eh_else): Check that the result of
gimple_seq_first_stmt is non-null.

gcc/testsuite/ChangeLog:

* g++.dg/asan/initlist2.C: New test.

Co-authored-by: Jakub Jelinek  
(cherry picked from commit 1e60a6abfece40c7bf55d6ca0a439078d3f5159a)

[Bug c++/115865] [14/15 Regression] ICE with auto/std::initializer_list variable definition with -fsanitize=address

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You either need to use gnu::no_dangling (with GCC 14+) or 

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
...
#pragma GCC diagnostic pop

As mentioned in PR 109642.

This is not exactly a false positive since GCC does not look further into the
functions to see if they return the reference or not.

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

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||durosu at yahoo dot com

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

[Bug c++/115986] [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|[14/15 Regression] ICE in   |[14/15 Regression] ICE in
   |fold_convert_loc, at|fold_convert_loc, at
   |fold-const.cc:2644  |fold-const.cc:2644
   |involving user-defined  |involving consteval
   |uint128 literals|user-defined uint128
   ||literals
   Target Milestone|--- |14.2

[Bug c++/115986] [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection

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

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

[durosu at yahoo dot com via Gcc-bugs]

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

--- Comment #2 from Dan Urosu  ---
 Hi Andrew,

I cannot use "#pragma GCC diagnostic ignored" because we have thousands of call
sites where we plan to use this kind of code.
And we don't want to disable globally this warning either.

Would "no_dangling (with GCC 14+) " disable globally this check as well?

Thanks,Dan


On Thursday, July 18, 2024 at 11:53:32 AM EDT, pinskia at gcc dot gnu.org
 wrote:  

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

Andrew Pinski  changed:

          What    |Removed                    |Added

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

--- Comment #1 from Andrew Pinski  ---
You either need to use gnu::no_dangling (with GCC 14+) or 

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
...
#pragma GCC diagnostic pop

As mentioned in PR 109642.

This is not exactly a false positive since GCC does not look further into the
functions to see if they return the reference or not.

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

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

[durosu at yahoo dot com via Gcc-bugs]

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

--- Comment #3 from Dan Urosu  ---
The 109642 is not a duplicate of the attached code.
The error is the same but the code that causes it is completely different.

Also, the "solution" to disable the warning/error is not actually resolving the
issue but merely hiding it.

[Bug rtl-optimization/115984] Missed optimization: unnecessary register copies

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-18
 Blocks||101926
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Keywords||ra

--- Comment #2 from Andrew Pinski  ---
Confirmed. This is only an issue with arguments and returns. So this is a minor
issue.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
[Bug 101926] [meta-bug] struct/complex/other argument passing and return should
be improved

[Bug c++/115986] [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords|needs-bisection |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with my:

commit 1f1c432226cf3db399b2a2a627e3c5720b02b1d6
Author: Marek Polacek 
Date:   Tue Sep 19 16:31:17 2023 -0400

c++: implement P2564, consteval needs to propagate up [PR107687]

and therefore, mine.

[Bug c++/115986] [14/15 Regression] ICE in fold_convert_loc, at fold-const.cc:2644 involving consteval user-defined uint128 literals

[valentin at tolmer dot fr via Gcc-bugs]

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

--- Comment #3 from Valentin Tolmer  ---
Some notes:
- The fact that the static_assert fails is not relevant. Changing b() to return
1 still exhibits the error.
- The branch taken in `long f = true ? 0 : b(long(1));` matters; it only fails
if b is not evaluated.
- The specific template arguments of b don't matter, as long as we have 2
different instantiations (one of them not actually called due to the branch
above).
- if the `0_c`, or an expression containing it, is assigned to a variable, it
doesn't fail. However, simply using the value (e.g. `(void)b(0_c);`) still
exhibits the bug.

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

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

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

--- Comment #4 from Jonathan Wakely  ---
Firstly, you're reporting a false positive warning, so using -Werror just
confuses things. Some warnings have false positives, that's unavoidable. But it
only fails to compile because you used -Werror. Don't use -Werror if you don't
like the warnings being errors, or use -Wno-error=dangling-reference so it's
just a warning not an error. GCC turning wanrings into errors when you ask it
to do that is not a bug.

(In reply to Dan Urosu from comment #2)
> I cannot use "#pragma GCC diagnostic ignored" because we have thousands of
> call sites where we plan to use this kind of code.

You don't need to use it at the call site:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
template 
const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}
#pragma GCC diagnostic pop


> And we don't want to disable globally this warning either.
> 
> Would "no_dangling (with GCC 14+) " disable globally this check as well?

No, only for calls to a function that uses the attribute:

template 
[[gnu::no_dangling]]
const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}

(In reply to Dan Urosu from comment #3)
> The 109642 is not a duplicate of the attached code.
> The error is the same but the code that causes it is completely different.

Andrew already said it's not an exact duplicate, but he's right that this is
another case of a -Wdangling-reference false positive that can be suppressed
the same way.

> Also, the "solution" to disable the warning/error is not actually resolving
> the issue but merely hiding it.

What's the difference between hiding a warning and stopping a false positive
warning from being emitted? You want the warning to go away, right?

The suggested solution is not just to disable the warning, but to decorate the
unwrap_2 function to tell the compiler not to warn there. That's not the same
as -Wno-dangling-reference globally.

The warning for your original example seems reasonable, the function is called
with a temporary of type int (binding to the FUN&& parameter) and returns a
const int&, which certainly could be a dangling reference.

But I don't understand why it warns for this version:

template 
struct Wrapper {
T val;
};

template 
const T& unwrap_2(const Wrapper& r, FUNC&&) {
  return r.val;
}

int main(int, char**) {
  const Wrapper w{1234};
  const auto& u = unwrap_2(w, 1L);
  __builtin_printf("Unwrapped value : %d\n", u);
}

Here we have a temporary of type long, so the return const int& can't bind to
that.

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

[durosu at yahoo dot com via Gcc-bugs]

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

--- Comment #5 from Dan Urosu  ---
 Ah indeed, but...
In the real use case we call it from macro.


#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
template 
    const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}

#define UNWRAP_2(x, y) unwrap_2(x,y)

#pragma GCC diagnostic pop


When using that macro I still get the error.

On Thursday, July 18, 2024 at 12:36:25 PM EDT, redi at gcc dot gnu.org
 wrote:  

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

--- Comment #4 from Jonathan Wakely  ---
Firstly, you're reporting a false positive warning, so using -Werror just
confuses things. Some warnings have false positives, that's unavoidable. But it
only fails to compile because you used -Werror. Don't use -Werror if you don't
like the warnings being errors, or use -Wno-error=dangling-reference so it's
just a warning not an error. GCC turning wanrings into errors when you ask it
to do that is not a bug.

(In reply to Dan Urosu from comment #2)
> I cannot use "#pragma GCC diagnostic ignored" because we have thousands of
> call sites where we plan to use this kind of code.

You don't need to use it at the call site:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
template 
    const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}
#pragma GCC diagnostic pop


> And we don't want to disable globally this warning either.
> 
> Would "no_dangling (with GCC 14+) " disable globally this check as well?

No, only for calls to a function that uses the attribute:

template 
    [[gnu::no_dangling]]
    const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}

(In reply to Dan Urosu from comment #3)
> The 109642 is not a duplicate of the attached code.
> The error is the same but the code that causes it is completely different.

Andrew already said it's not an exact duplicate, but he's right that this is
another case of a -Wdangling-reference false positive that can be suppressed
the same way.

> Also, the "solution" to disable the warning/error is not actually resolving
> the issue but merely hiding it.

What's the difference between hiding a warning and stopping a false positive
warning from being emitted? You want the warning to go away, right?

The suggested solution is not just to disable the warning, but to decorate the
unwrap_2 function to tell the compiler not to warn there. That's not the same
as -Wno-dangling-reference globally.

The warning for your original example seems reasonable, the function is called
with a temporary of type int (binding to the FUN&& parameter) and returns a
const int&, which certainly could be a dangling reference.

But I don't understand why it warns for this version:

template 
struct Wrapper {
    T val;
};

template 
    const T& unwrap_2(const Wrapper& r, FUNC&&) {
  return r.val;
}

int main(int, char**) {
  const Wrapper w{1234};
  const auto& u = unwrap_2(w, 1L);
  __builtin_printf("Unwrapped value : %d\n", u);
}

Here we have a temporary of type long, so the return const int& can't bind to
that.

[Bug c++/115985] anonymous struct with base class rejected by gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
After r12-2627 we start to reject anonymous struct with bases on purpose.

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

[durosu at yahoo dot com via Gcc-bugs]

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

--- Comment #6 from Dan Urosu  ---
 Using the macro with the unwrap_1 does not error.
The GCC behavior is very weird.


On Thursday, July 18, 2024 at 12:44:21 PM EDT, Dan Urosu 
wrote:  

  Ah indeed, but...
In the real use case we call it from macro.


#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
template 
    const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}

#define UNWRAP_2(x, y) unwrap_2(x,y)

#pragma GCC diagnostic pop


When using that macro I still get the error.

On Thursday, July 18, 2024 at 12:36:25 PM EDT, redi at gcc dot gnu.org
 wrote:  

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

--- Comment #4 from Jonathan Wakely  ---
Firstly, you're reporting a false positive warning, so using -Werror just
confuses things. Some warnings have false positives, that's unavoidable. But it
only fails to compile because you used -Werror. Don't use -Werror if you don't
like the warnings being errors, or use -Wno-error=dangling-reference so it's
just a warning not an error. GCC turning wanrings into errors when you ask it
to do that is not a bug.

(In reply to Dan Urosu from comment #2)
> I cannot use "#pragma GCC diagnostic ignored" because we have thousands of
> call sites where we plan to use this kind of code.

You don't need to use it at the call site:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
template 
    const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}
#pragma GCC diagnostic pop


> And we don't want to disable globally this warning either.
> 
> Would "no_dangling (with GCC 14+) " disable globally this check as well?

No, only for calls to a function that uses the attribute:

template 
    [[gnu::no_dangling]]
    const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}

(In reply to Dan Urosu from comment #3)
> The 109642 is not a duplicate of the attached code.
> The error is the same but the code that causes it is completely different.

Andrew already said it's not an exact duplicate, but he's right that this is
another case of a -Wdangling-reference false positive that can be suppressed
the same way.

> Also, the "solution" to disable the warning/error is not actually resolving
> the issue but merely hiding it.

What's the difference between hiding a warning and stopping a false positive
warning from being emitted? You want the warning to go away, right?

The suggested solution is not just to disable the warning, but to decorate the
unwrap_2 function to tell the compiler not to warn there. That's not the same
as -Wno-dangling-reference globally.

The warning for your original example seems reasonable, the function is called
with a temporary of type int (binding to the FUN&& parameter) and returns a
const int&, which certainly could be a dangling reference.

But I don't understand why it warns for this version:

template 
struct Wrapper {
    T val;
};

template 
    const T& unwrap_2(const Wrapper& r, FUNC&&) {
  return r.val;
}

int main(int, char**) {
  const Wrapper w{1234};
  const auto& u = unwrap_2(w, 1L);
  __builtin_printf("Unwrapped value : %d\n", u);
}

Here we have a temporary of type long, so the return const int& can't bind to
that.

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

[durosu at yahoo dot com via Gcc-bugs]

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

--- Comment #7 from Dan Urosu  ---
Why does not warn for unwarp_1?
The mere addition of an unused template parameter triggers this warning.

[Bug c++/115987] False "possibly dangling reference" false positive when having an extra template parameter

[durosu at yahoo dot com via Gcc-bugs]

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

--- Comment #8 from Dan Urosu  ---
Why does not warn for unwarp_1?
The mere addition of an unused template parameter triggers this warning.

Also "decorating the unwrap_2 function to tell the compiler not to warn there."
does not work if we have a macro calling unwrap_2. (Which we would use in the
real code)

#include 
#include 

// Compile: gcc -std=c++17 -Wall -Wextra -Werror -lstdc++ main_unwrap.cpp -o
main_unwrap
/**
'unwrap_1' and 'unwrap_2' are functionally identical.
By introducing an additional template parameter, the code fails to compile,
when unwrap_2 is used.
The code should not give errors because the lifetime of the returned reference
is tied to the lifetime of the 'wrapper' object.
*/

template 
struct Wrapper {
const T& value() const { return val.value(); }
T& value() { return val.value(); }
std::optional val;
};


template 
const T& unwrap_1(const Wrapper& r) {
  return r.value();
}

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
template 
const T& unwrap_2(const Wrapper& r, FUNC&&) { // note FUNC is not even
used
  return r.value();
}
#define UNWRAP_2(x, y) unwrap(x, y)
#pragma GCC diagnostic pop


#define WITH_FUNC_PARAM

int main(int, char**) {
  const Wrapper w{1234};
#ifndef WITH_FUNC_PARAM
  const auto& u = unwrap_1(w);
#else
  const auto& u = UNWRAP_2(w, 1); // This fails with error: possibly dangling
reference to a temporary [-Werror=dangling-reference]
#endif
  printf("Unwrapped value : %d\n", u);

  return 0;
}