[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html

[Bug target/109748] RISC-V: Mis code gen for the RVV intrinsic VSETVL

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #4 from Kito Cheng  ---
Should be resolved at trunk.

[Bug target/109748] RISC-V: Mis code gen for the RVV intrinsic VSETVL

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:8421f279e9eb00a2342ee3630dcdaf735b734fe8

commit r14-538-g8421f279e9eb00a2342ee3630dcdaf735b734fe8
Author: Juzhe-Zhong 
Date:   Fri May 5 22:12:39 2023 +0800

RISC-V: Fix incorrect demand info merge in local vsetvli optimization
[PR109748]

This patch is fixing my recent optimization patch:
   
https://github.com/gcc-mirror/gcc/commit/d51f2456ee51bd59a79b4725ca0e488c25260bbf

In that patch, the new_info = parse_insn (i) is not correct.
Since consider the following case:

vsetvli a5,a4, e8,m1
..
vsetvli zero,a5, e32, m4
vle8.v
vmacc.vv
...

Since we have backward demand fusion in Phase 1, so the real demand of
"vle8.v" is e32, m4.
However, if we use parse_insn (vle8.v) = e8, m1 which is not correct.

So this patch we change new_info = new_info.parse_insn (i)
into:

vector_insn_info new_info = m_vector_manager->vector_insn_infos[i->uid ()];

So that, we can correctly optimize codes into:

vsetvli a5,a4, e32, m4
..
.. (vsetvli zero,a5, e32, m4 is removed)
vle8.v
vmacc.vv

Since m_vector_manager->vector_insn_infos is the member variable of
pass_vsetvl class.
We remove static void function "local_eliminate_vsetvl_insn", and make it
as the member function
of pass_vsetvl class.

PR target/109748

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (local_eliminate_vsetvl_insn):
Remove it.
(pass_vsetvl::local_eliminate_vsetvl_insn): New function.

gcc/testsuite/ChangeLog:

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

[Bug gcov-profile/93680] [GCOV] "do-while" structure in case statement leads to incorrect code coverage

[yinyuefengyi at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Xionghu Luo (luoxhu at gcc dot gnu.org)  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616123.html

[Bug tree-optimization/85501] missed if-conversion / phiopt trick

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/107888] [12/13/14 Regression] Missed min/max transformation in phiopt due to VRP

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
So for the second testcase in comment #0 (with __builtin_trap replaced with
__builtin_unreachable so at least we have ranges):

  # RANGE [irange] int [5, +INF] NONZERO 0x7fff
  intD.9 ab_2(D) = abD.2773;
  # RANGE [irange] int [-INF, 6]
  intD.9 bb_3(D) = bbD.2774;
  intD.9 cD.2779;

__BB(2):
  if (ab_2(D) >= bb_3(D))
goto __BB4;
  else
goto __BB3;

__BB(3):

__BB(4):
  # RANGE [irange] int [5, +INF] NONZERO 0x7fff
  # c_1 = PHI 

We could detect (cond (a ge b) a CST) and look at CST to see if it is the same
as the max range of b and one more than the min of a. I think that will work.

That will also fix I think the first testcase.

Let me try to do that.
We won't get the __builtin_trap case correctly unless we do the full range
information inside phiopt; I will have to look into that later.

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

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

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

--- Comment #5 from Andrew Pinski  ---
I suspect the generated constructor for the clones is not getting the target
options on it like it should be ...

[Bug c++/109754] [ICE] internal compiler error: in coerce_template_parms, at cp/pt.cc:9183

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

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

--- Comment #5 from Andrew Pinski  ---
Reduced further:
```
template  class> class __meval{};
template 
  using __tuple_types_fn = decltype(_Fun(), [] {});
template 
struct __mexpand {
  template  using __f = __tuple_types_fn<_Fun, _MetaFn>;
};
auto t = __meval<__mexpand::template __f>();

```

Removing the lambda inside the decltype removes the ICE.

[Bug c++/109754] [ICE] internal compiler error: in coerce_template_parms, at cp/pt.cc:9183

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda

--- Comment #4 from Andrew Pinski  ---
I am getting a feeling this is another one of these lambda inside a decltype
issues.

[Bug target/109753] [13/14 Regression] pragma GCC target stops std::vector from compiling

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #3)
> I think the original problem must have been triggered by some libstdc++
> change.

Yes r13-3816-g9d549401ae8ab3 .

[Bug c++/109754] [ICE] internal compiler error: in coerce_template_parms, at cp/pt.cc:9183

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

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

--- Comment #3 from Marek Polacek  ---
cvise reduced it to

void declval();
template 
concept __same_as = requires { declval; };
template  _Tp __declval;
template  int __v;
using __msuccess = int;
template  struct __i;
template 
concept __ok = __same_as<_Arg, __msuccess>;
template 
concept _Ok = (__ok<_Args> && ...);
template  class> using __meval = __i<_Ok<>>;
template  using __minvoke = __meval<_Fn::template __f>;
template  struct __mexpand;
template  using __mapply = __minvoke<__mexpand<_List>>;
struct __msize;
template  using __call_result_t = decltype(0);
template 
using __tuple_types_fn = decltype(__declval<_Fun>, [] {});
template  struct __mexpand {
  template  using __f = __tuple_types_fn<_Fun, _MetaFn>;
};
template  long tuple_size_v = __v<__mapply<__msize, _Tuple>>;
template  using tuple = __call_result_t<>;
using T = tuple<>;
 static_assert(tuple_size_v< T >, "");


but that is probably invalid.

[Bug target/109753] [13/14 Regression] pragma GCC target stops std::vector from compiling

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #2)
> Reduced:
> ```
> #pragma GCC target("avx2")
> struct aa {
> __attribute__((__always_inline__)) aa() noexcept {}
> };
> aa _M_impl;
> ```

This started to give an error with

commit bef8491a658de9e8920acaeff6cb76ef4e946e2c
Author: Sriraman Tallam 
Date:   Tue Jun 18 22:45:03 2013 +

Emit errors when always_inline functions cannot be inlined in -O0 mode.

* tree-inline.c (expand_call_inline): Allow the error to be flagged
in early inline pass.
* ipa-inline.c (inline_always_inline_functions): Pretend
always_inline
functions are inlined during failures to flag an error.
* gcc.target/i386/inline_error.c: New test.
* gcc.c-torture/compile/pr44043.c: Fix test to expect an error.
* gcc.c-torture/compile/pr43791.c: Fix test to expect an error.

From-SVN: r200179

I think the original problem must have been triggered by some libstdc++ change.

[Bug c++/109754] [ICE] internal compiler error: in coerce_template_parms, at cp/pt.cc:9183

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

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

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

[Bug target/109690] bad SLP vectorization on zen

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

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

--- Comment #7 from Jan Hubicka  ---
Thanks a lot!  There however still seems to be problem with vectorization

On zen4 i now get:
jh@ryzen4:~/gcc/build/gcc> ./xgcc -B ./ -O2 -march=native slp.c  ; perf stat
./a.out

 Performance counter stats for './a.out':

  1,835.21 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
53  page-faults:u#   28.880 /sec
10,000,113,961  cycles:u #5.449 GHz
(83.22%)
31,284  stalled-cycles-frontend:u#0.00% frontend
cycles idle(83.23%)
64,771  stalled-cycles-backend:u #0.00% backend
cycles idle (83.43%)
 9,000,118,863  instructions:u   #0.90  insn per
cycle
  #0.00  stalled cycles per
insn (83.44%)
 2,999,980,507  branches:u   #1.635 G/sec  
(83.44%)
 1,445  branch-misses:u  #0.00% of all
branches (83.25%)

   1.835610338 seconds time elapsed

   1.835628000 seconds user
   0.0 seconds sys


jh@ryzen4:~/gcc/build/gcc> ./xgcc -B ./ -O2 -march=native -fno-tree-vectorize
slp.c  ; perf stat ./a.out

 Performance counter stats for './a.out':

  1,107.63 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
53  page-faults:u#   47.850 /sec
 6,000,774,547  cycles:u #5.418 GHz
(83.35%)
32,208  stalled-cycles-frontend:u#0.00% frontend
cycles idle(83.39%)
57,126  stalled-cycles-backend:u #0.00% backend
cycles idle (83.39%)
 7,999,763,446  instructions:u   #1.33  insn per
cycle
  #0.00  stalled cycles per
insn (83.39%)
 2,999,982,314  branches:u   #2.708 G/sec  
(83.39%)
   911  branch-misses:u  #0.00% of all
branches (83.09%)

   1.108032230 seconds time elapsed

   1.104079000 seconds user
   0.003985000 seconds sys


with -fno-tree-slp-vectorize I get:
loop:
.LFB0:
.cfi_startproc
salla(%rip)
salla+4(%rip)
salla+8(%rip)
ret

Which seem to be still faster. It is same if I do a[i]++
jh@ryzen4:~/gcc/build/gcc> ./xgcc -B ./ -O2 -march=native slp2.c  ; perf stat
./a.out

 Performance counter stats for './a.out':

  1,832.63 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
54  page-faults:u#   29.466 /sec
10,000,535,003  cycles:u #5.457 GHz
(83.19%)
36,576  stalled-cycles-frontend:u#0.00% frontend
cycles idle(83.34%)
75,320  stalled-cycles-backend:u #0.00% backend
cycles idle (83.41%)
 9,999,890,371  instructions:u   #1.00  insn per
cycle
  #0.00  stalled cycles per
insn (83.41%)
 2,999,935,610  branches:u   #1.637 G/sec  
(83.41%)
 1,447  branch-misses:u  #0.00% of all
branches (83.23%)

   1.833046939 seconds time elapsed

   1.833062000 seconds user
   0.0 seconds sys


jh@ryzen4:~/gcc/build/gcc> ./xgcc -B ./ -O2 -march=native slp2.c
-fno-tree-vectorize ; perf stat ./a.out

 Performance counter stats for './a.out':

  1,110.15 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
51  page-faults:u#   45.940 /sec
 6,000,096,821  cycles:u #5.405 GHz
(83.17%)
28,459  stalled-cycles-frontend:u#0.00% frontend
cycles idle(83.43%)
   

[Bug target/109753] [13/14 Regression] pragma GCC target stops std::vector from compiling

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Reduced:
```
#pragma GCC target("avx2")
struct aa {
__attribute__((__always_inline__)) aa() noexcept {}
};
aa _M_impl;
```

[Bug c++/109754] [ICE] internal compiler error: in coerce_template_parms, at cp/pt.cc:9183

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-05
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/109754] New: [ICE] internal compiler error: in coerce_template_parms, at cp/pt.cc:9183

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

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

Bug ID: 109754
   Summary: [ICE] internal compiler error: in
coerce_template_parms, at cp/pt.cc:9183
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

Created attachment 55012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55012=edit
result of -freport-bug including preprocessed source

similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475, but not using
coroutines

Repro: compile attached code with -std=c++20  

Result:

