[Bug tree-optimization/110494] [14 Regression] Wrong code at -O3 on x86_64-pc-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
  iftmp.3_55 = d[_57];
  iftmp.6_54 = (short int) iftmp.3_55;
  _6 = iftmp.3_55 > 1;
  _46 = (short int) _6;
  _143 = _46 | iftmp.6_54;


  # RANGE [irange] short int [0, 1] NONZERO 0x1
  iftmp.6_54 = (short intD.17) iftmp.3_55;

Another dup of bug 110252 (just a different testcase).

Tomorrow I am going to finish up the patch.

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

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

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

[Bug tree-optimization/110494] New: [14 Regression] Wrong code at -O3 on x86_64-pc-linux-gnu

[jwzeng at nuaa dot edu.cn via Gcc-bugs]

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

Bug ID: 110494
   Summary: [14 Regression] Wrong code at -O3 on
x86_64-pc-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwzeng at nuaa dot edu.cn
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/dq38c9zea

The following code snippet:

#include 
unsigned long long int seed = 0;
unsigned int var_1 = 631366671U;
#define min(a, b) ((a) < (b) ? (a) : (b))
int main() {
short a[18];
int b = 1;
unsigned long long int c[18];
unsigned long long int d[18];
for (int i = 0; i < 18; ++i)
a[i] = 4, c[i] = 3, d[i] = 2;
for (unsigned short i = 1; i < 16; i += var_1 - 57737)
a[i] = (short)min(b % (~var_1), c[i] ? d[i] : (long long unsigned
int)b);
for (int i = 0; i < 18; ++i)
seed ^= a[i];
printf("%llu\n", seed);
}

> $ /usr/gcc-trunk/bin/gcc -O0 bug.c; ./a.out
> 5
> $ /usr/gcc-trunk/bin/gcc -O1 bug.c; ./a.out
> 5
> $ /usr/gcc-trunk/bin/gcc -O2 bug.c; ./a.out
> 5
> $ /usr/gcc-trunk/bin/gcc -O3 bug.c; ./a.out
> 7
> $ /usr/gcc-trunk/bin/gcc -Os bug.c; ./a.out
> 5
When compiled with -O3, it prints the wrong result 7 instead of 5. Earlier GCCs
do not have this bug.

> $ /usr/gcc-trunk/bin/gcc --version
Using built-in specs.
COLLECT_GCC=/home/compilers/gcc/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/home/compilers/gcc/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk-source/gcc/configure
--enable-languages=c,c++,fortran --enable-checking=release
--enable-valgrind-annotations --disable-werror --disable-libstdcxx-pch
--enable-libgomp --enable-lto --enable-gold --with-plugin-ld=gold
--prefix=/usr/local/gcc-trunk
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230619 (experimental) [master r14-1917-gf8e0270272] (GCC)

[Bug c++/110493] 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #3 from Andrew Pinski  ---
Note it was not libstdc++ that changed but the front-end (PR 107079  ).

[Bug libstdc++/110493] 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107079
 Status|RESOLVED|UNCONFIRMED

--- Comment #2 from Andrew Pinski  ---
Actually let's reopen this ...

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

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

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

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

[Bug libstdc++/110493] 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
std::string::string is a constexpr in C++20 ...

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

[Bug libstdc++/110493] New: 'is not a constant expression' for function-local static std::initializer_list with fsanitize=undefined

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 110493
   Summary: 'is not a constant expression' for function-local
static std::initializer_list with
fsanitize=undefined
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Since 12.3.0, under -fsanitize=undefined -std=c++20:

#include 
#include 
void f() {
static auto a = {std::string()};
}

error: '(((const std::__cxx11::basic_string*)(& )) != 0)' is
not a constant expression

Clearly this is an instance of bug 71962, but this is in fairly unexceptional
code and could make ubsan unusable; it's not obvious that this code should have
anything to do with constant evaluation.

Since it only appears in a point release I would hope it might be possible to
fix in library for this specific case, within ?

