[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection
  Component|target  |tree-optimization
   Target Milestone|--- |14.0
Summary|internal compiler error: in |[14 Regression] internal
   |to_constant, at |compiler error: in
   |poly-int.h:504  |to_constant, at
   ||poly-int.h:504

--- Comment #4 from Andrew Pinski  ---
Looks like this one is already fixed.

[Bug middle-end/110989] RISC-V vector ICE due to invalid tree code in GIMPLE vect pass

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/629152.html
   Keywords|needs-bisection |patch

--- Comment #20 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629152.html

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

--- Comment #19 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #14)
> So I suspecting it is this pattern:
> /* -(type)!A -> (type)A - 1.  */
> (simplify
>  (negate (convert?:s (logical_inverted_value:s @0)))
>  (if (INTEGRAL_TYPE_P (type)
>   && TREE_CODE (type) != BOOLEAN_TYPE
>   && TYPE_PRECISION (type) > 1
>   && TREE_CODE (@0) == SSA_NAME
>   && ssa_name_has_boolean_range (@0))
>   (plus (convert:type @0) { build_all_ones_cst (type); })))
> 
> We start out with:
> -(unsigned int)(bool:31 == 0)
> 
> Yes bool:31 == 0 will have 0/1 but bool:31 does not.
> 
> Even more:
> bool
> ssa_name_has_boolean_range (tree op)
> {
>   gcc_assert (TREE_CODE (op) == SSA_NAME);
> 
>   /* Boolean types always have a range [0..1].  */
>   if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE)
> return true;


In the end I decided to just delete the above check.

[Bug c/111269] location for non-constant expressions inside static assert could be better

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #3 from Alejandro Colomar  ---
On 2023-09-01 18:57, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111269
>
> Andrew Pinski  changed:
>
>What|Removed |Added
> 
>See Also||https://gcc.gnu.org/bugzill
>||a/show_bug.cgi?id=55678
>

Did you accidentally point to a different bug?
I don't think that one is related at all.

_Static_assert escapes tick marks just to make me mad

[Bug c/111269] location for non-constant expressions inside static assert could be better

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #2 from Alejandro Colomar  ---
Hi Andrew,

On 2023-09-01 18:55, pinskia at gcc dot gnu.org wrote:
> It is pointing to the whole expression and just the outermost operator, || .

That's what I suspected.

>
> Now the C++ front-end gives a better location and information on why it is not
> a constant expression:
> : In function 'int main()':
> :11:26: error: non-constant condition for static assertion
>11 | _Static_assert(0 || 7 > x, "");
>   |~~^~~~
> :11:33: error: the value of 'x' is not usable in a constant expression
>11 | _Static_assert(0 || 7 > x, "");
>   | ^
> :9:13: note: 'int x' is not const
> 9 | int x = 42;
>   | ^
>
>
> The C front-end could do better ...

Yep, g++ seems good here.  If it's something easy that I could do, I'd
love some pointer to the code I should look at to do the same that the
C++ front end does.

Cheers,
Alex

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from TC  ---
The impacted members we observed are `_Hash_node_value_base::_M_valptr` and
`_Hash_node_value_base::_M_v`. I think the layout of `_Hash_node` didn't
change.

And I'm not seeing why fixing this will require breaking ABI again. For
example, if the affected functions are marked always_inline (or renamed, or
have their mangling otherwise changed), I would expect the resulting code to be
linkable with either the GCC10 version or the current version of the code,
unless I'm missing something?

[Bug c++/111272] [13/14 Regression] Truncated error messages with -std=c++23 and -std=c++26

[pkeir at outlook dot com via Gcc-bugs]

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

--- Comment #2 from Paul Keir  ---
Thanks. The `-Winvalid-constexpr` mentioned there is a helpful workaround.

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #17)
> (In reply to Andrew Pinski from comment #16)
> > Or just change ssa_name_has_boolean_range to use gimple_zero_one_valued_p
> > instead:
> > 
> > extern bool gimple_zero_one_valued_p (tree t, tree (*valueize)(tree));
> > bool
> > ssa_name_has_boolean_range (tree op)
> > {
> >   gcc_assert (TREE_CODE (op) == SSA_NAME);
> >   return gimple_zero_one_valued_p (op, NULL);
> > }
> > 
> > Later on we can remove the ssa_name_has_boolean_range wrapper around
> > gimple_zero_one_valued_p  too ...
> 
> But get_nonzero_bits needs to change to use not just the cached version of
> the range (nonzero bits) but instead `get_range_query (cfun)->range_of_expr`.
> 
> Anyways I have a fix still and this should fix other issues too ...

Except that does not work as we remove now during evrp too many
__builtin_unreachable's.

So back to drawing board for a second.

[Bug tree-optimization/107876] [13 Regression] ICE in verify_dominators, at dominance.cc:1184 (error: dominator of 4 should be 14, not 16) since r13-3749-g7314b98b1bcd382c

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

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

Eric Gallager  changed:

   What|Removed |Added

 Resolution|FIXED   |---
   Keywords||testsuite-fail
 CC||egallager at gcc dot gnu.org
 Status|RESOLVED|REOPENED

--- Comment #8 from Eric Gallager  ---
(In reply to Francois-Xavier Coudert from comment #7)
> The test case (g++.dg/tree-ssa/pr107876.C) fails on aarch64-darwin.
> 
> FAIL: g++.dg/tree-ssa/pr107876.C  -std=gnu++14  scan-tree-dump unswitch
> "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2"
> FAIL: g++.dg/tree-ssa/pr107876.C  -std=gnu++17  scan-tree-dump unswitch
> "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2"
> FAIL: g++.dg/tree-ssa/pr107876.C  -std=gnu++20  scan-tree-dump unswitch
> "unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2"
> 
> The output says:
> 
> ;; Function test17 (_Z6test17i, funcdef_no=0, decl_uid=4194, cgraph_uid=1,
> symbol_order=0)
> 
> Estimating # of iterations of loop 1
> g++.dg/tree-ssa/pr107876.C:21:7: optimized: unswitching loop 1 on 'if' with
> condition: i_7(D) == 0
> g++.dg/tree-ssa/pr107876.C:21:7: note: optimized sizes estimated to 0 (true)
> and 0 (false) from original size 16

reopening, then

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

--- Comment #17 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #16)
> Or just change ssa_name_has_boolean_range to use gimple_zero_one_valued_p
> instead:
> 
> extern bool gimple_zero_one_valued_p (tree t, tree (*valueize)(tree));
> bool
> ssa_name_has_boolean_range (tree op)
> {
>   gcc_assert (TREE_CODE (op) == SSA_NAME);
>   return gimple_zero_one_valued_p (op, NULL);
> }
> 
> Later on we can remove the ssa_name_has_boolean_range wrapper around
> gimple_zero_one_valued_p  too ...

But get_nonzero_bits needs to change to use not just the cached version of the
range (nonzero bits) but instead `get_range_query (cfun)->range_of_expr`.

Anyways I have a fix still and this should fix other issues too ...

[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

--- Comment #9 from Eric Feng  ---
(In reply to Hans-Peter Nilsson from comment #4)
> 
> If we move past the difference in semantics of the idioms in the patch, I
> still don't see why there actually was error for the original syntax.  There
> must be something in the difference between the hash_map and hash_set
> declarations.  Eagerly awaiting comments on the patch.  (Probably not the
> best way to learn recent C++ standards, but believe it or not, I'm exposed
> to a worse way, on another track... :)

Thanks again for the patch, Hans-Peter. For those interested, I try to dive
into why hash_map caused an error here whilst hash_set was fine in the original
syntax in the body of this e-mail:
https://gcc.gnu.org/pipermail/gcc/2023-September/242404.html. In short: I think
the issue was due to the compiler having trouble disambiguating between which
hash_map constructor to use in the original syntax in C++11. Please feel free
to chime in and correct my hypothesis. Cheers!

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[peter0x44 at disroot dot org via Gcc-bugs]

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

peter0x44 at disroot dot org changed:

   What|Removed |Added

 CC||peter0x44 at disroot dot org

--- Comment #5 from peter0x44 at disroot dot org ---

#include 
int main() { return typeid(0) == typeid(0); }

The following reproduces for me, although strangely only with -std=c++23 and
-static-libstdc++.

x86_64-w64-mingw32-g++ test.cpp -static-libstdc++ -std=c++20
// no error

x86_64-w64-mingw32-g++ test.cpp -static-libstdc++ -std=c++23
/usr/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld:
/usr/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.a(tinfo.o):
in function `std::type_info::operator==(std::type_info const&) const':
/build/mingw-w64-gcc/src/gcc/libstdc++-v3/libsupc++/tinfo.cc:42: multiple
definition of `std::type_info::operator==(std::type_info const&) const';
/tmp/ccyAJVlk.o:test.cpp:(.text$_ZNKSt9type_infoeqERKS_[_ZNKSt9type_infoeqERKS_]+0x0):
first defined here

Related issue:
https://github.com/skeeto/w64devkit/issues/86

[Bug c++/111273] New: Spurious array-bounds error when copying data using _GLIBCXX_DEBUG iterators

[jgrossma at qti dot qualcomm.com via Gcc-bugs]

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

Bug ID: 111273
   Summary: Spurious array-bounds error when copying data using
_GLIBCXX_DEBUG iterators
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgrossma at qti dot qualcomm.com
  Target Milestone: ---

When compiling with -Warray-bounds and -D_GLIBCXX_DEBUG on g++ 13.2.0, copying
from a vector to an array throws the Warray-bounds error during compilation.

Source:

#include 
#include 
#include 

static const int N = 1;

int func(std::vector const ) {
std::array a;
std::copy_n(v.begin(), N, a.begin());
return a[0];
}


Program should not have any problems at compile time. Copies 1 location to a 1
element array. Changing N=2 doesn't show the error. 

Compile options:

-Werror -O3 -Warray-bounds -D_GLIBCXX_DEBUG -std=c++20


Disabling -D_GLIBCXX_DEBUG doesn't show the error.


Output:

---

In file included from
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/vector:62,
 from :1:
In static member function 'static constexpr _Up* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
const int; _Up = int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = const int*; _OI = int*]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_algobase.h:506:30,
inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = false; _II = const int*; _OI = int*]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_algobase.h:533:42,
inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = false; _II = __gnu_cxx::__normal_iterator > >; _OI = int*]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_algobase.h:540:31,
inlined from '_OI std::__copy_move_a(const
__gnu_debug::_Safe_iterator<_Ite, _Seq, _Cat>&, const
__gnu_debug::_Safe_iterator<_Ite, _Seq, _Cat>&, _OI) [with bool _IsMove =
false; _Ite = __gnu_cxx::__normal_iterator > >; _Seq = __debug::vector; _Cat =
random_access_iterator_tag; _OI = int*]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/debug/safe_iterator.tcc:257:36,
inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II =
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, __debug::vector,
random_access_iterator_tag>; _OI = int*]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_algobase.h:633:7,
inlined from 'constexpr _OutputIterator
std::__copy_n(_RandomAccessIterator, _Size, _OutputIterator,
random_access_iterator_tag) [with _RandomAccessIterator =
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, __debug::vector,
random_access_iterator_tag>; _Size = int; _OutputIterator = int*]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_algo.h:731:23,
inlined from 'constexpr _OIter std::copy_n(_IIter, _Size, _OIter) [with
_IIter = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, __debug::vector,
random_access_iterator_tag>; _Size = int; _OIter = int*]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_algo.h:763:27,
inlined from 'int func(const std::__debug::vector&)' at :9:16:
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_algobase.h:437:30:
error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' forming
offset 4 is out of the bounds [0, 4] of object 'a' with type 'std::array' [-Werror=array-bounds=]
  437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~
