[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 Christoph Reiter changed: What|Removed |Added CC||tneumann at users dot sourceforge. ||net --- Comment #7 from Christoph Reiter --- Yes, I can confirm that reverting https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1c118c9970600117700cc12284587e0238de6bbe on top of 13.1.0 fixes exception handling, and cmake/ada/gdb work again.
[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #6 from LIU Hao --- Try reverting 1c118c9970600117700cc12284587e0238de6bbe?
[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017
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
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
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
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
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
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)
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
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109754 --- Comment #2 from Andrew Pinski --- Reducing ...
[Bug target/109690] bad SLP vectorization on zen
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
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
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
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&action=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
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
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
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
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
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"
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
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
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
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 &operator++(); iterator &operator++(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
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&action=edit Reduced testcase as far as I can get it
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
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.
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&action=edit Preprocessed source copied from the godbolt live link.
[Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13
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&action=edit Preprocessed source copied from the godbolt live link included in the original text.
[Bug c++/109750] Incorrect code generated for shifted bit field
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
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
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
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
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
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
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
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
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&action=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
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
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 > > &typeid(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"
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"
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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] https://gcc.gnu.org/legacy-ml/gcc
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
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
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
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
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
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&action=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
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
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
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
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
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
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
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
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
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
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
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
* 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
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)
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
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
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
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 (&value_) 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
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
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
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&action=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.