In file included from test.cpp:1:
stdexec/include/stdexec/__detail/__meta.hpp: In substitution of ‘template using __minvoke = stdexec::__meval<_Fn::template __f,
_Args ...> [with _Fn =
stdexec::__mexpand, const char*>(int&&,
stdexec::__tup::__coerce&&, const char*&&)
const > >; _Args = {stdexec::__msize}]’:
stdexec/include/stdexec/__detail/__meta.hpp:431:9:   required by substitution
of ‘template using __mapply =
stdexec::__minvoke, _Fn> [with _Fn =
stdexec::__msize; _List =
stdexec::__tuple, const char*>(int&&,
stdexec::__tup::__coerce&&, const char*&&)
const >]’
stdexec/include/stdexec/__detail/__tuple.hpp:491:47:   required from ‘const
std::size_t
stdexec::tuple_size_v, const char*>(int&&,
stdexec::__tup::__coerce&&, const char*&&)
const > >’
test.cpp:22:26:   required from here
stdexec/include/stdexec/__detail/__meta.hpp:233:9: internal compiler error: in
coerce_template_parms, at cp/pt.cc:9183
  233 |   using __minvoke = __meval<_Fn::template __f, _Args...>;
  | ^
0x6623b1 coerce_template_parms
../../src/gcc/cp/pt.cc:9183
0x818feb instantiate_alias_template
../../src/gcc/cp/pt.cc:21719
0x818feb tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15607
0x81c344 tsubst_decl
../../src/gcc/cp/pt.cc:14952
0x81815a instantiate_template_1
../../src/gcc/cp/pt.cc:21643
0x81908e instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.cc:21702
0x81908e instantiate_alias_template
../../src/gcc/cp/pt.cc:21740
0x81908e tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15607
0x81c344 tsubst_decl
../../src/gcc/cp/pt.cc:14952
0x81815a instantiate_template_1
../../src/gcc/cp/pt.cc:21643
0x81908e instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.cc:21702
0x81908e instantiate_alias_template
../../src/gcc/cp/pt.cc:21740
0x81908e tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15607
0x825bad tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:13517
0x8108fe tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:20055
0x8200e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:19491
0x81fe84 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x81fe84 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.cc:26653
0x7313c1 maybe_instantiate_decl(tree_node*)
../../src/gcc/cp/decl2.cc:5627
0x7375ef maybe_instantiate_decl(tree_node*)
../../src/gcc/cp/decl2.cc:5614
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/109753] [13/14 Regression] pragma GCC target stops std::vector from compiling

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

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

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

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.4|13.0

[Bug target/109753] [13/14 Regression] pragma GCC target stops std::vector from compiling

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.2

[Bug c++/109753] New: pragma GCC target stops std::vector from compiling

[magnus.hegdahl at gmail dot com via Gcc-bugs]

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

Bug ID: 109753
   Summary: pragma GCC target stops std::vector from compiling
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: magnus.hegdahl at gmail dot com
  Target Milestone: ---

Tested on g++ (GCC) 13.1.1 20230429 on x86-64 Linux

The following code doesn't compile without also enabling the target using
compile flags (like -mavx2). It did compile in GCC 12.2.0.

#pragma GCC target("avx2")

#include 

int main() {
  std::vector a;
}

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

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

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