: In function 'int func(const std::__debug::vector&)':
:8:24: note: 'a' declared here
8 | std::array a;
  |^
cc1plus: all warnings being treated as errors
Compiler returned: 1

---

Interestingly, the error location should not even be hit for a 1 element copy
as it's inside a check for length>1.


Godbolt link shows as well: https://godbolt.org/z/v8GK4nzde


GCC 12 does not seem to show this issue.

Seems related to this one: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

--- Comment #16 from Andrew Pinski  ---
Or just change ssa_name_has_boolean_range to use gimple_zero_one_valued_p
instead:

extern bool gimple_zero_one_valued_p (tree t, tree (*valueize)(tree));
bool
ssa_name_has_boolean_range (tree op)
{
  gcc_assert (TREE_CODE (op) == SSA_NAME);
  return gimple_zero_one_valued_p (op, NULL);
}

Later on we can remove the ssa_name_has_boolean_range wrapper around
gimple_zero_one_valued_p  too ...

[Bug target/111270] gcc/config/i386/i386-options.cc:3039:8: warning: duplicated ‘if ’ condition [-Wduplicated-cond]

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from David Binderman  ---
(In reply to Jonathan Wakely from comment #3)
> The correct git blame output is:
> 
> 105c2795b0d6 gcc/config/i386/i386-options.c  (Jan Hubicka 
> 2019-07-23 09:35:18 + 3037)   if (ix86_tune_features

Thanks for that. This bug looks like one for Jan, then.

My apologies for the lack of git knowledge. Despite multiple
attempts, I've never really reached a good understanding of it's
more subtle aspects.

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #14)
> Even more:
> bool
> ssa_name_has_boolean_range (tree op)
> {
>   gcc_assert (TREE_CODE (op) == SSA_NAME);
> 
>   /* Boolean types always have a range [0..1].  */
>   if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE)
> return true;

The other fix is for the above to check if the boolean type is signed or not
...

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #14 from Andrew Pinski  ---
So I suspecting it is this pattern:
/* -(type)!A -> (type)A - 1.  */
(simplify
 (negate (convert?:s (logical_inverted_value:s @0)))
 (if (INTEGRAL_TYPE_P (type)
  && TREE_CODE (type) != BOOLEAN_TYPE
  && TYPE_PRECISION (type) > 1
  && TREE_CODE (@0) == SSA_NAME
  && ssa_name_has_boolean_range (@0))
  (plus (convert:type @0) { build_all_ones_cst (type); })))

We start out with:
-(unsigned int)(bool:31 == 0)

Yes bool:31 == 0 will have 0/1 but bool:31 does not.

Even more:
bool
ssa_name_has_boolean_range (tree op)
{
  gcc_assert (TREE_CODE (op) == SSA_NAME);

  /* Boolean types always have a range [0..1].  */
  if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE)
return true;

Changing that pattern to:
/* -(type)!A -> (type)A - 1.  */
(simplify
 (negate (convert?:s (logical_inverted_value:s zero_one_valued_p@0)))
 (if (INTEGRAL_TYPE_P (type)
  && TREE_CODE (type) != BOOLEAN_TYPE
  && TYPE_PRECISION (type) > 1)
  (plus (convert:type @0) { build_all_ones_cst (type); })))

Fixes the testcase in comment #10 and should fix the original issue too.

[Bug c++/111272] [13/14 Regression] Truncated error messages with -std=c++23 and -std=c++26

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
Summary|Truncated error messages|[13/14 Regression]
   |with -std=c++23 and |Truncated error messages
   |-std=c++26  |with -std=c++23 and
   ||-std=c++26
   Last reconfirmed||2023-09-01
   Target Milestone|--- |13.3
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Keywords||diagnostic

--- Comment #1 from Marek Polacek  ---
Started with r13-4112-gc85f8dbb173f45:

commit c85f8dbb173f45053f6d8849d27adc98d9668769
Author: Marek Polacek 
Date:   Wed Nov 2 13:11:02 2022 -0400

c++: P2448 - Relaxing some constexpr restrictions [PR106649]

[Bug target/111270] gcc/config/i386/i386-options.cc:3039:8: warning: duplicated ‘if ’ condition [-Wduplicated-cond]

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

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

--- Comment #3 from Jonathan Wakely  ---
The correct git blame output is:

105c2795b0d6 gcc/config/i386/i386-options.c  (Jan Hubicka  2019-07-23
09:35:18 + 3037)   if (ix86_tune_features [X86_TUNE_AVOID_256FMA_CHAINS])
eef81eefcdc2 gcc/config/i386/i386-options.cc (Jan Hubicka  2022-12-22
10:55:46 +0100 3038) SET_OPTION_IF_UNSET (opts, opts_set,
param_avoid_fma_max_bits, 512);
eef81eefcdc2 gcc/config/i386/i386-options.cc (Jan Hubicka  2022-12-22
10:55:46 +0100 3039)   else if (ix86_tune_features
[X86_TUNE_AVOID_256FMA_CHAINS])
028d40925205 gcc/config/i386/i386-options.c  (Martin Liska 2019-11-12
11:08:40 +0100 3040) SET_OPTION_IF_UNSET (opts, opts_set,
param_avoid_fma_max_bits, 256);
105c2795b0d6 gcc/config/i386/i386-options.c  (Jan Hubicka  2019-07-23
09:35:18 + 3041)   else if (ix86_tune_features
[X86_TUNE_AVOID_128FMA_CHAINS])
028d40925205 gcc/config/i386/i386-options.c  (Martin Liska 2019-11-12
11:08:40 +0100 3042) SET_OPTION_IF_UNSET (opts, opts_set,
param_avoid_fma_max_bits, 128);

[Bug target/111270] gcc/config/i386/i386-options.cc:3039:8: warning: duplicated ‘if ’ condition [-Wduplicated-cond]

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

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

--- Comment #2 from Jonathan Wakely  ---
This is nothing to do with me, g:d4ba3b369 doesn't touch that file at all, and
git blame doesn't show that commit for me. Do you have a shallow clone maybe,
and d4ba3b369 is simply the first commit in your history?

[Bug fortran/31059] bounds-check does not detect nonconforming assignment arrays

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

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

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

https://gcc.gnu.org/g:6f06152541d62ae7c8579b7d7bf552be19e15b05

commit r14-3633-g6f06152541d62ae7c8579b7d7bf552be19e15b05
Author: Harald Anlauf 
Date:   Thu Aug 31 22:19:58 2023 +0200

Fortran: runtime bounds-checking in presence of array constructors
[PR31059]

gcc/fortran/ChangeLog:

PR fortran/31059
* trans-array.cc (gfc_conv_ss_startstride): For array bounds
checking,
consider also array constructors in expressions, and use their
shape.

gcc/testsuite/ChangeLog:

PR fortran/31059
* gfortran.dg/bounds_check_fail_5.f90: New test.

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

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

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

François Dumont  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #1 from François Dumont  ---
A 3 years old abi regression seems difficult to fix now. To do so we would need
to break abi again.

It seems to be a limited issue as you need a non-optimized build. The only
impacted member is the _M_next() which is a simple static_cast, I'm very
surprised that it's not always inlined even if non-optimized.

Apart perhaps documenting it I cannot think of anything to do.

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Zdenek Sojka from comment #12)
> Interesting, all the gcc's starting from gcc-6 up to gcc-13 at -O0 to -O3
> (including 32bit and 64bit targets) seem to "PASS" on this testcase.
> 
> ... wait, no, (unsigned)0 <= 0 is TRUE ...

Oh you are correct I read it incorrectly.
Anyways it is definitely a bug in veclower; looking into it.
  _1 = { -1 };
  _9 = VIEW_CONVERT_EXPR<>(_1);
  _10 = _9 != 0;
  _11 = _9 == 0;
  _12 = (unsigned long) _11;
  _13 = (unsigned long) _9;
  _14 = _13 + 18446744073709551615;
  _2 = {_14};

That produces:
_14 = _13 - 1; or rather _9 - 1 .
I suspect there is a missing check somewhere in match.pd really ...

[Bug analyzer/105948] RFE: analyzer could check c++ placement-new sizes

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

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

--- Comment #3 from Benjamin Priour  ---
I believe the above patch resolves this PR.
I'm letting it sip in trunk for a few days before marking it as solved.

[Bug c++/111272] New: Truncated error messages with -std=c++23 and -std=c++26

[pkeir at outlook dot com via Gcc-bugs]

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

Bug ID: 111272
   Summary: Truncated error messages with -std=c++23 and
-std=c++26
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

The C++14 code below requires the `constexpr` specifier on the `ft` member
function. Compiling this with `-std=c++14`, `-std=c++17` or `-std=c++20` will
provide a helpful error message which identifies the need to add the
`constexpr` specifier to `ft`.

However, if `-std=c++23`, or `-std=c++26` are used, no message indicating the
need for `constexpr` on `ft` is displayed; and the message itself is truncated:
ending only in "...not usable as a 'constexpr' function because:".

struct Jam
{
  // constexpr  // n.b.
  int ft() { return 42; }

  constexpr
  Jam() { ft(); }
};

constexpr bool test()
{
  Jam j;
  return true;
}

static_assert(test(), "");

The full truncated error message is:

$ /opt/gcc-latest/bin/g++ -std=c++26 -c truncated-constexpr-error-gcc.cpp 
truncated-constexpr-error-gcc.cpp:16:19: error: non-constant condition for
static assertion
   16 | static_assert(test(), "");
  |   ^~
truncated-constexpr-error-gcc.cpp:16:19:   in ‘constexpr’ expansion of ‘test()’
truncated-constexpr-error-gcc.cpp:12:7: error: ‘constexpr Jam::Jam()’ called in
a constant expression
   12 |   Jam j;
  |   ^
truncated-constexpr-error-gcc.cpp:7:3: note: ‘constexpr Jam::Jam()’ is not
usable as a ‘constexpr’ function because:
7 |   Jam() { ft(); }
  |   ^~~

[Bug analyzer/105948] RFE: analyzer could check c++ placement-new sizes

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

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

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Benjamin Priour :

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

commit r14-3632-ge7b267444045c507654a2a3f758efee5d5b550df
Author: benjamin priour 
Date:   Fri Sep 1 00:01:29 2023 +0200

analyzer: Add support of placement new and improved operator new
[PR105948,PR94355]

Fixed spurious possibly-NULL warning always tagging along throwing
operator new despite it never returning NULL.
Now operator new is correctly recognized as possibly returning NULL
if and only if it is non-throwing or exceptions have been disabled.
Different standard signatures of operator new are now properly
recognized.

Added support of placement new, so that it is now properly recognized,
and a 'heap_allocated' region is no longer created for it.
Placement new size is also checked and a 'Wanalyzer-allocation-size'
is emitted when relevant, as well as always a 'Wanalyzer-out-of-bounds'.

'operator new' non-throwing variants are detected y checking the types
of the parameters.
Indeed, in a call to new (std::nothrow) () the chosen overload
has signature 'operator new (void*, std::nothrow_t&)', where the second
parameter is a reference. In a placement new, the second parameter will
always be a void pointer.

Prior to this patch, some buffers first allocated with 'new', then deleted
an thereafter used would result in a 'Wanalyzer-user-after-free'
warning. However the wording was "use after 'free'" instead of the
expected "use after 'delete'".
This patch fixes this by introducing a new kind of poisoned value,
namely POISON_KIND_DELETED.

Due to how the analyzer sees calls to non-throwing variants of
operator new, dereferencing a pointer freshly allocated in this fashion
caused both a 'Wanalyzer-use-of-uninitialized-value' and a
'Wanalyzer-null-dereference' to be emitted, while only the latter was
relevant. As a result, 'null-dereference' now supersedes
'use-of-uninitialized'.

Signed-off-by: benjamin priour 

gcc/analyzer/ChangeLog:

PR analyzer/105948
PR analyzer/94355
* analyzer.h (is_placement_new_p): New declaration.
* call-details.cc
(call_details::deref_ptr_arg): New function.
Dereference the argument at given index if possible.
* call-details.h: Declaration of the above function.
* kf-lang-cp.cc (is_placement_new_p): Returns true if the gcall
is recognized as a placement new.
(kf_operator_delete::impl_call_post): Unbinding a region and its
descendents now poisons with POISON_KIND_DELETED.
(register_known_functions_lang_cp): Known function "operator
delete" is now registered only once independently of its number of
arguments.
* region-model.cc (region_model::eval_condition): Now
recursively calls itself if any of the operand is wrapped in a
cast.
* sm-malloc.cc (malloc_state_machine::on_stmt):
Add placement new recognition.
* svalue.cc (poison_kind_to_str): Wording for the new PK.
* svalue.h (enum poison_kind): Add value POISON_KIND_DELETED.

gcc/testsuite/ChangeLog:

PR analyzer/105948
PR analyzer/94355
* g++.dg/analyzer/out-of-bounds-placement-new.C: Added a directive.
* g++.dg/analyzer/placement-new.C: Added tests.
* g++.dg/analyzer/new-2.C: New test.
* g++.dg/analyzer/noexcept-new.C: New test.
* g++.dg/analyzer/placement-new-size.C: New test.

[Bug analyzer/94355] analyzer support for C++ new expression

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

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

--- Comment #16 from CVS Commits  ---
The trunk branch has been updated by Benjamin Priour :

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

commit r14-3632-ge7b267444045c507654a2a3f758efee5d5b550df
Author: benjamin priour 
Date:   Fri Sep 1 00:01:29 2023 +0200

analyzer: Add support of placement new and improved operator new
[PR105948,PR94355]

Fixed spurious possibly-NULL warning always tagging along throwing
operator new despite it never returning NULL.
Now operator new is correctly recognized as possibly returning NULL
if and only if it is non-throwing or exceptions have been disabled.
Different standard signatures of operator new are now properly
recognized.

Added support of placement new, so that it is now properly recognized,
and a 'heap_allocated' region is no longer created for it.
Placement new size is also checked and a 'Wanalyzer-allocation-size'
is emitted when relevant, as well as always a 'Wanalyzer-out-of-bounds'.

'operator new' non-throwing variants are detected y checking the types
of the parameters.
Indeed, in a call to new (std::nothrow) () the chosen overload
has signature 'operator new (void*, std::nothrow_t&)', where the second
parameter is a reference. In a placement new, the second parameter will
always be a void pointer.

Prior to this patch, some buffers first allocated with 'new', then deleted
an thereafter used would result in a 'Wanalyzer-user-after-free'
warning. However the wording was "use after 'free'" instead of the
expected "use after 'delete'".
This patch fixes this by introducing a new kind of poisoned value,
namely POISON_KIND_DELETED.

Due to how the analyzer sees calls to non-throwing variants of
operator new, dereferencing a pointer freshly allocated in this fashion
caused both a 'Wanalyzer-use-of-uninitialized-value' and a
'Wanalyzer-null-dereference' to be emitted, while only the latter was
relevant. As a result, 'null-dereference' now supersedes
'use-of-uninitialized'.

Signed-off-by: benjamin priour 

gcc/analyzer/ChangeLog:

PR analyzer/105948
PR analyzer/94355
* analyzer.h (is_placement_new_p): New declaration.
* call-details.cc
(call_details::deref_ptr_arg): New function.
Dereference the argument at given index if possible.
* call-details.h: Declaration of the above function.
* kf-lang-cp.cc (is_placement_new_p): Returns true if the gcall
is recognized as a placement new.
(kf_operator_delete::impl_call_post): Unbinding a region and its
descendents now poisons with POISON_KIND_DELETED.
(register_known_functions_lang_cp): Known function "operator
delete" is now registered only once independently of its number of
arguments.
* region-model.cc (region_model::eval_condition): Now
recursively calls itself if any of the operand is wrapped in a
cast.
* sm-malloc.cc (malloc_state_machine::on_stmt):
Add placement new recognition.
* svalue.cc (poison_kind_to_str): Wording for the new PK.
* svalue.h (enum poison_kind): Add value POISON_KIND_DELETED.

gcc/testsuite/ChangeLog:

PR analyzer/105948
PR analyzer/94355
* g++.dg/analyzer/out-of-bounds-placement-new.C: Added a directive.
* g++.dg/analyzer/placement-new.C: Added tests.
* g++.dg/analyzer/new-2.C: New test.
* g++.dg/analyzer/noexcept-new.C: New test.
* g++.dg/analyzer/placement-new-size.C: New test.

[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #8 from Hans-Peter Nilsson  ---
.

[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

--- Comment #7 from Hans-Peter Nilsson  ---
I don't think it's worthwhile to keep this open, as I'm pretty sure I fixed it
for all targets, as the cause wasn't target-related.  Otherwise, reopen; if
adding a sarcastic comment, then preferably also with a humorous twist.

[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

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

commit r14-3631-gd3dd69706af4c086cb3385ff1f321887b91f49fb
Author: Hans-Peter Nilsson 
Date:   Fri Sep 1 04:36:03 2023 +0200

testsuite: Fix analyzer_cpython_plugin.c declarations, PR testsuite/111264

Also, add missing newline at end of file.

PR testsuite/111264
* gcc.dg/plugin/analyzer_cpython_plugin.c: Make declarations
C++11-compatible.

[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

  Component|analyzer|testsuite
   Assignee|efric at gcc dot gnu.org   |hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  ---
I'm taking it as I'm about to commit the approved patch.
Also, changing component to testsuite.

[Bug tree-optimization/111262] [14 Regression] error: count of bb not initialized with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
$ git bisect bad 0c78240fd7d519fc
0c78240fd7d519fc27ca822f66a92f85edf43f70 is the first bad commit
commit 0c78240fd7d519fc27ca822f66a92f85edf43f70
Author: Jan Hubicka 
Date:   Thu Aug 24 15:10:46 2023 +0200

Check that passes do not forget to define profile

[Bug tree-optimization/111262] [14 Regression] error: count of bb not initialized with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
I am trying a bisection. Current range is g:d96659e34cdcf436
to g:603bdf906af6d42c, which is 11 commits.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

--- Comment #11 from Xi Ruoyao  ---
(In reply to Alex Mohr from comment #10)
> (In reply to Xi Ruoyao from comment #9)
> > I believe the only real issue is imprecise documentation: "It is a better
> > choice than -O0" has some caveats and it's not always true.
> 
> Is there a way to explicitly enable the compiler passes that collect debug
> info that are disabled at -O0?

I don't think so, many -fxxx optimize options have no effect at -O0.

But if you are using -Og you can add -fno-inline if you really don't want
inlining.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

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

--- Comment #10 from Alex Mohr  ---
(In reply to Xi Ruoyao from comment #9)
> I believe the only real issue is imprecise documentation: "It is a better
> choice than -O0" has some caveats and it's not always true.

Is there a way to explicitly enable the compiler passes that collect debug info
that are disabled at -O0?

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

--- Comment #9 from Xi Ruoyao  ---
(In reply to Alex Mohr from comment #8)
> (In reply to Jonathan Wakely from comment #5)
> > A 4x slowdown isn't really acceptable IMHO. At that point, why not just use
> > -O0 instead?
> 
> I've been using -O0 for years.  I was trying to move to -Og because of this
> from the manual; particularly the second sentence:
> 
> "-Og should be the optimization level of choice for the standard
> edit-compile-debug cycle, offering a reasonable level of optimization while
> maintaining fast compilation and a good debugging experience. It is a better
> choice than -O0 for producing debuggable code because some compiler passes
> that collect debug information are disabled at -O0."
> 
> I definitely do not want to lose debug info.  The speed improvement is a
> nice bonus, but top-notch debugging is my main goal for my debug builds.

I believe the only real issue is imprecise documentation: "It is a better
choice than -O0" has some caveats and it's not always true.

[Bug c/111269] Confusing location of error in source code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-09-01

--- Comment #1 from Andrew Pinski  ---
It is pointing to the whole expression and just the outermost operator, || .

Now the C++ front-end gives a better location and information on why it is not
a constant expression:
: In function 'int main()':
:11:26: error: non-constant condition for static assertion
   11 | _Static_assert(0 || 7 > x, "");
  |~~^~~~
:11:33: error: the value of 'x' is not usable in a constant expression
   11 | _Static_assert(0 || 7 > x, "");
  | ^
:9:13: note: 'int x' is not const
9 | int x = 42;
  | ^


The C front-end could do better ...

[Bug c/111269] Confusing location of error in source code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

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

--- Comment #8 from Alex Mohr  ---
(In reply to Jonathan Wakely from comment #5)
> A 4x slowdown isn't really acceptable IMHO. At that point, why not just use
> -O0 instead?

I've been using -O0 for years.  I was trying to move to -Og because of this
from the manual; particularly the second sentence:

"-Og should be the optimization level of choice for the standard
edit-compile-debug cycle, offering a reasonable level of optimization while
maintaining fast compilation and a good debugging experience. It is a better
choice than -O0 for producing debuggable code because some compiler passes that
collect debug information are disabled at -O0."

I definitely do not want to lose debug info.  The speed improvement is a nice
bonus, but top-notch debugging is my main goal for my debug builds.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
I think maybe this is a debuginfo and/or gdb problem, where 'next' doesn't
really do what you want, and 'finish' leaves the frame which has unpredictable
results if anything has been inlined (gdb shows you're in function 'foo' but
since that was actually inlined into its caller, running 'finish' returns from
foo's caller not from foo).

Ideally we'd keep the inlining, but improve the debug experience. Disabling
inlining seems like a hack to work around the fact that gdb doesn't really do
what we want.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #3)
> it shouldn't make much difference when single-stepping
> statements since the debugger should enter inlined bodies the same as
> not inlined bodies?

'step' works OK, but 'next' and 'finish' are pretty useless. And if you can
only use 'step' then you end up descending into constructors and destructors of
temporaries and other uninteresting junk that isn't what you're trying to
debug.

For example, with this code:

#include 
#include 
#include 

int main()
{
  using namespace std::chrono;
  const sys_seconds expected = sys_days(2023y/August/9) + 20h + 44min;
  file_time tp;

  minutes offset;
  std::string abbrev;
  std::istringstream is("002023-08-09 21:44 +01 BST!");
  assert( is >> parse("%6F %R %z %Z", tp, abbrev, offset) );
}

Compiled with -Og I get:

$ gdb -q  -ex start -ex n -ex n -ex n -ex n -ex n -ex step -ex step -ex step
-ex step -ex step -ex step -ex step -ex  step -ex step  ./parse
Reading symbols from ./parse...
Temporary breakpoint 1 at 0x402296: file parse.cc, line 6.
Starting program: /tmp/parse 
[Thread debugging using libthread_db enabled]   
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at parse.cc:6
6   {
9 file_time tp;
12std::string abbrev;
88__new_allocator() _GLIBCXX_USE_NOEXCEPT { }
13std::istringstream is("002023-08-09 21:44 +01 BST!");
14VERIFY( is >> parse("%6F %R %z %Z", tp, abbrev, offset) );
std::chrono::parse, std::allocator,
std::__cxx11::basic_string, std::allocator
>, std::chrono::time_point > > >
(__offset=std::chrono::duration = { 73728min }, 
__abbrev="", __tp=std::chrono::file_time = { 0s [2174-01-01 00:00:00] },
__fmt=0x406324 "%6F %R %z %Z")
at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2980
2980 
&__offset);
std::chrono::__detail::_Parse > >, char,
std::char_traits, std::allocator >::_Parse
(__offset=0x7fffd8d8, __abbrev=0x7fffd8b0, __tp=std::chrono::file_time
= { 0s [2174-01-01 00:00:00] }, 
__fmt=0x406324 "%6F %R %z %Z", this=0x7fffd710) at
/home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2868
2868  _Parse(const _CharT* __fmt, _Parsable& __tp,
std::chrono::__detail::operator>> (__is=..., __p=...) at
/home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2887
2887  operator>>(__stream_type& __is, _Parse&& __p)
std::chrono::from_stream,
std::chrono::duration >, std::allocator >
(__is=..., 
__fmt=0x406324 "%6F %R %z %Z", __tp=std::chrono::file_time = { 0s
[2174-01-01 00:00:00] }, __abbrev=0x7fffd8b0, __offset=0x7fffd8d8)
at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2806
2806from_stream(basic_istream<_CharT, _Traits>& __is, const _CharT*
__fmt,
std::chrono::from_stream,
std::chrono::duration >, std::allocator >
(__is=..., 
__fmt=0x406324 "%6F %R %z %Z", __tp=std::chrono::sys_time = { 0s
[1970-01-01 00:00:00] }, __abbrev=0x7fffd8b0, __offset=0x7fffd8d8)
at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2705
2705from_stream(basic_istream<_CharT, _Traits>& __is, const _CharT*
__fmt,
2716  __detail::_Parser_t<_Duration> __p(__need);
std::chrono::__detail::_Parser >
>::_Parser (__need=23, this=0x7fffd680)
at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2136
2136  _Parser(__format::_ChronoParts __need) : _M_need(__need) { }
std::chrono::time_point > >::time_point
(this=0x7fffd688)
at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono.h:935
935 constexpr time_point() : __d(duration::zero())
0x0040306b in
std::chrono::__detail::_Parser >
>::operator(), std::allocator >
(this=this@entry=0x7fffd680, __is=..., __fmt=0x406324 "%6F %R %z %Z",
__abbrev=0x7fffd8b0, __offset=__offset@entry=0x7fffd8d8)
at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:3007
3007  ios_base::iostate __err = ios_base::goodbit;

I don't know what the __new_allocator constructor is doing there. The
time_point constructor isn't interesting.

If you replace any of those 'step' commands with 'next' you end up somewhere
you don't want to be:

$ gdb -q  -ex start -ex n -ex n -ex n -ex n -ex n -ex step -ex step -ex step
-ex n -ex step -ex step -ex step -ex  step -ex step  ./parse
Reading symbols from ./parse...
Temporary breakpoint 1 at 0x402296: file parse.cc, line 6.
Starting program: /tmp/parse 
[Thread debugging using libthread_db enabled]   
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at parse.cc:6
6   {
9 file_time tp;
12std::string abbrev;
88__new_allocator() _GLIBCXX_USE_NOEXCEPT { }
13std::istringstream is("002023-08-09 

[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var

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

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

--- Comment #4 from Andrew Pinski  ---
Solving this one is easier, just going with:
/* (nop_outer_cast)-(inner_cast)var -> -(outer_cast)(var)
   if var is smaller in precision. */
(simplify
 (convert (negate:s@1 (convert:s @0)))
 (if (INTEGRAL_TYPE_P (type)
  && tree_nop_conversion_p (type, TREE_TYPE (@1))
  && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0)))
(negate (convert @0

[Bug tree-optimization/107765] missing (int)-(unsigned)int_val to just -int_val if int_val is known not to contain INT_MIN

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

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

--- Comment #3 from Andrew Pinski  ---
So I have decided to solve the original testcase differently.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

--- Comment #5 from Jonathan Wakely  ---
A 4x slowdown isn't really acceptable IMHO. At that point, why not just use -O0
instead?

[Bug libstdc++/110879] [14 Regression] Unnecessary reread from memory in a loop with std::vector

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This should be fixed now. Thanks for the report and the patch.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
I remember I've asked "why not disable -finline with -Og" via gcc-help and
Jonathan told me it would make any "real" C++ programs stupidly slow.

[Bug fortran/111271] gcc/fortran/trans-expr.cc:1134:8: warning: duplicated ‘if’ condition [-Wduplicated-cond]

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
git blame says

6c95fe9bc0 (Paul Thomas  2023-05-16 06:35:40 +0100  1087)   if
(unlimited_poly)

...

6c95fe9bc0 (Paul Thomas  2023-05-16 06:35:40 +0100  1134)   else if
(unlimited_poly)

Adding Paul for their best advice.

[Bug target/111270] gcc/config/i386/i386-options.cc:3039:8: warning: duplicated ‘if ’ condition [-Wduplicated-cond]

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
git blame says:

^d4ba3b369 (Jonathan Wakely 2022-11-01 09:48:41 + 3037)   if
(ix86_tune_features [X86_TUNE_AVOID_256FMA_CHAINS])
eef81eefcd (Jan Hubicka 2022-12-22 10:55:46 +0100 3038)
SET_OPTION_IF_UNSET (opts, opts_set, param_avoid_fma_max_bits, 512);

Adding Jonathan for their best advice.

[Bug libstdc++/110879] [14 Regression] Unnecessary reread from memory in a loop with std::vector

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

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

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

https://gcc.gnu.org/g:419c423d3aeca754e47e1ce1bf707735603a90a3

commit r14-3627-g419c423d3aeca754e47e1ce1bf707735603a90a3
Author: Vladimir Palevich 
Date:   Wed Aug 9 01:34:05 2023 +0300

libstdc++: fix memory clobbering in std::vector [PR110879]

Fix ordering to prevent clobbering of class members by a call to deallocate
in _M_realloc_insert and _M_default_append.

Because of recent changes in _M_realloc_insert and _M_default_append,
calls to deallocate were ordered after assignment to class members of
std::vector (in the guard destructor), which is causing said members to
be call-clobbered.  This is preventing further optimization, the
compiler is unable to move memory read out of a hot loop in this case.

This patch reorders the call to before assignments by putting guard in
its own block. Plus a new testsuite for this case.  I'm not very happy
with the new testsuite, but I don't know how to properly test this.

PR libstdc++/110879

libstdc++-v3/ChangeLog:

* include/bits/vector.tcc (_M_realloc_insert): End guard
lifetime just before assignment to class members.
(_M_default_append): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/pr110879.C: New test.

Signed-off-by: Vladimir Palevich  

[Bug libstdc++/111077] atomic_ref compare_exchange_strong doesn't properly ignore padding bits

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

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

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

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

commit r14-3625-gdcbec954fcba42d97760c6bd98a4c5618473ec93
Author: Jonathan Wakely 
Date:   Wed Aug 23 12:23:37 2023 +0100

libstdc++: Use a loop in atomic_ref::compare_exchange_strong [PR111077]

We need to use a loop in std::atomic_ref::compare_exchange_strong in
order to properly implement the C++20 requirement that padding bits do
not participate when checking the value for equality. The variable being
modified by a std::atomic_ref might have an initial value with non-zero
padding bits, so when the __atomic_compare_exchange built-in returns
false we need to check whether that was only because of non-equal
padding bits that are not part of the value representation. If the value
bits differ, it's just a failed compare-exchange. If the value bits are
the same, we need to retry the __atomic_compare_exchange using the value
that was just read by the previous failed call. As noted in the
comments, it's possible for that second try to also fail due to another
thread storing the same value but with differences in padding.

Because it's undefined to access a variable directly while it's held by
a std::atomic_ref, and because std::atomic_ref will only ever store
values with zeroed padding, we know that padding bits will never go from
zero to non-zero during the lifetime of a std::atomic_ref. They can only
go from an initial non-zero state to zero. This means the loop will
terminate, rather than looping indefinitely as padding bits flicker on
and off. In theory users could call __atomic_store etc. directly and
write a value with non-zero padding bits, but we don't need to support
that. Users doing that should ensure they do not write non-zero padding,
to be compatibile with our std::atomic_ref's invariants.

This isn't a problem for std::atomic::compare_exchange_strong because
the initial value (and all later stores to the variable) are performed
by the library, so we ensure that stored values always have padding bits
cleared. That means we can simply clear the padding bits of the
'expected' value and we will be comparing two values with equal padding
bits. This means we don't need the loop for std::atomic, so update the
__atomic_impl::__compare_exchange function to take a bool parameter that
says whether it's being used by std::atomic_ref. If not, we can use a
simpler, non-looping implementation.

libstdc++-v3/ChangeLog:

PR libstdc++/111077
* include/bits/atomic_base.h (__atomic_impl::__compare_exchange):
Add _AtomicRef non-type template parameter and use a loop if it
is true.
(__atomic_impl::compare_exchange_weak): Add _AtomicRef NTTP.
(__atomic_impl::compare_exchange_strong): Likewise.
(atomic_ref::compare_exchange_weak): Use true for NTTP.
(atomic_ref::compare_exchange_strong): Use true for NTTP.
* testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc:
Fix test to not rely on atomic_ref::load() to return an object
with padding preserved.

[Bug fortran/111271] New: gcc/fortran/trans-expr.cc:1134:8: warning: duplicated ‘if’ condition [-Wduplicated-cond]

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111271
   Summary: gcc/fortran/trans-expr.cc:1134:8: warning: duplicated
‘if’ condition [-Wduplicated-cond]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Source code is

  if (unlimited_poly)
{
   // ...
}
  else if (unlimited_poly)
{ 
  ctree = gfc_class_len_get (var);
  gfc_add_modify (>pre, ctree,
  fold_convert (TREE_TYPE (ctree),
integer_zero_node));
}  

Suggest code rework.

[Bug target/111270] New: gcc/config/i386/i386-options.cc:3039:8: warning: duplicated ‘if ’ condition [-Wduplicated-cond]

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111270
   Summary: gcc/config/i386/i386-options.cc:3039:8: warning:
duplicated ‘if ’ condition [-Wduplicated-cond]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Source code is

  if (ix86_tune_features [X86_TUNE_AVOID_256FMA_CHAINS])
SET_OPTION_IF_UNSET (opts, opts_set, param_avoid_fma_max_bits, 512);
  else if (ix86_tune_features [X86_TUNE_AVOID_256FMA_CHAINS])
SET_OPTION_IF_UNSET (opts, opts_set, param_avoid_fma_max_bits, 256);
  else if (ix86_tune_features [X86_TUNE_AVOID_128FMA_CHAINS])
SET_OPTION_IF_UNSET (opts, opts_set, param_avoid_fma_max_bits, 128);

Suggest code rework. 

I got this by adding -Wduplicated-cond to a build.

If someone were brave enough to add this warning flag to -Wall, then
other developers could benefit from a well hidden but useful flag.

[Bug target/111161] [13 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4394 during build

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to xu...@eswincomputing.com from comment #1)
> backport 
> https://github.com/gcc-mirror/gcc/commit/
> 7f26e76c9848aeea9ec10ea701a6168464a4a9c2
> to gcc-13, should be fixed now.

I can confirm this fixed the build for me. Thank you!

[Bug c++/104661] [C++17+] Catching exception by const value when exception-object has lvalue-reference constructor

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Fedor Chelnokov  ---
Related discussion: https://stackoverflow.com/a/77021213/7325599

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #6 from Iain Sandoe  ---
is there a version available for testing, rebased to trunk (the one I saw from
Aug 19th pretty much fails to apply for most entries)?

[Bug analyzer/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to Andrew Pinski from comment #3)
> You are mostly correct.
> In C++17, Copy elision is guaranteed to be done here while in earlier
> versions it is not and earlier versions of C++ require a copy/move
> constructor even if copy elision is to be done. See
> https://en.cppreference.com/w/cpp/language/copy_elision for more information.

So before this "copy elision", there'd be temporaries constructed and then
copied into other temporaries, this in an object that is essentially just
declared, without initializer?  Weird.  Thanks for the pointer; I guess that's
the general idea, but here there'd be no difference.  IOW, sounds like the
patch is right.

If we move past the difference in semantics of the idioms in the patch, I still
don't see why there actually was error for the original syntax.  There must be
something in the difference between the hash_map and hash_set declarations. 
Eagerly awaiting comments on the patch.  (Probably not the best way to learn
recent C++ standards, but believe it or not, I'm exposed to a worse way, on
another track... :)

[Bug c/111269] New: Confusing location of error in source code

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 111269
   Summary: Confusing location of error in source code
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

I've been confused for some time with a compilation error that
pointed to a slightly-off location.  I wasn't seeing that I used
a temporary variable in a constant expression.  The code could be
reduced to:

$ cat const.c 
int
main(void)
{
int x = 42;

_Static_assert(0 || 7 > x, "");
}
$ gcc-13 -Wall -Wextra const.c
const.c: In function ‘main’:
const.c:6:26: error: expression in static assertion is not constant
6 | _Static_assert(0 || 7 > x, "");
  |~~^~~~
$ clang-16 -Weverything const.c
const.c:6:26: error: static assertion expression is not an integral constant
expression
_Static_assert(0 || 7 > x, "");
   ~^
1 error generated.


Clang points to the precise location of the problem, while GCC is too fuzzy.

I suspect this is a duplicate of other bugs, but I'm not sure, so I'll let you
decide that.

[Bug c++/111069] Mangling of static structured bindings

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

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

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

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

commit r14-3624-gcd37325b8d500bf4021692620686572d5ffb0868
Author: Jakub Jelinek 
Date:   Fri Sep 1 15:07:48 2023 +0200

c++: Fix up mangling of function/block scope static structured bindings
[PR111069]

As can be seen on the testcase, we weren't correctly mangling
static/thread_local structured bindings (C++20 feature) at function/block
scope.  The following patch fixes that by using what write_local_name
does for those cases (note, structured binding mandling doesn't use the
standard path because it needs to pass a list of all the identifiers in
the structured binding to the mangling).  In addition to that it fixes
mangling of various helpers which use write_guarded_name (_ZGV*, _ZTH*,
_ZTW*) and kills find_decomp_unqualified_name which for the local names
would be too hard to implement and uses write_guarded_name for structured
binding related _ZGR* names as well.

All the mangled names on the first testcase match now clang++ and my
expectations.
Because the old mangled names were plain wrong (they mangled the same as
structured binding at global scope and resulted in assembly errors if there
was more than one static structured binding with the same identifiers in
the same (or another) function, I think we don't need to play with another
mangling ABI level which turns on/off the old broken way.

In addition to that the patch starts to emit abi-tags into the
mangle_decomp
produced names when needed and emits a -Wabi warning for that as well.
To make that work, I had to move cp_maybe_mangle_decomp calls from before
cp_finish_decl into a middle of cp_finish_decl after type is deduced and
maybe_commonize_var (which also had to be changed not to ignore structured
bindings) is called but before anything might need a mangled name for the
decl, so a new cp_decomp structure is passed to cp_finish_decl; various
other structured binding related functions have been changed to pass
pointer to that around instead of passing a tree and unsigned int
separately.

On decomp9.C, there is a
_ZZ3barI1TB3quxEivEDC1o1pEB3qux
(g++) vs.
_ZZ3barI1TB3quxEivEDC1o1pE
(clang++) mangling difference, but that seems to be a clang++ bug and
happens
also with normal static block vars, doesn't need structured bindings.

2023-09-01  Jakub Jelinek  

PR c++/111069
gcc/
* common.opt (fabi-version=): Document version 19.
* doc/invoke.texi (-fabi-version=): Likewise.
gcc/c-family/
* c-opts.cc (c_common_post_options): Change latest_abi_version to
19.
gcc/cp/
* cp-tree.h (determine_local_discriminator): Add NAME argument with
NULL_TREE default.
(struct cp_decomp): New type.
(cp_finish_decl): Add DECOMP argument defaulted to nullptr.
(cp_maybe_mangle_decomp): Remove declaration.
(cp_finish_decomp): Add cp_decomp * argument, remove tree and
unsigned
args.
(cp_convert_range_for): Likewise.
* decl.cc (determine_local_discriminator): Add NAME argument, use
it
if non-NULL, otherwise compute it the old way.
(maybe_commonize_var): Don't return early for structured bindings.
(cp_finish_decl): Add DECOMP argument, if non-NULL, call
cp_maybe_mangle_decomp.
(cp_maybe_mangle_decomp): Make it static with a forward
declaration.
Call determine_local_discriminator.  Replace FIRST and COUNT
arguments
with DECOMP argument.
(cp_finish_decomp): Replace FIRST and COUNT arguments with DECOMP
argument.
* mangle.cc (find_decomp_unqualified_name): Remove.
(write_unqualified_name): Don't call find_decomp_unqualified_name.
(mangle_decomp): Handle mangling of static function/block scope
structured bindings.  Don't call decl_mangling_context twice.  Call
check_abi_tags, call write_abi_tags for abi version >= 19 and emit
-Wabi warnings if needed.
(write_guarded_var_name): Handle structured bindings.
(mangle_ref_init_variable): Use write_guarded_var_name.
* parser.cc (cp_parser_range_for): Adjust
do_range_for_auto_deduction
and cp_convert_range_for callers.
(do_range_for_auto_deduction): Replace DECOMP_FIRST_NAME and
DECOMP_CNT arguments with DECOMP.  Adjust cp_finish_decomp caller.
(cp_convert_range_for): Replace DECOMP_FIRST_NAME and
DECOMP_CNT arguments with DECOMP.  Don't call
cp_maybe_mangle_decomp,
adjust cp_finish_decl and cp_finish_decomp callers.

[Bug target/111268] internal compiler error: in to_constant, at poly-int.h:504

[malat at debian dot org via Gcc-bugs]

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

--- Comment #3 from Mathieu Malaterre  ---
For reference

% /usr/lib/gcc-snapshot/bin/gcc -march=armv8.2-a+sve -O2 -c m.c && echo
"success"
success

with

% cat m.c
#pragma GCC aarch64 "arm_sve.h"

svbool_t
foo (svint8_t a, svint8_t b, svbool_t c)
{
  svbool_t d = svcmplt_s8 (svptrue_pat_b8 (SV_ALL), a, b);
  return svsel_b (d, c, d);
}

[Bug target/111268] internal compiler error: in to_constant, at poly-int.h:504

[malat at debian dot org via Gcc-bugs]

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

--- Comment #1 from Mathieu Malaterre  ---
Created attachment 55830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55830=edit
preprocessed source

% /usr/lib/gcc-snapshot/bin/g++ -O2 -g -DNDEBUG -c testcase.i

[Bug target/111268] internal compiler error: in to_constant, at poly-int.h:504

[malat at debian dot org via Gcc-bugs]

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

--- Comment #2 from Mathieu Malaterre  ---
% /usr/lib/gcc-snapshot/bin/g++ --version
g++ (Debian 20230811-1) 14.0.0 20230811 (experimental) [master
r14-3139-g68783211f66]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/111268] New: internal compiler error: in to_constant, at poly-int.h:504

[malat at debian dot org via Gcc-bugs]

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

Bug ID: 111268
   Summary: internal compiler error: in to_constant, at
poly-int.h:504
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malat at debian dot org
  Target Milestone: ---

I am well aware of PR/109176 but it looks somewhat different. Reporting it
here:

ref:
*
https://buildd.debian.org/status/fetch.php?pkg=highway=arm64=1.0.8%7Egit20230830.fed142a-1=1693567540=0

In file included from /<>/hwy/foreach_target.h:207,
 from /<>/hwy/tests/shift_test.cc:18:
/<>/hwy/tests/shift_test.cc: In function 'void
hwy::N_SVE2_128::TestRotateRight::operator()(T, D) [with T = long unsigned int;
D = hwy::N_SVE2_128::Simd]':
/<>/hwy/tests/shift_test.cc:157:34: internal compiler error: in
to_constant, at poly-int.h:504
0xe96ec3 internal_error(char const*, ...)
???:0
0xe81f63 fancy_abort(char const*, int, char const*)
???:0
0x19f174f vect_slp_analyze_operations(vec_info*)
???:0
0x17b9f63 vect_slp_function(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/111267] New: Codegen regression from i386 argument passing changes

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

Bug ID: 111267
   Summary: Codegen regression from i386 argument passing changes
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manolis.tsamis at vrull dot eu
CC: roger at nextmovesoftware dot com, ubizjak at gmail dot com
  Target Milestone: ---

Code generation for the following testcase:

typedef struct {
  float minx, miny;
  float maxx, maxy;
} AABB;

int TestOverlap(AABB a, AABB b) {
  return a.minx <= b.maxx
  && a.miny <= b.maxy
  && a.maxx >= b.minx
  && a.maxx >= b.minx;
}

int TestOverlap2(AABB a, AABB b) {
  return a.miny <= b.maxy
  && a.maxx >= b.minx;
}

has regressed due to commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bdf2737cda53a83332db1a1a021653447b05a7e7

GCC13.2:

TestOverlap:
comiss  xmm3, xmm0
movqrdx, xmm0
movqrsi, xmm1
movqrax, xmm3
jb  .L10
shr rdx, 32
shr rax, 32
movdxmm0, eax
movdxmm4, edx
comiss  xmm0, xmm4
jb  .L10
movdxmm1, esi
xor eax, eax
comiss  xmm1, xmm2
setnb   al
ret
.L10:
xor eax, eax
ret
TestOverlap2:
shufps  xmm0, xmm0, 85
shufps  xmm3, xmm3, 85
comiss  xmm3, xmm0
jb  .L17
xor eax, eax
comiss  xmm1, xmm2
setnb   al
ret
.L17:
xor eax, eax
ret

GCC trunk:

TestOverlap:
movqrax, xmm1
movqrdx, xmm2
movqrsi, xmm0
mov rdi, rax
movqrax, xmm3
mov rcx, rsi
xchgrdx, rax
movdxmm1, edx
mov rsi, rax
mov rax, rdx
comiss  xmm1, xmm0
jb  .L10
shr rcx, 32
shr rax, 32
movdxmm0, eax
movdxmm4, ecx
comiss  xmm0, xmm4
jb  .L10
movdxmm0, esi
movdxmm1, edi
xor eax, eax
comiss  xmm1, xmm0
setnb   al
ret
.L10:
xor eax, eax
ret
TestOverlap2:
movqrdx, xmm2
movqrax, xmm3
movqrsi, xmm0
xchgrdx, rax
mov rcx, rsi
mov rsi, rax
mov rax, rdx
shr rcx, 32
shr rax, 32
movdxmm4, ecx
movdxmm0, eax
comiss  xmm0, xmm4
jb  .L17
movdxmm0, esi
xor eax, eax
comiss  xmm1, xmm0
setnb   al
ret
.L17:
xor eax, eax
ret

(Can also be seen here https://godbolt.org/z/E4xrEn6KW)

[Bug middle-end/111017] [12/13/14 Regression][OpenMP] Wrong code with non-rectangular loop nest

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #8 from Tobias Burnus  ---
FIXED on all affected branches: mainline, GCC 13 and GCC 12. -> Close.

[Bug middle-end/111017] [12/13/14 Regression][OpenMP] Wrong code with non-rectangular loop nest

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Tobias Burnus
:

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

commit r12-9841-g2f8ccacd41a45bccf3e19625c0fbd2627472b45e
Author: Tobias Burnus 
Date:   Sat Aug 19 07:49:06 2023 +0200

omp-expand.cc: Fix wrong code with non-rectangular loop nest [PR111017]

Before commit r12-5295-g47de0b56ee455e, all gimple_build_cond in
expand_omp_for_* were inserted with
  gsi_insert_before (gsi_p, cond_stmt, GSI_SAME_STMT);
except the one dealing with the multiplicative factor that was
  gsi_insert_after (gsi, cond_stmt, GSI_CONTINUE_LINKING);

That commit for PR103208 fixed the issue of some missing regimplify of
operands of GIMPLE_CONDs by moving the condition handling to the new
function
expand_omp_build_cond. While that function has an 'bool after = false'
argument to switch between the two variants.

However, all callers ommited this argument. This commit reinstates the
prior behavior by passing 'true' for the factor != 0 condition, fixing
the included testcase.

PR middle-end/111017
gcc/
* omp-expand.cc (expand_omp_for_init_vars): Pass after=true
to expand_omp_build_cond for 'factor != 0' condition, resulting
in pre-r12-5295-g47de0b56ee455e code for the gimple insert.

libgomp/
* testsuite/libgomp.c-c++-common/non-rect-loop-1.c: New test.

(cherry picked from commit 1dc65003b66e5a97200f454eeddcccfce34416b3)

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

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

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

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

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

commit r14-3623-gc2d3211d580369b75200fbdd7b854d30460e0aba
Author: Jakub Jelinek 
Date:   Fri Sep 1 14:22:17 2023 +0200

testsuite: Fix vectcond-1.C FAIL on i686-linux [PR19832]

This test FAILs on i686-linux with
.../gcc/testsuite/g++.dg/opt/vectcond-1.C:8:57: warning: MMX vector return
without MMX enabled changes the ABI [-Wpsabi]
.../gcc/testsuite/g++.dg/opt/vectcond-1.C:17:12: warning: MMX vector
argument without MMX enabled changes the ABI [-Wpsabi]
excess warning.  Fixed by using -Wno-psabi.

2023-09-01  Jakub Jelinek  

PR tree-optimization/19832
* g++.dg/opt/vectcond-1.C: Add -Wno-psabi to dg-options.

[Bug tree-optimization/110915] vector version of `x == MIN & x > y` is not optimized

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

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

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

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

commit r14-3622-gb8df57b3221aac70f22fb5c93d0b95bf22fded90
Author: Jakub Jelinek 
Date:   Fri Sep 1 14:17:06 2023 +0200

testsuite: Fix up pr110915* tests on i686-linux [PR110915]

These tests FAIL on i686-linux, with
.../gcc/testsuite/gcc.dg/pr110915-1.c:8:1: warning: MMX vector return
without MMX enabled changes the ABI [-Wpsabi]
.../gcc/testsuite/gcc.dg/pr110915-1.c:7:15: warning: MMX vector argument
without MMX enabled changes the ABI [-Wpsabi]
excess warnings.  I've added -Wno-psabi to quiet that up, plus I think
it is undesirable to define macros like vector before including C library
headers in case the header would use that identifier in non-obfuscated
form somewhere.

2023-09-01  Jakub Jelinek  

PR tree-optimization/110915
* gcc.dg/pr110915-1.c: Add -Wno-psabi to dg-options.  Move vector
macro definition after limits.h inclusion.
* gcc.dg/pr110915-2.c: Likewise.
* gcc.dg/pr110915-3.c: Likewise.
* gcc.dg/pr110915-4.c: Likewise.
* gcc.dg/pr110915-5.c: Likewise.
* gcc.dg/pr110915-6.c: Likewise.
* gcc.dg/pr110915-7.c: Likewise.
* gcc.dg/pr110915-8.c: Likewise.
* gcc.dg/pr110915-9.c: Likewise.
* gcc.dg/pr110915-10.c: Likewise.
* gcc.dg/pr110915-11.c: Likewise.
* gcc.dg/pr110915-12.c: Likewise.

[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.

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

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

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

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

commit r14-3616-gf2eb6132c6951edf7960a82828c571a1b98a1a09
Author: Jonathan Wakely 
Date:   Thu Aug 31 18:31:32 2023 +0100

libstdc++: Avoid useless dependency on read_symlink from tzdb

chrono::tzdb::current_zone uses filesystem::read_symlink, which creates
a dependency on the fs_ops.o object in libstdc++.a, which then creates
dependencies on several OS functions if --gc-sections isn't used. For
more details see PR libstdc++/104167 comment 8 and comment 11.

In the cases where that causes linker failures, we probably don't have
readlink anyway, so the filesystem::read_symlink call will always fail.
Repeat the preprocessor conditions for filesystem::read_symlink in the
body of chrono::tzdb::current_zone so that we don't create a
dependency on fs_ops.o for a function that will always fail.

libstdc++-v3/ChangeLog:

* src/c++20/tzdb.cc (tzdb::current_zone): Check configure macros
for POSIX readlink before using filesystem::read_symlink.

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #12 from Zdenek Sojka  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Zdenek Sojka from comment #10)
> > Probably related, even simpler testcase, failing everywhere at -O0:
> > 
> > $ cat testcase.c
> > typedef unsigned long __attribute__((__vector_size__ (8))) V;
> > 
> > int
> > main (void)
> > {
> >   V v = ~((V) { } <=0);
> >   if (v[0])
> > __builtin_abort ();
> >   return 0;
> > }
> 
> But unsigned<=0 is always false and taking the bitwise not of that is always
> -1.

Interesting, all the gcc's starting from gcc-6 up to gcc-13 at -O0 to -O3
(including 32bit and 64bit targets) seem to "PASS" on this testcase.

... wait, no, (unsigned)0 <= 0 is TRUE ...

[Bug libstdc++/111162] signed integer overflow triggered by std::chrono::parse

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
This should be fixed now, thanks for the report.

[Bug libstdc++/111162] signed integer overflow triggered by std::chrono::parse

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

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

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

https://gcc.gnu.org/g:207c507499d23f0176cbfdfe96d3cd50dec39584

commit r14-3609-g207c507499d23f0176cbfdfe96d3cd50dec39584
Author: Jonathan Wakely 
Date:   Tue Aug 29 13:07:21 2023 +0100

libstdc++: Do not allow chrono::parse to overflow for %C [PR62]

libstdc++-v3/ChangeLog:

PR libstdc++/62
* include/bits/chrono_io.h (_Parser::Operator()): Check %C
values are in range of year::min() to year::max().
* testsuite/std/time/parse.cc: Check out of range centuries.

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Zdenek Sojka from comment #10)
> Probably related, even simpler testcase, failing everywhere at -O0:
> 
> $ cat testcase.c
> typedef unsigned long __attribute__((__vector_size__ (8))) V;
> 
> int
> main (void)
> {
>   V v = ~((V) { } <=0);
>   if (v[0])
> __builtin_abort ();
>   return 0;
> }

But unsigned<=0 is always false and taking the bitwise not of that is always
-1.

[Bug tree-optimization/110817] [14 Regression] wrong code with vector compares and vector lowering

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #10 from Zdenek Sojka  ---
Probably related, even simpler testcase, failing everywhere at -O0:

$ cat testcase.c
typedef unsigned long __attribute__((__vector_size__ (8))) V;

int
main (void)
{
  V v = ~((V) { } <=0);
  if (v[0])
__builtin_abort ();
  return 0;
}
$ x86_64-pc-linux-gnu-gcc testcase.c && ./a.out
Aborted
$ aarch64-unknown-linux-gnu-gcc testcase.c -static && ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

[Bug analyzer/111266] New: Missing -Wanalyzer-out-of-bounds for concrete offset overwrite.

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

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

Bug ID: 111266
   Summary: Missing -Wanalyzer-out-of-bounds for concrete offset
overwrite.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: vultkayn at gcc dot gnu.org
  Target Milestone: ---

Hi,

The analyzer do not emit the expected "heap-based write overflow" in the
reproducer below.

#include 
void *malloc (__SIZE_TYPE__);
void free (void *);

void test_binop2 ()
{
  char *p = (char *) malloc (4);
  int32_t *i = (int32_t *) (p + 3);
  *i = 20042; /* { dg-warning "heap-based buffer overflow" "" { xfail *-*-* } }
*/
  free (p);
}


A quick investigation showed that on *i = 20042, check_region_bounds had the
following:

reg is an offset_region(heap_allocated(12), 'int32_', 3) as expected
base_reg is heap_allocated(12)
base_reg's capacity is correct too, and reg_offset *is* 3 bytes, as it should.

The issue comes from num_bytes_sval, which corresponds to the number of bytes
accessed. It should be a constant_svalue of value 4, but is instead of value 1.

Therefore the "read_bytes" byte_range do not overflow the buffer, as we get
(offset) 3 + (accessed bytes) 1 = 4, which is not an overflow (3 + 4 expected)

Re: C++ undefined behaviour sanitiser bug when compiled with optimization

[Jonathan Wakely via Gcc-bugs]

This mailing list is for automated email from our bug tracker, it's
not for reporting bugs directly. Emails sent to this list are likely
to be missed, and definitely won't get entered into the bug tracker.

Please use Bugzilla to report bugs, as described at https://gcc.gnu.org/bugs/

[Bug tree-optimization/23970] loop-invariant-motion is not doing it's work

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

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

--- Comment #3 from Richard Biener  ---
Unswitching does this as a separate transform now, the "hoist guards"
transform.
It's even done completely separate now:

unsigned int
tree_ssa_unswitch_loops (function *fun)
{   
  bool changed_unswitch = false;
  bool changed_hoist = false;
  auto_edge_flag ignored_edge_flag (fun);

  ranger = enable_ranger (fun);

  /* Go through all loops starting from innermost, hoisting guards.  */
  for (auto loop : loops_list (fun, LI_FROM_INNERMOST))
{ 
  if (loop->inner)
changed_hoist |= tree_unswitch_outer_loop (loop);
}

  /* Go through innermost loops, unswitching on invariant predicates
 within those.  */
...

the question is how we'd call the "cheap" unswitching transform.  I guess
simply testing optimize > 2 || opt_enabled or so isn't quite desirable.

Note it's possible to separate this into an entirely separate pass as well.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

--- Comment #3 from Richard Biener  ---
The problem is that -Og aimed at solving two problems that are often in
conflict with each other - improving the debugging experience _and_ runtime
performance.
For the second goal it started as -O1 and then removing optimizations that make
the debugging experience bad which is transforms that re-order things because
then the debugging gets jumpy.  For the first goal we wanted to make
-fvar-tracking usable (not enabled at -O0) without big hits on compile-time
because that also allows the second goal as not all locals are materialized on
the stack.

So yes, we probably should tune down inlining for -Og, possibly also by
simply disabling the size/time estimation logic.  Inlining helps when
you single-step assembler instructions (because you have less instructions
to execute), it shouldn't make much difference when single-stepping
statements since the debugger should enter inlined bodies the same as
not inlined bodies?

[Bug c++/111261] No warning for out of order class initialisation when using class initialisers

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

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

--- Comment #4 from Jonathan Wakely  ---
The FE already has to do lookup for s in that initializer, so it knows that
another member was found.

[Bug c++/111261] No warning for out of order class initialisation when using class initialisers

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #2)
> In fact with trunk we diagnose this properly with -std=c++17 but not
> -std=c++20.

So it's probably because c++17 uses extern template for std::string and C++20
doesn't.

This could probably be done in the front end. The rule about init order is
purely lexical, and so if the initializer odr-uses another member declared
later, we should warn.

[Bug target/111260] arm: ice in maybe_legitimize_operand, at optabs.cc:8054

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from David Binderman  ---
Reduced C code seems to be:

long long g_263;
func_16_l_1358;
func_1() {
  int p_18 = 357942, __trans_tmp_5 = p_18 - (p_18 != g_263);
  if (__trans_tmp_5 <= func_16_l_1358)
func_16_l_1358 = 0;
}

C++ undefined behaviour sanitiser bug when compiled with optimization

[Hannes Mühleisen]

Hello,

we ran into an issue with the following (rather benign) C++ snippet:

#include 
#include 

struct Foo {
  void Bar() ;

  std::mutex some_lock;
  std::atomic some_number;
};

void Foo::Bar() {
some_lock.lock();
some_number++;
some_lock.unlock();
}

When compiling this with a recent GCC on Linux (!) with the following flags

g++ -fsanitize=undefined  -O2 -Werror -c test.cpp -o test.o

The following error is thrown:

In member function ‘std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::fetch_add(__int_type, std::memory_order)
[with _ITp = unsigned char]’,
inlined from ‘std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::operator++(int) [with _ITp = unsigned
char]’ at /usr/include/c++/12/bits/atomic_base.h:369:25,
inlined from ‘void Foo::Bar()’ at test.cpp:13:13:
/usr/include/c++/12/bits/atomic_base.h:618:34: error: ‘unsigned char
__atomic_fetch_add_1(volatile void*, unsigned char, int)’ writing 1
byte into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
  618 |   { return __atomic_fetch_add(&_M_i, __i, int(__m)); }
  |~~^~

Interestingly, the error disappears with -O0 or -O1 which makes me
think it's a bug related to optimization.

Thanks

Hannes

[Bug fortran/111265] New: Compiler segfault with character array in deferred type, when returned by a function

[mailling-lists-bd at posteo dot de via Gcc-bugs]

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

Bug ID: 111265
   Summary: Compiler segfault with character array in deferred
type, when returned by a function
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mailling-lists-bd at posteo dot de
  Target Milestone: ---

Hi,

the following code is giving a compiler segfault with Gfortran 13.2.1 on
Fedora, when compiled with `gfortran -c test.f90`.

``` test.f90
module mod_abs_type
  implicit none

  type, abstract :: my_abs_type_t
 private
 character(len=1024), allocatable :: str_(:)
   contains
 private
 procedure, public :: str
  end type my_abs_type_t

contains
  pure function str(self) result(res)
class(my_abs_type_t), intent(in) :: self
character(len=1024), allocatable :: res(:)

allocate(res(size(self%str_)))
res(:) = self%str_(:)
  end function str
end module mod_abs_type

module mod_container
  use mod_abs_type, only: my_abs_type_t
  implicit none

  type :: my_container_t
 private
 class(my_abs_type_t), allocatable :: ele
   contains
 private
 procedure, public :: str
  end type my_container_t

contains

  pure function str(self) result(res)
class(my_container_t), intent(in) :: self

character(len=1024), allocatable :: res(:)

res = self%ele%str()
  end function str

end module mod_container
```

The error message is:

   42 | res = self%ele%str()
  |1
internal compiler error: Segmentation fault
Please submit a full bug report, with preprocessed source.
See  for instructions.

Thanks !

[Bug c++/111261] No warning for out of order class initialisation when using class initialisers

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
In fact with trunk we diagnose this properly with -std=c++17 but not
-std=c++20.
With -std=c++20 we see

   [local count: 1073741824]:
  _35 = operator new (21);
  __builtin_memcpy (_35, "A rather long string", 20);
  MEM[(char_type &)_35 + 20] = 0;
  operator delete (_35, 21);
  s ={v} {CLOBBER};
  s ={v} {CLOBBER(eol)};
  return 0;

at the point we would be supposed to diagnose the init but you can see
that 's' was elided.

One issue is probably that we elide the standalone S::S() during IPA
(because we inline it) and thus fail to run the late diagnostic passes
on its optimized body:

void S::S (struct S * const this)
{
  struct allocator D.46788;
  struct string * _1;
  struct string * _2;
  long unsigned int _8;

   [local count: 1073741824]:
  _8 = MEM[(const struct basic_string *)this_3(D) + 8B]._M_string_length;
  *this_3(D).len = _8;
  _1 = _3(D)->s;
  std::__cxx11::basic_string::basic_string<> (_1, "A rather long string",
);
  D.46788 ={v} {CLOBBER(eol)};
  return;

of course we lack a start-of-live CLOBBER of *this here (I think I've seen
this before), so we'd fail to diagnose this body as well.

[Bug libstdc++/111258] std::string cannot to be moved in constant evaluated expression

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #2 from Jiang An  ---
Perhaps this is a compiler bug and there's nothing wrong in the move
constructor.

GCC 13 also incorrectly rejects the following program
(https://godbolt.org/z/Yn98KMKv5)
```
#include 

constexpr bool foo11(std::string s)
{
s.push_back('\0');
return true;
}

int main()
{
static_assert(foo11(std::string{}));
}

```

with similar message:

```
: In function 'int main()':
:12:24: error: non-constant condition for static assertion
   12 | static_assert(foo11(std::string{}));
  |   ~^~~
:12:24:   in 'constexpr' expansion of
'foo11(std::__cxx11::basic_string())'
:5:16:   in 'constexpr' expansion of
's.std::__cxx11::basic_string::push_back(0)'
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/basic_string.h:1552:33:
  in 'constexpr' expansion of
'((std::__cxx11::basic_string*)this)->std::__cxx11::basic_string::capacity()'
:12:24: error: accessing 'std::__cxx11::basic_string_M_allocated_capacity' member instead of initialized
'std::__cxx11::basic_string_M_local_buf' member in
constant expression
Compiler returned: 1
```

It seems that gcc currently miscompiles passing-by-value of
non-trivially-copyable classes in constant evaluation.

[Bug analyzer/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |14.0
  Component|other   |analyzer

[Bug c++/111261] No warning for out of order class initialisation when using class initialisers

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-09-01

--- Comment #1 from Richard Biener  ---
We diagnose this at -O1 now but not -O0, -O2 or -O3.  We rely on the late
uninit diagnostic pass here but that's faced with optimized code. 
Interestingly an older version of libstdc++ warned at -O2 and -O3 as well.

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

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

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

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

https://gcc.gnu.org/g:3d86e7f4a8aef1b864a51660825597eafe9059b1

commit r14-3606-g3d86e7f4a8aef1b864a51660825597eafe9059b1
Author: Andrew Pinski 
Date:   Wed Aug 30 21:21:01 2023 -0700

MATCH [PR19832]: Optimize some `(a != b) ? a OP b : c`

This patch adds the following match patterns to optimize these:
 /* (a != b) ? (a - b) : 0 -> (a - b) */
 /* (a != b) ? (a ^ b) : 0 -> (a ^ b) */
 /* (a != b) ? (a & b) : a -> (a & b) */
 /* (a != b) ? (a | b) : a -> (a | b) */
 /* (a != b) ? min(a,b) : a -> min(a,b) */
 /* (a != b) ? max(a,b) : a -> max(a,b) */
 /* (a != b) ? (a * b) : (a * a) -> (a * b) */
 /* (a != b) ? (a + b) : (a + a) -> (a + b) */
 /* (a != b) ? (a + b) : (2 * a) -> (a + b) */
Note currently only integer types (include vector types)
are handled. Floating point types can be added later on.

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

The first pattern had still shows up in GCC in cse.c's preferable
function which was the original motivation for this patch.

PR tree-optimization/19832

gcc/ChangeLog:

* match.pd: Add pattern to optimize
`(a != b) ? a OP b : c`.

gcc/testsuite/ChangeLog:

* g++.dg/opt/vectcond-1.C: New test.
* gcc.dg/tree-ssa/phi-opt-same-1.c: New test.