[Bug c++/92752] [10 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-11483-g8c12c47d0c5c40df6e5eeb8625d4708c8a42dbe0
Author: Patrick Palka 
Date:   Fri Jan 28 15:41:15 2022 -0500

c++: bogus warning with value init of const pmf [PR92752]

Here we're emitting a -Wignored-qualifiers warning for an intermediate
compiler-generated cast of nullptr to 'method-type* const' as part of
value initialization of a const pmf.  This patch suppresses the warning
by instead casting to the corresponding unqualified type.

PR c++/92752

gcc/cp/ChangeLog:

* typeck.c (build_ptrmemfunc): Cast a nullptr constant to the
unqualified pointer type not the qualified one.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wignored-qualifiers2.C: New test.

Co-authored-by: Jason Merrill 
(cherry picked from commit e971990cbda091b4caf5e1a5bded5121068934e4)

[Bug c++/97420] [10 Regression] NTTP function reference cannot bind to noexcept function

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-11482-gad42219766d0e67bede2c9bd94c98082cde42518
Author: Patrick Palka 
Date:   Wed May 26 08:35:31 2021 -0400

c++: Fix reference NTTP binding to noexcept fn [PR97420]

Here, in C++17 mode, convert_nontype_argument_function is rejecting
binding a non-noexcept function reference template parameter to a
noexcept function (encoded as the template argument '*(int (&) (int)) ').

The first roadblock to making this work is that the argument is wrapped
an an implicit INDIRECT_REF, so we need to unwrap it before calling
strip_fnptr_conv.

The second roadblock is that the NOP_EXPR cast converts from a function
pointer type to a reference type while simultaneously removing the
noexcept qualification, and fnptr_conv_p doesn't consider this cast to
be a function pointer conversion.  This patch fixes this by making
fnptr_conv_p treat REFERENCE_TYPEs and POINTER_TYPEs interchangeably.

Finally, in passing, this patch also simplifies noexcept_conv_p by
removing a bunch of redundant checks already performed by its only
caller fnptr_conv_p.

PR c++/97420

gcc/cp/ChangeLog:

* cvt.c (noexcept_conv_p): Remove redundant checks and simplify.
(fnptr_conv_p): Don't call non_reference.  Use INDIRECT_TYPE_P
instead of TYPE_PTR_P.
* pt.c (convert_nontype_argument_function): Look through
implicit INDIRECT_REFs before calling strip_fnptr_conv.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept68.C: New test.

(cherry picked from commit b4329e3dd6fb7c78948fcf9d2f5b9d873deec284)

[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #5 from Hans-Peter Nilsson  ---
Re-fixed and re-closed.

[Bug c++/110492] Attempted optimization of switch statement pessimizes it instead

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 55431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55431=edit
testcase

Next time please attach or paste inline the code instead of posting just a link
to godbolt.org .

[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C

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

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

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

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

commit r14-2206-gb22cf5f0321f6425a357c06647a4366d99ddac61
Author: Hans-Peter Nilsson 
Date:   Sat Feb 4 18:38:45 2023 +0100

libstdc++: Re-apply PR108672 fix (avoid use of naked int32_t in
unseq_backend_simd.h)

The fix was overwritten by r14-2109-g3162ca09dbdc2e "libstdc++:
Synchronize PSTL with upstream".

libstdc++-v3:

PR libstdc++/108672
* include/pstl/unseq_backend_simd.h (__simd_or): Re-apply using
__INT32_TYPE__ instead of int32_t.

[Bug target/109435] overaligned structs are not passed correctly for mips64

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by YunQiang Su :

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

commit r14-2205-ge20abdb749d0c0c8552da998ff8ec139b830f5eb
Author: Jovan Dmitrovic 
Date:   Mon Jun 26 17:00:20 2023 +0200

mips: Fix overaligned function arguments [PR109435]

This patch changes alignment for typedef types when passed as
arguments, making the alignment equal to the alignment of
original (aliased) types.

This change makes it impossible for a typedef type to have
alignment that is less than its size.

2023-06-27  Jovan DmitroviÄ  

gcc/ChangeLog:

PR target/109435
* config/mips/mips.cc (mips_function_arg_alignment): Returns
the alignment of function argument. In case of typedef type,
it returns the aligment of the aliased type.
(mips_function_arg_boundary): Relocated calculation of the
aligment of function arguments.

gcc/testsuite/ChangeLog:

* gcc.target/mips/align-1-n64.c: New test.
* gcc.target/mips/align-1-o32.c: New test.

[Bug libstdc++/108672] [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-30
 Status|RESOLVED|REOPENED

--- Comment #3 from Hans-Peter Nilsson  ---
I'm briefly reopening this PR so my next commit makes sense, as
r14-2109-g3162ca09dbdc2e overwrote the fix from February, making the fails
re-appear.  I'll re-commit the fix shortly.

[Bug c++/110492] New: Attempted optimization of switch statement pessimizes it instead

[qufanat at gmail dot com via Gcc-bugs]

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

Bug ID: 110492
   Summary: Attempted optimization of switch statement pessimizes
it instead
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qufanat at gmail dot com
  Target Milestone: ---

This happens on my local GCC 11.3, but you can also see it on 13.1 at this
godbolt link https://godbolt.org/z/G3qecWxPr

I'm creating a switch statement of hashed strings, which compiles to a binary
search on the hashes, all well and good.  However, with -O3 specified, GCC
peels back the last multiplication of the hash for some of the comparison
branches, but is unable to do it for others, resulting in longer assembly with
twice as many comparisons as is necessary.  Here is lines 15..19 in
get_choice_1()

(end of the hash loop)
imulesi, eax, 16777619
testdl, dl
jne .L3
(start of the switch)
cmp eax, 1954414351
je  .L8
cmp esi, 1901626525
ja  .L4

eax is the hash without the last imul, and esi is the final hash.  If we
prevent inlining of the hash function, the compiler can't make this
"optimization" and gives the assembly I expect.  Here is lines 90..93 in
get_choice_2()

callhash32_noinline(char const*)
cmp eax, 1901626525
je  .L33
jbe .L46

Now it only does one comparison per entry and uses it for both the == and <=
branches.

This isn't that important to my program but I thought you'd like to know.

[Bug c/110491] Wrong code at -O2 on x86_64-linux-gnu (a recent regression)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 110228.



  # RANGE [irange] int [0, 1] NONZERO 0x1
  # c_lsm.10_3 = PHI <_17(D)(2), _11(5)>
...
  if (c_lsm_flag.11_16 != 0)
goto ; [66.67%]
  else
goto ; [33.33%]
;;succ:   7 [33.3% (adjusted)]  count:357913944 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
;;8 [66.7% (adjusted)]  count:715827880 (estimated locally)
(TRUE_VALUE,EXECUTABLE)

;;   basic block 7, loop depth 0, count 357913944 (estimated locally), maybe
hot
;;prev block 6, next block 8, flags: (NEW)
;;pred:   6 [33.3% (adjusted)]  count:357913944 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
;;succ:   8 [always]  count:357913944 (estimated locally) (FALLTHRU)

;;   basic block 8, loop depth 0, count 1073741824 (estimated locally), maybe
hot
;;prev block 7, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   7 [always]  count:357913944 (estimated locally) (FALLTHRU)
;;6 [66.7% (adjusted)]  count:715827880 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  # RANGE [irange] int [0, 1] NONZERO 0x1
  # prephitmp_27 = PHI <1(7), c_lsm.10_3(6)>

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

[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

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

[Bug c/110491] New: Wrong code at -O2 on x86_64-linux-gnu (a recent regression)

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

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

Bug ID: 110491
   Summary: Wrong code at -O2 on x86_64-linux-gnu (a recent
regression)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

gcc at -O2 produced wrong code.

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

$ cat a.c
int printf(const char *, ...);
int a, c, d, e;
short b;
void f(int *g) { c &= *g; }
void h(void);
void i() {
  a = 1;
  h();
  f();
}
void h() {
  int *j = 
  *j = 5;
k:
  for (; 4 + b <= 0;)
;
  for (; d;) {
c = e == 0;
goto k;
  }
}
int main() {
  i();
  printf("%d\n", c);
}
$
$ gcc-tk -O0 a.c &&./a.out
1
$ gcc-tk -O2 a.c && ./a.out
-2003318871
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-5f590ee3174cf6058ac882c3a84a96ae639349c8/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-5f590ee3174cf6058ac882c3a84a96ae639349c8
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230629 (experimental) (GCC)
$

[Bug analyzer/110198] [14 regression] g++.dg/analyzer/pr100244.C fails after r14-1632-g9589a46ddadc8b

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

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

Benjamin Priour  changed:

   What|Removed |Added

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

--- Comment #7 from Benjamin Priour  ---
Finally fixed as patch
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1eb90f46c16453f72dc119ba20b07053a15b452d

[Bug analyzer/110198] [14 regression] g++.dg/analyzer/pr100244.C fails after r14-1632-g9589a46ddadc8b

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

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

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

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

commit r14-2203-g1eb90f46c16453f72dc119ba20b07053a15b452d
Author: benjamin priour 
Date:   Thu Jun 22 21:39:05 2023 +0200

analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [PR110198]

g++.dg/analyzer/PR100244.C was failing after a patch of PR109439.
The reason was a spurious preemptive return of get_store_value upon
out-of-bounds read that was preventing further checks. Now instead,
a boolean value check_poisoned goes to false when a OOB is detected,
and is later on given to get_or_create_initial_value.

gcc/analyzer/ChangeLog:
PR analyzer/110198
* region-model-manager.cc
(region_model_manager::get_or_create_initial_value): Take an
optional boolean value to bypass poisoning checks
* region-model-manager.h: Update declaration of the above function.
* region-model.cc (region_model::get_store_value): No longer
returns
on OOB, but rather gives a boolean to get_or_create_initial_value.
(region_model::check_region_access): Update docstring.
(region_model::check_region_for_write): Update docstring.

Signed-off-by: benjamin priour 

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

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |---
 CC||seurer at gcc dot gnu.org
 Status|RESOLVED|REOPENED

--- Comment #9 from seurer at gcc dot gnu.org ---
I am still seeing this failure with r14-2201-g94c71750cdd742 

This is compiling one of the spec test cases on a powerpc BE machine.

/home/seurer/gcc/git/install/gcc-test/bin/gfortran -c -o
module_bc_time_utilities.fppized.o -I. -I./netcdf/include -m64 -O3 -mcpu=power7
-fpeel-loops -funroll-loops -ffast-math -mpopcntd -mrecip=rsqrt
-fvect-cost-model -std=legacy module_bc_time_utilities.fppized.f90
0x10cceb2b crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.cc:314
0x11c8596c vect_supportable_dr_alignment(vec_info*, dr_vec_info*, tree_node*,
int)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-data-refs.cc:6817
0x11ca16c3 get_group_load_store_type
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:2445
0x11ca16c3 get_load_store_type
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:2564
0x11cb498f vectorizable_load
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:9547
0x11cc7e5b vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:11910
0x110c1833 vect_slp_analyze_node_operations_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:5993
0x110c1833 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6191
0x110c1757 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c1757 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c1757 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c1757 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c3b63 vect_slp_analyze_operations(vec_info*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6431
0x1108a10b vect_analyze_loop_2
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:2782
0x1108c73b vect_analyze_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3303
0x1108d093 vect_analyze_loop(loop*, vec_info_shared*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3457
0x110e2507 try_vectorize_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1064
0x110e2507 try_vectorize_loop
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1180
0x110e2d43 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1296

I also traced this back to r14-2117-gdd86a5a69cbda4

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

--- Comment #3 from Andrew Pinski  ---
/* Optimize
   # x_5 in range [cst1, cst2] where cst2 = cst1 + 1
   x_5 ? cstN ? cst4 : cst3
   # op is == or != and N is 1 or 2
   to r_6 = x_5 + (min (cst3, cst4) - cst1) or
   r_6 = (min (cst3, cst4) + cst1) - x_5 depending on op, N and which
   of cst3 and cst4 is smaller.
   This was originally done by two_value_replacement in phiopt (PR 88676).  */


is going to have the same issue I think.

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for GCC 13.2

[Bug libstdc++/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d

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

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

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

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

commit r13-7511-g2d40cd2f199e32f185d4b72db2043e91313ab7f2
Author: Jonathan Wakely 
Date:   Mon Jun 26 14:46:46 2023 +0100

libstdc++: Fix std::format for pointers [PR110239]

The formatter for pointers was casting to uint64_t which sign extends a
32-bit pointer and produces a value that won't fit in the provided
buffer. Cast to uintptr_t instead.

There was also a bug in the __parse_integer helper when converting a
wide string to a narrow string in order to use std::from_chars on it.
The function would always try to read 32 characters, even if the format
string was shorter than that. Fix that bug, and remove the constexpr
implementation of __parse_integer by just using __from_chars_alnum
instead of from_chars, because that's usable in constexpr even in
C++20.

libstdc++-v3/ChangeLog:

PR libstdc++/110239
* include/std/format (__format::__parse_integer): Fix buffer
overflow for wide chars.
(formatter::format): Cast to uintptr_t instead
of uint64_t.
* testsuite/std/format/string.cc: Test too-large widths.

(cherry picked from commit 3bb9f9329c378934541ae4cff9977b7487e97cf0)

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

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

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

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

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

commit r13-7510-gae7cdc8c0f5278e7941f1de7c72ffe9f1fed2775
Author: Jonathan Wakely 
Date:   Thu Jun 8 21:35:21 2023 +0100

libstdc++: Fix P2510R3 "Formatting pointers" [PR110149]

I had intended to support the P2510R3 proposal unconditionally in C++20
mode, but I left it half implemented. The parse function supported the
new extensions, but the format function didn't.

This adds the missing pieces, and makes it only enabled for C++26 and
non-strict modes.

libstdc++-v3/ChangeLog:

PR libstdc++/110149
* include/std/format (formatter::parse):
Only alow 0 and P for C++26 and non-strict modes.
(formatter::format): Use toupper for P
type, and insert zero-fill characters for 0 option.
* testsuite/std/format/functions/format.cc: Check pointer
formatting. Only check P2510R3 extensions conditionally.
* testsuite/std/format/parse_ctx.cc: Only check P2510R3
extensions conditionally.

(cherry picked from commit 628ba410b9265dbd4278c1f1b1fadf05348adef2)

[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-7509-gdbd4acd72274f3b3d542ebf68f9962eda8f8b769
Author: Jonathan Wakely 
Date:   Tue May 16 15:09:20 2023 +0100

libstdc++: Disable cacheline alignment for DJGPP [PR109741]

DJGPP (and maybe other targets) uses MAX_OFILE_ALIGNMENT=16 which means
that globals (and static objects) can't have alignment greater than 16.
This causes an error for the locks defined in src/c++11/shared_ptr.cc
because we try to align them to the cacheline size, to avoid false
sharing.

Add a configure check for the increased alignment, and live with false
sharing where we can't increase the alignment.

libstdc++-v3/ChangeLog:

PR libstdc++/109741
* acinclude.m4 (GLIBCXX_CHECK_ALIGNAS_CACHELINE): Define.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_ALIGNAS_CACHELINE.
* src/c++11/shared_ptr.cc (__gnu_internal::get_mutex): Do not
align lock table if not supported. use __GCC_DESTRUCTIVE_SIZE
instead of hardcoded 64.

(cherry picked from commit 94a311abf783de754f0f1b2d4c1f00a9788e795b)

[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)

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

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:132015b9c6c9f9156ff31f7d66ba92cf01d0bc90

commit r13-7508-g132015b9c6c9f9156ff31f7d66ba92cf01d0bc90
Author: Jonathan Wakely 
Date:   Fri Jun 9 12:15:21 2023 +0100

libstdc++: Add preprocessor checks to  [PR100285]

We can't define endpoints and resolvers without the relevant OS support.
If IPPROTO_TCP and IPPROTO_UDP are both undefined then we won't need
basic_endpoint and basic_resolver anyway, so make them depend on those
macros.

libstdc++-v3/ChangeLog:

PR libstdc++/100285
* include/experimental/internet [IPPROTO_TCP || IPPROTO_UDP]
(basic_endpoint, basic_resolver_entry, resolver_base)
(basic_resolver_results, basic_resolver): Only define if the tcp
or udp protocols will be defined.

(cherry picked from commit 793ed718b522b15e2d758eca953feeec1979fe2c)

[Bug libstdc++/52799] deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:52997b14311726447850341ecaf286b68587ff32

commit r13-7505-g52997b14311726447850341ecaf286b68587ff32
Author: Jonathan Wakely 
Date:   Thu Jun 8 12:19:26 2023 +0100

libstdc++: Improve tests for emplace member of sequence containers

Our existing tests for std::deque::emplace, std::list::emplace and
std::vector::emplace are poor. We only have compile tests for PR 52799
and the equivalent for a const_iterator as the insertion point. This
fails to check that the value is actually inserted correctly and the
right iterator is returned.

Add new tests that cover the existing 52799.cc and const_iterator.cc
compile-only tests, as well as verifying the effects are correct.

libstdc++-v3/ChangeLog:

* testsuite/23_containers/deque/modifiers/emplace/52799.cc:
Removed.
*
testsuite/23_containers/deque/modifiers/emplace/const_iterator.cc:
Removed.
* testsuite/23_containers/list/modifiers/emplace/52799.cc:
Removed.
* testsuite/23_containers/list/modifiers/emplace/const_iterator.cc:
Removed.
* testsuite/23_containers/vector/modifiers/emplace/52799.cc:
Removed.
*
testsuite/23_containers/vector/modifiers/emplace/const_iterator.cc:
Removed.
* testsuite/23_containers/deque/modifiers/emplace/1.cc: New
test.
* testsuite/23_containers/list/modifiers/emplace/1.cc: New
test.
* testsuite/23_containers/vector/modifiers/emplace/1.cc: New
test.

(cherry picked from commit 3ec1d76a359542ed4c8370390efa9ee9e25e757f)

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #5 from palmer at gcc dot gnu.org ---
(In reply to Bin Meng from comment #4)
> I can't get the build to pass with the same configure scripts on current GCC
> HEAD :(
> 
> --host=x86_64-linux-gnu --build=aarch64-linux --target=riscv64-linux
> --enable-targets=all
> --prefix=/home/arnd/cross/x86_64/gcc-13.1.0-nolibc/riscv64-linux
> --enable-languages=c --without-headers --disable-bootstrap --disable-nls
> --disable-threads --disable-shared --disable-libmudflap --disable-libssp
> --disable-libgomp --disable-decimal-float --disable-libquadmath
> --disable-libatomic --disable-libcc1 --disable-libmpx
> --enable-checking=release --with-static-standard-libraries
> 
> Error below:
> 
> Checking multilib configuration for libgcc...
> make[2]: Entering directory '/home/bmeng/git/gcc/riscv64-linux/libgcc'
> Makefile:183: ../.././gcc/libgcc.mvars: No such file or directory
> make[2]: *** No rule to make target '../.././gcc/libgcc.mvars'.  Stop.
> make[2]: Leaving directory '/home/bmeng/git/gcc/riscv64-linux/libgcc'
> make[1]: *** [Makefile:12855: all-target-libgcc] Error 2

It's building for me using riscv-gnu-toolchain and 070a6bf0bdc ("Update
documentation to clarify a GCC extension [PR c/77650]").  If the failure is
still reproducing on a HEAD can you give me a pointer to the exact commit? 
Also might be better to put that in a different bug, it's probably not the same
issue.

[Bug tree-optimization/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

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

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

--- Comment #3 from Andrew Pinski  ---
I was wrong about where the problem was but not wrong about the missed
optimization.

Anyways the issue is in expression_expensive_p where the issue of clzdi2 and
not having clzsi2 ...

expression_expensive_p should check if you can do a widening of the mode ...

[Bug tree-optimization/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|testsuite   |tree-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-29
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
So the problem is a missing optimization.
In this case, arch14 (which enables TARGET_EXTIMM) only defines a clzdi2 and
not a clzsi2 so the code in build_cltz_expr does not realize that it could
still support clzsi2 ...

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r14-2202-g9dc18fca431626404b0692c689a2e103666e7adb
Author: Jan Hubicka 
Date:   Thu Jun 29 22:45:37 2023 +0200

Compute ipa-predicates for conditionals involving __builtin_expect_p

std::vector allocator looks as follows:

__attribute__((nodiscard))
struct pair * std::__new_allocator
>::allocate (struct __new_allocator * const this, size_type __n, const void *
D.27753)
{
  bool _1;
  long int _2;
  long int _3;
  long unsigned int _5;
  struct pair * _9;

   [local count: 1073741824]:
  _1 = __n_7(D) > 1152921504606846975;
  _2 = (long int) _1;
  _3 = __builtin_expect (_2, 0);
  if (_3 != 0)
goto ; [10.00%]
  else
goto ; [90.00%]

   [local count: 107374184]:
  if (__n_7(D) > 2305843009213693951)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 53687092]:
  std::__throw_bad_array_new_length ();

   [local count: 53687092]:
  std::__throw_bad_alloc ();

   [local count: 966367641]:
  _5 = __n_7(D) * 8;
  _9 = operator new (_5);
  return _9;
}

So there is check for allocated block size being greater than max_size
which is
wrapper in __builtin_expect.  This makes ipa-fnsummary to give up analyzing
predicates and it will miss the fact that the two different calls to
__throw
will be optimized out if __n is larady smaller than 1152921504606846975
which
it is after _M_check_len.

This patch extends ipa-fnsummary to understand functions that return their
parameter.

gcc/ChangeLog:

PR tree-optimization/109849
* ipa-fnsummary.cc (decompose_param_expr): Skip
functions returning its parameter.
(set_cond_stmt_execution_predicate): Return early
if predicate was constructed.

gcc/testsuite/ChangeLog:

PR tree-optimization/109849
* gcc.dg/ipa/pr109849.c: New test.

[Bug testsuite/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
I suspect this is a testsuite issue:
>/* { dg-require-effective-target clzl } */

basically the check_effective_target_clz* (ctz*) test is passing for some
reason when it should not be ...

[Bug testsuite/110490] New: tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14

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

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

Bug ID: 110490
   Summary: tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with
arch14
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

(Not sure what component is most appropriate for this.)

The following FAILs can be seen in

(s390x-ibm-linux-gnu arch14)
but not in

(s390x-ibm-linux-gnu default)

It would be great to fix them.

FAIL: gcc.dg/tree-ssa/clz-char.c scan-tree-dump-times optimized
"__builtin_clz|.CLZ" 1
FAIL: gcc.dg/tree-ssa/clz-complement-char.c scan-tree-dump-times optimized
"__builtin_clz|.CLZ" 1
FAIL: gcc.dg/tree-ssa/clz-complement-int.c scan-tree-dump-times optimized
"__builtin_clz|.CLZ" 1
FAIL: gcc.dg/tree-ssa/clz-complement-long.c scan-tree-dump-times optimized
"__builtin_clz|.CLZ" 1
FAIL: gcc.dg/tree-ssa/clz-int.c scan-tree-dump-times optimized
"__builtin_clz|.CLZ" 1
FAIL: gcc.dg/tree-ssa/clz-long.c scan-tree-dump-times optimized
"__builtin_clz|.CLZ" 1
FAIL: gcc.dg/tree-ssa/ctz-char.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1
FAIL: gcc.dg/tree-ssa/ctz-complement-char.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1
FAIL: gcc.dg/tree-ssa/ctz-complement-int.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1
FAIL: gcc.dg/tree-ssa/ctz-complement-long-long.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1
FAIL: gcc.dg/tree-ssa/ctz-complement-long.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1
FAIL: gcc.dg/tree-ssa/ctz-int.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1
FAIL: gcc.dg/tree-ssa/ctz-long-long.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1
FAIL: gcc.dg/tree-ssa/ctz-long.c scan-tree-dump-times optimized
"__builtin_ctz|.CTZ" 1

[Bug analyzer/110483] Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL

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

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this; sorry about the failures.

What's the endianness of the hosts that this is happening on?

Is there a machine in the GCC compile farm that this happens on?

The row of indices is is created here in
string_region_spatial_item::make_table:
if (m_show_full_string)
  {
   for (byte_offset_t byte_idx = bytes.get_start_byte_offset ();
byte_idx < bytes.get_next_byte_offset ();
byte_idx = byte_idx + 1)
 add_column_for_byte (t, btm, sm, byte_idx,
  byte_idx_table_y, byte_val_table_y);
where class string_region_spatial_item has:
  void add_column_for_byte (table , const bit_to_table_map ,
style_manager ,
const byte_offset_t byte_idx,
const int byte_idx_table_y,
const int byte_val_table_y) const
  {
tree string_cst = get_string_cst ();
gcc_assert (byte_idx >= 0);
gcc_assert (byte_idx < TREE_STRING_LENGTH (string_cst));

const byte_range bytes (byte_idx, 1);
if (1) // show_byte_indices
  {
const table::rect_t idx_table_rect
  = btm.get_table_rect (_string_reg, bytes, byte_idx_table_y, 1);
t.set_cell_span (idx_table_rect,
 fmt_styled_string (sm, "[%li]",
byte_idx.ulow ()));
  }

so presumably an issue with:

 fmt_styled_string (sm, "[%li]",
byte_idx.ulow ()));
on those hosts.

Possibly an endianness-handling mistake by me?

[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:9479da4515f7d019b4ef282d0e21536431c44f71

commit r14-2199-g9479da4515f7d019b4ef282d0e21536431c44f71
Author: Patrick Palka 
Date:   Thu Jun 29 16:10:18 2023 -0400

c++: NSDMI instantiation during overload resolution [PR110468]

Here we find ourselves instantiating the NSDMI for A<1>::m when
computing argument conversions during overload resolution, and
thus tf_conv is set.  The flag causes mark_used for the constructor
used in the NSDMI to exit early and not instantiate its noexcept-spec,
which eventually leads to an ICE from nothrow_spec_p.

This patch fixes this by clearing any special tsubst flags during
instantiation of an NSDMI, since the result should be independent of
the context that requires the instantiation.

PR c++/110468

gcc/cp/ChangeLog:

* init.cc (maybe_instantiate_nsdmi_init): Mask out all
tsubst flags except for tf_warning_or_error.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept79.C: New test.

[Bug c++/110463] [13/14 Regression] Mutable subobject is usable in a constant expression

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-2198-gfd8a1be04d4cdbfefea457b99ed8404d77b35dd6
Author: Patrick Palka 
Date:   Thu Jun 29 16:02:04 2023 -0400

c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

Here we're incorrectly accepting the mutable member accesses because
cp_fold neglects to propagate CONSTRUCTOR_MUTABLE_POISON when folding a
CONSTRUCTOR.

PR c++/110463

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_fold) : Propagate
CONSTRUCTOR_MUTABLE_POISON.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-mutable6.C: New test.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #30 from anlauf at gcc dot gnu.org ---
BTW: you can get a traceback on FP exceptions by adding to the linker options:

 -ffpe-trap=zero,overflow,invalid

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

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

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

--- Comment #15 from Benjamin Priour  ---
(In reply to Jonathan Wakely from comment #14)
> [...snip...]
> 
> See the -fcheck-new option:
> 
>   Check that the pointer returned by "operator new" is non-null before
> attempting to modify the storage allocated.  This check is normally
> unnecessary because the C++ standard specifies that "operator new" only
> returns 0 if it is declared "throw()", in which case the compiler always
> checks the return value even without this option.  In all other cases, when
> "operator new" has a non-empty exception specification, memory exhaustion is
> signalled by throwing "std::bad_alloc".  See also new (nothrow).


Should we use the above flag's value to also optionally disable the analyzer
warnings on operator new possibly returning NULL?

Or maybe there could be an additional flag -fanalyzer-new-returns-null, turned
'on' by default.

Having such capability would be useful to run the analyzer against itself, as
GCC is built without exceptions (thus every operator new possibly returns
NULL).

[Bug middle-end/110489] Slow building virtual.c.i from p11-kit

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

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

--- Comment #2 from Andrew Pinski  ---
So I took a look at the sources, there are very many small functions.
This might be the reason why dump files Timevar takes a long time, it is called
for each pass and for each function. Maybe that can be improved.

the register allocator and schedule costs I suspect is due to there being a
small setup cost which multiply by many functions add up.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #36 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14, and backported to 13-branch for 13.2.

The backport required a backport of r14-90 concerning some poor scan patterns.

Closing.

[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90

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

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

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

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

commit r13-7501-g1a023e688186ea4cd284f5d269f2ecde9f80438c
Author: Harald Anlauf 
Date:   Tue Apr 18 21:24:20 2023 +0200

testsuite: fix scan-tree-dump patterns [PR83904,PR100297]

Adjust scan-tree-dump patterns so that they do not accidentally match a
valid path.

gcc/testsuite/ChangeLog:

PR testsuite/83904
PR fortran/100297
* gfortran.dg/allocatable_function_1.f90: Use "__builtin_free "
instead of the naive "free".
* gfortran.dg/reshape_8.f90: Extend pattern from a simple "data".

(cherry picked from commit 6fc8e25cb6b5d720bedd85194b0ad740d75082f4)

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #35 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:74ef4221b5ebb1122349ad48422ddc40e98c267d

commit r13-7502-g74ef4221b5ebb1122349ad48422ddc40e98c267d
Author: Harald Anlauf 
Date:   Mon Jun 12 23:08:48 2023 +0200

Fortran: fix passing of zero-sized array arguments to procedures [PR86277]

gcc/fortran/ChangeLog:

PR fortran/86277
* trans-array.cc (gfc_trans_allocate_array_storage): When passing a
zero-sized array with fixed (= non-dynamic) size, allocate
temporary
by the caller, not by the callee.

gcc/testsuite/ChangeLog:

PR fortran/86277
* gfortran.dg/zero_sized_14.f90: New test.
* gfortran.dg/zero_sized_15.f90: New test.

Co-authored-by: Mikael Morin 
(cherry picked from commit c1691509e5a8875f36c068a5ea101bf13f140948)

[Bug testsuite/83904] gfortran.dg allocatable_function_1 failures

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

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

commit r13-7501-g1a023e688186ea4cd284f5d269f2ecde9f80438c
Author: Harald Anlauf 
Date:   Tue Apr 18 21:24:20 2023 +0200

testsuite: fix scan-tree-dump patterns [PR83904,PR100297]

Adjust scan-tree-dump patterns so that they do not accidentally match a
valid path.

gcc/testsuite/ChangeLog:

PR testsuite/83904
PR fortran/100297
* gfortran.dg/allocatable_function_1.f90: Use "__builtin_free "
instead of the naive "free".
* gfortran.dg/reshape_8.f90: Extend pattern from a simple "data".

(cherry picked from commit 6fc8e25cb6b5d720bedd85194b0ad740d75082f4)

[Bug middle-end/110489] Slow building virtual.c.i from p11-kit

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

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

--- Comment #1 from Andrew Pinski  ---
The only ones that stick out are:
 dump files :   1.07 (  4%)   0.24 (  5%)   1.58 (  5%)
0  (  0%)
 integrated RA  :   1.75 (  7%)   0.11 (  2%)   2.10 (  7%)
  147M ( 24%)
 scheduling 2   :   1.55 (  6%)   0.14 (  3%)   1.35 (  4%)
 2653k (  0%)


Nothing else sticks out really. (but they do add up).

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #29 from Jürgen Reuter  ---
(In reply to anlauf from comment #28)
> Update: recompiling that file with 13-branch fails for me, too.
> Playing with the one-line patch for pr86277 makes no difference, fortunately.
> 
> Compiling the file with gfortran-12 seems to work ok.
> 
> So is this really a 14-only regression, or is 13-branch already suspicious?

We have gcc 13.1 in our CI, everything works fine there. I am still working on
a smaller test, but have very bad connection rn.

[Bug c/110489] New: Slow building virtual.c.i from p11-kit

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

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

Bug ID: 110489
   Summary: Slow building virtual.c.i from p11-kit
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55430=edit
virtual.c.i.xz

I fear this is a degenerate case as it's a largeish generated file (made during
the build process), but it's noticeable enough for me to raise it anyway.

When building p11-kit, I noticed a handful of files took considerably longer to
build. This is with release checking.

The standout seems to be `virtual.c.i`:

```
$ time gcc -c virtual.c.i -O2 -fPIC

real0m12.429s
user0m12.137s
sys 0m0.238s

$ gcc --version
gcc (Gentoo 12.3.1_p20230526 p2) 12.3.1 20230526
Copyright (C) 2022 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.

$ gcc -c virtual.c.i -O2 -pipe -fPIC -ftime-report
Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)
 1326k (  0%)
 phase parsing  :   1.24 (  5%)   1.01 ( 20%)   2.26 (  7%)
   53M (  9%)
 phase lang. deferred   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
   96  (  0%)
 phase opt and generate :  24.16 ( 95%)   4.08 ( 80%)  28.74 ( 93%)
  570M ( 91%)
 phase finalize :   0.00 (  0%)   0.00 (  0%)   0.02 (  0%)
0  (  0%)
 garbage collection :   0.08 (  0%)   0.00 (  0%)   0.08 (  0%)
0  (  0%)
 dump files :   1.07 (  4%)   0.24 (  5%)   1.58 (  5%)
0  (  0%)
 callgraph construction :   0.14 (  1%)   0.01 (  0%)   0.22 (  1%)
   18M (  3%)
 callgraph optimization :   0.36 (  1%)   0.12 (  2%)   0.50 (  2%)
   13k (  0%)
 callgraph functions expansion  :  20.14 ( 79%)   3.12 ( 61%)  23.71 ( 76%)
  390M ( 62%)
 callgraph ipa passes   :   3.61 ( 14%)   0.84 ( 17%)   4.48 ( 14%)
  132M ( 21%)
 ipa function summary   :   0.14 (  1%)   0.04 (  1%)   0.12 (  0%)
   13M (  2%)
 ipa dead code removal  :   0.09 (  0%)   0.00 (  0%)   0.07 (  0%)
0  (  0%)
 ipa devirtualization   :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 ipa cp :   0.14 (  1%)   0.04 (  1%)   0.11 (  0%)
 6933k (  1%)
 ipa inlining heuristics:   0.14 (  1%)   0.02 (  0%)   0.10 (  0%)
  135k (  0%)
 ipa function splitting :   0.39 (  2%)   0.06 (  1%)   0.34 (  1%)
   40M (  7%)
 ipa comdats:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 ipa reference  :   0.03 (  0%)   0.00 (  0%)   0.03 (  0%)
0  (  0%)
 ipa profile:   0.02 (  0%)   0.00 (  0%)   0.03 (  0%)
0  (  0%)
 ipa pure const :   0.07 (  0%)   0.02 (  0%)   0.16 (  1%)
 2416  (  0%)
 ipa icf:   0.14 (  1%)   0.00 (  0%)   0.14 (  0%)
 8112  (  0%)
 ipa SRA:   0.10 (  0%)   0.00 (  0%)   0.11 (  0%)
 1116k (  0%)
 ipa free lang data :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
0  (  0%)
 ipa free inline summary:   0.02 (  0%)   0.00 (  0%)   0.04 (  0%)
0  (  0%)
 ipa modref :   0.08 (  0%)   0.00 (  0%)   0.08 (  0%)
 2874k (  0%)
 cfg construction   :   0.02 (  0%)   0.02 (  0%)   0.06 (  0%)
 1323k (  0%)
 cfg cleanup:   0.23 (  1%)   0.06 (  1%)   0.34 (  1%)
 3108k (  0%)
 trivially dead code:   0.07 (  0%)   0.02 (  0%)   0.14 (  0%)
0  (  0%)
 df scan insns  :   0.20 (  1%)   0.03 (  1%)   0.25 (  1%)
  282k (  0%)
 df reaching defs   :   0.21 (  1%)   0.03 (  1%)   0.37 (  1%)
0  (  0%)
 df live regs   :   0.35 (  1%)   0.08 (  2%)   0.31 (  1%)
0  (  0%)
 df live regs   :   0.23 (  1%)   0.01 (  0%)   0.17 (  1%)
0  (  0%)
 df must-initialized regs   :   0.06 (  0%)   0.00 (  0%)   0.03 (  0%)
0  (  0%)
 df use-def / def-use chains:   0.10 (  0%)   0.02 (  0%)   0.17 (  1%)
0  (  0%)
 df reg dead/unused notes   :   0.40 (  2%)   0.02 (  0%)   0.32 (  1%)
 6334k (  1%)
 register information   :   0.14 (  1%)   0.01 (  0%)   0.06 (  0%)
0  (  0%)
 alias analysis :   0.46 (  2%)   0.03 (  1%)   0.31 (  1%)
   11M (  2%)
 alias stmt walking :   0.13 (  1%)   0.04 (  

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #28 from anlauf at gcc dot gnu.org ---
Update: recompiling that file with 13-branch fails for me, too.
Playing with the one-line patch for pr86277 makes no difference, fortunately.

Compiling the file with gfortran-12 seems to work ok.

So is this really a 14-only regression, or is 13-branch already suspicious?

[Bug ada/110488] New: Legal deferred constant rejected

[lo50goa3 at duck dot com via Gcc-bugs]

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

Bug ID: 110488
   Summary: Legal deferred constant rejected
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lo50goa3 at duck dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55429=edit
Minimal reproducer

Xubuntu 23.04 X86_64

GNAT 13 installed with

apt install gnat-13

Compiling the attached with

gnatmake -gnatc b_strings_prob.ads

gives

b_strings_prob.ads:11:04: error: subtype does not statically match deferred
declaration at line 4
gnatmake: "b_strings_prob.ads" compilation error

According to Randy Brukardt, ARG member and ARM editor, this is legal Ada and
should be accepted.

Output of

x86_64-linux-gnu-gcc-13 -v

Using built-in specs.
COLLECT_GCC=x86_64-linux-gnu-gcc-13
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13-20230320-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-oz92yP/gcc-13-13-20230320/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-oz92yP/gcc-13-13-20230320/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230320 (experimental) [master r13-6759-g5194ad1958c]
(Ubuntu 13-20230320-1ubuntu1)

[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector

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

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

--- Comment #18 from Jonathan Wakely  ---
That's not a crash, it's a warning. And it looks like a separate problem, since
it comes from vector::reserve not vector::insert. Please file a new bug for it
instead.

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|invalid wide Boolean value  |[12/13/14 Regression]
   ||invalid wide Boolean value
 Target||aarch64-linux-gnu
   Target Milestone|--- |12.4

[Bug tree-optimization/110487] invalid wide Boolean value

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

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

--- Comment #2 from Andrew Pinski  ---
Part of the issue is what does TYPE_PRECISION on BOOLEAN_TYPE really mean. 
there are many more of these issues all over GCC about boolean types assuming
being TYPE_PRECISION == 1 even and such.

[Bug tree-optimization/110487] invalid wide Boolean value

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Keywords||wrong-code
   Last reconfirmed||2023-06-29

--- Comment #1 from Andrew Pinski  ---
Applying pattern match.pd:4705, gimple-match-10.cc:15878
gimple_simplified to _38 = () _16;
_66 = -_38;
Global Exported: _66 = [irange]  [-1, 0]
Folded into: _66 = -_38;


/* a ? -1 : 0 -> -a.  No need to check the TYPE_PRECISION not being 1
   here as the powerof2cst case above will handle that case correctly.  */
(if (INTEGRAL_TYPE_P (type) && integer_all_onesp (@1))
 (negate (convert (convert:boolean_type_node @0))


I guess is mine 

[Bug tree-optimization/110487] New: invalid wide Boolean value

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

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

Bug ID: 110487
   Summary: invalid wide Boolean value
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vrp2 pass generates IR where a  may get the value 1 (in
addition to the valid 0 and -1).

This can be seen in gcc.c-torture/compile/pr53410-1.c

  int *a, b, c, d;

  void
  foo (void)
  {
for (; d <= 0; d++)
  b &= ((a || d) ^ c) == 1;
  }

when compiled as "gcc -O3". The vectorizer has created (correct) code

  _Bool _16;
   _66;
  ...
  _16 = a.1_1 != 0B;
  _66 = _16 ? -1 : 0;

which then is transformed by vrp2 to

  _Bool _16;
   _38;
   _66;
  ...
  _16 = a.1_1 != 0B;
  _38 = () _16;
  _66 = -_38;

_16 can be both true/false depending on the values of some global variables, so
_38 has the value 0 or -1, and _66 has the value 0 or 1.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #27 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #26)
> It is included here:
> https://www.desy.de/~reuter/downloads/repro002.tar.xz
> I am working on a smaller example right now.

Good.  I can reproduce the failure, but here's what others need to know:

- I have to

rm -f nlo_9_p2.i1.phs nlo_9_p2.m1.vg2

  each time *before* running the test. ???

- I am using the modification to rng_stream_sub.f90 from comment#24 with the
  printout added

- I am switching between

  res = mod (x1, x2)

and
  res = x1 - int(x1/x2) * x2

- I am disabling optimization completely for this file and added to Makefile:

rng_stream_sub.o: rng_stream_sub.f90
$(FC) $(FCFLAGS) -c $< -O0 -fdump-tree-original -fdump-tree-optimized


which gives (v1 is with intrinsic mod, v2 is with explicitly coded mod):

--- rng_stream_sub.f90.005t.original.v1 2023-06-29 20:44:58.148284991 +0200
+++ rng_stream_sub.f90.005t.original.v2 2023-06-29 20:45:45.408160849 +0200
@@ -3,7 +3,7 @@
 {
   real(kind=8) res;

-  res = __builtin_fmod (*x1, *x2);
+  res = *x1 - (real(kind=8)) (integer(kind=4)) (*x1 / *x2) * *x2;
   return res;
 }

as expected.  The dump-tree-optimized looks unsuspicious to me.

[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Rogério de Souza Moraes  
---
Created attachment 55428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55428=edit
Preprocessed file for GCC 13.1.0 bug

This is the preprocessed file (*.i*) that triggers the bug reported by Rogerio
on GCC v13.1.0.

[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector

[rogerio.souza at gmail dot com via Gcc-bugs]

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

Rogério de Souza Moraes  changed:

   What|Removed |Added

 CC||rogerio.souza at gmail dot com

--- Comment #16 from Rogério de Souza Moraes  
---
I have a similar issue that happens using GCC v13.1.0 on Red Hat 7.9
3.10.0-1160.90.1.el7.x86_64.

The compiler configuration settings are:

/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/gcc
COLLECT_LTO_WRAPPER=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/libexec/gcc/x86_64-redhat-linux/13.1.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: /tmp/gcc-v13.1.0d1rh74_lnx86/gcc.source/configure
--prefix=/grid/common/test/gcc-v13.1.0d1rh74_lnx86 --with-pkgversion=Cadence
--disable-libgcj --enable-threads=posix --enable-shared --with-system-zlib
--enable-checking=release --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,fortran --disable-nls --enable-gnu-unique-object
--enable-bootstrap --enable-plugin --enable-linker-build-id
--enable-gnu-indirect-function --enable-install-libiberty --with-tune=generic
--enable-initfini-array --enable-multiarch --with-linker-hash-style=gnu
--with-ld=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/ld
--with-as=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/as
--build=x86_64-redhat-linux --host=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.1.0 (Cadence)

=

The command line to reproduce the crash and the compiler output:

/opt/gcc-v13.1.0d1rh74_lnx86/bin/gcc -c -fpic  -std=c++2b -pthread
-D_GLIBCXX_USE_CXX11_ABI=1 -Wstrict-aliasing=3 -O3 -Wall -Werror -DNDEBUG
-Wstrict-aliasing=3  -Wextra   -DET7 -DETX=7
-DCMG_QT_VERSION='"MAIN_WXE_23.05.539.d000-Z2, VEngineering"'  -DLINUX2   
-I/opt/ua/3party/capnproto -I/opt/ua/Framework -I. -I.. -I/opt/ap/include
-I/grid/cva/p4/eugene/gcc_wxe/ua/include -I/opt/ua/3party/xlm_inst/include 
-MMD ../radbSerializer.C

In file included from
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/string:51,
 from
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/stdexcept:39,
 from ../radbSerializer.C:9:
In static member function 'static constexpr _Up* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
long unsigned int; _Up = long unsigned int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:506:3 ,
inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:533:4 ,
inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:540:31,   
inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = long unsigned
int*; _OI = long unsigned int*]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:633:7,
inlined from 'constexpr std::vector::iterator
std::vector::_M_copy_aligned(const_iterator, const_iterator,
iterator) [with _Alloc = std::allocator]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_bvector.h:1303:28,
inlined from 'constexpr void std::vector::_M_reallocate(size_type) [with _Alloc = std::allocator]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/vector.tcc:851:40,
inlined from 'constexpr void std::vector::reserve(size_type)
[with _Alloc = std::allocator]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_bvector.h:1091:17,
inlined from 'radb::ScopesSerializer::ScopesSerializer()' at
../radbSerializer.C:25:24:
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:437:30:
error: 'void* __builtin_memmove(void*, const void*, long unsigned int)' forming
offset 8 is out of the bounds [0, 8] [-Werror=array-bounds=]
  437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~
In static member function 'static constexpr _Up* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
long unsigned int; _Up = long unsigned int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:506:3 ,
inlined 

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #26 from Jürgen Reuter  ---
(In reply to anlauf from comment #25)

> Unfortunately, there is no main.f90, which is needed to build whizard.
>

Indeed, sorry, cf. below

> The Makefile needs to be modified to take into account that pythia.f
> needs preprocessing, e.g.:
> 
> %.o: %.f
>   $(FC) $(FCFLAGS) -c $< -cpp
> 
> Furthermore, one needs to compile serially; parallel make does not seem to
> be supported.

I changed the pythia.f to make the preprocessing unnecessary.

> 
> Can you please provide the missing file?

It is included here:
https://www.desy.de/~reuter/downloads/repro002.tar.xz
I am working on a smaller example right now.

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
It appears that the issue could be studied with the following code:

program p
  implicit none
  integer :: a = 65
  call val ("A", char(a))
contains
  subroutine val (x, c)
character(kind=1), intent(in) :: x  ! control: pass by reference
character(kind=1), value  :: c
print *, "by reference(kind=1): ", x
print *, "by value(kind=1): ", c
if (c /= x)   stop 1
  end
end

If this works on LE with -m64 and -m32, and also on BE with -m64,
why would it fail on BE with -m32 ?

[Bug rtl-optimization/110391] [12/13/14 Regression] wrong code at -O2 and -O3 with "-fsel-sched-pipelining -fselective-scheduling2" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #4 from Zhendong Su  ---
Another likely related reproducer that affects 9.* and later.

Compiler Explorer: https://godbolt.org/z/8vTd7rx6d

[641] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230629 (experimental) [master r14-924-gd709841ae0f] (GCC) 
[642] % 
[642] % gcctk -O2 -fselective-scheduling2 -fno-tree-pre small.c
[643] % ./a.out
34
[644] % gcctk -O2 small.c
[645] % ./a.out
1
[646] % cat small.c
int printf(const char *, ...);
int a, b;
int main() {
  unsigned int c = 0;
  unsigned char d = 33;
  for (; a < 1; a++) {
unsigned int e = 0;
unsigned char f = 0;
if (c < 1) {
  e = f = d;
  c = b * 4;
  if (c < b)
printf("%ld", (long)d);
  if (!f)
break;
}
c = e;
d = f;
  }
  printf("%d\n", a);
  return 0;
}

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #24)
> Here is a first reproducer without the need for OCaml, unfortunately a bit
> too big to be uploaded, here is the link:
> https://www.desy.de/~reuter/downloads/repro001.tar.xz
> the tarball contains Fortran files that compile to two binaries, ./whizard
> and ./whizard_check.

Unfortunately, there is no main.f90, which is needed to build whizard.

The Makefile needs to be modified to take into account that pythia.f
needs preprocessing, e.g.:

%.o: %.f
$(FC) $(FCFLAGS) -c $< -cpp

Furthermore, one needs to compile serially; parallel make does not seem to
be supported.

Can you please provide the missing file?

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

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Qing Zhao :

https://gcc.gnu.org/g:070a6bf0bdc6761ad77ac97404c98f00a7007d54

commit r14-2197-g070a6bf0bdc6761ad77ac97404c98f00a7007d54
Author: Qing Zhao 
Date:   Thu Jun 29 17:07:26 2023 +

Update documentation to clarify a GCC extension [PR c/77650]

on a structure with a C99 flexible array member being nested in
another structure.

"The GCC extension accepts a structure containing an ISO C99 "flexible
array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.

 There are two situations:

   * A structure containing a C99 flexible array member, or a union
 containing such a structure, is the last field of another structure,
 for example:

  struct flex  { int length; char data[]; };
  union union_flex { int others; struct flex f; };

  struct out_flex_struct { int m; struct flex flex_data; };
  struct out_flex_union { int n; union union_flex flex_data; };

 In the above, both 'out_flex_struct.flex_data.data[]' and
 'out_flex_union.flex_data.f.data[]' are considered as flexible
 arrays too.

   * A structure containing a C99 flexible array member, or a union
 containing such a structure, is not the last field of another
structure,
 for example:

  struct flex  { int length; char data[]; };

  struct mid_flex { int m; struct flex flex_data; int n; };

 In the above, accessing a member of the array
'mid_flex.flex_data.data[]'
 might have undefined behavior.  Compilers do not handle such a case
 consistently, Any code relying on this case should be modified to
ensure
 that flexible array members only end up at the ends of structures.

 Please use the warning option '-Wflex-array-member-not-at-end' to
 identify all such cases in the source code and modify them.  This
extension
 is now deprecated.
"

PR c/77650

gcc/c-family/ChangeLog:

* c.opt: New option -Wflex-array-member-not-at-end.

gcc/c/ChangeLog:

* c-decl.cc (finish_struct): Issue warnings for new option.

gcc/ChangeLog:

* doc/extend.texi: Document GCC extension on a structure containing
a flexible array member to be a member of another structure.

gcc/testsuite/ChangeLog:

* gcc.dg/variable-sized-type-flex-array.c: New test.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55416|0   |1
is obsolete||

--- Comment #72 from Jakub Jelinek  ---
Created attachment 55427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55427=edit
gcc14-bitint-wip.patch

Testsuite coverage for shifts and />= comparisons and associated fixes
discovered by that.

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

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Iain Sandoe from comment #10)
> do all the other (I guess non-embedded) platforms now have init priority
> support?

It's OK if they don't, as long as (1) the attribute tells the truth, and (2)
clang doesn't support it where gcc doesn't.

It's fine to have no init_priority support, the library handles that OK.

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

[bmeng.cn at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Bin Meng  ---
I can't get the build to pass with the same configure scripts on current GCC
HEAD :(

--host=x86_64-linux-gnu --build=aarch64-linux --target=riscv64-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-13.1.0-nolibc/riscv64-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
--with-static-standard-libraries

Error below:

Checking multilib configuration for libgcc...
make[2]: Entering directory '/home/bmeng/git/gcc/riscv64-linux/libgcc'
Makefile:183: ../.././gcc/libgcc.mvars: No such file or directory
make[2]: *** No rule to make target '../.././gcc/libgcc.mvars'.  Stop.
make[2]: Leaving directory '/home/bmeng/git/gcc/riscv64-linux/libgcc'
make[1]: *** [Makefile:12855: all-target-libgcc] Error 2

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

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

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Patrick Palka from comment #9)
> (In reply to Jonathan Wakely from comment #1)
> > Patrick, we talked about this and IIRC your suggestion was to move the
> > __has_attribute check into configure, so that it depends on GCC, not on
> > whichever compiler happens to include  later.
> 
> Yes, sorry for letting this issue slip through the cracks.  It makes sense
> to fix this by simply disabling the  optimization on macOS as you
> suggested, and perhaps worry about a configure-time check only if it turns
> out another platform hits this issue.

do all the other (I guess non-embedded) platforms now have init priority
support?
(I think maybe something was added to AIX recently, and I suppose that Solaris
when using bfd ld, at least would).

the solution is a reasonable band-aid (given that a patch to make init priority
work on Darwin is some way in the future).

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

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Target Milestone|--- |13.2
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #9 from Patrick Palka  ---
(In reply to Jonathan Wakely from comment #1)
> Patrick, we talked about this and IIRC your suggestion was to move the
> __has_attribute check into configure, so that it depends on GCC, not on
> whichever compiler happens to include  later.

Yes, sorry for letting this issue slip through the cracks.  It makes sense to
fix this by simply disabling the  optimization on macOS as you
suggested, and perhaps worry about a configure-time check only if it turns out
another platform hits this issue.

[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #12 from Christophe Lyon  ---
The new testcase (gcc.dg/vect/pr110381.c) fails:
FAIL: gcc.dg/vect/pr110381.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr110381.c execution test

on arm-linux-gnueabihf configured with --with-float=hard
--with-fpu=neon-fp-armv8 --with-mode=thumb --with-arch=armv8-a

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

[sascha.scandella at dentsplysirona dot com via Gcc-bugs]

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

--- Comment #8 from Sascha Scandella  ---
I've tested the proposed solution ...

#if !__has_attribute(__init_priority__) || defined __APPLE__

... and it works as expected. I had also done something similar before, so I
wasn't that surprised.

Let me know if you need more information from my side.

Who will fix the bug?

Thank you for your help and support! I appreciate it very much.

[Bug tree-optimization/110458] [14 Regression] -Warray-bounds=2 new false positive

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|-Warray-bounds=2 new false  |[14 Regression]
   |positive|-Warray-bounds=2 new false
   ||positive
   Target Milestone|--- |14.0

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

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

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

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

[Bug tree-optimization/110475] [14 Regression] Wrong code at -O2/3/s on x86_64-pc-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

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

  _10 = a.2_2 > 1;
  _11 = (long long unsigned int) _10;
  _12 = iftmp.3_5 | _11;

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

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I just tried r14-2190-ge972bdce61cc52 on another BE machine and got:

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

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

Backtrace for this error:
#0  0xf7f603f3 in ???
#1  0x1fcc in ???
#2  0x1adb in ???
#3  0xfa5a81f in ???
#4  0xfa5aa5f in ???
#5  0x in ???
FAIL: gfortran.dg/value_9.f90   -Os  execution test

[Bug c++/110484] Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after optimizing the rnreg, directly replaced other registers with the $r22 register, so that the value of the

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao  ---
Hmm, I don't quite get the problem.  r22 is a saved register, so if it's
clobbered w/o being saved, the issue will be a wrong-code, instead of a
missed-optimization?

[Bug c/101537] -Wconversion false positive in ternary and |=

[wolter.hellmundvega at tevva dot com via Gcc-bugs]

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

--- Comment #9 from wolter.hellmundvega at tevva dot com ---
Will the current fix be released when the C++ FE is patched as well or perhaps
before that?

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
Should be fixed now.

[Bug rtl-optimization/110479] Unnecessary register move

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to Thomas Koenig from comment #0)
> 
> > movl%edi, %ecx
> 
> This one? It is needed because SAL wants its count argument in %cl and first
> argument is passed in %edi (mandated by x86_64 ABI).
> 
> With -mbmi2, one gets:
> 
> shrl$10, %edi
> movl$1, %eax
> andl$3, %edi
> addl$3, %edi
> shlx%edi, %eax, %eax
> ret

Hm, you're right.  The intricacies of x86...

Closing.

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

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

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

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

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

commit r14-2191-gff29ee6af88f709e08ee467869d8c1b13889a724
Author: Jonathan Wakely 
Date:   Wed Jun 28 19:10:29 2023 +0100

libstdc++: Do not use off64_t in calls to copy_file_range [PR110462]

Although the copy_file_range(2) man page shows the arguments as off64_t*
that is not portable. For musl there is no off64_t type, as off_t is
always 64-bit. Use the loff_t type which is always 64-bit even if off_t
isn't. We could just use off_t because the filesystem library is
compiled with _FILE_OFFSET_BITS=64, but loff_t is the more correct type
for this interface.

libstdc++-v3/ChangeLog:

PR libstdc++/110462
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check that
copy_file_range can be called with loff_t* arguments.
* configure: Regenerate.
* src/filesystem/ops-common.h (copy_file_copy_file_range):
Use loff_t for offsets.

[Bug middle-end/110472] 60% slowdown with fwrapv when using openmp

[ryanpholt at me dot com via Gcc-bugs]

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

--- Comment #2 from Ryan Holt  ---
(In reply to Andrew Pinski from comment #1)
> I think it is just wrong iv-opt choices.
> 
> Works just fine on aarch64-linux-gnu too:
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
> -fopenmp
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
> time: 15.191220
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
> -fopenmp -fwrapv
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
> time: 18.854280
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
> time: 16.705876
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
> -fopenmp
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
> time: 17.491387
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
> time: 17.519264

I forgot to explicitly call out that I can only reproduce the big speedup
without fwrapv when compiling with -O3. I noticed you were using O2 on
aarch64-linux-gnu.

[Bug c++/110486] gcc rejects constant expression with consteval lambda

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

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

--- Comment #1 from Andrew Pinski  ---
The question is the second lamdba implicitly consteval or not ...

If it is, then the bug is dealing with that. That is adding consteval to the
second lamdba allows GCC to accept the code.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Jonathan Wakely from comment #9)
> > One solution would be to just add the declaration to the header, and adjust
> > the exports so this new symbol is exported at GLIBCXX_3.4.32 not
> > GLIBCXX_3.4.31
> 
> N.B. this is what we do for glibc-based linux targets. The symbol is present
> in the library even when glibc doesn't provide strtof128. This means that we
> don't have a different set of exported symbols when built on old or new
> glibc.

Actually that's not true, we always define it in the library but for old glibc
we *don't* declare it in the header. So to make Solaris x86 consistent we'd
just want to fix up the symbol version.

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[wolter.hellmundvega at tevva dot com via Gcc-bugs]

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

wolter.hellmundvega at tevva dot com changed:

   What|Removed |Added

 CC||wolter.hellmundvega at tevva 
dot c
   ||om

--- Comment #14 from wolter.hellmundvega at tevva dot com ---
I'm not sure this is fixed, please correct me if wrong, but

#include 
#include 

int main(void)
{
const uint8_t u = 0U;
const uint8_t y = (uint8_t) ~u;

return ((uint8_t) u != (uint8_t) ~y);
}

gives warning

test.c: In function ‘main’:
test.c:9:25: warning: comparison of promoted bitwise complement of an
unsigned value with unsigned [-Wsign-compare]
9 | return ((uint8_t) u != (uint8_t) ~y);
  | ^~

Does this not mean that this issue is still present?

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This affects aarch64 too:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620335.html
> And probably other targets where long double uses binary128 rep.

For the record, this is fixed for aarch64 (by the same commit that fixed it for
solaris sparc):
https://gcc.gnu.org/pipermail/libstdc++/2023-June/056246.html

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #9)
> One solution would be to just add the declaration to the header, and adjust
> the exports so this new symbol is exported at GLIBCXX_3.4.32 not
> GLIBCXX_3.4.31

N.B. this is what we do for glibc-based linux targets. The symbol is present in
the library even when glibc doesn't provide strtof128. This means that we don't
have a different set of exported symbols when built on old or new glibc.

If Solaris is ever going to get support for strtof128 and other _Float128
support then that is probably what we should do here as well.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #24 from Jürgen Reuter  ---
Here is a first reproducer without the need for OCaml, unfortunately a bit too
big to be uploaded, here is the link:
https://www.desy.de/~reuter/downloads/repro001.tar.xz
the tarball contains Fortran files that compile to two binaries, ./whizard and
./whizard_check.
After compilation, perform ./whizard r1.sin 
to run the program. There will be NaNs generated in our RNG stream random
number generator. They originate from an erroneous optimization by the
gcc/gfortran tree-optimizer. This code resides in rng_stream_sub.f90, in the
function mult_mod. Eliminating the intrinsic function mod and explicitly doing
the calculation makes the problem go away.
  function mult_mod (a, b, c, m) result (v)
real(default), intent(in) :: a
real(default), intent(in) :: b
real(default), intent(in) :: c
real(default), intent(in) :: m
real(default) :: v
integer :: a1
real(default) :: a2
v = a * b + c
if (v >= two53 .or. v <= -two53) then
   a1 = int (a / two17)
   a2 = a - a1 * two17
   v = mmm_mod (a1 * b, m)
   v = v * two17 + a2 * b + c
end if
v = mmm_mod (v, m)
if (v < 0.0_default) v = v + m
  contains
elemental function mmm_mod (x1, x2) result (res)
  real(default), intent(in) :: x1, x2
  real(default) :: res
  res = x1 - int(x1/x2) * x2
end function mmm_mod
  end function mult_mod

[Bug c++/110486] New: gcc rejects constant expression with consteval lambda

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 110486
   Summary: gcc rejects constant expression with consteval lambda
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

GCC rejects the following, while MSVC and Clang compile fine.
Not sure if the code is well-formed.

#include 

constexpr auto g = []() consteval {
  std::vector v;
  v.push_back(0);
  return v;
};

constexpr auto l = [] {
  constexpr auto sz = g().size();
  return 0;
}();

https://godbolt.org/z/WrTx3bn3r

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #9 from Jonathan Wakely  ---
Thanks for the quick response!

For x86 both these conditions are false:

#if defined(__STDCPP_FLOAT128_T__) &&
defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128)
...
#elif defined(__STDCPP_FLOAT128_T__) && defined(_GLIBCXX_HAVE_FLOAT128_MATH)
...
#endif

and that means we the header doesn't declare from_chars for _Float128.

With my changes for PR 109921 (r14-1431) that from_chars overload gets defined
in the library, causing the abi-check error. But if it's not present in the
header, it's useless to define it in the library, it can't be called.

One solution would be to just add the declaration to the header, and adjust the
exports so this new symbol is exported at GLIBCXX_3.4.32 not GLIBCXX_3.4.31

Alternatively, I need to find the right set of conditions to suppress the
definition in the library.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #8 from Rainer Orth  ---
(In reply to Jonathan Wakely from comment #6)
> This is going to be hard for me to figure out without access to a Solaris
> x86 system.

There's hope that at least one, maybe two, Solaris 11.4/x86 systems can be
added to the cfarm.  As always, the primary problem is politics...

> Could you please attach the output of this command using GCC trunk on
> solaris x86?
> 
> g++ -std=c++23 -include charconv -x c++ /dev/null -E -dD

Sure, done.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #7 from Rainer Orth  ---
Created attachment 55426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55426=edit
32-bit i386-pc-solaris2.11 charconv.ii

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #6 from Jonathan Wakely  ---
This is going to be hard for me to figure out without access to a Solaris x86
system.

Could you please attach the output of this command using GCC trunk on solaris
x86?

g++ -std=c++23 -include charconv -x c++ /dev/null -E -dD

[Bug rtl-optimization/110479] Unnecessary register move

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to Thomas Koenig from comment #0)

> movl%edi, %ecx

This one? It is needed because SAL wants its count argument in %cl and first
argument is passed in %edi (mandated by x86_64 ABI).

With -mbmi2, one gets:

shrl$10, %edi
movl$1, %eax
andl$3, %edi
addl$3, %edi
shlx%edi, %eax, %eax
ret

[Bug tree-optimization/110485] New: vectorizing simd clone calls without loop masking applied

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

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

Bug ID: 110485
   Summary: vectorizing simd clone calls without loop masking
applied
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

#include 

double a[1024];
double b[1024];

void foo (int n)
{
  for (int i = 0; i < n; ++i)
a[i] = pow (b[i], 71.2);
}

with -Ofast -march=znver4 --param vect-partial-vector-usage=1 gets us
the following OK main loop

.L4:
vmovapd b(%rbx), %zmm0
vmovapd -112(%rbp), %zmm1
addq$64, %rbx
call_ZGVeN8vv_pow
vmovapd %zmm0, a-64(%rbx)
cmpq%r13, %rbx
jne .L4

but the following vectorized masked epilogue:

movl%r12d, %eax
andl$-8, %eax
testb   $7, %r12b
je  .L13
.L3:
subl%eax, %r12d
movl%eax, %edx
vmovapd -112(%rbp), %zmm1
vpbroadcastw%r12d, %xmm0
leaq0(,%rdx,8), %rbx
vpcmpuw $6, .LC2(%rip), %xmm0, %k1
vmovapd b(,%rdx,8), %zmm0{%k1}{z}
kmovb   %k1, -113(%rbp)
call_ZGVeN8vv_pow
kmovb   -113(%rbp), %k1
vmovapd %zmm0, a(%rbx){%k1}

so we simply call _ZGVeN8vv_pow without any masking applied.  That's
possibly OK since we use zero-masking and thus actual masked argument
lanes are zero but it seems this isn't the expected behavior for
vectorizable_simd_clone_call.  Instead it should probably unconditionally
set LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) to false?

Is there a way to query which SIMD clone is "happy" with zero arguments
and thus for example with -ffast-math would be OK to run unmasked?

[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #12 from Patrick Palka  ---
Started with r12-3559-g22806064a67cf3

[Bug target/110457] Unnecessary movsx eax, dil

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||xry111 at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-06-29

--- Comment #5 from Xi Ruoyao  ---
I guess we need an ABI expert to clarify things.

[Bug c++/110484] Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after optimizing the rnreg, directly replaced other registers with the $r22 register, so that the value of the

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---

The following code modification problem can be solved：

--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1112,7 +1112,9 @@ loongarch_first_stack_step (struct loongarch_frame_info
*frame)
 static void
 loongarch_emit_stack_tie (void)
 {
-  emit_insn (gen_stack_tie (Pmode, stack_pointer_rtx,
hard_frame_pointer_rtx));
+  emit_insn (gen_stack_tie (Pmode, stack_pointer_rtx,
+   frame_pointer_needed ? hard_frame_pointer_rtx
+   : stack_pointer_rtx));
 }

[Bug c++/110484] New: Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after optimizing the rnreg, directly replaced other registers with the $r22 register, so that the value of

[chenglulu at loongson dot cn via Gcc-bugs]

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

Bug ID: 110484
   Summary: Spec2017 541 after adding the
'-flto-fomit-frame-pointer' optimization, after
optimizing the rnreg, directly replaced other
registers with the $r22 register, so that the value of
the $r22 register was destroyed without being saved.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenglulu at loongson dot cn
  Target Milestone: ---
Target: loongarch64-*-linux

Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after
optimizing the rnreg, directly replaced other registers with the $r22 register,
so that the value of the $r22 register was destroyed without being saved.

Through debugging, it was found that when compiling the SGFTree .cpp file, the
load_from_file function generated the following template in pro_and_epilogue
optimization:
(insn 782 781 783 61 (set (mem:BLK (scratch) [0  A8])
(unspec:BLK [
(reg/f:DI 3 $r3)
(reg/f:DI 22 $r22)
] UNSPEC_TIE)) "SGFTree.cpp":115:1 -1
 (nil))
This results in $r22 being present in the load_from_file's reg ever live list
thereafter.　However, this is not desirable when the $r22 register is not used
in the function.

[Bug c++/110476] constexpr floating point regression with -std=c++XX

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

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

--- Comment #3 from Jonathan Wakely  ---
I think the justification for GCC's behaviour is that "representable value" is
to be interpreted in the context of FLT_EVAL_METHOD, so it means representable
as double (for FLT_EVAL_METHOD==1) or long double (for 2).

"its type" is only mentioned in the first sentence, which doesn't apply to IEEE
types because they support infinities and so all values are in the range of
representable values. The second sentence doesn't mention "its type".

[Bug analyzer/110483] Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug analyzer/110483] New: Several gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL

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

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

Bug ID: 110483
   Summary: Several gcc.dg/analyzer/out-of-bounds-diagram-*.c
tests FAIL
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11, pru-unknown-elf,
powerpc-ibm-aix7.2.5.0, avr-unknown-none

Several of the new gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL on
Solaris/SPARC (32 and 64-bit):

+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-13.c (test for excess errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-13.c 2 blank line(s) in output
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-13.c expected multiline pattern
lines 17-42
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-15.c (test for excess errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-15.c 2 blank line(s) in output
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-15.c expected multiline pattern
lines 16-41
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-4.c (test for excess errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-4.c 2 blank line(s) in output
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-4.c expected multiline pattern
lines 23-44
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-ascii.c (test for excess errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-ascii.c 2 blank line(s) in
output
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-ascii.c expected multiline
pattern lines 16-39
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-unicode.c (test for excess
errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-unicode.c 2 blank line(s) in
output
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-unicode.c expected multiline
pattern lines 16-41
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-7.c (test for excess errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-7.c 2 blank line(s) in output
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-7.c expected multiline pattern
lines 14-35

I also see gcc-testresults reports for several other targets, but it's
difficult
to the if that's the same issue without the actual gcc.log.

E.g. for

FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-unicode.c (test for excess
errors)

the log shows

Excess errors:
  ┌─┬─┬─┬┬┐┌┬┬┬┬┬┬┬──┐
  │ [0] │ [0] │ [0] │[0] │[0] ││[0] │[0] │[0] │[0] │[0] │[0] │[0] │ [0]  │
  ├─┼─┼─┼┼┤├┼┼┼┼┼┼┼──┤
  │0xe6 │0x96 │0x87 │0xe5│0xad││0x97│0xe5│0x8c│0x96│0xe3│0x81│0x91│ 0x00 │
  ├─┴─┴─┼┴┴┴┼┴┴┼┴┴┼──┤
  │ U+6587  │U+5b57 │U+5316│U+3051│U+│
  ├─┼───┼──┼──┼──┤
  │   文│  字   │  化  │  け  │ NUL  │
  ├─┴───┴──┴──┴──┤
  │  string literal (type: 'char[13]')   │
  └──┘
 │ │ │││ │││││││ │   
 │ │ │││ │││││││ │
 v v vvv vvvvvvv v   
  ┌─┬┬┐┌─┐
  │ [0] │  ...   │[4] ││ │
  ├─┴┴┤│after valid range│
  │  'buf' (type: 'char[5]')  ││ │
  └───┘└─┘
  ├─┬─┤├┬┤
│   │
   ╭┴╮╭─┴─╮
   │capacity: 5 bytes││overflow of 8 bytes│
   ╰─╯╰───╯

while the test expects

  │ [0] │ [1] │ [2] │[3] │[4] ││[5] │[6] │[7] │[8] │[9] │[10]│[11]│ [12] │

above.