--- Comment #17 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Alex Coplan from comment #14)
> > > I'm working on this.
> > 
> > I will rebase my WIP and push it somewhere - [ it has __has_feature and
> > __has_extension components .. but likely bit rotten with changes to libcpp ]
> > (sorry for being slow to do this - releases tie up all my Darwin time.
> 
> https://github.com/iains/gcc-git/tree/master-wip-has-extension
> 
> (it might not even build - I was hoping to have some time to refresh it -
> but better publish now in case it's useful in any way )

heh, despite that I've not done anything to it since 2019 actually it builds
and the tests pass - at least for C.  Anyway, see what you think and how it
lines up with your intended impl.

[Bug tree-optimization/109714] mesa/aux/draw_llvm: bogus "may be used uninitialized warning"

[david at ixit dot cz via Gcc-bugs]

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

--- Comment #9 from David Heidelberg (okias)  ---
Sorry, the previous command was for different bug (bugzilla weirdly switching
bugs when sending the comment, probably disabled JS :/ )

Here it's:

/usr/lib/gcc-snapshot/bin/gcc -Isrc/gallium/auxiliary/libgallium.a.p
-Isrc/gallium/auxiliary -I../src/gallium/auxiliary -Isrc/loader -I../src/loader
-I../src/gallium/include -Isrc -I../src -Iinclude -I../include
-I../src/gallium/auxiliary/util -Isrc/compiler/nir -I../src/compiler/nir
-I/usr/include/libdrm -I/usr/include/valgrind -I/usr/include/x86_64-linux-gnu
-fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64
-Wall -Winvalid-pch -std=c11 -O3 '-DPACKAGE_VERSION="23.2.0-devel"'
'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues;'
-DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_R300
-DHAVE_I915 -DHAVE_IRIS -DHAVE_SWRAST -DVIDEO_CODEC_VC1DEC=0
-DVIDEO_CODEC_H264DEC=1 -DVIDEO_CODEC_H264ENC=1 -DVIDEO_CODEC_H265DEC=1
-DVIDEO_CODEC_H265ENC=1 -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM
-DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM
-DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DALLOW_KCMP -DENABLE_SHADER_CACHE
-DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ
-DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT
-DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT
-DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE
-DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK
-DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED
-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_ALIAS
-DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128
-DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS
-DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAS_SCHED_H -DHAS_SCHED_GETAFFINITY
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H
-DHAVE_CET_H -DHAVE_SYS_INOTIFY_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
-DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK
-DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_POSIX_FALLOCATE -DHAVE_GNU_QSORT_R
-DHAVE_STRUCT_TIMESPEC -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_ISSIGNALING
-DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR
-DHAVE_DL_ITERATE_PHDR -DSUPPORT_INTEL_INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD
-DHAVE_COMPRESSION -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM
-DHAVE_LIBUDEV -DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="14.0.6"'
-DLLVM_IS_SHARED=1 -DDRAW_LLVM_AVAILABLE -DUSE_LIBELF -DHAVE_VALGRIND
-DMESA_EXECMEM -DHAVE_LIBUNWIND -DWL_HIDE_DEPRECATED -DHAVE_OPENMP -DHAVE_DRI
-DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_DRISW_KMS
-DHAVE_GALLIUM_EXTRA_HUD=1 -mtls-dialect=gnu2
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -Werror=empty-body -Werror=incompatible-pointer-types
-Werror=int-conversion -Wimplicit-fallthrough -Wmisleading-indentation
-Wno-missing-field-initializers -Wno-format-truncation -Wno-nonnull-compare
-fno-math-errno -fno-trapping-math -fno-common -Wno-unused-function
-Werror=format -Wformat-security -ffunction-sections -fdata-sections
-Wno-unused-variable -Wno-unused-but-set-variable -save-temps -fPIC -pthread
-isystem/usr/lib/llvm-14/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Werror=pointer-arith -Werror=vla
-MD -MQ src/gallium/auxiliary/libgallium.a.p/draw_draw_llvm.c.o -MF
src/gallium/auxiliary/libgallium.a.p/draw_draw_llvm.c.o.d -o
src/gallium/auxiliary/libgallium.a.p/draw_draw_llvm.c.o -c
../src/gallium/auxiliary/draw/draw_llvm.c

[Bug tree-optimization/109744] mesa/panvk: bogus Warray-bounds on gcc 12.2, fixed in 13 branch

[david at ixit dot cz via Gcc-bugs]

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

--- Comment #2 from David Heidelberg (okias)  ---
cc -Isrc/panfrost/vulkan/libvulkan_panfrost.so.p -Isrc/panfrost/vulkan
-I../src/panfrost/vulkan -Iinclude -I../include -Isrc -I../src -Isrc/compiler
-I../src/compiler -I../src/gallium/include -Isrc/gallium/auxiliary
-I../src/gallium/auxiliary -Isrc/panfrost -I../src/panfrost
-I../src/panfrost/include -Isrc/panfrost/shared -I../src/panfrost/shared
-Isrc/panfrost/midgard -I../src/panfrost/midgard -Isrc/panfrost/compiler
-I../src/panfrost/compiler -Isrc/panfrost/lib -I../src/panfrost/lib
-Isrc/compiler/nir -I../src/compiler/nir -Isrc/panfrost/lib/genxml
-I../src/panfrost/lib/genxml -Isrc/vulkan/util -I../src/vulkan/util
-Isrc/vulkan/runtime -I../src/vulkan/runtime -Isrc/vulkan/wsi
-I../src/vulkan/wsi -Isrc/egl/wayland/wayland-drm -I/usr/include/libdrm
-I/usr/include/valgrind -I/usr/include/x86_64-linux-gnu
-fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=c11 -O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="23.2.0-devel"'
'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues;'
-DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST
-DVIDEO_CODEC_VC1DEC=0 -DVIDEO_CODEC_H264DEC=1 -DVIDEO_CODEC_H264ENC=1
-DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1 -DHAVE_X11_PLATFORM
-DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM
-DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DALLOW_KCMP
-DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
-DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P
-DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN
-DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE
-DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT
-DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY
-DHAVE_FMEMOPEN -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS
-DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAS_SCHED_H -DHAS_SCHED_GETAFFINITY
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H
-DHAVE_CET_H -DHAVE_SYS_INOTIFY_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
-DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK
-DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_POSIX_FALLOCATE -DHAVE_GNU_QSORT_R
-DHAVE_STRUCT_TIMESPEC -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_ISSIGNALING
-DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR
-DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION
-DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LIBUDEV
-DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="14.0.6"' -DLLVM_IS_SHARED=1
-DDRAW_LLVM_AVAILABLE -DUSE_LIBELF -DHAVE_VALGRIND -DMESA_EXECMEM
-DHAVE_LIBUNWIND -DWL_HIDE_DEPRECATED -DHAVE_OPENMP -DHAVE_DRI -DHAVE_DRI2
-DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_DRISW_KMS -DHAVE_GALLIUM_EXTRA_HUD=1
-mtls-dialect=gnu2 -Werror=implicit-function-declaration
-Werror=missing-prototypes -Werror=return-type -Werror=empty-body
-Werror=incompatible-pointer-types -Werror=int-conversion
-Wimplicit-fallthrough -Wmisleading-indentation -Wno-missing-field-initializers
-Wno-format-truncation -Wno-nonnull-compare -fno-math-errno -fno-trapping-math
-fno-common -Wno-unused-function -Werror=format -Wformat-security
-ffunction-sections -fdata-sections -Wno-unused-variable
-Wno-unused-but-set-variable -save-temps -fPIC -DVK_USE_PLATFORM_XCB_KHR
-DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_WAYLAND_KHR
-DVK_USE_PLATFORM_DISPLAY_KHR -DVK_USE_PLATFORM_XLIB_XRANDR_EXT -pthread
-Wno-override-init -MD -MQ
src/panfrost/vulkan/libvulkan_panfrost.so.p/panvk_cmd_buffer.c.o -MF
src/panfrost/vulkan/libvulkan_panfrost.so.p/panvk_cmd_buffer.c.o.d -o
src/panfrost/vulkan/libvulkan_panfrost.so.p/panvk_cmd_buffer.c.o -c
../src/panfrost/vulkan/panvk_cmd_buffer.c

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)

> Which does make it look invalid for the reasons why I mentioned. clang
> compiles the above just fine and so does GCC 12.x.

I should note the ICE does not happen with this fully reduced testcase, I put a
less reduced testcase in the bug report for the ICE.

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #11 from Andrew Pinski  ---
Reduced down to:
```
template concept cmpeq
  = requires(_Tp __t, _Tp __u) { { __u != __t } ; };
template
struct iterator_interface
{
  friend constexpr bool operator>=(D lhs, D rhs) requires cmpeq { return
true; }
};
template
struct iterator : iterator_interface>
{
bool operator==(iterator) const;
iterator ++();
iterator ++(int);
};
static_assert(cmpeq>);
```
Which does make it look invalid for the reasons why I mentioned. clang compiles
the above just fine and so does GCC 12.x.

[Bug c++/109752] [ICE] in check_complete_insertion, at hash-table.h:578

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 55011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55011=edit
Reduced testcase as far as I can get it

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #10 from Andrew Pinski  ---
Note is_constructible_v changes answers between the two places I think.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

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

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

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

https://gcc.gnu.org/g:185da7c2014ba41f38dd62cc719873ebf020b076

commit r14-529-g185da7c2014ba41f38dd62cc719873ebf020b076
Author: Harald Anlauf 
Date:   Fri May 5 21:22:12 2023 +0200

Fortran: overloading of intrinsic binary operators [PR109641]

Fortran allows overloading of intrinsic operators also for operands of
numeric intrinsic types.  The intrinsic operator versions are used
according to the rules of F2018 table 10.2 and imply type conversion as
long as the operand ranks are conformable.  Otherwise no type conversion
shall be performed to allow the resolution of a matching user-defined
operator.

gcc/fortran/ChangeLog:

PR fortran/109641
* arith.cc (eval_intrinsic): Check conformability of ranks of
operands
for intrinsic binary operators before performing type conversions.
* gfortran.h (gfc_op_rank_conformable): Add prototype.
* resolve.cc (resolve_operator): Check conformability of ranks of
operands for intrinsic binary operators before performing type
conversions.
(gfc_op_rank_conformable): New helper function to compare ranks of
operands of binary operator.

gcc/testsuite/ChangeLog:

PR fortran/109641
* gfortran.dg/overload_5.f90: New test.

[Bug tree-optimization/109714] mesa/aux/draw_llvm: bogus "may be used uninitialized warning"

[david at ixit dot cz via Gcc-bugs]

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

--- Comment #8 from David Heidelberg (okias)  ---
Thank you for your patience with me!

ccache cc -Isrc/panfrost/vulkan/libvulkan_panfrost.so.p -Isrc/panfrost/vulkan
-I../src/panfrost/vulkan -Iinclude -I../include -Isrc -I../src -Isrc/compiler
-I../src/compiler -I../src/gallium/include -Isrc/gallium/auxiliary
-I../src/gallium/auxiliary -Isrc/panfrost -I../src/panfrost
-I../src/panfrost/include -Isrc/panfrost/shared -I../src/panfrost/shared
-Isrc/panfrost/midgard -I../src/panfrost/midgard -Isrc/panfrost/compiler
-I../src/panfrost/compiler -Isrc/panfrost/lib -I../src/panfrost/lib
-Isrc/compiler/nir -I../src/compiler/nir -Isrc/panfrost/lib/genxml
-I../src/panfrost/lib/genxml -Isrc/vulkan/util -I../src/vulkan/util
-Isrc/vulkan/runtime -I../src/vulkan/runtime -Isrc/vulkan/wsi
-I../src/vulkan/wsi -Isrc/egl/wayland/wayland-drm -I/usr/include/libdrm
-I/usr/include/valgrind -I/usr/include/x86_64-linux-gnu
-fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=c11 -O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="23.2.0-devel"'
'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues;'
-DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST
-DVIDEO_CODEC_VC1DEC=0 -DVIDEO_CODEC_H264DEC=1 -DVIDEO_CODEC_H264ENC=1
-DVIDEO_CODEC_H265DEC=1 -DVIDEO_CODEC_H265ENC=1 -DHAVE_X11_PLATFORM
-DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM
-DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DALLOW_KCMP
-DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
-DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P
-DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN
-DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE
-DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT
-DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY
-DHAVE_FMEMOPEN -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS
-DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS -DHAS_SCHED_H -DHAS_SCHED_GETAFFINITY
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H
-DHAVE_CET_H -DHAVE_SYS_INOTIFY_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
-DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK
-DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_POSIX_FALLOCATE -DHAVE_GNU_QSORT_R
-DHAVE_STRUCT_TIMESPEC -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_ISSIGNALING
-DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR
-DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION
-DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LIBUDEV
-DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="14.0.6"' -DLLVM_IS_SHARED=1
-DDRAW_LLVM_AVAILABLE -DUSE_LIBELF -DHAVE_VALGRIND -DMESA_EXECMEM
-DHAVE_LIBUNWIND -DWL_HIDE_DEPRECATED -DHAVE_OPENMP -DHAVE_DRI -DHAVE_DRI2
-DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_DRISW_KMS -DHAVE_GALLIUM_EXTRA_HUD=1
-mtls-dialect=gnu2 -Werror=implicit-function-declaration
-Werror=missing-prototypes -Werror=return-type -Werror=empty-body
-Werror=incompatible-pointer-types -Werror=int-conversion
-Wimplicit-fallthrough -Wmisleading-indentation -Wno-missing-field-initializers
-Wno-format-truncation -Wno-nonnull-compare -fno-math-errno -fno-trapping-math
-fno-common -Wno-unused-function -Werror=format -Wformat-security
-ffunction-sections -fdata-sections -Wno-unused-variable
-Wno-unused-but-set-variable -save-temps -fPIC -DVK_USE_PLATFORM_XCB_KHR
-DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_WAYLAND_KHR
-DVK_USE_PLATFORM_DISPLAY_KHR -DVK_USE_PLATFORM_XLIB_XRANDR_EXT -pthread
-Wno-override-init -MD -MQ
src/panfrost/vulkan/libvulkan_panfrost.so.p/panvk_cmd_buffer.c.o -MF
src/panfrost/vulkan/libvulkan_panfrost.so.p/panvk_cmd_buffer.c.o.d -o
src/panfrost/vulkan/libvulkan_panfrost.so.p/panvk_cmd_buffer.c.o -c
../src/panfrost/vulkan/panvk_cmd_buffer.c

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Luke Dalessandro from comment #8)
> 
> Right.
> 
> I was sort of surprised that that boost code could get away with a requires
> on any of those CRTP functions where it uses the CRTP "D" type, but I tested
> gcc-12 and all the clangs, and nvc++, and msvc 19, and gcc-13 was the only
> one reporting problems here, so I went with consensus.

Note I could be wrong too. Which is why I kept it open until someone else who
is more familar with the C++ standard makes a judgement.

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Luke Dalessandro  ---
(In reply to Andrew Pinski from comment #7)
> I think the error message is correct.
> 
> In the original code we have:
> ```
> ...
>   template
> concept incrementable = regular<_Iter> && requires(_Iter __i) { { __i++
> } -> same_as<_Iter>; };
> ...
> 
> namespace boost { namespace stl_interfaces { inline namespace v2 {
> template<  typename D,  typename IteratorConcept, typename
> DifferenceType>
> struct iterator_interface
> {
>   friend constexpr bool operator>=(D lhs, D rhs)
> requires std::equality_comparable {}
> };
> ...
> 
> template
> struct iterator : boost::stl_interfaces::iterator_interface,
> std::forward_iterator_tag, T>
> {
> bool operator==(iterator) const;
> };
> 
> ```
> iterator is not complete until after the instantiation is finished but we
> have a std::equality_comparable which does the confusion

Right.

I was sort of surprised that that boost code could get away with a requires on
any of those CRTP functions where it uses the CRTP "D" type, but I tested
gcc-12 and all the clangs, and nvc++, and msvc 19, and gcc-13 was the only one
reporting problems here, so I went with consensus.

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #7 from Andrew Pinski  ---
I think the error message is correct.

In the original code we have:
```
...
  template
concept incrementable = regular<_Iter> && requires(_Iter __i) { { __i++ }
-> same_as<_Iter>; };
...

namespace boost { namespace stl_interfaces { inline namespace v2 {
template<  typename D,  typename IteratorConcept, typename
DifferenceType>
struct iterator_interface
{
  friend constexpr bool operator>=(D lhs, D rhs)
requires std::equality_comparable {}
};
...

template
struct iterator : boost::stl_interfaces::iterator_interface,
std::forward_iterator_tag, T>
{
bool operator==(iterator) const;
};

```
iterator is not complete until after the instantiation is finished but we
have a std::equality_comparable which does the confusion

[Bug c++/109750] Incorrect code generated for shifted bit field

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

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

--- Comment #7 from Andrew Pinski  ---
This is also definitely a bug in MSVC and should reported to them.
ICC fixed their bug already even.

[Bug c++/109750] Incorrect code generated for shifted bit field

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

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

--- Comment #6 from Andrew Pinski  ---
icc version 2021.1.2 (gcc version 10.1.0 compatibility)
Has the same behavior as GCC.
While:
icc version 19.0.0.117 (gcc version 8.2.0 compatibility)
had the MSVC behavior

clang has the same behavior as GCC since clang 3.0.0.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

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

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

--- Comment #16 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #15)
> (In reply to Alex Coplan from comment #14)
> > I'm working on this.
> 
> I will rebase my WIP and push it somewhere - [ it has __has_feature and
> __has_extension components .. but likely bit rotten with changes to libcpp ]
> (sorry for being slow to do this - releases tie up all my Darwin time.

https://github.com/iains/gcc-git/tree/master-wip-has-extension

(it might not even build - I was hoping to have some time to refresh it - but
better publish now in case it's useful in any way )

AFAIR the main blocker to progress was trying to decide how to represent the
target/language/language version dependencies of the features and extensions
(there's a rudimentary scheme at the moment but it probably is not flexible
enough)

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Luke Dalessandro from comment #5)
> Ah, I didn't realize that. If you want to close one of the two issues that's
> fine with me. I sort of thought two different things were going on.

The ICE might not be related so keeping both open until it is figured out is
good.

[Bug c++/109750] Incorrect code generated for shifted bit field

[jim.gray at atos dot net via Gcc-bugs]

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

--- Comment #5 from jim.gray at atos dot net ---
I don't know if it makes any difference, but I ran with an older version of the
Intel C++ compiler on Linux, with the results below:

Good output when compiling with the Intel C++ compiler 
on CentOS Linux release 7.7.1908 

[builder@7f936516e827 ~]$ icc --version
icc (ICC) 17.0.2 20170213
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

[builder@af80ebc5f176 gccbug]$ icc gccbug.cpp
[builder@af80ebc5f176 gccbug]$ 

[builder@af80ebc5f176 gccbug]$ ls -l
total 28
-rwxrwxr-x 1 builder builder 22592 May  5 18:02 a.out
-rw-rw-r-- 1 builder builder  3553 May  5 18:02 gccbug.cpp
[builder@af80ebc5f176 gccbug]$ 

[builder@af80ebc5f176 gccbug]$ ./a.out
Example showing GCC bug:
  Source = 0002
  Target = 0200
  Target = 02000200
Example showing workaround for bug:
  Source = 0002
  Target = 0200
  Temp   = 0002
  Temp   = 0200
  Target = 02000200
[builder@af80ebc5f176 gccbug]$

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Luke Dalessandro  ---
Ah, I didn't realize that. If you want to close one of the two issues that's
fine with me. I sort of thought two different things were going on.

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Luke Dalessandro from comment #3)
> One thing to note about this failure, the concept evaluation changes in
> gcc-13. The when I try with current trunk it actually ICEs in addition.

The ICE on the trunk is because extra checking is enabled by default, it most
likely also ICEs in GCC 13 also (maybe even with -fchecking=2).

[Bug c++/109752] [ICE] in check_complete_insertion, at hash-table.h:578

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Luke Dalessandro  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Luke Dalessandro from comment #0)
> > 
> > PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 fails the same
> > assert but I don't know if it's the same cause.
> 
> That bug was in the fortran front-end and has not relationship to the C++
> front-end issues.

Thanks for checking.

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Luke Dalessandro  ---
One thing to note about this failure, the concept evaluation changes in gcc-13.
The when I try with current trunk it actually ICEs in addition.

I reported that ICE as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109752.

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

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

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

--- Comment #15 from Iain Sandoe  ---
(In reply to Alex Coplan from comment #14)
> I'm working on this.

I will rebase my WIP and push it somewhere - [ it has __has_feature and
__has_extension components .. but likely bit rotten with changes to libcpp ]
(sorry for being slow to do this - releases tie up all my Darwin time.

[Bug c++/109750] Incorrect code generated for shifted bit field

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to jim.gray from comment #3)
> The "correct" answer is also provided by the Intel C++ compiler,
> so apparently GCC is the odd one out.

I think MSVC is the odd one out really. see below.
You can also do the testing yourself at https://godbolt.org/ to see that.

Huh? Maybe ICC on windows gives a different answer than ICC on Linux.
Which might make sense if ICC on Windows is trying to provide bug for bug
compatibility with MSVC.

ICC gives:

icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and
will be removed from product release in the second half of 2023. The Intel(R)
oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward.
Please transition to use this compiler. Use '-diag-disable=10441' to disable
this message.
ASM generation compiler returned: 0
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and
will be removed from product release in the second half of 2023. The Intel(R)
oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward.
Please transition to use this compiler. Use '-diag-disable=10441' to disable
this message.
Execution build compiler returned: 0
Program returned: 0
Example showing GCC bug:
  Source = 0002
  Target = 0200
  Target = 1776000200

clang gives:
:103:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char *argv[]) {
 ^
:103:26: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char *argv[]) {
 ^
2 warnings generated.
ASM generation compiler returned: 0
:103:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char *argv[]) {
 ^
:103:26: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char *argv[]) {
 ^
2 warnings generated.
Execution build compiler returned: 0
Program returned: 0
Example showing GCC bug:
  Source = 0002
  Target = 0200
  Target = 1776000200

[Bug c++/109752] [ICE] in check_complete_insertion, at hash-table.h:578

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Luke Dalessandro  ---
Created attachment 55010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55010=edit
Preprocessed source copied from the godbolt live link.

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Luke Dalessandro  ---
Created attachment 55009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55009=edit
Preprocessed source copied from the godbolt live link included in the original
text.

[Bug c++/109750] Incorrect code generated for shifted bit field

[jim.gray at atos dot net via Gcc-bugs]

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

--- Comment #3 from jim.gray at atos dot net ---
The "correct" answer is also provided by the Intel C++ compiler,
so apparently GCC is the odd one out.

[Bug c++/109752] [ICE] in check_complete_insertion, at hash-table.h:578

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=108451|

--- Comment #2 from Andrew Pinski  ---
(In reply to Luke Dalessandro from comment #0)
> 
> PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 fails the same
> assert but I don't know if it's the same cause.

That bug was in the fortran front-end and has not relationship to the C++
front-end issues.

[Bug c++/109752] [ICE] in check_complete_insertion, at hash-table.h:578

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

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

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source?

[Bug c++/109752] New: [ICE] in check_complete_insertion, at hash-table.h:578

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 109752
   Summary: [ICE] in check_complete_insertion, at hash-table.h:578
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

The following example is reduced from
https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/example/node_iterator.cpp.
It causes the ICE on trunk (gcc-14).

  #include 

  template
  struct iterator : boost::stl_interfaces::iterator_interface, 
  std::forward_iterator_tag, T>
  {
using base_type = boost::stl_interfaces::iterator_interface,
std::forward_iterator_tag, T>;
using base_type::operator++;

T& operator*() const;
iterator& operator++();
bool operator==(iterator) const;
  };

  static_assert(std::incrementable>);

Live: https://godbolt.org/z/n9hMW4a4b

PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 fails the same assert
but I don't know if it's the same cause.

PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751 same example may
trigger gcc-13 bug (I'm not sure)

[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source?

[Bug libstdc++/109751] New: boost interface_interface fails concept check starting in gcc-13

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 109751
   Summary: boost interface_interface fails concept check starting
in gcc-13
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

The following example is reduced from
https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/example/node_iterator.cpp.
It compiles fine in gcc-12 but fails a concept check in gcc-13.


  #include 

  template
  struct iterator : boost::stl_interfaces::iterator_interface, 
  std::forward_iterator_tag, T>
  {
using base_type = boost::stl_interfaces::iterator_interface,
std::forward_iterator_tag, T>;
using base_type::operator++;

T& operator*() const;
iterator& operator++();
bool operator==(iterator) const;
  };

  static_assert(std::incrementable>);

Live: https://godbolt.org/z/6qsx1narj

The error tells us that this requires clause changes from false to true.

  friend constexpr bool operator<(D lhs, D rhs)
requires std::equality_comparable {
  return (lhs - rhs) < typename D::difference_type(0);
}

https://github.com/boostorg/stl_interfaces/blob/boost-1.82.0/include/boost/stl_interfaces/iterator_interface.hpp#L779

I don't think that requires clause makes any sense, but I also don't know why
the behavior would have changed from gcc-12 to gcc-13.

[Bug c++/109750] Incorrect code generated for shifted bit field

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
MSVC bug:

In [conv.prom] p5 the standard says:

"A prvalue for an integral bit-field (11.4.9) can be converted to a prvalue of
type int if int can represent all the values of the bit-field;"

[Bug c++/109750] Incorrect code generated for shifted bit field

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

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

--- Comment #1 from Andrew Pinski  ---

((UI64)source.sH.lower)

The question is source.sH.lower promoted to int rather than the underlying
type. Note clang has the same behavior as GCC here even. So I am thinking this
is a bug in MSVC rather than GCC ... (or some implemented defined behavior and
both are correct).

[Bug c++/109750] New: Incorrect code generated for shifted bit field

[jim.gray at atos dot net via Gcc-bugs]

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

Bug ID: 109750
   Summary: Incorrect code generated for shifted bit field
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim.gray at atos dot net
  Target Milestone: ---

Created attachment 55008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55008=edit
Tar file with source, assembly listing, compile script, executable

Attached is a simple program that shows the problem encountered.

Bad output when compiling with GCC compiler on Ubuntu
~/gcc-bug$ ./gccbug
  Source = 0002
  Target = 0200
  Target = 1776000200

Good output when compiling with MS C++ compiler on Windows:
>gccbug
  Source = 0002
  Target = 0200
  Target = 02000200

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #14 from Alex Coplan  ---
I'm working on this.

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

[frankhb1989 at gmail dot com via Gcc-bugs]

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

--- Comment #9 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)

> I don't think that's true. If __GXX_MERGED_TYPEINFO_NAMES is true then the
> out-of-line definition is correct. You can't just redefine that macro to 1
> in your code and expect it to affect the out-of-line definition in the
> library. Even if you recompile the library with 
> -D__GXX_MERGED_TYPEINFO_NAMES=1 that doesn't magically make it true. If the
> platform ABI and compiler and linker really do guarantee that all typeinfo
> names are unique, then address comparison works correctly.
> 

Yes, -D__GXX_MERGED_TYPEINFO_NAMES=1 is harmful and unnecessary to work around
the issue. As illustrated, it just works for some of my cases accidentally, and
fails for some other cases.

Further, I want to make sure no out-of-line definition of type_info::before is
called in the system libraries (which I can't rebuild). Does libstdc++ have
calls to type_info::before internally?

> You can't expect that to give meaningful results though, you would need to
> rebuild the entire compiler for meaningful results with redefined macros,
> and even then it would fail when you use RTTI across dynamic library
> boundaries.
> 
> You can't just redefine those macros and expect the compiler and OS to
> change how they work.
> 

I don't quite get this point about the compiler. Do you mean not only libstdc++
and the linker, but also the compiler's codegen of the mangled names works
differently depending on the macro definitions, besides the possible duplicate
(but having identical mangled names) definitions of the internal objects
providing the mangle names? Will it affect the section layout of the object
code? Are there existing optimizations relying on the assumptions?

I know it will not be formally supported to have consistent behavior just by
rebuilding the user programs, and it will be plain wrong without things like
ICF or in cases dynamic loading is relied on, but I'm curious: what are the
actual consequences from the compiler's view, when (1) all TUs of the program
code eventually use these macro definitions consistently, (2) definitions of
RTTI information for identical types are totally merged; and, (3) each instance
of the call to the out-of-line definition of type_info::before is avoided?

I am interesting in such questions because there are cases where rebuiding the
toolchain is impossible. It is not even possible to rebuilt libstdc++ for
production system unless more than one instance can be deployed side by side
(e.g. by static linking), because I cannot make sure no other part of the
environment have relied on the bug-to-bug compatibility to the existing system
libraries. In my case, I have to make sure which parts of the deployed code are
actually affected before the toolchain update (either system-wide or not) is
possible. And before that, the redefinition of macros seems the only viable
workaround (with certain limitations).

> > Accidentally the
> > inline definition of std::type_info::before does the right thing
> 
> I don't think it's an accident.
> 

Good news to me.

> > (hopefully), so __GXX_TYPEINFO_EQUALITY_INLINE == 1 just works. Otherwise
> > there would be no easy workaround without the modification on the standard
> > headers.
> > 
> > Forcing address comparisons is wrong in general, but with some additional
> > assumptions to rule out all potential offending features, then all type_info
> > objects follow ODR in the strict sense, so this just works. When this is an
> > issue, __GXX_TYPEINFO_EQUALITY_INLINE == 1 && __GXX_MERGED_TYPEINFO_NAMES ==
> > 0 should be safe for all names not from unnamed namespaces. This is a real
> > problem for MinGW (at least with GNU ld which does not perform ICF on
> > PE/COFF AFAIK), where __GXX_TYPEINFO_EQUALITY_INLINE == 1 &&
> > __GXX_MERGED_TYPEINFO_NAMES == 1 causes something like
> > (shared_ptr<...>) not unique across module boundaries, and my code
> > fails elsewhere due to this reason.
> 
> So stop redefining those macros then, you're lying to the compiler.
> 

Sadly, we *have to* lie for some degrees... ODR in ISO C++ is already
conceptually violated in cases when dynamic libraries are taken into account.
There is no such strong guarantee (like ICF) for all implementations, so
implementation-specific details are already kicked in.

> __GXX_MERGED_TYPEINFO_NAMES=1 is a lie on your target. Don't do that.

Agreed for the current case, though.

[Bug tree-optimization/109714] mesa/aux/draw_llvm: bogus "may be used uninitialized warning"

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

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

--- Comment #7 from Andrew Pinski  ---
That is how is gcc being invoked to create draw_draw_llvm.c.o .

[Bug tree-optimization/109714] mesa/aux/draw_llvm: bogus "may be used uninitialized warning"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed|2023-05-03 00:00:00 |2023-05-05

--- Comment #6 from Andrew Pinski  ---
(In reply to David Heidelberg (okias) from comment #5)
> Created attachment 55005 [details]
> meson-setup-output.txt

This does not enough information.
How is gcc invoked for compiling this?
You might be able to add --verbose to meson command line to see that. Otherwise
there is not much that can be done here.

[Bug tree-optimization/109749] new test case g++.dg/vect/pr109573.cc ICEs with checks turned on

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
I tried this on gcc 12 and it did not ICE.

[Bug tree-optimization/109749] New: new test case g++.dg/vect/pr109573.cc ICEs with checks turned on

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

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

Bug ID: 109749
   Summary: new test case g++.dg/vect/pr109573.cc ICEs with checks
turned on
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

The compiler was built with --enable-checking=yes,extra,rtl.  Without that it
does not ICE.

g:8ee420c763add757bfb7c451f3ec986046644021, r11-10679-g8ee420c763add7
make  -k check-gcc RUNTESTFLAGS="vect.exp=g++.dg/vect/pr109573.cc"
FAIL: g++.dg/vect/pr109573.cc  -std=c++2a (internal compiler error)
FAIL: g++.dg/vect/pr109573.cc  -std=c++2a (test for excess errors)
# of unexpected failures2
# of unsupported tests  3


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-11-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-11-test/gcc/testsuite/g++/../../
exceptions_enabled1011389.cc -fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-11-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-11-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-11-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-11-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-11-test/libstdc++-v3/testsuite/util
-fmessage-length=0 -S -o exceptions_enabled1011389.s
FAIL: g++.dg/vect/pr109573.cc  -std=c++2a (test for excess errors)
Excess errors:
during GIMPLE pass: slp
/home/seurer/gcc/git/gcc-11-test/gcc/testsuite/g++.dg/vect/pr109573.cc:81:6:
internal compiler error: in vectorizable_live_operation, at
tree-vect-loop.c:8879
0x113c0cc7 vectorizable_live_operation(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*, int, bool,
vec*)
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-loop.c:8876
0x11376137 can_vectorize_live_stmts
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-stmts.c:10663
0x113a4d13 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-stmts.c:11047
0x113e4517 vect_schedule_slp_node
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:6391
0x113e4517 vect_schedule_slp_node
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:6198
0x113f5137 vect_schedule_scc
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:6553
0x113f4edb vect_schedule_scc
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:6534
0x113f58fb vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>)
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:6669
0x113f7507 vect_slp_region
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:5074
0x113f896b vect_slp_bbs
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:5186
0x113f8f9b vect_slp_function(function*)
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vect-slp.c:5272
0x114051c3 execute
/home/seurer/gcc/git/gcc-11-test/gcc/tree-vectorizer.c:1450


commit 8ee420c763add757bfb7c451f3ec986046644021 (HEAD, refs/bisect/bad)
Author: Richard Biener 
Date:   Fri Apr 21 12:57:17 2023 +0200

tree-optimization/109573 - avoid ICEing on unexpected live def

[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

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

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

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

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

commit r13-7300-gf077b784a6e6876682606bd788ac77a698b81016
Author: Patrick Palka 
Date:   Tue May 2 08:48:59 2023 -0400

c++: Add testcase for already fixed PR [PR109506]

The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR.

PR c++/109506

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template26.C: New test.

(cherry picked from commit 9a9840cedbdc8be8252fd8f2d31d8fbd36632a2e)

[Bug tree-optimization/109691] Takes until forwprop2 to remove !a sometimes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-May/617
   ||612.html

--- Comment #6 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617612.html

[Bug c++/109745] [13/14 Regression] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Incorrect code generated|[13/14 Regression]
   |with -O1 when having a  |Incorrect code generated
   |constexpr object modifying  |with -O1 when having a
   |a mutable member|constexpr object modifying
   ||a mutable member
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2023-05-05
   Priority|P3  |P2
   Target Milestone|--- |13.2
 Status|UNCONFIRMED |NEW

--- Comment #3 from Marek Polacek  ---
Looks like it started with r13-2701:

commit 7107ea6fb933f1e928593c7e92edfd64ccf0df63
Author: Patrick Palka 
Date:   Fri Sep 16 11:10:43 2022 -0400

c++: 'mutable' member within constexpr [PR92505]

[Bug c/107898] [11 Regression] ICE in irange_intersect, at value-range.cc:1640

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/107898] [11 Regression] ICE in irange_intersect, at value-range.cc:1640

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

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

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

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

commit r11-10746-gbca26e97f167ccc3161488113d8bed48542b4ca2
Author: Richard Biener 
Date:   Tue Nov 29 09:03:46 2022 +0100

tree-optimization/107898 - ICE with -Walloca-larger-than

The following avoids ICEing with a mismatched prototype for alloca
and -Walloca-larger-than using irange for checks which doesn't
like mismatched types.

PR tree-optimization/107898
* gimple-ssa-warn-alloca.c (alloca_call_type): Check
the type of the alloca argument is compatible with size_t
before querying ranges.

(cherry picked from commit 9948daa4fd0f0ea0a9d56c2fefe1bca478554d27)

[Bug target/109748] RISC-V: Mis code gen for the RVV intrinsic VSETVL

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #2 from Li Pan  ---
No, should be introduced by one optimization of Juzhe in GCC 14. Juzhe is
working on fixing this, just open a bug on behalf of Juzhe for tracking.

[Bug target/109615] Redundant VSETVL after optimized code of RVV

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

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

commit r14-503-gd875d75653ed67e125e70dd8530182ce7872af65
Author: Juzhe-Zhong 
Date:   Fri May 5 14:33:44 2023 +0800

RISC-V: Fix PR109615

This patch is to fix following case:
void f (int8_t * restrict in, int8_t * restrict out, int n, int m, int
cond)
{
  size_t vl = 101;
  if (cond)
vl = m * 2;
  else
vl = m * 2 * vl;

  for (size_t i = 0; i < n; i++)
{
  vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i, vl);
  __riscv_vse8_v_i8mf8 (out + i, v, vl);

  vbool64_t mask = __riscv_vlm_v_b64 (in + i + 100, vl);

  vint8mf8_t v2 = __riscv_vle8_v_i8mf8_tumu (mask, v, in + i + 100,
vl);
  __riscv_vse8_v_i8mf8 (out + i + 100, v2, vl);
}

  for (size_t i = 0; i < n; i++)
{
  vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i + 300, vl);
  __riscv_vse8_v_i8mf8 (out + i + 300, v, vl);
}
}

The value of "vl" is coming from different blocks so it will be wrapped as
a PHI node of each
block.

In the first loop, the "vl" source is a PHI node from bb 4.
In the second loop, the "vl" source is a PHI node from bb 5.
since bb 5 is dominated by bb 4, the PHI input of "vl" in the second loop
is the PHI node of "vl"
in bb 4.
So when 2 "vl" PHI node are both degenerate PHI node (the phi->num_inputs
() == 1) and their only
input are same, it's safe for us to consider they are compatible.

This patch is only optimize degenerate PHI since it's safe and simple
optimization.

non-dengerate PHI are considered as incompatible unless the PHI are the
same in RTL_SSA.
TODO: non-generate PHI is complicated, we can support it when it is
necessary in the future.

Before this patch:

...
.L2:
addia4,a1,100
add t1,a0,a2
mv  t0,a0
beq a2,zero,.L1
vsetvli zero,a3,e8,mf8,tu,mu
.L4:
addia6,t0,100
addia7,a4,-100
vle8.v  v1,0(t0)
addit0,t0,1
vse8.v  v1,0(a7)
vlm.v   v0,0(a6)
vle8.v  v1,0(a6),v0.t
vse8.v  v1,0(a4)
addia4,a4,1
bne t0,t1,.L4
addia0,a0,300
addia1,a1,300
add a2,a0,a2
vsetvli zero,a3,e8,mf8,ta,ma
.L5:
vle8.v  v2,0(a0)
addia0,a0,1
vse8.v  v2,0(a1)
addia1,a1,1
bne a2,a0,.L5
.L1:
ret

After this patch:

...
.L2:
addia4,a1,100
add t1,a0,a2
mv  t0,a0
beq a2,zero,.L1
vsetvli zero,a3,e8,mf8,tu,mu
.L4:
addia6,t0,100
addia7,a4,-100
vle8.v  v1,0(t0)
addit0,t0,1
vse8.v  v1,0(a7)
vlm.v   v0,0(a6)
vle8.v  v1,0(a6),v0.t
vse8.v  v1,0(a4)
addia4,a4,1
bne t0,t1,.L4
addia0,a0,300
addia1,a1,300
add a2,a0,a2
.L5:
vle8.v  v2,0(a0)
addia0,a0,1
vse8.v  v2,0(a1)
addia1,a1,1
bne a2,a0,.L5
.L1:
ret

PR target/109615

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (avl_info::multiple_source_equal_p):
Add
denegrate PHI optmization.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-74.c: Adapt testcase.
* gcc.target/riscv/rvv/vsetvl/vsetvl-11.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/pr109615.c: New test.

[Bug fortran/109622] [13/14 regression][OpenACC] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Julian Brown
:

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

commit r13-7299-ga4cc474b15ecd148f5bb13a1db3bc3e40a4ff86e
Author: Julian Brown 
Date:   Fri Apr 28 22:27:54 2023 +

OpenACC: Further attach/detach clause fixes for Fortran [PR109622]

This patch moves several tests introduced by the following patch:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html
  commit r14-325-gcacf65d74463600815773255e8b82b4043432bd7

into the proper location for OpenACC testing (thanks to Thomas for
spotting my mistake!), and also fixes a few additional problems --
missing diagnostics for non-pointer attaches, and a case where a pointer
was incorrectly dereferenced. Tests are also adjusted for vector-length
warnings on nvidia accelerators.

2023-04-29  Julian Brown  

PR fortran/109622

gcc/fortran/
* openmp.cc (resolve_omp_clauses): Add diagnostic for
non-pointer/non-allocatable attach/detach.
* trans-openmp.cc (gfc_trans_omp_clauses): Remove dereference for
pointer-to-scalar derived type component attach/detach.  Fix
attach/detach handling for descriptors.

gcc/testsuite/
* gfortran.dg/goacc/pr109622-5.f90: New test.
* gfortran.dg/goacc/pr109622-6.f90: New test.

libgomp/
* testsuite/libgomp.fortran/pr109622.f90: Move test...
* testsuite/libgomp.oacc-fortran/pr109622.f90: ...to here. Ignore
vector length warning.
* testsuite/libgomp.fortran/pr109622-2.f90: Move test...
* testsuite/libgomp.oacc-fortran/pr109622-2.f90: ...to here.  Add
missing copyin/copyout variable. Ignore vector length warnings.
* testsuite/libgomp.fortran/pr109622-3.f90: Move test...
* testsuite/libgomp.oacc-fortran/pr109622-3.f90: ...to here. 
Ignore
vector length warnings.
* testsuite/libgomp.oacc-fortran/pr109622-4.f90: New test.

(cherry picked from commit 0a26a42b237bada32165e61867a2bf4461c5fab2)

[Bug fortran/109622] [13/14 regression][OpenACC] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Julian Brown
:

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

commit r13-7298-gfa7c4ab36585ba128733265fb626ff3f4066400f
Author: Julian Brown 
Date:   Wed Apr 26 14:31:53 2023 +

OpenACC: Stand-alone attach/detach clause fixes for Fortran [PR109622]

This patch fixes several cases where multiple attach or detach mapping
nodes were being created for stand-alone attach or detach clauses
in Fortran.  After the introduction of stricter checking later during
compilation, these extra nodes could cause ICEs, as seen in the PR.

The patch also fixes cases that "happened to work" previously where
the user attaches/detaches a pointer to array using a descriptor, and
(I think!) the "_data" field has offset zero, hence the same address as
the descriptor as a whole.

2023-04-27  Julian Brown  

PR fortran/109622

gcc/fortran/
* trans-openmp.cc (gfc_trans_omp_clauses): Attach/detach clause
fixes.

gcc/testsuite/
* gfortran.dg/goacc/attach-descriptor.f90: Adjust expected output.

libgomp/
* testsuite/libgomp.fortran/pr109622.f90: New test.
* testsuite/libgomp.fortran/pr109622-2.f90: New test.
* testsuite/libgomp.fortran/pr109622-3.f90: New test.

(cherry picked from commit cacf65d74463600815773255e8b82b4043432bd7)

[Bug target/109748] RISC-V: Mis code gen for the RVV intrinsic VSETVL

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

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

--- Comment #1 from Kito Cheng  ---
Is this also happened in GCC 13 branch?

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

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

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

commit r14-501-g0a85544e1aaeca41133ecfc438cda913dbc0f122
Author: Tamar Christina 
Date:   Fri May 5 13:42:17 2023 +0100

match.pd: Use splits in makefile and make configurable.

This updates the build system to split up match.pd files into chunks of 10.
This also introduces a new flag --with-matchpd-partitions which can be used
to
change the number of partitions.

For the analysis of why 10 please look at the previous patch in the series.

gcc/ChangeLog:

PR bootstrap/84402
* Makefile.in (NUM_MATCH_SPLITS, MATCH_SPLITS_SEQ,
GIMPLE_MATCH_PD_SEQ_SRC, GIMPLE_MATCH_PD_SEQ_O,
GENERIC_MATCH_PD_SEQ_SRC, GENERIC_MATCH_PD_SEQ_O): New.
(OBJS, MOSTLYCLEANFILES, .PRECIOUS): Use them.
(s-match): Split into s-generic-match and s-gimple-match.
* configure.ac (with-matchpd-partitions,
DEFAULT_MATCHPD_PARTITIONS): New.
* configure: Regenerate.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

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

https://gcc.gnu.org/g:703417a030b3d80f55ba1402adc3f1692d3631e5

commit r14-500-g703417a030b3d80f55ba1402adc3f1692d3631e5
Author: Tamar Christina 
Date:   Fri May 5 13:38:50 2023 +0100

match.pd: automatically partition *-match.cc files.

Following on from Richi's RFC[1] this is another attempt to split up
match.pd
into multiple gimple-match and generic-match files.  This version is fully
automated and requires no human intervention.

First things first, some perf numbers.  The following shows the effect of
the
patch on my desktop doing parallel compilation of gimple-match:

++--++--+
| splits | rel. improvement | splits | rel. improvement |
++--++--+
|  1 | 0.00%| 33 | 91.03%   |
|  2 | 71.77%   | 34 | 84.02%   |
|  3 | 100.71%  | 35 | 83.42%   |
|  4 | 143.08%  | 36 | 78.80%   |
|  5 | 176.18%  | 37 | 74.06%   |
|  6 | 174.40%  | 38 | 55.76%   |
|  7 | 176.62%  | 39 | 66.90%   |
|  8 | 168.35%  | 40 | 18.25%   |
|  9 | 189.80%  | 41 | 16.55%   |
| 10 | 171.77%  | 42 | 47.02%   |
| 11 | 152.82%  | 43 | 15.29%   |
| 12 | 112.20%  | 44 | 21.63%   |
| 13 | 158.57%  | 45 | 41.53%   |
| 14 | 158.57%  | 46 | 21.98%   |
| 15 | 152.07%  | 47 | -42.74%  |
| 16 | 151.70%  | 48 | -32.62%  |
| 17 | 131.52%  | 49 | 11.81%   |
| 18 | 133.11%  | 50 | 34.07%   |
| 19 | 137.33%  | 51 | 2.71%|
| 20 | 103.83%  | 52 | -22.23%  |
| 21 | 132.47%  | 53 | 32.30%   |
| 22 | 116.52%  | 54 | 21.45%   |
| 23 | 112.73%  | 55 | 40.02%   |
| 24 | 111.94%  | 56 | 42.83%   |
| 25 | 112.73%  | 57 | -9.98%   |
| 26 | 104.07%  | 58 | 18.01%   |
| 27 | 113.27%  | 59 | -4.91%   |
| 28 | 96.77%   | 60 | 22.94%   |
| 29 | 93.42%   | 61 | -3.73%   |
| 30 | 87.67%   | 62 | -27.43%  |
| 31 | 89.54%   | 63 | -1.05%   |
| 32 | 84.42%   | 64 | -5.44%   |
++--++--+

As can be seen there seems to be a point of diminishing returns in doing
splits.
This comes from the fact that these match files consume a sizeable amount
of
headers.  At a certain point the parsing overhead of the headers dominate
and
you start losing in gains.

As such from this I've made the default 10 splits per file to allow for
some
room for growth in the future without needing changes to the split amount.
Since 5-10 show roughly the same gains it means we can afford to double the
file sizes before we need to up the split amount.  This can be controlled
by the configure parameter --with-matchpd-partitions=.

At 10 splits the sizes of the files are:

 1.2M gimple-match-1.cc
 490K gimple-match-2.cc
 459K gimple-match-3.cc
 462K gimple-match-4.cc
 466K gimple-match-5.cc
 690K gimple-match-6.cc
 517K gimple-match-7.cc
 693K gimple-match-8.cc
1011K gimple-match-9.cc
 490K gimple-match-10.cc
 210K gimple-match-auto.h

The reason gimple-match-1.cc is so large is because it got allocated a very
large function: gimple_simplify_NE_EXPR.

Because of these sporadically large functions the allocation to a split
happens
based on the amount of data already written to a split instead of just a
simple
round robin allocation (though the patch supports that too.).   This means
that
once gimple_simplify_NE_EXPR is allocated to gimple-match-1.cc nothing uses
it
again until the rest of the files catch up.

To support this split a new header file *-match-auto.h is generated to
allow
the individual files to compile separately.

Lastly for the auto generated files I use pragmas to silence the unused
predicate warnings instead of the previous Makefile way because I couldn't
find
a way to set them without knowing the number of split files beforehand.

Finally with this change, bootstrap time has dropped 8 minutes on AArch64.

[1] 

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

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

https://gcc.gnu.org/g:27fcf994c5515e1bbf2ff03d28fd2fa927c7e7b5

commit r14-499-g27fcf994c5515e1bbf2ff03d28fd2fa927c7e7b5
Author: Tamar Christina 
Date:   Fri May 5 13:37:49 2023 +0100

genmatch: split shared code to gimple-match-exports.cc

In preparation for automatically splitting match.pd files I split off the
non-static helper functions that are shared between the match.pd functions
off
to another file.

This file can be compiled in parallel and also allows us to later avoid
duplicate symbols errors.

gcc/ChangeLog:

PR bootstrap/84402
* Makefile.in (OBJS): Add gimple-match-exports.o.
* genmatch.cc (decision_tree::gen): Export gimple_gimplify helpers.
* gimple-match-head.cc (gimple_simplify, gimple_resimplify1,
gimple_resimplify2, gimple_resimplify3, gimple_resimplify4,
gimple_resimplify5, constant_for_folding, convert_conditional_op,
maybe_resimplify_conditional_op, gimple_match_op::resimplify,
maybe_build_generic_op, build_call_internal, maybe_push_res_to_seq,
do_valueize, try_conditional_simplification, gimple_extract,
gimple_extract_op, canonicalize_code, commutative_binary_op_p,
commutative_ternary_op_p, first_commutative_argument,
associative_binary_op_p, directly_supported_p,
get_conditional_internal_fn): Moved to gimple-match-exports.cc
* gimple-match-exports.cc: New file.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

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

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

commit r14-497-ge487fcc0f7466ea663a0fea52076337bebd42b8b
Author: Tamar Christina 
Date:   Fri May 5 13:36:01 2023 +0100

match.pd: Remove commented out line pragmas unless -vv is used.

genmatch currently outputs commented out line directives that have no
effect
but the compiler still has to parse only to discard.

They are however handy when debugging genmatch output.  As such this moves
them
behind the -vv flag.

gcc/ChangeLog:

PR bootstrap/84402
* genmatch.cc (output_line_directive): Only emit commented
directive
when -vv.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

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

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

commit r14-498-gc0ce29bc1ce329001b6c02bb3d34bcbb086e1b72
Author: Tamar Christina 
Date:   Fri May 5 13:36:43 2023 +0100

match.pd: CSE the dump output check.

This is a small improvement in QoL codegen for match.pd to save time not
re-evaluating the condition for printing debug information in every
function.

There is a small but consistent runtime and compile time win here.  The
runtime
win comes from not having to do the condition over again, and on Arm
plaforms
we now use the new test-and-branch support for booleans to only have a
single
instruction here.

gcc/ChangeLog:

PR bootstrap/84402
* genmatch.cc (decision_tree::gen, write_predicate): Generate new
debug_dump var.
(dt_simplify::gen_1): Use it.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

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

https://gcc.gnu.org/g:580cda3c2799b1f8323af770e52f1eb0fa204718

commit r14-496-g580cda3c2799b1f8323af770e52f1eb0fa204718
Author: Tamar Christina 
Date:   Fri May 5 13:35:17 2023 +0100

match.pd: don't emit label if not needed

This is a small QoL codegen improvement for match.pd to not emit labels
when
they are not needed.  The codegen is nice and there is a small (but
consistent)
improvement in compile time.

gcc/ChangeLog:

PR bootstrap/84402
* genmatch.cc (dt_simplify::gen_1): Only emit labels if used.

[Bug c/109748] New: RISC-V: Mis code gen for the

[pan2.li at intel dot com via Gcc-bugs]

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

Bug ID: 109748
   Summary: RISC-V: Mis code gen for the
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

Created attachment 55007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55007=edit
Test file for reproducing

Given we have bellow code.

#include 

int byte_mac_vec(unsigned char *a, unsigned char *b, int len) {
  size_t vlmax = __riscv_vsetvlmax_e8m1();
  vint32m4_t vec_s = __riscv_vmv_v_x_i32m4(0, vlmax);
  vint32m1_t vec_zero = __riscv_vmv_v_x_i32m1(0, vlmax);
  int k = len;

  for (size_t vl; k > 0; k -= vl, a += vl, b += vl) {
  vl = __riscv_vsetvl_e8m1(k);

  vuint8m1_t a8s = __riscv_vle8_v_u8m1(a, vl);
  vuint8m1_t b8s = __riscv_vle8_v_u8m1(b, vl);
  vuint32m4_t a8s_extended = __riscv_vzext_vf4_u32m4(a8s, vl);
  vuint32m4_t b8s_extended = __riscv_vzext_vf4_u32m4(a8s, vl);

  vint32m4_t a8s_as_i32 = __riscv_vreinterpret_v_u32m4_i32m4(a8s_extended);
  vint32m4_t b8s_as_i32 = __riscv_vreinterpret_v_u32m4_i32m4(b8s_extended);

  vec_s = __riscv_vmacc_vv_i32m4_tu(vec_s, a8s_as_i32, b8s_as_i32, vl);
  }

  vint32m1_t vec_sum = __riscv_vredsum_vs_i32m4_i32m1(vec_s, vec_zero,
__riscv_vsetvl_e32m4(len));
  int sum = __riscv_vmv_x_s_i32m1_i32(vec_sum);

  return sum;
}

It will generate the below assembly code with build option '-march=rv64gcv
-mabi=lp64 -O3 -c -S test.c -o -'.

byte_mac_vec:
vsetvli a5,zero,e32,m4,ta,ma
vmv.v.i v4,0
vsetvli zero,a5,e32,m1,ta,ma
vmv.v.i v2,0
ble a2,zero,.L2
mv  a4,a2
.L3:
vsetvli a5,a4,e8,m1,ta,ma   <- should be e32m4
subwa4,a4,a5
vle8.v  v1,0(a0)
add a0,a0,a5
vzext.vf4   v8,v1
vmacc.vvv4,v8,v8
bgt a4,zero,.L3
.L2:
vsetvli zero,a2,e32,m4,ta,ma
vredsum.vs  v4,v4,v2
vmv.x.s a0,v4
sext.w  a0,a0
ret

[Bug tree-optimization/109746] Fails removing redundant comparison in for loop over multiple variables, unless members of struct

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Probably some pass ordering issue.

[Bug tree-optimization/109735] [14 Regression] ICE in vectorizable_store, at tree-vect-stmts.cc:8529 since r14-322-g821ef93976e750

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/109735] [14 Regression] ICE in vectorizable_store, at tree-vect-stmts.cc:8529 since r14-322-g821ef93976e750

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

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

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

https://gcc.gnu.org/g:37b5f031292fbdb854ee791de3883362cf2afcff

commit r14-494-g37b5f031292fbdb854ee791de3883362cf2afcff
Author: Richard Biener 
Date:   Fri May 5 08:54:28 2023 +0200

tree-optimization/109735 - conversion for vectorized pointer-diff

There's handling in vectorizable_operation for POINTER_DIFF_EXPR
requiring conversion of the result of the unsigned operation to
a signed type.  But that's conditional on the "default" kind of
vectorization.  In this PR it's shown the emulated vector path
needs it and I think the masked operation case will, too (though
we might eventually never mask an integral MINUS_EXPR).  So the
following makes that handling unconditional.

PR tree-optimization/109735
* tree-vect-stmts.cc (vectorizable_operation): Perform
conversion for POINTER_DIFF_EXPR unconditionally.

[Bug target/109690] bad SLP vectorization on zen

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
The missing pattern was committed as part of:

commit r14-493-g919642fa4b2bc4c32910336dd200d53766801c80
Author: Uros Bizjak 
Date:   Fri May 5 14:10:18 2023 +0200

i386: Introduce mulv2si3 instruction

For SSE2 targets the expander unpacks input elements into the correct
position in the V4SI vector and emits PMULUDQ instruction.  The output
elements are then shuffled back to their positions in the V2SI vector.

For SSE4 targets PMULLD instruction is emitted directly.

gcc/ChangeLog:

* config/i386/mmx.md (mulv2si3): New expander.
(*mulv2si3): New insn pattern.

gcc/testsuite/ChangeLog:

* gcc.target/i386/sse2-mmx-mult-vec.c: New test.

[Bug target/108724] [11 Regression] Poor codegen when summing two arrays without AVX or SSE

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |target
 Target||x86_64-*-* i?86-*-*

--- Comment #9 from Richard Biener  ---
And the remaining issue with GCC 11 would be that we fail to account for the
GPR -> XMM move.  Or the remaining issue for _all_ branches is that we fail
to realize that emulated "vector" CTORs are even more expensive since we lack
a good way to materialize the CTOR in a GPR (generic RTL expansion fails to
consider using shift + and for example).

Not sure what a good expansion of a V2SImode, V4HImode or V8QImode
CTOR to a GPR DImode reg would look like.

[Bug target/109747] [12/13/14 Regression] SLP cost of constructors is off

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
 Target||x86_64-*-* i?86-*-*
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed||2023-05-05

--- Comment #1 from Richard Biener  ---
A fix, and maybe exactly a step in the right direction, would be to construct
individual new SLP nodes for each call to record_stmt_cost from
vect_prologue_cost_for_slp:

  /* ???  We're just tracking whether vectors in a single node are the same.
 Ideally we'd do something more global.  */
  for (unsigned int start : starts)
{ 
  vect_cost_for_stmt kind;
  if (SLP_TREE_DEF_TYPE (node) == vect_constant_def)
kind = vector_load;
  else if (vect_scalar_ops_slice { ops, start, nelt_limit }.all_same_p ())
kind = scalar_to_vec;
  else
kind = vec_construct;
  record_stmt_cost (cost_vec, 1, kind, node, vectype, 0, vect_prologue);
}   

alternatively we could pass down 'start' as well.  The x86 backend code
could also detect the mismatch of TYPE_VECTOR_SUBPARTS * count and
the number of SLP lanes (but not sure what it should do in that case).

Note we can't currently meaningfully put such a split set of SLP nodes
into the SLP graph, but in the end we might want to go into the direction
of splitting it into individual vector ops, esp. for load/store vectorization
and interleaving.

Short-term passing down 'start' (and only interpreting it with count is one?)
might be easiest.

Any opinions?

[Bug target/109747] New: [12/13/14 Regression] SLP cost of constructors is off

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

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

Bug ID: 109747
   Summary: [12/13/14 Regression] SLP cost of constructors is off
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When r12-7319-g90d693bdc9d718 added the accounting for GPR->XMM moves to the
cost of SLP CTORs I failed to realize that the costing code will pass down
the very same (and full) SLP node from vect_prologue_cost_for_slp but
will generate costs for each individual actual vector that's constructed.

So for the case where the SLP node covers more than one vector the costing
will be off.  That's visible in the costing of the testcase for PR108724
for example which is

void foo(int *a, const int *__restrict b, const int *__restrict c)
{
  for (int i = 0; i < 16; i++) {
a[i] = b[i] + c[i];
  }
}

and we end up with

_17 8 times unaligned_store (misalign -1) costs 96 in body
node 0x3fb5838 1 times vec_construct costs 100 in prologue
node 0x3fb5838 1 times vec_construct costs 100 in prologue
node 0x3fb5838 1 times vec_construct costs 100 in prologue
node 0x3fb5838 1 times vec_construct costs 100 in prologue
node 0x3fb5838 1 times vec_construct costs 100 in prologue
node 0x3fb5838 1 times vec_construct costs 100 in prologue
node 0x3fb5838 1 times vec_construct costs 100 in prologue
node 0x3fb5838 1 times vec_construct costs 100 in prologue

[Bug c++/109745] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member

[albin at yahoo dot com via Gcc-bugs]

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

albin  changed:

   What|Removed |Added

 CC||albin at yahoo dot com

--- Comment #2 from albin  ---
Simpler example:

#include 

template 
struct Foo
{
T val;
};

class Bar {
   public:
constexpr Bar() = default;
constexpr Bar(Bar const& other) { other.val_ = 42; }
constexpr int val() const { return val_; }
 private:
mutable int val_{};
};

int main()
{
constexpr Foo x{};
Foo y{x};
assert(x.val.val() == 42);
}

[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

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

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103133
 CC||fw at gcc dot gnu.org

--- Comment #13 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the
> > weak refs in gthr-posix.h
> 
> I think that is indeed the correct fix, as you originally asked about. But
> only for glibc 2.34 and later.

Only glibc 2.34 and later have this problem because previous upstream versions
lack dual-API time64 support. I would like to claim that we did this
deliberately, but the version alignment between libpthread removal and the new
time64 support was a bit of a coincidence.

Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[Jakub Jelinek via Gcc-bugs]

On Fri, May 05, 2023 at 01:13:50PM +0200, Florian Weimer via Gcc-bugs wrote:
> * Puneet Kumar Yatnal via Gcc-bugs:
> 
> > What is next step here? How do I post this in Bugzilla and get
> > support.
> 
> This issue has already been fixed with this commit:
> 
> commit 80fe172ba9820199c2bbce5d0611ffca27823049
> Author: Jonathan Wakely 
> Date:   Tue Nov 9 23:45:36 2021 +
> 
> libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]
> 
> Since Glibc 2.34 all pthreads symbols are defined directly in libc not
> libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
> avoid unnecessary locking in single-threaded programs. This means there
> is no reason to avoid linking to libpthread now, and so no reason to use
> weak symbols defined in gthr-posix.h for all the pthread_xxx functions.
> 
> libstdc++-v3/ChangeLog:
> 
> PR libstdc++/100748
> PR libstdc++/103133
> * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
> Define for glibc 2.34 and later.
> 
> It's been backported to GCC 10, but not GCC 9.  Backporting to 9
> requires some messaging to get into 9 which lacks commit
> b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined
> __gthread_self weak symbol [PR 95989]").

GCC 9 is not supported anymore, so backporting anything to it (at least
upstream) is not possible.

Jakub

Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[Jonathan Wakely via Gcc-bugs]

On Fri, 5 May 2023 at 12:13, Florian Weimer  wrote:
>
> * Puneet Kumar Yatnal via Gcc-bugs:
>
> > What is next step here? How do I post this in Bugzilla and get
> > support.
>
> This issue has already been fixed with this commit:
>
> commit 80fe172ba9820199c2bbce5d0611ffca27823049
> Author: Jonathan Wakely 
> Date:   Tue Nov 9 23:45:36 2021 +
>
> libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

Indeed, as pointed out in bugzilla after the discussion moved there:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540

>
> Since Glibc 2.34 all pthreads symbols are defined directly in libc not
> libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
> avoid unnecessary locking in single-threaded programs. This means there
> is no reason to avoid linking to libpthread now, and so no reason to use
> weak symbols defined in gthr-posix.h for all the pthread_xxx functions.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/100748
> PR libstdc++/103133
> * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
> Define for glibc 2.34 and later.
>
> It's been backported to GCC 10, but not GCC 9.  Backporting to 9
> requires some messaging to get into 9 which lacks commit
> b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined
> __gthread_self weak symbol [PR 95989]").
>
> Thanks,
> Florian
>

Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[Florian Weimer via Gcc-bugs]

* Puneet Kumar Yatnal via Gcc-bugs:

> What is next step here? How do I post this in Bugzilla and get
> support.

This issue has already been fixed with this commit:

commit 80fe172ba9820199c2bbce5d0611ffca27823049
Author: Jonathan Wakely 
Date:   Tue Nov 9 23:45:36 2021 +

libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

Since Glibc 2.34 all pthreads symbols are defined directly in libc not
libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
avoid unnecessary locking in single-threaded programs. This means there
is no reason to avoid linking to libpthread now, and so no reason to use
weak symbols defined in gthr-posix.h for all the pthread_xxx functions.

libstdc++-v3/ChangeLog:

PR libstdc++/100748
PR libstdc++/103133
* config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
Define for glibc 2.34 and later.

It's been backported to GCC 10, but not GCC 9.  Backporting to 9
requires some messaging to get into 9 which lacks commit
b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined
__gthread_self weak symbol [PR 95989]").

Thanks,
Florian

[Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

Alejandro Colomar  changed:

   What|Removed |Added

 CC||colomar.6.4.3 at gmail dot com

--- Comment #1 from Alejandro Colomar  ---
I can still reproduce it with GCC-13 and glibc 2.36:


$ cat glibc.c 
#include 

int main(void)
{
printf("glibc version: %d.%d\n", __GLIBC__, __GLIBC_MINOR__);
}

$ gcc-13 -Wall -Wextra glibc.c 
$ ./a.out 
glibc version: 2.36
$ gcc-13 --version
gcc-13 (Debian 13.1.0-1) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug tree-optimization/100162] missed optimization for dead code elimination at -O3 (vs. -O2)

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Andrew Pinski from comment #2)
> FRE is no longer able to optimize _7 to 2 in GCC 13+:
>   c[0][b.1_1] = 2;
>   c[1][b.1_1] = 2;
>   c[2][b.1_1] = 2;
>   c[3][b.1_1] = 2;
>   c[4][b.1_1] = 2;
>   a = 5;
>   _5 = b.1_1 != 0;
>   _6 = (int) _5;
>   _7 = c[0][0];

That's PR108355.  The "magic" special-casing of single element arrays went
away (or rather now triggers more unreliably).

[Bug tree-optimization/109746] New: Fails removing redundant comparison in for loop over multiple variables, unless members of struct

[magnus.hegdahl at gmail dot com via Gcc-bugs]

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

Bug ID: 109746
   Summary: Fails removing redundant comparison in for loop over
multiple variables, unless members of struct
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: magnus.hegdahl at gmail dot com
  Target Milestone: ---

Compiled with g++ (GCC) 13.1.1 20230429 on x86-64 Linux, with -O2 or higher.

In the code below, the comparisons with i are redundant because j is increasing
much faster.
GCC manages to optimize this away when i and j are members of some struct, but
not when they are just integers.

struct S {
  unsigned x;
};

unsigned f() {
  unsigned N = 1e9, x = 0;
  for (unsigned i = 3, j = 1; i < N && j < N; i += 2, j += 3)
x ^= i * j;
  return x;
}

unsigned g() {
  unsigned N = 1e9, x = 0;
  for (S i {3}, j {1}; i.x < N && j.x < N; i.x += 2, j.x += 3)
x ^= i.x * j.x;
  return x;
}

int main() {
  return f();
}

[Bug c++/109745] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Carlos Galvez  ---
In case it wasn't clear: the test passes also on O0 - it only fails when
increasing from O1 all the way to O3.

[Bug c++/109745] New: Incorrect code generated with -O1 when having a constexpr object modifying a mutable member

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 109745
   Summary: Incorrect code generated with -O1 when having a
constexpr object modifying a mutable member
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Hi!

We are bumping our GCC installation from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
07c52d1eec9671af92b7ce977b469f13a87887ad and one of our unit tests fails. I
have managed to reduce the code to the following minimal example, compiled with
-std=c++14 -O1:

#include 
#include 

template 
class Foo {
   public:
constexpr Foo() : has_value_{true} {}

Foo(Foo const& other) {
if (other.hasValue()) {
static_cast(new (_) T(other.value()));
has_value_ = true;
}
}

constexpr bool hasValue() const { return has_value_; }
constexpr T const& value() const { return value_; }

   private:
T value_{};
bool has_value_{false};
};

enum class State {
initialized,
copy_constructed,
copied_from,
};

class Stateful {
   public:
constexpr Stateful() = default;
constexpr Stateful(Stateful const& other)
: state_{State::copy_constructed} {
other.state_ = State::copied_from;
}
constexpr State state() const { return state_; }

   private:
mutable State state_{State::initialized};
};

int main() {
constexpr Foo x{};
const Foo y{x};
assert(State::copied_from == x.value().state());
}

Godbolt: https://godbolt.org/z/oTd8M9P91

The problem seems to also appear between GCC 12.2 and 13.1.
The test runs fine on Clang trunk.

One observation is that if I make "x" 'const' instead of 'constexpr', the test
passes.

Do we have UB in our code, or is this an actual regression in GCC?

Thanks!

[Bug c/109744] mesa/panvk: bogus Warray-bounds on gcc 12.2, fixed in 13 branch

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
Please include the flags needed to reproduce (i.e. the compiler
invocation/compile line) for these bugs.

[Bug libgomp/108098] OpenMP/nvptx reverse offload execution test FAILs

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:4359724cba31b2645f6106266bef019c3d6ef16a

commit r14-491-g4359724cba31b2645f6106266bef019c3d6ef16a
Author: Tobias Burnus 
Date:   Fri May 5 11:27:32 2023 +0200

nvptx/mkoffload.cc: Add dummy proc for OpenMP rev-offload table [PR108098]

Seemingly, the ptx JIT of CUDA <= 10.2 replaces function pointers in global
variables by NULL if a translation does not contain any executable code. It
works with CUDA 11.1.  The code of this commit is about reverse offload;
having NULL values disables the side of reverse offload during image load.

Solution is the same as found by Thomas for a related issue: Adding a dummy
procedure. Cf. the PR of this issue and Thomas' patch
"nvptx: Support global constructors/destructors via 'collect2'"
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607749.html

As that approach also works here:

Co-authored-by: Thomas Schwinge 

gcc/
PR libgomp/108098

* config/nvptx/mkoffload.cc (process): Emit dummy procedure
alongside reverse-offload function table to prevent NULL values
of the function addresses.

[Bug c/109744] New: bogus Warray-bounds on gcc 12.2, fixed in 13 branch

[david at ixit dot cz via Gcc-bugs]

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

Bug ID: 109744
   Summary: bogus Warray-bounds on gcc 12.2, fixed in 13 branch
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at ixit dot cz
  Target Milestone: ---
  Host: x86_64
Target: x86_64

Created attachment 55006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55006=edit
panvk_cmd_buffer.c.i.gz

Compiler: gcc version 12.2.0 (Debian 12.2.0-14) 
!!! Fixed in: gcc version 13.0.1 20230315 (experimental) [master
r13-6680-ga9ae16db8cb] (Debian 20230315-1) 
Commands:
meson setup builddir-snapshot -D libdir=lib -D buildtype=release -D
build-tests=false -D enable-glcpp-tests=false -D libunwind=enabled -D glx=dri
-D gbm=enabled -D egl=enabled -D platforms=x11,wayland -D dri3=enabled -D
gallium-extra-hud=true -D gallium-vdpau=disabled -D gallium-omx=disabled -D
gallium-va=disabled -D gallium-xa=disabled -D gallium-nine=false -D
gallium-opencl=disabled -D gallium-rusticl=false -D llvm=enabled -D
gallium-drivers=r300,i915,iris,swrast -D vulkan-drivers=panfrost -D
video-codecs=h264dec,h264enc,h265dec,h265enc -D spirv-to-dxil=false -D
osmesa=true -D intel-clc=disabled -D imagination-srv=false -Dc_args=-save-temps
-Dcpp_args=-save-temps
cd builddir-snapshot && meson compile

```
[756/1419] Compiling C object
src/panfrost/vulkan/libvulkan_panfrost.so.p/panvk_cmd_buffer.c.o
In file included from ../src/vulkan/runtime/vk_command_buffer.h:32,
 from ../src/panfrost/vulkan/panvk_private.h:53,
 from ../src/panfrost/vulkan/panvk_cmd_buffer.c:29:
In function ‘util_dynarray_init’,
inlined from ‘panvk_CmdBeginRenderPass2’ at
../src/panfrost/vulkan/panvk_cmd_buffer.c:507:4:
../src/util/u_dynarray.h:58:4: warning: ‘memset’ offset [0, 15] is out of the
bounds [0, 0] [-Warray-bounds]
   58 |memset(buf, 0, sizeof(*buf));
  |^~~~
```

Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8638

Feel free to close, if there is no intention to backport fix from 13 branch.

[Bug libgomp/66005] libgomp make check time is excessive

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Thomas Schwinge  ---
  -

"Support parallel testing in libgomp, part I [PR66005]"
  -

"Support parallel testing in libgomp, part II [PR66005]"

[Bug tree-optimization/109714] mesa/aux/draw_llvm: bogus "may be used uninitialized warning"

[david at ixit dot cz via Gcc-bugs]

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

--- Comment #5 from David Heidelberg (okias)  ---
Created attachment 55005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55005=edit
meson-setup-output.txt