[Bug c/105270] gcc hangs with error "symbol definition loop encountered"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105270 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- Please report this to binutils (http://sourceware.org/bugzilla/) since it is the assembler which is causing the issue rather than GCC.
[Bug target/105271] New: ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105271 Bug ID: 105271 Summary: ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-e300c3-linux-gnu gcc 12.0.1 20220410 snapshot (g:54c5e064cc3dc3c9b3dff12b6d48dc3efd482b07) ICEs when compiling gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c w/ -mvsx for 32-bit BE powerpc target: % powerpc-e300c3-linux-gnu-gcc-12.0.1 -mvsx -c gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c In file included from gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c:8: gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.h: In function 'test3': gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.h:16:1: error: unrecognizable insn: 16 | } | ^ (insn 8 7 11 2 (set (reg:V2DI 117 [ _2 ]) (minus:V2DI (reg:V2DI 120) (reg:V2DI 119))) "gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.h":15:10 -1 (nil)) during RTL pass: vregs gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.h:16:1: internal compiler error: in extract_insn, at recog.cc:2791 0x690b53 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/rtl-error.cc:108 0x690b71 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/rtl-error.cc:116 0x68f485 extract_insn(rtx_insn*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/recog.cc:2791 0xada6c5 instantiate_virtual_regs_in_insn /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/function.cc:1611 0xada6c5 instantiate_virtual_regs /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/function.cc:1985 0xada6c5 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/function.cc:2034
[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #26 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:53254184bda6305ac38e6e37480303b9f167b5ae commit r11-9879-g53254184bda6305ac38e6e37480303b9f167b5ae Author: Iain Sandoe Date: Mon Feb 7 15:36:35 2022 + Darwin, rs6000: Amend lo_sum use for forced constants [PR104117]. Two issues resulted in this PR, which manifests when we force a constant into memory in LRA (in PIC code on Darwin). The presence of such forced constants is quite dependent on other RTL optimisations, and it is easy for the issue to become latent for a specific case. First, in the Darwin-specific rs6000 backend code, we were not being careful enough in rejecting invalid symbolic addresses. Specifically, when generating PIC code, we require a SYMBOL_REF to be wrapped in an UNSPEC_MACHOPIC_OFFSET. We now split the Darwin high/low selectors into two: 1. One that handles non-PIC addresses (kernel mode, mdynamic-no-pic). 2. One that handles PIC addresses and rejects SYMBOL_REFs unless they are suitably wrapped in the MACHOPIC_OFFSET unspec. The second case is handled by providing a new predicate (macho_pic_address) that checks the requirements. Backported from 4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84 and f1b3e3853329b58fb2e50c17487df2ecbc4a5608 Signed-off-by: Iain Sandoe Co-authored-by: Vladimir Makarov PR target/104117 gcc/ChangeLog: * config/rs6000/rs6000.c (darwin_rs6000_legitimate_lo_sum_const_p): Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses when emitting PIC code. (legitimate_lo_sum_address_p): Likewise. (rs6000_legitimize_address): Do not apply the TLS processing to Darwin. * config/rs6000/darwin.md (@machopic_high_): New. (@machopic_low_): New. * config/rs6000/predicates.md (macho_pic_address): New.
[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 --- Comment #65 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:94c9c6acdc14de186abe4ea59c54920fbfb60beb commit r11-9878-g94c9c6acdc14de186abe4ea59c54920fbfb60beb Author: Iain Sandoe Date: Sat Sep 18 23:38:53 2021 +0100 Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556]. This addresses a long-standing problem where a work-around for an unwinder issue (also a regression) regresses other functionality. The patch replaces several work-arounds with a fix for PR80556 and a work-around for PR88590. * The fix for PR80556 requires a bump to the SO name for libgcc_s, since we need to remove the unwinder symbols from it. This would trigger PR88590 hence the work-around for that. * We weaken the symbols for emulated TLS support so that it is possible for a DSO linked with static-libgcc to interoperate with a DSO linked with libgcc_s. Likewise main exes. * We remove all the gcc-4.2.1 era stubs machinery and workarounds. * libgcc is always now linked ahead of libc, which avoids fails where the libc (libSystem) builtins implementations are not up to date. * The unwinder now always comes from the system - for Darwin9 from /usr/lib/libgcc_s.1.dylib - for Darwin10 from /usr/lib/libSystem.dylib - for Darwin11+ from /usr/lib/system/libunwind.dylib. We still insert a shim on Darwin10 to fix an omitted unwind function, but the underlying unwinder remains the system one. * The work-around for PR88590 has two parts (1) we always link libgcc from its convenience lib on affected system versions (avoiding the need to find the DSO path); (2) we add and export the emutls functions from DSOs - this makes a relatively small (20k) addition to a DSO. These can be backed out when a proper fix for PR88590 is committed. For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage from exes that linked against the stubs can use a reexported libgcc_s.1.1 (since that contains all the symbols that were previously exported via the stubs). The replacement libgcc_s.1 forwards the symbols from the new SO. In order to support DYLD_LIBRARY_PATH on systems (where it works) we forward the libSystem unwinder symbols from 10.7+ and a compiler-local version of the libgcc unwinder on earlier. For macOS 10.4 to 10.6 this is 'bug-compatible' with existing uses. For 10.7+ the behaviour will now actually be correct. Backported from commits d4943ce939d9654932624b9ece24c3a474ae4157, 7add7f7bb3d35726a0c45322ffdbbab2bbf6a348, b504917e43b9a559c9ac779e08784ad412125f2e, 32731fa5b0abf092029b8e2be64319b978bda514, 574c09da48a5a0ff4c32dd4577eaf65bac8c94a0 and c18ddb05b0391a397f8882fc6a12a1bab7e0df52 Signed-off-by: Iain Sandoe gcc/ChangeLog: PR target/80556 * config/darwin-driver.c (darwin_driver_init): Handle exported symbols and symbol lists (suppress automatic export of the TLS symbols). * config/darwin.c (darwin_rename_builtins): Remove workaround. * config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise. (REAL_LIBGCC_SPEC): Handle revised library uses. * config/darwin.opt (nodefaultexport): New. * config/i386/darwin.h (PR80556_WORKAROUND): Remove. * config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise. * config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise. libgcc/ChangeLog: * config.host: Add weak emutls crt to the extra_parts. (*-*-darwin*): Add logic to build a shared unwinder library for Darwin8-10. Add shim declaration header to powerpc*-darwin builds. * config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove workaround. * config/libgcc-libsystem.ver: Add exclude list for the system- provided unwinder. * config/t-slibgcc-darwin: Bump SO version, remove stubs code. Build a legacy libgcc_s.1 and the supporting pieces (all FAT libs). * config/t-darwin-ehs: Add dependencies to the shared unwinder objects. Add dependency on unwind.h. * config/t-darwin: Reorganise the EH fragments to place them for inclusion in a shared EH lib. Add libgcc_tm.h to the dependencies for darwin10-unwind-find-enc-func. * config/i386/libgcc-darwin.10.4.ver: Removed. * config/i386/libgcc-darwin.10.5.ver: Removed. * config/rs6000/libgcc-darwin.10.4.ver: Removed. * config/rs6000/libgcc-darwin.10.5.ver: Removed. * config/i386/t-darwin: Build legacy libgcc_s.1. * config/rs6000/t-darwin: Likewise. * config/rs6000/t-darwin-ehs: Remove dependency on
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #38 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:6841e9fc63b260186f8c980c7e0534b6376b073f commit r11-9873-g6841e9fc63b260186f8c980c7e0534b6376b073f Author: Iain Sandoe Date: Thu Nov 4 09:37:14 2021 + IPA: Provide a mechanism to register static DTORs via cxa_atexit. For at least one target (Darwin) the platform convention is to register static destructors (i.e. __attribute__((destructor))) with __cxa_atexit rather than placing them into a list that is run by some other mechanism. This patch provides a target hook that allows a target to opt into this and handling for the process in ipa_cdtor_merge (). When the mode is enabled (dtors_from_cxa_atexit is set) we: * Generate new CTORs to register static destructors with __cxa_atexit and add them to the existing list of CTORs; we then process the revised CTORs list. * We sort the DTORs into priority and then TU order, this means that they are registered in that order with __cxa_atexit () and therefore will be run in the reverse order. * Likewise, CTORs are sorted into priority and then TU order, which means that they will run in that order. This matches the behavior of using init/fini (or mod_init_func/mod_term_func) sections. This also fixes a bug where Fortran needs a DTOR to be run to close IO. Signed-off-by: Iain Sandoe PR fortran/102992 gcc/ChangeLog: * config/darwin.h (TARGET_DTORS_FROM_CXA_ATEXIT): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Add TARGET_DTORS_FROM_CXA_ATEXIT hook. * ipa.c (cgraph_build_static_cdtor_1): Return the built function decl. (build_cxa_atexit_decl): New. (build_dso_handle_decl): New. (build_cxa_dtor_registrations): New. (compare_cdtor_tu_order): New. (build_cxa_atexit_fns): New. (ipa_cdtor_merge): If dtors_from_cxa_atexit is set, process the DTORs/CTORs accordingly. (pass_ipa_cdtor_merge::gate): Also run if dtors_from_cxa_atexit is set. * target.def (dtors_from_cxa_atexit): New hook. (cherry picked from commit fabe8cc41e9b01913e2016861237d1d99d7567bf)
[Bug jit/100613] libgccjit should produce dylib on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100613 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:846d19e44c85c83a50e51867d854f8d98a087a77 commit r11-9857-g846d19e44c85c83a50e51867d854f8d98a087a77 Author: Iain Sandoe Date: Thu Aug 5 09:55:19 2021 +0100 Darwin, jit: Fix build [PR100613]. The generic unix build is not completely suitable for Darwin platforms: * It is a convention to encode the library versioning in the binary and to have only one level of symlink for the installed files. This needs to be applied to the installation too. * The library needs to be built with its correct install name so that two-level library naming works. * The extension for shared libraries should be .dylib Signed-off-by: Iain Sandoe PR jit/100613 - libgccjit should produce dylib on macOS PR jit/100613 gcc/jit/ChangeLog: * Make-lang.in: Provide clauses for Darwin hosts. (cherry picked from commit 08defd9c4e4f8dc428f2f490705ab816af81a03d)
[Bug c/105270] New: gcc hangs with error "symbol definition loop encountered"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105270
Bug ID: 105270
Summary: gcc hangs with error "symbol definition loop
encountered"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenyang.xu at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/xuzhy/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.X0iCNYeprY-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/home/xuzhy/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220414 (experimental) [master -g8369b4e4c] (GCC)
$ cat test.c
a() { asm("); b = b if 0 return 1 if (b.get_type
[Bug target/104482] ICE: Segmentation fault (in rs6000_builtin_type_compatible), or ICE: tree check: expected class 'type', have 'reference' (attr_addr_expr) in cp_type_quals, at cp/typeck.cc:10955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482 Kewen Lin changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-April/5 ||93155.html --- Comment #3 from Kewen Lin --- patch v2 with better commit logs and one test case: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593155.html
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-April/5 ||93216.html Ever confirmed|0 |1 Last reconfirmed||2022-04-14 Status|UNCONFIRMED |ASSIGNED
[Bug c++/65211] [9/10/11/12 Regression] Type alignment lost inside templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65211 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8369b4e4c6433535981d377edc1d4abb799c9225 commit r12-8153-g8369b4e4c6433535981d377edc1d4abb799c9225 Author: Jason Merrill Date: Wed Apr 13 21:56:03 2022 -0400 c++: alignment of local typedef in template [PR65211] Because common_handle_aligned_attribute only applies the alignment to the TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it explicitly in tsubst. PR c++/65211 gcc/cp/ChangeLog: * pt.cc (tsubst_decl) [TYPE_DECL]: Copy TYPE_ALIGN. gcc/testsuite/ChangeLog: * g++.target/i386/vec-tmpl1.C: New test.
[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
This is like PR105147, we need dg-skip for powerpc and s390 like what we did in
PR105147, the fix could be like:
/* { dg-skip-if "PR105266" { powerpc*-*-* s390*-*-* } } */
[Bug c++/105268] type/value mismatch when using variadic concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268
--- Comment #2 from Marek Polacek ---
Looks like we mistakenly parse C_many as a placeholder-type-specifier, and
things go wrong from there.
For C_one cp_parser_placeholder_type_specifier -> finish_type_constraints
-> build_type_constraint -> build_concept_check -> build_standard_check ->
coerce_template_parms -> coerce_template_parms fails here:
8916 nargs = inner_args ? NUM_TMPL_ARGS (inner_args) : 0;
8917 if ((nargs - variadic_args_p > nparms && !variadic_p)
8918 || (nargs < nparms - variadic_p
8919 && require_all_args
8920 && !variadic_args_p
8921 && (!use_default_args
8922 || (TREE_VEC_ELT (parms, nargs) != error_mark_node
8923 && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))
8924 {
8925 bad_nargs:
but for C_many variadic_p is true so we don't return error_mark_node but
.
[Bug c++/65211] [9/10/11/12 Regression] Type alignment lost inside templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65211 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug libstdc++/105269] New: missing some library feature test macros in c++20 and c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105269 Bug ID: 105269 Summary: missing some library feature test macros in c++20 and c++23 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: cooky.ykooc922 at gmail dot com Target Milestone: --- Given the code: #include #ifndef __cpp_lib_constexpr_vector # warning "__cpp_lib_constexpr_vector is not defined" #endif #ifndef __cpp_lib_stdatomic_h # warning "__cpp_lib_stdatomic_h is not defined" #endif #ifdef __cpp_lib_monadic_optional # warning "__cpp_lib_monadic_optional shouldn't be defined since LWG3621" # if __cpp_lib_optional != 202110L # warning "__cpp_lib_optional value should be adjusted to 202110L since LWG3621" # endif #endif all warnings are emitted: :4:5: warning: #warning "__cpp_lib_constexpr_vector is not defined" [-Wcpp] 4 | # warning "__cpp_lib_constexpr_vector is not defined" | ^~~ :8:5: warning: #warning "__cpp_lib_stdatomic_h is not defined" [-Wcpp] 8 | # warning "__cpp_lib_stdatomic_h is not defined" | ^~~ :12:5: warning: #warning "__cpp_lib_monadic_optional shouldn't be defined since LWG3621" [-Wcpp] 12 | # warning "__cpp_lib_monadic_optional shouldn't be defined since LWG3621" | ^~~ :14:9: warning: #warning "__cpp_lib_optional value should be adjusted to 202110L since LWG3621" [-Wcpp] 14 | # warning "__cpp_lib_optional value should be adjusted to 202110L since LWG3621" | ^~~ Compiler returned: 0 godbolt link: https://godbolt.org/z/Y9Wqccnv3 since: - https://github.com/gcc-mirror/gcc/commit/1ae8edf5f73ca5c3bf132cc52825dc1f709499dd is committed to implementing constexpr std::vector (C++20) - https://github.com/gcc-mirror/gcc/commit/d7f2a09e98520c4e4927f460ad96803b05a205b1 is committed to implementing (P0943 has __cpp_lib_stdatomic_h provided) (C++23) - https://github.com/gcc-mirror/gcc/commit/82b2e4f8cf5a01c6724fe3f465a77ee03cfcaae2 is commited to implementing monadic operations (before LWG3621 is adopted) (C++23)
[Bug target/102146] [11 regression] several test cases fails after r11-8940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146 --- Comment #10 from HaoChen Gui --- (In reply to HaoChen Gui from comment #9) > Could you backport the patch to GCC11? Thanks. Please ignore it as the patch has problem. Thanks.
[Bug target/102146] [11 regression] several test cases fails after r11-8940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146 --- Comment #9 from HaoChen Gui --- Could you backport the patch to GCC11? Thanks.
[Bug c++/101698] [9/10/11 Regression] Template type conversion operator from base class preferred over matching overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101698 Jason Merrill changed: What|Removed |Added Known to work||12.0 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Known to fail|12.0| Status|NEW |ASSIGNED Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Template type conversion|Template type conversion |operator from base class|operator from base class |preferred over matching |preferred over matching |overload|overload
[Bug c++/97219] [9/10/11 Regression] Generic lambda does not find function declaration from enclosing block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97219 Jason Merrill changed: What|Removed |Added Known to work||12.0 Status|NEW |ASSIGNED Assignee|nathan at gcc dot gnu.org |jason at gcc dot gnu.org Known to fail|12.0| Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Generic lambda does not |Generic lambda does not |find function declaration |find function declaration |from enclosing block scope |from enclosing block scope
[Bug c++/97219] [9/10/11/12 Regression] Generic lambda does not find function declaration from enclosing block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97219 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1824da60663b4532199ecd051d8ba6da8995821d commit r12-8152-g1824da60663b4532199ecd051d8ba6da8995821d Author: Jason Merrill Date: Wed Apr 13 16:42:25 2022 -0400 c++: local fn and generic lambda [PR97219] When instantiating the op() for a generic lambda, we can no longer do name lookup inside function scopes enclosing the lambda, so we need to remember the lookup result from processing the definition of the lambda. So the code in finish_call_expr to throw away the lookup result and instead look it up again at instantiation time needs to be adjusted. The approach I take is to only discard the result if the local extern comes from dependent scope; once the enclosing function template is instantiated and we're regenerating the lambda, then we can remember the result of lookup. We also need any default arguments to be instantiated at that point. PR c++/97219 gcc/cp/ChangeLog: * name-lookup.cc (dependent_local_decl_p): New. * cp-tree.h (dependent_local_decl_p): Declare. * semantics.cc (finish_call_expr): Use it. * pt.cc (tsubst_arg_types): Also substitute default args for local externs. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-local-fn1.C: New test.
[Bug c++/101698] [9/10/11/12 Regression] Template type conversion operator from base class preferred over matching overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101698 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:d4e00ccef6c706a4a4a6446bffaf4111f98d5771 commit r12-8151-gd4e00ccef6c706a4a4a6446bffaf4111f98d5771 Author: Jason Merrill Date: Wed Apr 13 14:49:04 2022 -0400 c++: template conversion op [PR101698] Asking for conversion to a dependent type also makes a BASELINK dependent. PR c++/101698 gcc/cp/ChangeLog: * pt.cc (tsubst_baselink): Also check dependent optype. gcc/testsuite/ChangeLog: * g++.dg/template/conv19.C: New test.
[Bug c++/101442] [9/10/11/12 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ad8161e6d7b26d690d90069ae9a129e7ac36892a commit r12-8150-gad8161e6d7b26d690d90069ae9a129e7ac36892a Author: Jason Merrill Date: Wed Apr 13 13:23:08 2022 -0400 c++: NRV and ref-extended temps [PR101442] This issue goes back to r83221, where the cleanup for extended ref temps changed from being unconditional to being tied to the declaration they formed part of the initializer for. The named return value optimization changes the cleanup for the NRV variable to only run on the EH path; we don't want that change to affect temporary cleanups. The perform_member_init change isn't necessary (there 'decl' is a COMPONENT_REF), it's just for consistency. PR c++/101442 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Don't pass decl to push_cleanup. * init.cc (perform_member_init): Likewise. * semantics.cc (push_cleanup): Adjust comment. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-nrv1.C: New test.
[Bug c++/100838] [11 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:019d6d4149ee97d55ce9efe4e5e470d38130cdeb commit r12-8149-g019d6d4149ee97d55ce9efe4e5e470d38130cdeb Author: Jason Merrill Date: Wed Apr 13 12:44:54 2022 -0400 c++: add test [PR105265] This was fixed by r12-1165, but good to have a test that doesn't need -fno-elide-constructors. PR c++/105265 PR c++/100838 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-new6.C: New test.
[Bug c++/105265] [9/10/11 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:019d6d4149ee97d55ce9efe4e5e470d38130cdeb commit r12-8149-g019d6d4149ee97d55ce9efe4e5e470d38130cdeb Author: Jason Merrill Date: Wed Apr 13 12:44:54 2022 -0400 c++: add test [PR105265] This was fixed by r12-1165, but good to have a test that doesn't need -fno-elide-constructors. PR c++/105265 PR c++/100838 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-new6.C: New test.
[Bug c++/105268] type/value mismatch when using variadic concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-04-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/105268] New: type/value mismatch when using variadic concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105268
Bug ID: 105268
Summary: type/value mismatch when using variadic concept
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
>From StackOverflow (https://stackoverflow.com/q/71864544/2069064):
template concept C_one = true;
template concept C_many = true;
template struct S { };
template>> void f(); // ok
template>> void g(); // error
gcc rejects the declaration of g with:
:7:35: error: type/value mismatch at argument 1 in template parameter
list for 'template struct S'
7 | template>> void g();
| ^~
:7:35: note: expected a constant of type 'bool', got
''
But C_many is a bool, so this should be fine. And template-parameter-1-1
isn't a very useful diagnostic anyway.
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 --- Comment #9 from David Malcolm --- (In reply to Kamil Dudka from comment #8) > As spotted by Vincent Mihalkovic, the fix seems to be incomplete. If we run > gcc-12.0.1-0.14.fc37.x86_64 on the following test-case, some diagnostic > messages are still printed without any location info: Thanks; I'm testing a fix.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #7 from Andrew Pinski --- mongodb is using these two values incorrectly and even misunderstanding what they mean. hardware_constructive_interference_size means the Minimum offset between two objects which will avoid false sharing. So if you have two objects that are that distant apart, then there will be NO false sharing at all (some offsets smaller might also work too but it depends on the HW which is run on). While hardware_constructive_interference_size says the maxium offset between two obejcts which will promote true sharing. That is if the two objects are within that alignment, there is a guarantee that there will be sharing. So if they want to guarantee true sharing, then they need to have it as aligned to hardware_constructive_interference_size and make sure the size is smaller than hardware_constructive_interference_size . So In this case Together should be aligned to hardware_constructive_interference_size . The other CacheAligned cases need to be looked into make sure they are using the correct values too. Depending on what they are trying to do.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #6 from Khem Raj --- this is from mongodb.
[Bug testsuite/105267] New: [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105267 Bug ID: 105267 Summary: [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:6b7cc7294770ecb57c0f3a116a27ce1aaff170b5, r12-8128-g6b7cc7294770ec make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr56605.c" FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):(?:[SD]I) \\((?:sub)?reg:[SD]I" 1 # of expected passes1 # of unexpected failures1 commit 6b7cc7294770ecb57c0f3a116a27ce1aaff170b5 (HEAD, refs/bisect/bad) Author: Alexandre Oliva Date: Tue Apr 12 22:41:45 2022 -0300 ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146]
[Bug testsuite/105266] New: new test case gcc.dg/pr105250.c fails in r12-8134-g4e892de6774f86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266 Bug ID: 105266 Summary: new test case gcc.dg/pr105250.c fails in r12-8134-g4e892de6774f86 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:4e892de6774f86540d36385701aa7b0a2bba5155, r12-8134-g4e892de6774f86 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr105250.c" FAIL: gcc.dg/pr105250.c (test for excess errors) # of unexpected failures1 FAIL: gcc.dg/pr105250.c (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr105250.c:28:8: error: AltiVec argument passed to unprototyped function commit 4e892de6774f86540d36385701aa7b0a2bba5155 (HEAD, refs/bisect/bad) Author: Richard Biener Date: Wed Apr 13 08:52:57 2022 +0200 tree-optimization/105250 - adjust fold_convertible_p PR105140 fix
[Bug jit/104293] Add support for setting the alignment of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/104073] Add option to hide stderr logging in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/104072] Register variables in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/104071] Add support for bitcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #5 from David Malcolm --- Marking as resolved; please reopen if there's an issue integrating the version of the patch I committed with rustc_codegen_gcc.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #5 from Andrew Pinski --- (In reply to Khem Raj from comment #4) > I dont think its a bug per-se, I am looking for fixing it right way. Should > I pass a non-default value via gcc cmdline or adjust the size expectations > in code. Well adjusting the code is correct fix. But adjusting to what is more for the developers of that code. Where does this code show up and that might help us help you.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #4 from Khem Raj --- I dont think its a bug per-se, I am looking for fixing it right way. Should I pass a non-default value via gcc cmdline or adjust the size expectations in code.
[Bug c++/97165] [9/10/11/12 Regression] Infinite error stream on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97165 Marek Polacek changed: What|Removed |Added Priority|P2 |P5 --- Comment #4 from Marek Polacek --- The code is complete gibberish, downgrading to P5.
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #15 from Marek Polacek ---
Better test:
struct S {
struct Prefs {
struct {
int i = j;
int j = 42;
} p;
void Load();
};
};
void S::Prefs::Load() {
*this = {};
};
[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.5 Summary|ICE compiling firefox-99|[9/10/11/12 Regression] ICE ||compiling firefox-99 Status|WAITING |NEW Priority|P3 |P2 --- Comment #14 from Marek Polacek --- The testcase in the previous comment started to ICE with r258593: commit 570f86f94eca76fbfab919dcbfe639a5ba69f20e Author: Jakub Jelinek Date: Fri Mar 16 13:46:12 2018 +0100 re PR c++/79937 (ICE in replace_placeholders_r) So confirmed. I'm not sure this is the same ICE Chris saw though...
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
--- Comment #13 from Marek Polacek ---
This reduced code crashes with GCC 8 up to trunk:
struct S {
struct Prefs {
struct {
int i = i;
} p;
void Load();
};
};
void S::Prefs::Load() {
*this = {};
};
$ xg++ -c ff.C
ff.C: In member function ‘void S::Prefs::Load()’:
ff.C:11:12: internal compiler error: in gimplify_expr, at gimplify.cc:15905
11 | *this = {};
|^
0x1370253 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.cc:15905
0x13360f8 gimplify_compound_lval
/home/mpolacek/src/gcc/gcc/gimplify.cc:3272
0x136cfa4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.cc:15050
0x133bc99 gimplify_init_ctor_preeval
/home/mpolacek/src/gcc/gcc/gimplify.cc:4781
0x133bc48 gimplify_init_ctor_preeval
/home/mpolacek/src/gcc/gcc/gimplify.cc:4767
0x133bc48 gimplify_init_ctor_preeval
/home/mpolacek/src/gcc/gcc/gimplify.cc:4767
0x133d603 gimplify_init_constructor
/home/mpolacek/src/gcc/gcc/gimplify.cc:5357
0x133e452 gimplify_modify_expr_rhs
/home/mpolacek/src/gcc/gcc/gimplify.cc:5674
0x133f66f gimplify_modify_expr
/home/mpolacek/src/gcc/gcc/gimplify.cc:6040
0x136d142 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.cc:15098
0x1343c11 gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.cc:7151
0x1343164 gimplify_cleanup_point_expr
/home/mpolacek/src/gcc/gcc/gimplify.cc:6892
0x136ebdb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.cc:15491
0x1343c11 gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.cc:7151
0x1371bfb gimplify_body(tree_node*, bool)
/home/mpolacek/src/gcc/gcc/gimplify.cc:16355
0x13722f8 gimplify_function_tree(tree_node*)
/home/mpolacek/src/gcc/gcc/gimplify.cc:16509
0x10c08c9 cgraph_node::analyze()
/home/mpolacek/src/gcc/gcc/cgraphunit.cc:676
0x10c2955 analyze_functions
/home/mpolacek/src/gcc/gcc/cgraphunit.cc:1241
0x10c5b05 symbol_table::finalize_compilation_unit()
/home/mpolacek/src/gcc/gcc/cgraphunit.cc:2501
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #12 from Marek Polacek --- (In reply to Martin Liška from comment #11) > Marek, what -std do you use? I see the following compilation errors: -std=c++17, but I saw that error too, followed by a crash with GCC 11.
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #11 from Martin Liška --- Marek, what -std do you use? I see the following compilation errors: /home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h:638:74: error: ‘static void nsFrameList::operator delete(void*)’ is private within this context In file included from /home/chris/rpm/BUILD/firefox-99.0.1/layout/base/nsFrameManager.h:14, from /home/chris/rpm/BUILD/firefox-99.0.1/obj-dir/dist/include/mozilla/PresShell.h:36, from /home/chris/rpm/BUILD/firefox-99.0.1/obj-dir/dist/include/mozilla/dom/DocumentInlines.h:11, from /home/chris/rpm/BUILD/firefox-99.0.1/layout/style/ImageLoader.cpp:14: /home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsFrameList.h:571:8: note: declared private here /home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h: In member function ‘nsFrameList* nsContainerFrame::SetOverflowContainers(nsFrameList&&)’: /home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h:648:78: error: ‘static void nsFrameList::operator delete(void*)’ is private within this context /home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsFrameList.h:571:8: note: declared private here /home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h: In member function ‘nsFrameList* nsContainerFrame::SetExcessOverflowContainers(nsFrameList&&)’: /home/chris/rpm/BUILD/firefox-99.0.1/layout/generic/nsContainerFrame.h:661:75: error: ‘static void nsFrameList::operator delete(void*)’ is private within this context Both with master and GCC 11.x.
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #10 from Marek Polacek --- (In reply to Andrew Pinski from comment #9) > (In reply to Marek Polacek from comment #8) > > In fact I see the ICE even without any options. > > > > Looks like for the NSDMI of mFocusText > > leaks into the gimplifier. But I cannot reproduce this with gcc 11 on a > > different box, weird. > > Maybe PR 104583? I think that's unlikely. I'm trying to reduce the #c3/#c4 .ii. Let's see if I get anywhere...
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #9 from Andrew Pinski --- (In reply to Marek Polacek from comment #8) > In fact I see the ICE even without any options. > > Looks like for the NSDMI of mFocusText > leaks into the gimplifier. But I cannot reproduce this with gcc 11 on a > different box, weird. Maybe PR 104583?
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #8 from Marek Polacek --- In fact I see the ICE even without any options. Looks like for the NSDMI of mFocusText leaks into the gimplifier. But I cannot reproduce this with gcc 11 on a different box, weird.
[Bug c++/51405] Passing method result to constructor treated as function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51405 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Keywords|rejects-valid | Status|NEW |RESOLVED Summary|[9/10/11/12 Regression] |Passing method result to |Passing method result to|constructor treated as |constructor treated as |function declaration |function declaration| Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- (In reply to Andrew Pinski from comment #3) > We started to reject the code in GCC 9 with: > : In function 'int main()': > :43:8: error: trailing return type only available with '-std=c++11' > or '-std=gnu++11' So the bug was fixed in GCC 9. The remaining behavior is just the "most vexing parse": in A a (B::Instance ()->Something ()); We parse a function declaration for a function named a that returns A, with an unnamed parameter which has type function returning B::Instance and a trailing return type of function returning Something, aka int. Now, clearly this is ill-formed, and so we correctly diagnose that the trailing return type requires that the previous declared return type be 'auto'. But this is a semantic rule, not part of the grammar. We could make this work in GCC by catching some of these problems in the parser, but that's not what the standard says. The EDG compiler gives the same error.
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- I see this ICE with GCC 11 with just -O2. Mainline doesn't crash. /home/chris/rpm/BUILD/firefox-99.0.1/layout/style/PreferenceSheet.cpp:181:12: internal compiler error: in gimplify_expr, at gimplify.c:14924 0x126cac0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/mpolacek/src/gcc11/gcc/gimplify.c:14924 0x1236bab gimplify_compound_lval /home/mpolacek/src/gcc11/gcc/gimplify.c:3079 0x1269991 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/mpolacek/src/gcc11/gcc/gimplify.c:14091 0x123c263 gimplify_init_ctor_preeval /home/mpolacek/src/gcc11/gcc/gimplify.c:4546 0x123c212 gimplify_init_ctor_preeval /home/mpolacek/src/gcc11/gcc/gimplify.c:4532 0x123c212 gimplify_init_ctor_preeval /home/mpolacek/src/gcc11/gcc/gimplify.c:4532 0x123dc3f gimplify_init_constructor /home/mpolacek/src/gcc11/gcc/gimplify.c:5127 0x123e99f gimplify_modify_expr_rhs /home/mpolacek/src/gcc11/gcc/gimplify.c:5421 0x123fbae gimplify_modify_expr /home/mpolacek/src/gcc11/gcc/gimplify.c:5784 0x1269b2f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/mpolacek/src/gcc11/gcc/gimplify.c:14139 0x1244105 gimplify_stmt(tree_node**, gimple**) /home/mpolacek/src/gcc11/gcc/gimplify.c:6888 0x124361e gimplify_cleanup_point_expr /home/mpolacek/src/gcc11/gcc/gimplify.c:6630 0x126b5c8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/mpolacek/src/gcc11/gcc/gimplify.c:14532 0x1244105 gimplify_stmt(tree_node**, gimple**) /home/mpolacek/src/gcc11/gcc/gimplify.c:6888 0x12330a6 gimplify_statement_list /home/mpolacek/src/gcc11/gcc/gimplify.c:1880 0x126b975 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/mpolacek/src/gcc11/gcc/gimplify.c:14584 0x1244105 gimplify_stmt(tree_node**, gimple**) /home/mpolacek/src/gcc11/gcc/gimplify.c:6888 0x126e341 gimplify_body(tree_node*, bool) /home/mpolacek/src/gcc11/gcc/gimplify.c:15363 0x126ea3e gimplify_function_tree(tree_node*) /home/mpolacek/src/gcc11/gcc/gimplify.c:15517 0xfe3aba cgraph_node::analyze() /home/mpolacek/src/gcc11/gcc/cgraphunit.c:670
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #6 from Chris Clayton --- I'm struggling to get the compiler command line. The build system is wrapped in a build tool called mach and I'm darned if I can find an argument that will cause it to report the command it is about to launch. The -verbose argument seems to have very little effect on the messages that are output as does the --log-file argument. Hey ho.
[Bug c/97578] [11 Regression] ice during IPA pass: inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578 --- Comment #16 from Martin Jambor --- I tend to think Honza kept the bug open as a reminder to look into things listed in comment #8. Those should probably be tracked in another bug, alternatively this one should be adjusted to reflect that.
[Bug target/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P4 |P3 --- Comment #15 from kargl at gcc dot gnu.org --- It's been over two years, can someone please commit the new path? Testing shows 31 new passes and no regressions. === gcc Summary === w/o patch w patch # of expected passes175405 175434 # of unexpected failures1081 1051 # of unexpected successes 20 20 # of expected failures 1459 1459 # of unresolved testcases 10 10 # of unsupported tests 3252 3252 === g++ Summary === w/o patch w patch # of expected passes225338 225341 # of unexpected failures678676 # of expected failures 2071 2071 # of unresolved testcases 11 11 # of unsupported tests 10353 10353 === gfortran Summary === w/o patch w patch # of expected passes65901 65901 # of unexpected failures12 12 # of expected failures 272272 # of unsupported tests 100100
[Bug tree-optimization/105254] ICE in exact_div, at poly-int.h:2219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/105254] ICE in exact_div, at poly-int.h:2219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:f2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 commit r12-8146-gf2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 Author: Richard Sandiford Date: Wed Apr 13 17:53:54 2022 +0100 aarch64: Make sure the UF divides the VF [PR105254] In this PR, we were trying to set the unroll factor to a value higher than the minimum VF (or more specifically, to a value that doesn't divide the VF). I guess there are two approaches to this: let the target pick any value it likes and make target-independent code pare it back to something that makes sense, or require targets to supply sensible values from the outset. This patch goes for the latter approach. gcc/ PR tree-optimization/105254 * config/aarch64/aarch64.cc (aarch64_vector_costs::determine_suggested_unroll_factor): Take a loop_vec_info as argument. Restrict the unroll factor to values that divide the VF. (aarch64_vector_costs::finish_cost): Update call accordingly. gcc/testsuite/ PR tree-optimization/105254 * g++.dg/vect/pr105254.cc: New test.
[Bug fortran/105242] [OpenMP] ICE with EXIT in collapsed loop: in gfc_trans_exit, at fortran/trans-stmt.cc:6147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105242 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Tobias Burnus --- FIXED on MAINLINE (= GCC 12)
[Bug fortran/105242] [OpenMP] ICE with EXIT in collapsed loop: in gfc_trans_exit, at fortran/trans-stmt.cc:6147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105242 --- Comment #5 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:469fad0161afeb9369010ad498198297993ca592 commit r12-8145-g469fad0161afeb9369010ad498198297993ca592 Author: Tobias Burnus Date: Wed Apr 13 18:40:52 2022 +0200 OpenMP/Fortran: Fix EXIT in loop diagnostic [PR105242] gcc/fortran/ChangeLog: PR fortran/105242 * match.cc (match_exit_cycle): Handle missing OMP LOOP, DO and SIMD directives in the EXIT/CYCLE diagnostic. gcc/testsuite/ChangeLog: PR fortran/105242 * gfortran.dg/gomp/loop-exit.f90: New test.
[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 --- Comment #1 from David Malcolm --- Thanks for filing this bug. I suspect the analyzer is getting confused about the loop index on successive iterations (and state relating to this). Please can you: (a) specify exactly which compilation flags you use to reproduce the false positive, and (b) attach the preprocessed source. You can get this via the -E option to gcc. Thanks!
[Bug c/97578] [11 Regression] ice during IPA pass: inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578 --- Comment #15 from David Binderman --- (In reply to Jakub Jelinek from comment #14) > Resetting to P3, as the state is unknown. I tried out the code in the original bug, and it looks fine to me. $ /home/dcb/gcc/results/bin/gcc -c bug659.c $ /home/dcb/gcc/results/bin/gcc -c -g -O1 bug659.c $ /home/dcb/gcc/results/bin/gcc -c -g -O2 bug659.c $ /home/dcb/gcc/results/bin/gcc -c -g -O3 bug659.c $ /home/dcb/gcc/results/bin/gcc -c -g -O3 -march=native bug659.c $ /home/dcb/gcc/results/bin/gcc -c -g -Ofast -march=native bug659.c $ /home/dcb/gcc/results/bin/gcc -c -g -Os -march=native bug659.c $ /home/dcb/gcc/results/bin/gcc -v 2>&1 | fgrep exp gcc version 12.0.1 20220412 (experimental) (82a4c5c704433249) $
[Bug analyzer/105252] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions since r12-1931-ge61ffa201403e381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug. I'm testing a fix.
[Bug c++/105265] [9/10/11 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/101442] [9/10/11/12 Regression] Destructor not called for a temporary object, if it's bound to a ref member of an object subject to NRVO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101442 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/105265] [9/10/11 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 --- Comment #8 from Jason Merrill --- Probably makes sense to remove that extra condition on the 11 branch now.
[Bug c++/105260] Union with user-defined empty destructor leads to worse code-gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #8 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #7)
> Or find out why SRA doesn't optimize this (remove the useless union, replace
> all the un.value occurrences with a var with Foo type.
IIUC, it just isn't profitable, SRA sees:
un.value = D.2545;
dummyFunc (MEM[(const struct Foo &)]);
un ={v} {CLOBBER(eol)};
and it just cannot avoid ultimately setting up the structure and pass
it to dummyFunc (IPA-SRA does not control that function and so cannot
change it).
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #5 from Chris Clayton --- The .ii file was huge so I've had to split it and then compress the parts
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #4 from Chris Clayton --- Created attachment 52804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52804=edit Second Requested file - part2
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #3 from Chris Clayton --- Created attachment 52803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52803=edit Second requested file - part1
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233 --- Comment #10 from Jakub Jelinek --- Sure, but while for alignas it is the standard that makes it clear, for the attributes it is up to us to decide what to do. Jason said he'd like for GCC 13 us to try making all attribute arguments manifestly const eval and see how far we get with that. As for your #c9 testcase, there is an easy workaround, just add a constexpr var (or static data member etc.) with the value, that will make it clearly manifestly constant evaluated and will work even with older compilers.
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233
--- Comment #9 from Jonathan Strobl ---
Thanks a lot for fixing this so quickly!
Here's my two cents about whether to special-case attribute aligned or whether
to make a general solution: aligned isn't the only attribute that's affected.
It'd also make sense for things like vector_size to evaluate their arguments
with manifestly_const_eval; adding another column in the attribute table
therefore seems like a logical thing to do to me.
However, special-casing aligned for now is of course also a perfectly valid fix
until there's a more general solution.
Here's a small, somewhat realistic test case for vector_size that currently
fails because of the same problem:
constexpr unsigned bit_ceil(unsigned val) {
bool a = __builtin_is_constant_evaluated();
unsigned result = 1;
while (result < val) result <<= 2;
return result;
}
template
struct VecImpl {
typedef __attribute__((vector_size(bit_ceil(sizeof(T) * num T type;
};
using Vec3f = VecImpl::type;
[Bug c++/105200] user-defined operator <=> for enumerated types is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200 --- Comment #5 from Patrick Palka --- (In reply to Jakub Jelinek from comment #2) > If one defines instead say bool operator<(const foo, const foo); > then the built-in candidate isn't considered because of > https://eel.is/c++draft/over.match.oper#3.3 > But for the user operator<=> vs. built-in operator<, they don't have the > same operator name, so the built-in operator< is in the candidate set. I came to the same conclusion but for a different reason. According to p3.3.4 only a "non-member candidate" can prevent a built-in candidate from being considered. And according to p3.2 and p3.4, a user operator<=> is a "rewritten candidate" not a "non-member candidate", and therefore a user operator<=> can't prevent a built-in candidate from being considered (even if their parameter-type-lists are the same).
[Bug fortran/105242] [OpenMP] ICE with EXIT in collapsed loop: in gfc_trans_exit, at fortran/trans-stmt.cc:6147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105242 --- Comment #4 from Tobias Burnus --- Submitted patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593194.html
[Bug c++/105265] [9/10/11 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 --- Comment #7 from Patrick Palka --- (In reply to Jonathan Wakely from comment #6) > But not fixed on gcc-11 by the r11-8715 backport for PR100838, suggesting > there was an earlier change on trunk that affects it. Perhaps that's because of (from the r11-8715 commit message): For GCC 11, limit the changes to -fno-elide-constructors
[Bug c++/105256] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #2 from Chris Clayton --- Created attachment 52802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52802=edit First requested file
[Bug c++/105265] [9/10/11 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100838 --- Comment #6 from Jonathan Wakely --- But not fixed on gcc-11 by the r11-8715 backport for PR100838, suggesting there was an earlier change on trunk that affects it.
[Bug c++/105265] [9/10/11/12 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 Jonathan Wakely changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 --- Comment #5 from Jonathan Wakely --- Ah yes, it was fixed by r12-1165
[Bug c/97578] [11 Regression] ice during IPA pass: inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P3 --- Comment #14 from Jakub Jelinek --- Resetting to P3, as the state is unknown. It really can't be a P1, at least not for 11.3, if it has been introduced in r11-4267, i.e. before 11.1 release, because if it is still not fixed, 11.1 and 11.2 would have the same bug.
[Bug c++/105265] [9/10/11/12 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- The testcase seems to work correctly with trunk for me.
[Bug c/97578] [11 Regression] ice during IPA pass: inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578 --- Comment #13 from Jonathan Wakely --- I've put the [11 Regression] marker back in the summary, since it looks to have been removed accidentally. But maybe it's fixed since comment 7, so not a regression now? In which case, it shouldn't be P1, and a comment saying why it's still open would help.
[Bug c++/102300] [10/11 Regression] Qualified name of same template in class template is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102300 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Note, this is only a P1 regression for 10.4, not for 11.3, because 11.1 and 11.2 had the bug too, while 10.3 didn't.
[Bug fortran/105242] [OpenMP] ICE with EXIT in collapsed loop: in gfc_trans_exit, at fortran/trans-stmt.cc:6147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105242 Tobias Burnus changed: What|Removed |Added Last reconfirmed||2022-04-13 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #2) > Why do you say accepts invalid for C/C++? Because I messed up initially due to doing do much in parallel, found the issue, but forget to delete that line before hitting 'save'. I have patch – the problem is that the check does exist, but only takes care of a small subset of directives.
[Bug c++/105265] [9/10/11/12 Regression] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||10.1.0, 10.3.0, 11.1.0,
||11.2.0, 12.0, 9.3.0
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Known to work||8.5.0, 9.2.0
Last reconfirmed||2022-04-13
CC||jason at gcc dot gnu.org
Target Milestone|--- |9.5
Summary|temporary object not|[9/10/11/12 Regression]
|destructed causing memory |temporary object not
|leaks |destructed causing memory
||leaks
--- Comment #3 from Jonathan Wakely ---
Started with r279236
PR c++/57082 - new X{} and private destructor.
build_new_1 already passes tf_no_cleanup to build_value_init, but in this
testcase we end up calling build_value_init by way of
build_special_member_call, so we need to pass it to that function as well.
* init.c (build_new_1): Also pass tf_no_cleanup to
build_special_member_call.
Backported to gcc-9 as r279335
[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3 since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
I think pedantically both #c0 and #c3 or even
int
foo (void)
{
char *p = __builtin_malloc (32);
char *q = __builtin_realloc (p, 64);
if (p == q)
return __builtin_object_size (p, 0);
else
return -1;
}
are invalid (the pointer that is passed to realloc can't be used subsequently).
If the comparison is in integral type, it is fuzzier.
The problem is that in real-world, this is a very common thing to do, either
with pointer or integral comparisons, often one needs to find out if it has
been reallocated and adjust say some embedded pointers in the allocation or
some other pointers so that they point into the new allocation rather than the
old one and for optimization purposes it is complete waste of time to do it
when the allocation wasn't actually moved.
The above also returns 32 when it should return 64, even with very old gcc
versions.
On the other side, the standard making that invalid makes a lot of sense,
otherwise we couldn't assume anything in case of
char *p = __builtin_malloc (32);
bar (p);
return __builtin_object_size (p, 0);
because if we don't see into bar, it could do something like
if (__builtin_realloc (p, 33) != p)
exit (25);
or similar (or say realloc to smaller size, then bos2/bos3).
Even if the realloc is in the same function as the malloc, we might not know
that it is that exact pointer passed to realloc (say pointer is passed to some
function, that stores the pointer into global var, another function returns it,
we then pass it to realloc, or any other way of obfuscation).
I'm afraid in those cases we should just point at the standard that it is
undefined.
Then there is the case where we can clearly see that the pointer from malloc is
passed to realloc or can trace it to such easily. I'd say in that case it
would be worthwhile to do some extra work.
For __bos the simplest solution would be if we detect something like that (e.g.
that the SSA_NAME passed to realloc has uses dominated by the realloc call
(though, even figuring that can mean we e.g. mark gimple stmts in each bb with
increasing uids to determine like reassoc what stmt is before another one) just
to punt, say we don't know anything about the SSA_NAME's size, or use
conservative choice from both malloc and realloc (maximum for bos0/bos1,
minimum for bos2/bos3).
For __bdos perhaps the same. Another possibility would be to temporarily split
the SSA_NAME passed to realloc, kind like old VRP was introducing ASSERT_EXPRs.
So, basically when we see:
whatever = realloc (p_34, ...);
rewrite that (temporarily?) to:
p_121 = p_34;
whatever = realloc (p_121, ...);
and change all p_34 uses dominated by the realloc stmt to p_121, and add the
p_121 = p_34; stmt to some hash table or otherwise mark it so that we wouldn't
propagate the objsz knowledge from p_34 to p_121, but instead set it on the
realloc call. That won't cover the integral comparisons though I'm afraid...
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 --- Comment #49 from ro at CeBiTec dot Uni-Bielefeld.DE --- > Anyway, I'm out of ideas and unfortunately Solaris/x86 is not on GCCFarm. I'd meant to provide a Solaris/x86 system for the cfarm, but it turned out every user would have to sign an acceptable use policy and run through a video ident before being granted access, which I consider unusable for developers and too much effort on the admin side. I'll see if I can find a different solution, though. In the meantime, it's possible for indivudual gcc developers to get regular access to my internal gcc test farm. I've done that with iant, for example. Let me know if you're interested. > Why is this a P1 when Solaris/x86 is neither primary nor secondary though? I have no idea: it certainly wasn't me... > Unless it reproduces also on Solaris/SPARC, which is primary but is on > GCCFarm. No, Solaris/SPARC is fine.
[Bug c++/103871] [11/12 Regression] co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871 --- Comment #14 from Iain Sandoe --- (In reply to Iain Sandoe from comment #13) > (In reply to Jason Merrill from comment #12) > > Should we revert the backport for 11.3? > > I think that will regress other tests (but admit I did not have time to try > it). (and it does not actually fix the underlying problem - which is why I hadn't pushed on that)
[Bug c++/103871] [11/12 Regression] co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871 --- Comment #13 from Iain Sandoe --- (In reply to Jason Merrill from comment #12) > Should we revert the backport for 11.3? I think that will regress other tests (but admit I did not have time to try it).
[Bug libstdc++/93602] [9/10/11/12 Regression] Missing reference to libiconv in 9.x libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #18 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593191.html
[Bug c++/103871] [11/12 Regression] co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871 --- Comment #12 from Jason Merrill --- Should we revert the backport for 11.3?
[Bug c++/105265] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 --- Comment #2 from jack --- Additional info: g++8.4 and clang++ 3.8 have no such issue
[Bug c++/105245] [10/11/12 Regression] ICE in clear_no_implicit_zero, in cp/constexpr.cc:1892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105245 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ec03862f809e544a9b7d28067e51597dc92a0244 commit r12-8144-gec03862f809e544a9b7d28067e51597dc92a0244 Author: Jason Merrill Date: Tue Apr 12 17:46:59 2022 -0400 c++: empty base constexpr -fno-elide-ctors [PR105245] The patch for 100111 extended our handling of empty base elision to the case where the derived class has no other fields, but we still need to make sure that there's some initializer for the derived object. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_store_expression): Build a CONSTRUCTOR as needed in empty base handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
[Bug c++/100111] [10 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 --- Comment #11 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ec03862f809e544a9b7d28067e51597dc92a0244 commit r12-8144-gec03862f809e544a9b7d28067e51597dc92a0244 Author: Jason Merrill Date: Tue Apr 12 17:46:59 2022 -0400 c++: empty base constexpr -fno-elide-ctors [PR105245] The patch for 100111 extended our handling of empty base elision to the case where the derived class has no other fields, but we still need to make sure that there's some initializer for the derived object. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_store_expression): Build a CONSTRUCTOR as needed in empty base handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
[Bug c++/105265] temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265
--- Comment #1 from jack ---
#include
using namespace std;
class Block
{
public:
Block(int n) : data{new char[n]}, size{n}
{
cout << "Block ctor\n";
}
~Block()
{
cout << "Block dtor\n";
delete[] data;
}
private:
char* data;
int size;
};
struct Cargo
{
Block const& block;
};
int main()
{
{
Cargo* c = new Cargo{{4000}};
cout << "main\n";
delete c;
}
return 0;
}
Compile and run:
g++ -Wall -Wextra -fno-strict-aliasing -fwrapv -g -std=c++17
Output:
Block ctor
main
---
Issue: Block not destructed.
however, below forms are fine
{
Cargo{{4000}};
cout << "main";
}
{
Cargo* c = new Cargo{Block{4000}};
cout << "main";
delete c;
}
They all output:
Block ctor
Block dtor
main
[Bug c++/105265] New: temporary object not destructed causing memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105265 Bug ID: 105265 Summary: temporary object not destructed causing memory leaks Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jack.cui2 at foxmail dot com Target Milestone: --- Created attachment 52801 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52801=edit file that trigger the issue Using built-in specs. COLLECT_GCC=g++-11 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.1.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-g' '-std=c++17' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test_temporary.cpp -mtune=generic -march=x86-64 -std=c++17 -Wall -Wextra -fno-strict-aliasing -fwrapv -g -fworking-directory -fpch-preprocess -fasynchronous-unwind-tables -fstack-protector-strong -Wformat-security -o a-test_temporary.ii ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/11" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/11 /usr/include/x86_64-linux-gnu/c++/11 /usr/include/c++/11/backward /usr/lib/gcc/x86_64-linux-gnu/11/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-g' '-std=c++17' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -fpreprocessed a-test_temporary.ii -quiet -dumpdir a- -dumpbase test_temporary.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g -Wall -Wextra -std=c++17 -version -fno-strict-aliasing -fwrapv -fasynchronous-unwind-tables -fstack-protector-strong -Wformat-security -o a-test_temporary.s GNU C++17 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (x86_64-linux-gnu) compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP warning: GMP header version 6.1.2 differs from library version 6.2.0. warning: MPFR header version 4.0.1 differs from library version 4.0.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++17 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (x86_64-linux-gnu) compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP warning: GMP header version 6.1.2 differs from library version 6.2.0. warning: MPFR header version 4.0.1 differs from library version 4.0.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: fa8709337e38341bd283d8a4fb935104 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-g' '-std=c++17' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' as -v --64 -o a-test_temporary.o a-test_temporary.s GNU assembler version 2.34 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.34
[Bug middle-end/105263] [9/10/11 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2655 with _Decimal64 -ffast-math since r7-950-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105263 Richard Biener changed: What|Removed |Added Known to work||12.0 Summary|[9/10/11/12 Regression] |[9/10/11 Regression] ICE: |ICE: gimple check: expected |gimple check: expected |gimple_assign(error_mark), |gimple_assign(error_mark), |have gimple_nop() in|have gimple_nop() in |gimple_assign_rhs1, at |gimple_assign_rhs1, at |gimple.h:2655 with |gimple.h:2655 with |_Decimal64 -ffast-math |_Decimal64 -ffast-math |since |since |r7-950-g8a85cee26eabf5cf|r7-950-g8a85cee26eabf5cf --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug middle-end/105263] [9/10/11/12 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2655 with _Decimal64 -ffast-math since r7-95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105263 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ca145c6306f19272ac8756d88c4eba0bfdf01dfb commit r12-8142-gca145c6306f19272ac8756d88c4eba0bfdf01dfb Author: Richard Biener Date: Wed Apr 13 14:53:40 2022 +0200 tree-optimization/105263 - reassoc and DFP reassoc has certain tricks which in the end depend on the ability to undo them. For DFP creating a -1. constant is easy but re-identifying is appearantly not - real_minus_onep rejects those outright for DFP. So we have to disable (at least) this one trick. 2022-04-13 Richard Biener PR tree-optimization/105263 * tree-ssa-reassoc.cc (try_special_add_to_ops): Do not consume negates in multiplication chains with DFP. * gcc.dg/pr105263.c: New testcase.
[Bug analyzer/105264] New: -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105264 Bug ID: 105264 Summary: -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i] Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: avarab at gmail dot com Target Milestone: --- After reading https://developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12-compiler I tried out -fanalyzer on GCC 12 (built from c1ff207af66 (ppc: testsuite: skip pr60203 on no ldbl128, 2022-04-12)) against git.git, and discover what seems to be a bug. When compiling git (https://github.com/git/git/) as: $ make CC=gcc CFLAGS=-fanalyzer builtin/merge-file.o It will complain about: builtin/merge-file.c:86:28: error: use of uninitialized value ‘mmfs[i].size’ [CWE-457] [-Werror=analyzer-use-of-uninitialized-value] 86 | if (mmfs[i].size > MAX_XDIFF_SIZE || [...] The basic control flow is: mmfile_t mmfs[3]; [...] for-loop [...] ret = read_mmfile(mmfs + i, fname); [...] Where read_mmfile() function is always either returning -1 or populating mmfs[i] structure, in the case of -1 we can't reach the code -fanalyzer raises an issue about. The warning will go away if I apply: diff --git a/builtin/merge-file.c b/builtin/merge-file.c index e695867ee54..0ca3580b27d 100644 --- a/builtin/merge-file.c +++ b/builtin/merge-file.c @@ -77,7 +77,7 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix) names[i] = argv[i]; fname = prefix_filename(prefix, argv[i]); - ret = read_mmfile(mmfs + i, fname); + ret = read_mmfile([i], fname); free(fname); if (ret) return -1; Which to me suggests a bug in the analyzer, that's not the most obvious code in the world and probably could use that patch in any case, but the analyzer should understand that mmfs+i and [i] yield the same pointer. analyzer-use-of-uninitialized-value
[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219 --- Comment #10 from Tamar Christina --- nb_iterations_upper_bound is indeed set incorrectly and tracked to this commit, commit 7ed1cd9665d8ca0fa07b2483e604c25e704584af Author: Andre Vieira Date: Thu Jun 3 13:55:24 2021 +0100 vect: Use main loop's thresholds and VF to narrow upper_bound of epilogue This patch uses the knowledge of the conditions to enter an epilogue loop to help come up with a potentially more restricive upper bound. gcc/ChangeLog: * tree-vect-loop.c (vect_transform_loop): Use main loop's various' thresholds to narrow the upper bound on epilogue iterations. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/part_vect_single_iter_epilog.c: New test. I don't quite understand when comparing the two bounds there's a -1 in the min comparison. And indeed: diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc index 5c7b163f01c..19235ea79fe 100644 --- a/gcc/tree-vect-loop.cc +++ b/gcc/tree-vect-loop.cc @@ -9971,7 +9971,7 @@ vect_transform_loop (loop_vec_info loop_vinfo, gimple *loop_vectorized_call) LOOP_VINFO_VECT_FACTOR (loop_vinfo), )) loop->nb_iterations_upper_bound - = wi::umin ((widest_int) (bound - 1), + = wi::umin ((widest_int)bound, loop->nb_iterations_upper_bound); } } fixes it. It looks to me that when comparing the bounds of the main loop and epilogue you shouldn't subtract 1 again. But need to ask why this is there.
[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jakub Jelinek --- Fixed.
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk, I'd wait some time before considering to backport this, so not going to be in 11.3.
[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:29c46490de4616b911fccb34a9479f768fb51e94
commit r12-8141-g29c46490de4616b911fccb34a9479f768fb51e94
Author: Jakub Jelinek
Date: Wed Apr 13 15:44:51 2022 +0200
tree.cc: Use useless_type_conversion_p in
tree_builtin_call_types_compatible_p while in gimple form [PR105253]
tree_builtin_call_types_compatible_p uses TYPE_MAIN_VARIANT comparisons
or tree_nop_conversion_p to ensure a builtin has correct GENERIC arguments.
Unfortunately this regressed when get_call_combined_fn is called during
GIMPLE optimizations. E.g. when number_of_iterations_popcount is called,
it doesn't ensure TYPE_MAIN_VARIABLE compatible argument type, it picks
__builtin_popcount{,l,ll} based just on types' precision and doesn't
fold_convert the arg to the right type. We are in GIMPLE, such conversions
are useless...
So, either we'd need to fix number_of_iterations_popcount to add casts
and inspect anything else that creates CALL_EXPRs late, or we can
in tree_builtin_call_types_compatible_p just use the GIMPLE type
comparisons (useless_type_conversion_p) when we are in GIMPLE form and
the TYPE_MAIN_VARIANT comparison or tree_nop_conversion_p test otherwise.
I think especially this late in stage4 the latter seems safer to me.
2022-04-13 Jakub Jelinek
PR middle-end/105253
* tree.cc (tree_builtin_call_types_compatible_p): If PROP_gimple,
use useless_type_conversion_p checks instead of TYPE_MAIN_VARIANT
comparisons or tree_nop_conversion_p checks.
* gcc.target/i386/pr105253.c: New test.
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:13c32c1984f5857ccce2aeb00ce34343e5a26954 commit r12-8140-g13c32c1984f5857ccce2aeb00ce34343e5a26954 Author: Jakub Jelinek Date: Wed Apr 13 15:43:34 2022 +0200 c++: Treat alignas align_expr and aligned attribute's operand as manifestly constant evaluation [PR105233] The following testcase fails, because we only constant evaluate the alignas argument as non-manifestly constant-evaluated and as __builtin_is_constant_evaluated appears, we make it non-constant (the reason is that we often try to evaluate some expression without manifestly_const_eval perhaps even multiple times before actually evaluating it with manifestly_const_eval (e.g. when folding for warnings and in many other places), and we don't want __builtin_is_constant_evaluated to evaluate to false in those cases, because we could get a different result from when we actually evaluate it with manifestly_const_eval set). Now, for alignas the standard seems to be clear, it says the argument is constant-expression, which means we should manifestly-constant-eval it. Attributes are a fuzzy area, they are extensions and various attributes take e.g. identifiers, or string literals etc. as arguments. Either we can just treat alignas as manifestly-const-eval, for that we'd need some way how to differentiate between alignas and gnu::aligned or aligned attribute. Another possibility is what the patch below implements, treat both alignas and gnu::aligned and aligned attribute's argument as manifestly-const-eval and not do that for other attributes. Another is to go through all attributes and figure out for which such treatment is useful (e.g. those that expect INTEGER_CST as argument), and either add a new column in the attribute table or have another table in the C++ FE to find out which attribute needs that. Another is do that for all the attribute arguments that are EXPR_P and see what breaks (bet that it could be quite risky this late in GCC 12 cycle and especially for backporting). 2022-04-13 Jakub Jelinek PR c++/105233 * decl2.cc (cp_check_const_attributes): For aligned attribute pass manifestly_const_eval=true to fold_non_dependent_expr. * g++.dg/cpp2a/is-constant-evaluated13.C: New test.
[Bug debug/105261] schedule-insns2 and ipa-sra make alive constant variables not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105261 --- Comment #1 from Cristian Assaiante --- The gdb bug report can be found at: https://sourceware.org/bugzilla/show_bug.cgi?id=29060
[Bug c++/105255] Narrowing conversion from enumerator to integer not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105255 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-04-13 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
