aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
7 hoursDaily bump.releases/gcc-14GCC Administrator5-1/+120
12 hoursc++: decltype of capture proxy of ref [PR115504]Patrick Palka2-1/+22
The finish_decltype_type capture proxy handling added in r14-5330 was incorrectly stripping references in the type of the captured variable. PR c++/115504 gcc/cp/ChangeLog: * semantics.cc (finish_decltype_type): Don't strip the reference type (if any) of a capture proxy's captured variable. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/decltype-auto8.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 737449e5f233feb682b5dd2cc153892ad90a79bd)
12 hoursc++: alias CTAD and copy deduction guide [PR115198]Patrick Palka2-1/+19
Here we're neglecting to update DECL_NAME during the alias CTAD guide transformation, which causes copy_guide_p to return false for the transformed copy deduction guide since DECL_NAME is still __dguide_C with TREE_TYPE C<B, T> but it should be __dguide_A with TREE_TYPE A<T> (i.e. C<false, T>). This ultimately results in ambiguity during overload resolution between the copy deduction guide vs copy ctor guide. This patch makes us update DECL_NAME of a transformed guide accordingly during alias/inherited CTAD. PR c++/115198 gcc/cp/ChangeLog: * pt.cc (alias_ctad_tweaks): Update DECL_NAME of the transformed guides. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias22.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 06ebb7c6f31fe42ffdea6f51ac1ba1f6b058c090)
12 hoursc++: using non-dep array var of unknown bound [PR115358]Patrick Palka4-14/+16
For a non-dependent array variable of unknown bound, it seems we need to try instantiating its definition upon use in a template context for sake of proper checking and typing of the overall expression, like we do for function specializations with deduced return type. PR c++/115358 gcc/cp/ChangeLog: * decl2.cc (mark_used): Call maybe_instantiate_decl for an array variable with unknown bound. * semantics.cc (finish_decltype_type): Remove now redundant handling of array variables with unknown bound. * typeck.cc (cxx_sizeof_expr): Likewise. gcc/testsuite/ChangeLog: * g++.dg/template/array37.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit e3915c1ad56591cbd68229a64c941c38330abd69)
22 hourslibstdc++: Fix std::format for chrono::duration with unsigned rep [PR115668]Jonathan Wakely2-1/+10
Using std::chrono::abs is only valid if numeric_limits<rep>::is_signed is true, so using it unconditionally made it ill-formed to format a duration with an unsigned rep. The duration formatter might as well negate the duration itself instead of using chrono::abs, because it already needs to check for a negative value. libstdc++-v3/ChangeLog: PR libstdc++/115668 * include/bits/chrono_io.h (formatter<duration<R,P, C>::format): Do not use chrono::abs. * testsuite/20_util/duration/io.cc: Check formatting a duration with unsigned rep. (cherry picked from commit dafa750c8a6f0a088677871bfaad054881737ab1)
31 hoursrs6000: Fix wrong RTL patterns for vector merge high/low word on LEKewen Lin5-40/+232
Commit r12-4496 changes some define_expands and define_insns for vector merge high/low word, which are altivec_vmrg[hl]w, vsx_xxmrg[hl]w_<VSX_W:mode>. These defines are mainly for built-in function vec_merge{h,l}, __builtin_vsx_xxmrghw, __builtin_vsx_xxmrghw_4si and some internal gen function needs. These functions should consider endianness, taking vec_mergeh as example, as PVIPR defines, vec_mergeh "Merges the first halves (in element order) of two vectors", it does note it's in element order. So it's mapped into vmrghw on BE while vmrglw on LE respectively. Although the mapped insns are different, as the discussion in PR106069, the RTL pattern should be still the same, it is conformed before commit r12-4496, define_expand altivec_vmrghw got expanded into: (vec_select:VSX_W (vec_concat:<VS_double> (match_operand:VSX_W 1 "register_operand" "wa,v") (match_operand:VSX_W 2 "register_operand" "wa,v")) (parallel [(const_int 0) (const_int 4) (const_int 1) (const_int 5)])))] on both BE and LE then. But commit r12-4496 changed it to expand into: (vec_select:VSX_W (vec_concat:<VS_double> (match_operand:VSX_W 1 "register_operand" "wa,v") (match_operand:VSX_W 2 "register_operand" "wa,v")) (parallel [(const_int 0) (const_int 4) (const_int 1) (const_int 5)])))] on BE, and (vec_select:VSX_W (vec_concat:<VS_double> (match_operand:VSX_W 1 "register_operand" "wa,v") (match_operand:VSX_W 2 "register_operand" "wa,v")) (parallel [(const_int 2) (const_int 6) (const_int 3) (const_int 7)])))] on LE, although the mapped insn are still vmrghw on BE and vmrglw on LE, the associated RTL pattern is completely wrong and inconsistent with the mapped insn. If optimization passes leave this pattern alone, even if its pattern doesn't represent its mapped insn, it's still fine, that's why simple testing on bif doesn't expose this issue. But once some optimization pass such as combine does some changes basing on this wrong pattern, because the pattern doesn't match the semantics that the expanded insn is intended to represent, it would cause the unexpected result. So this patch is to fix the wrong RTL pattern, ensure the associated RTL patterns become the same as before which can have the same semantic as their mapped insns. With the proposed patch, the expanders like altivec_vmrghw expands into altivec_vmrghb_direct_be or altivec_vmrglb_direct_le depending on endianness, "direct" can easily show which insn would be generated, _be and _le are mainly for the different RTL patterns as endianness. Co-authored-by: Xionghu Luo <xionghuluo@tencent.com> PR target/106069 PR target/115355 gcc/ChangeLog: * config/rs6000/altivec.md (altivec_vmrghw_direct_<VSX_W:mode>): Rename to ... (altivec_vmrghw_direct_<VSX_W:mode>_be): ... this. Add the condition BYTES_BIG_ENDIAN. (altivec_vmrghw_direct_<VSX_W:mode>_le): New define_insn. (altivec_vmrglw_direct_<VSX_W:mode>): Rename to ... (altivec_vmrglw_direct_<VSX_W:mode>_be): ... this. Add the condition BYTES_BIG_ENDIAN. (altivec_vmrglw_direct_<VSX_W:mode>_le): New define_insn. (altivec_vmrghw): Adjust by calling gen_altivec_vmrghw_direct_v4si_be for BE and gen_altivec_vmrglw_direct_v4si_le for LE. (altivec_vmrglw): Adjust by calling gen_altivec_vmrglw_direct_v4si_be for BE and gen_altivec_vmrghw_direct_v4si_le for LE. (vec_widen_umult_hi_v8hi): Adjust the call to gen_altivec_vmrghw_direct_v4si by gen_altivec_vmrghw for BE and by gen_altivec_vmrglw for LE. (vec_widen_smult_hi_v8hi): Likewise. (vec_widen_umult_lo_v8hi): Adjust the call to gen_altivec_vmrglw_direct_v4si by gen_altivec_vmrglw for BE and by gen_altivec_vmrghw for LE (vec_widen_smult_lo_v8hi): Likewise. * config/rs6000/rs6000.cc (altivec_expand_vec_perm_const): Replace CODE_FOR_altivec_vmrghw_direct_v4si by CODE_FOR_altivec_vmrghw_direct_v4si_be for BE and CODE_FOR_altivec_vmrghw_direct_v4si_le for LE. And replace CODE_FOR_altivec_vmrglw_direct_v4si by CODE_FOR_altivec_vmrglw_direct_v4si_be for BE and CODE_FOR_altivec_vmrglw_direct_v4si_le for LE. * config/rs6000/vsx.md (vsx_xxmrghw_<VSX_W:mode>): Adjust by calling gen_altivec_vmrghw_direct_v4si_be for BE and gen_altivec_vmrglw_direct_v4si_le for LE. (vsx_xxmrglw_<VSX_W:mode>): Adjust by calling gen_altivec_vmrglw_direct_v4si_be for BE and gen_altivec_vmrghw_direct_v4si_le for LE. gcc/testsuite/ChangeLog: * g++.target/powerpc/pr106069.C: New test. * gcc.target/powerpc/pr115355.c: New test. (cherry picked from commit 52c112800d9f44457c4832309a48c00945811313)
31 hoursDaily bump.GCC Administrator4-1/+34
33 hourslibstdc++: Replace viewcvs links in docs with cgit linksJonathan Wakely6-18/+18
For this backport to the release branch, the links to the git repo refer to the branch. libstdc++-v3/ChangeLog: * doc/xml/faq.xml: Replace viewcvs links with cgit links. * doc/xml/manual/allocator.xml: Likewise. * doc/xml/manual/mt_allocator.xml: Likewise. * doc/html/*: Regenerate. (cherry picked from commit 9d8021d1875677286c3dde90dfed2aca864edad0)
45 hours[libstdc++] [testsuite] defer to check_vect_support* [PR115454]Alexandre Oliva1-1/+0
The newly-added testcase overrides the default dg-do action set by check_vect_support_and_set_flags (in libstdc++-dg/conformance.exp), so it attempts to run the test even if runtime vector support is not available. Remove the explicit dg-do directive, so that the default is honored, and the test is run if vector support is found, and only compiled otherwise. for libstdc++-v3/ChangeLog PR libstdc++/115454 * testsuite/experimental/simd/pr115454_find_last_set.cc: Defer to check_vect_support_and_set_flags's default dg-do action. (cherry picked from commit 95faa1bea7bdc7f92fcccb3543bfcbc8184c5e5b)
2 daysaarch64: Add support for -mcpu=graceKyrylo Tkachov3-3/+5
This adds support for the NVIDIA Grace CPU to aarch64. We reuse the tuning decisions for the Neoverse V2 core, but include a number of architecture features that are not enabled by default in -mcpu=neoverse-v2. This allows Grace users to more simply target the CPU with -mcpu=grace rather than remembering what extensions to tag on top of -mcpu=neoverse-v2. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ * config/aarch64/aarch64-cores.def (grace): New entry. * config/aarch64/aarch64-tune.md: Regenerate. * doc/invoke.texi (AArch64 Options): Document the above. Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
2 daystree-ssa-pre.c/115214(ICE in find_or_generate_expression, at ↵Jiawei2-3/+59
tree-ssa-pre.c:2780): Return NULL_TREE when deal special cases. Return NULL_TREE when genop3 equal EXACT_DIV_EXPR. https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652641.html version log v3: remove additional POLY_INT_CST check. https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652795.html gcc/ChangeLog: * tree-ssa-pre.cc (create_component_ref_by_pieces_1): New conditions. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/pr115214.c: New test.
2 daysDaily bump.GCC Administrator1-1/+1
3 daysDaily bump.GCC Administrator6-1/+45
3 dayslibstdc++: Remove confusing text from status tables for release branchJonathan Wakely9-16/+16
When I tried to make the release branch versions of these docs refer to the release branch instead of "mainline GCC", for some reason I left the text "not any particular release" there. That's just confusing, because the docs are for a particular release, the latest on that branch. Remove that confusing text in several places. libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx1998.xml: Remove confusing "not in any particular release" text. * doc/xml/manual/status_cxx2011.xml: Likewise. * doc/xml/manual/status_cxx2014.xml: Likewise. * doc/xml/manual/status_cxx2017.xml: Likewise. * doc/xml/manual/status_cxx2020.xml: Likewise. * doc/xml/manual/status_cxx2023.xml: Likewise. * doc/xml/manual/status_cxxtr1.xml: Likewise. * doc/xml/manual/status_cxxtr24733.xml: Likewise. * doc/html/manual/status.html: Regenerate.
4 daysFix PR c/115587, uninitialized variable in c_parser_omp_loop_nestSandra Loosemore2-9/+3
This function had a reference to an uninitialized variable on the error path. The problem was diagnosed by clang but not gcc. It seems the cleanest solution is to initialize all the loop-clause variables at the point of declaration rather than at different places in the code. The C++ front end didn't have this problem, but I've made similar changes there to keep the code in sync. gcc/c/ChangeLog: PR c/115587 * c-parser.cc (c_parser_omp_loop_nest): Move initializations to point of declaration. gcc/cp/ChangeLog: PR c/115587 * parser.cc (cp_parser_omp_loop_nest): Move initializations to point of declaration. (cherry picked from commit 21f1073d388af8af207183b0ed592e1cc47d20ab)
4 daysSPARC: fix internal error with -mv8plus on 64-bit LinuxEric Botcazou1-1/+1
This passes -m32 when -mv8plus is specified on Linux (like on Solaris). gcc/ PR target/115608 * config/sparc/linux64.h (CC1_SPEC): Pass -m32 for -mv8plus.
4 daysc-family: Add Warning property to Wnrvo option [PR115624]Andrew Pinski1-1/+1
This was missing when Wnrvo was added in r14-1594-g2ae5384d457b9c67586de012816dfc71a6943164 . Pushed after a bootstrap/test on x86_64-linux-gnu. gcc/c-family/ChangeLog: PR c++/115624 * c.opt (Wnrvo): Add Warning property. Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com> (cherry picked from commit f7747210947a7c66e865c6ac571cce39e2b87caf)
4 daysDaily bump.GCC Administrator3-1/+23
5 daysrs6000: Don't clobber return value when eh_return called [PR114846]Kewen Lin3-4/+38
As the associated test case in PR114846 shows, currently with eh_return involved some register restoring for EH RETURN DATA in epilogue can clobber the one which holding the return value. Referring to the existing handlings in some other targets, this patch makes eh_return expander call one new define_insn_and_split eh_return_internal which directly calls rs6000_emit_epilogue with epilogue_type EPILOGUE_TYPE_EH_RETURN instead of the previous treating normal return with crtl->calls_eh_return specially. PR target/114846 gcc/ChangeLog: * config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): As EPILOGUE_TYPE_EH_RETURN would be passed as epilogue_type directly now, adjust the relevant handlings on it. * config/rs6000/rs6000.md (eh_return expander): Append by calling gen_eh_return_internal and emit_barrier. (eh_return_internal): New define_insn_and_split, call function rs6000_emit_epilogue with epilogue type EPILOGUE_TYPE_EH_RETURN. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr114846.c: New test. (cherry picked from commit e5fc5d42d25c86ae48178db04ce64d340a834614)
5 daysDaily bump.GCC Administrator1-1/+1
6 daysDaily bump.GCC Administrator1-1/+1
7 daysDaily bump.GCC Administrator5-1/+73
8 daysAArch64: Fix cpu features initialization [PR115342]Wilco Dijkstra1-106/+75
The CPU features initialization code uses CPUID registers (rather than HWCAP). The equality comparisons it uses are incorrect: for example FEAT_SVE is not set if SVE2 is available. Using HWCAPs for these is both simpler and correct. The initialization must also be done atomically to avoid multiple threads causing corruption due to non-atomic RMW accesses to the global. libgcc: PR target/115342 * config/aarch64/cpuinfo.c (__init_cpu_features_constructor): Use HWCAP where possible. Use atomic write for initialization. Fix FEAT_PREDRES comparison. (__init_cpu_features_resolver): Use atomic load for correct initialization. (__init_cpu_features): Likewise. (cherry picked from commit d7cbcfe7c33645eaf95f175f19884d443817857b)
8 dayslibstdc++: Fix test on x86_64 and non-simd targetsMatthias Kretz1-2/+4
* Running a test compiled with AVX512 instructions requires avx512f_runtime not just avx512f. * The 'reduce2' test violated an invariant of fixed_size_simd_mask and thus failed on all targets without 16-Byte vector builtins enabled (in bits/simd.h). Signed-off-by: Matthias Kretz <m.kretz@gsi.de> libstdc++-v3/ChangeLog: PR libstdc++/115575 * testsuite/experimental/simd/pr115454_find_last_set.cc: Require avx512f_runtime. Don't memcpy fixed_size masks. (cherry picked from commit 77f321435b4ac37992c2ed6737ca0caa1dd50551)
8 daysBuild: Set gcc_cv_as_mips_explicit_relocs if ↵YunQiang Su2-0/+4
gcc_cv_as_mips_explicit_relocs_pcrel We check gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel only, while gcc_cv_as_mips_explicit_relocs is used by later code. gcc * configure.ac: Set gcc_cv_as_mips_explicit_relocs if gcc_cv_as_mips_explicit_relocs_pcrel. * configure: Regenerate. (cherry picked from commit 573f11ec34eeb6a6c3bd3d7619738f927236727b)
8 daystree-optimization/115278 - fix DSE in if-conversion wrt volatilesRichard Biener2-1/+41
The following adds the missing guard for volatile stores to the embedded DSE in the loop if-conversion pass. PR tree-optimization/115278 * tree-if-conv.cc (ifcvt_local_dce): Do not DSE volatile stores. * g++.dg/vect/pr115278.cc: New testcase. (cherry picked from commit 65dbe0ab7cdaf2aa84b09a74e594f0faacf1945c)
8 daystree-optimization/115508 - fix ICE with SLP scheduling and extern vectorRichard Biener2-0/+16
When there's a permute after an extern vector we can run into a case that didn't consider the scheduled node being a permute which lacks a representative. PR tree-optimization/115508 * tree-vect-slp.cc (vect_schedule_slp_node): Guard check on representative. * gcc.target/i386/pr115508.c: New testcase. (cherry picked from commit 65e72b95c63a5501cf1482f3814ae8c8e672bf06)
8 daysAvoid SLP_REPRESENTATIVE access for VEC_PERM in SLP schedulingRichard Biener1-12/+16
SLP permute nodes can end up without a SLP_REPRESENTATIVE now, the following avoids touching it in this case in vect_schedule_slp_node. * tree-vect-slp.cc (vect_schedule_slp_node): Avoid looking at SLP_REPRESENTATIVE for VEC_PERM nodes. (cherry picked from commit 31e9bae0ea5e5413abfa3ca9050e66cc6760553e)
8 daysDaily bump.GCC Administrator4-1/+80
9 dayslibstdc++: Fix find_last_set(simd_mask) to ignore padding bitsMatthias Kretz2-13/+62
With the change to the AVX512 find_last_set implementation, the change to AVX512 operator!= is unnecessary. However, the latter was not producing optimal code and unnecessarily set the padding bits. In theory, the compiler could determine that with the new != implementation, the bit operation for clearing the padding bits is a no-op and can be elided. Signed-off-by: Matthias Kretz <m.kretz@gsi.de> libstdc++-v3/ChangeLog: PR libstdc++/115454 * include/experimental/bits/simd_x86.h (_S_not_equal_to): Use neq comparison instead of bitwise negation after eq. (_S_find_last_set): Clear unused high bits before computing bit_width. * testsuite/experimental/simd/pr115454_find_last_set.cc: New test. (cherry picked from commit 1340ddea0158de3f49aeb75b4013e5fc313ff6f4)
9 daysvshuf-mem.C: Make -march=z14 depend on s390_vxeAndreas Krebbel1-1/+1
gcc/testsuite/ChangeLog: * g++.dg/torture/vshuf-mem.C: Use -march=z14 only, if the we are on a machine which can actually run it. (cherry picked from commit 7e59f0c05da840ca13ba73d25947df8a4eaf199e)
9 daystestsuite: Add -Wno-psabi to vshuf-mem.C testJakub Jelinek1-1/+1
The newly added test FAILs on i686-linux. On x86_64-linux make check-g++ RUNTESTFLAGS='--target_board=unix\{-m64,-m32/-msse2,-m32/-mno-sse/-mno-mmx\} dg-torture.exp=vshuf-mem.C' shows that as well. The problem is that without SSE2/MMX the vector is passed differently than normally and so GCC warns about that. -Wno-psabi is the usual way to shut it up. Also wonder about the // { dg-additional-options "-march=z14" { target s390*-*-* } } line, doesn't that mean the test will FAIL on all pre-z14 HW? Shouldn't it use some z14_runtime or similar effective target, or check in main (in that case copied over to g++.target/s390) whether z14 instructions can be actually used at runtime? 2024-06-14 Jakub Jelinek <jakub@redhat.com> * g++.dg/torture/vshuf-mem.C: Add -Wno-psabi to dg-options. (cherry picked from commit 1bb2535c7cb279e6aab731e79080d8486dd50cce)
9 daysIBM Z: Fix ICE in expand_perm_as_replicateAndreas Krebbel3-3/+43
The current implementation assumes to always be invoked with register operands. For memory operands we even have an instruction though (vlrep). With the patch we try this first and only if it fails force the input into a register and continue. vec_splats generation fails for single element 128bit types which are allowed for vec_splat. This is something to sort out with another patch I guess. gcc/ChangeLog: * config/s390/s390.cc (expand_perm_as_replicate): Handle memory operands. * config/s390/vx-builtins.md (vec_splats<mode>): Turn into parameterized expander. (@vec_splats<mode>): New expander. gcc/testsuite/ChangeLog: * g++.dg/torture/vshuf-mem.C: New test. (cherry picked from commit 21fd8c67ad297212e3cb885883cc8df8611f3040)
9 daysbitint: Fix up lowering of COMPLEX_EXPR [PR115544]Jakub Jelinek2-1/+20
We don't really support _Complex _BitInt(N), the only place we use bitint complex types is for the .{ADD,SUB,MUL}_OVERFLOW internal function results and COMPLEX_EXPR in the usual case should be either not present yet because the ifns weren't folded and will be lowered, or optimized into something simpler, because normally the complex bitint should be used just for extracting the 2 subparts from it. Still, with disabled optimizations it can occassionally happen that it appears in the IL and that is why there is support for lowering those, but it doesn't handle optimizing those too much, so if it uses SSA_NAME, it relies on them having a backing VAR_DECL during the lowering. This is normally achieves through the && ((is_gimple_assign (use_stmt) && (gimple_assign_rhs_code (use_stmt) != COMPLEX_EXPR)) || gimple_code (use_stmt) == GIMPLE_COND) hunk in gimple_lower_bitint, but as the following testcase shows, there is one thing I've missed, the load optimization isn't guarded by the above stuff. So, either we'd need to add support for loads to lower_complexexpr_stmt, or because they should be really rare, this patch just disables the load optimization if at least one load use is a COMPLEX_EXPR (like we do already for PHIs, calls, asm). 2024-06-19 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/115544 * gimple-lower-bitint.cc (gimple_lower_bitint): Disable optimizing loads used by COMPLEX_EXPR operands. * gcc.dg/bitint-107.c: New test. (cherry picked from commit 25860fd2a674373a6476af5ff0bd92354fc53d06)
9 daysdiagnostics: Fix add_misspelling_candidates [PR115440]Jakub Jelinek2-2/+12
The option_map array for most entries contains just non-NULL opt0 { "-Wno-", NULL, "-W", false, true }, { "-fno-", NULL, "-f", false, true }, { "-gno-", NULL, "-g", false, true }, { "-mno-", NULL, "-m", false, true }, { "--debug=", NULL, "-g", false, false }, { "--machine-", NULL, "-m", true, false }, { "--machine-no-", NULL, "-m", false, true }, { "--machine=", NULL, "-m", false, false }, { "--machine=no-", NULL, "-m", false, true }, { "--machine", "", "-m", false, false }, { "--machine", "no-", "-m", false, true }, { "--optimize=", NULL, "-O", false, false }, { "--std=", NULL, "-std=", false, false }, { "--std", "", "-std=", false, false }, { "--warn-", NULL, "-W", true, false }, { "--warn-no-", NULL, "-W", false, true }, { "--", NULL, "-f", true, false }, { "--no-", NULL, "-f", false, true } and so add_misspelling_candidates works correctly for it, but 3 out of these, { "--machine", "", "-m", false, false }, { "--machine", "no-", "-m", false, true }, and { "--std", "", "-std=", false, false }, use non-NULL opt1. That says that --machine foo should map to -mfoo and --machine no-foo should map to -mno-foo and --std c++17 should map to -std=c++17 add_misspelling_canidates was not handling this, so it hapilly registered say --stdc++17 or --machineavx512 (twice) as spelling alternatives, when those options aren't recognized. Instead we support --std c++17 or --machine avx512 --machine no-avx512 The following patch fixes that. On this particular testcase, we no longer suggest anything, even when among the suggestion is say that --std c++17 or -std=c++17 etc. 2024-06-17 Jakub Jelinek <jakub@redhat.com> PR driver/115440 * opts-common.cc (add_misspelling_candidates): If opt1 is non-NULL, add a space and opt1 to the alternative suggestion text. * g++.dg/cpp1z/pr115440.C: New test. (cherry picked from commit 96db57948b50f45235ae4af3b46db66cae7ea859)
9 daysDaily bump.GCC Administrator1-1/+1
10 daysDaily bump.GCC Administrator1-1/+1
11 daysDaily bump.GCC Administrator5-1/+116
12 daysc-family: Fix -Warray-compare warning ICE [PR115290]Jakub Jelinek2-4/+22
The warning code uses %D to print the ARRAY_REF first operands. That works in the most common case where those operands are decls, but as can be seen on the following testcase, they can be other expressions with array type. Just changing %D to %E isn't enough, because then the diagnostics can suggest something like note: use '&(x) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0] == &(y) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0]' to compare the addresses which is a bad suggestion, the %E printing doesn't know that the warning code will want to add & before it and [0] after it. So, the following patch adds ()s around the operand as well, but does that only for non-decls, for decls keeps it as &arr[0] like before. 2024-06-17 Jakub Jelinek <jakub@redhat.com> PR c/115290 * c-warn.cc (do_warn_array_compare): Use %E rather than %D for printing op0 and op1; if those operands aren't decls, also print parens around them. * c-c++-common/Warray-compare-3.c: New test. (cherry picked from commit b63c7d92012f92e0517190cf263d29bbef8a06bf)
12 daysc++: Fix up floating point conversion rank comparison for _Float32 and float ↵Jakub Jelinek2-0/+29
if float/double are same size [PR115511] On AVR and SH with some options sizeof (float) == sizeof (double) and the 2 types have the same set of values. http://eel.is/c++draft/conv.rank#2.2 for this says that double still has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2 says that extended type with the same set of values as more than one standard floating point type shall have the same rank as double. I've implemented the latter rule as if (cnt > 1 && mv2 == long_double_type_node) return -2; with the _Float64/double/long double case having same mode case (various targets with -mlong-double-64) in mind. But never thought there are actually targets where float and double are the same, that needs handling too, if cnt > 1 (that is the extended type mv1 has same set of values as 2 or 3 of float/double/long double) and mv2 is float, we need to return 2, because mv1 in that case should have same rank as double and double has bigger rank than float. 2024-06-17 Jakub Jelinek <jakub@redhat.com> PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. * g++.dg/cpp23/ext-floating18.C: New test. (cherry picked from commit 8584c98f370cd91647c184ce58141508ca478a12)
12 daysc++: undeclared identifier in requires-clause [PR99678]Patrick Palka2-0/+16
Since the terms of a requires-clause are grammatically primary-expressions and not e.g. postfix-expressions, it seems we need to explicitly handle and diagnose the case where a term parses to a bare unresolved identifier, like cp_parser_postfix_expression does, since cp_parser_primary_expression leaves that up to its callers. Otherwise we incorrectly accept the first three requires-clauses below. Note that the only occurrences of primary-expression in the grammar are postfix-expression and constraint-logical-and-expression, so it's not too surprising that we need this special handling here. PR c++/99678 gcc/cp/ChangeLog: * parser.cc (cp_parser_constraint_primary_expression): Diagnose a bare unresolved unqualified-id. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires38.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit d387ecb2b2f44f33fd6a7c5ec7eadaf6dd70efc9)
12 daysc++: ICE w/ ambig and non-strictly-viable cands [PR115239]Patrick Palka2-1/+12
Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to ever since r14-6522. These latter candidates have an empty second arg conversion since the first arg conversion was deemed bad, and this trips up joust when called on #3 and #4 which assumes all arg conversions are there. We can fix this by making joust robust to empty arg conversions, but in this situation we shouldn't need to compare #3 and #4 at all given that we have a strictly viable candidate. To that end, this patch makes tourney shortcut considering non-strictly viable candidates upon encountering ambiguity between two strictly viable candidates (taking advantage of the fact that the candidates list is sorted according to viability via splice_viable). PR c++/115239 gcc/cp/ChangeLog: * call.cc (tourney): Don't consider a non-strictly viable candidate as the champ if there was ambiguity between two strictly viable candidates. gcc/testsuite/ChangeLog: * g++.dg/overload/error7.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 7fed7e9bbc57d502e141e079a6be2706bdbd4560)
12 daysc++: visibility wrt concept-id as targ [PR115283]Patrick Palka2-2/+17
Like with alias templates, it seems we don't maintain visibility flags for concepts either, so min_vis_expr_r should ignore them for now. Otherwise after r14-6789 we may incorrectly give a function template that uses a concept-id in its signature internal linkage. PR c++/115283 gcc/cp/ChangeLog: * decl2.cc (min_vis_expr_r) <case TEMPLATE_DECL>: Ignore concepts. gcc/testsuite/ChangeLog: * g++.dg/template/linkage5.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit b1fe718cbe0c8883af89f52e0aad3ebf913683de)
12 dayss390: testsuite: Fix ifcvt-one-insn-bool.cStefan Schulze Frielinghaus1-1/+1
With the change of r15-787-g57e04879389f9c I forgot to also update this test. gcc/testsuite/ChangeLog: * gcc.target/s390/ifcvt-one-insn-bool.c: Fix loc. (cherry picked from commit ac66736bf2f8a10d2f43e83ed6377e4179027a39)
12 dayss390: Implement TARGET_NOCE_CONVERSION_PROFITABLE_P [PR109549]Stefan Schulze Frielinghaus2-2/+34
Consider a NOCE conversion as profitable if there is at least one conditional move. gcc/ChangeLog: PR target/109549 * config/s390/s390.cc (TARGET_NOCE_CONVERSION_PROFITABLE_P): Define. (s390_noce_conversion_profitable_p): Implement. gcc/testsuite/ChangeLog: * gcc.target/s390/ccor.c: Order of loads are reversed, now, as a consequence the condition has to be reversed. (cherry picked from commit 57e04879389f9c0d5d53f316b468ce1bddbab350)
12 daysDaily bump.GCC Administrator1-1/+1
13 daysDaily bump.GCC Administrator2-1/+11
14 daysriscv: Allocate enough space to strcpy() stringChristoph Müllner1-3/+3
I triggered an ICE on Ubuntu 24.04 when compiling code that uses function attributes. Looking into the sources shows that we have a systematic issue in the attribute handling code: * we determine the length with strlen() (excluding the terminating null) * we allocate a buffer with this length * we copy the original string using strcpy() (incl. the terminating null) To quote the man page of strcpy(): "The programmer is responsible for allocating a destination buffer large enough, that is, strlen(src) + 1." The ICE looks like this: *** buffer overflow detected ***: terminated xtheadmempair_bench.c:14:1: internal compiler error: Aborted 14 | { | ^ 0xaf3b99 crash_signal /home/ubuntu/src/gcc/scaleff/gcc/toplev.cc:319 0xe5b957 strcpy /usr/include/riscv64-linux-gnu/bits/string_fortified.h:79 0xe5b957 riscv_process_target_attr /home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:339 0xe5baaf riscv_process_target_attr /home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:314 0xe5bc5f riscv_option_valid_attribute_p(tree_node*, tree_node*, tree_node*, int) /home/ubuntu/src/gcc/scaleff/gcc/config/riscv/riscv-target-attr.cc:389 0x6a31e5 handle_target_attribute /home/ubuntu/src/gcc/scaleff/gcc/c-family/c-attribs.cc:5915 0x5d3a07 decl_attributes(tree_node**, tree_node*, int, tree_node*) /home/ubuntu/src/gcc/scaleff/gcc/attribs.cc:900 0x5db403 c_decl_attributes /home/ubuntu/src/gcc/scaleff/gcc/c/c-decl.cc:5501 0x5e8965 start_function(c_declspecs*, c_declarator*, tree_node*) /home/ubuntu/src/gcc/scaleff/gcc/c/c-decl.cc:10562 0x6318ed c_parser_declaration_or_fndef /home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:2914 0x63a8ad c_parser_external_declaration /home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:2048 0x63b219 c_parser_translation_unit /home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:1902 0x63b219 c_parse_file() /home/ubuntu/src/gcc/scaleff/gcc/c/c-parser.cc:27277 0x68fec5 c_common_parse_file() /home/ubuntu/src/gcc/scaleff/gcc/c-family/c-opts.cc:1311 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. gcc/ChangeLog: * config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch): Fix allocation size of buffer. (riscv_process_one_target_attr): Likewise. (riscv_process_target_attr): Likewise. (cherry picked from commit 6762d5738b02d84ad3f51e89979b48acb68db65b) Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2024-06-15Daily bump.GCC Administrator2-1/+9
2024-06-14libstdc++: Fix declaration of posix_memalign for freestandingJonathan Wakely1-1/+1
Thanks to Jérôme Duval for noticing this. libstdc++-v3/ChangeLog: * libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Fix declaration of posix_memalign. (cherry picked from commit 161efd677458f20d13ee1018a4d5e3964febd508)
generated by cgit v1.1 at 2024-06-29 07:50:43 +0000