aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-25Daily bump.GCC Administrator3-1/+23
2024-06-23rs6000: 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)
2024-06-24Daily bump.GCC Administrator1-1/+1
2024-06-23Daily bump.GCC Administrator1-1/+1
2024-06-22Daily bump.GCC Administrator5-1/+73
2024-06-21AArch64: 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)
2024-06-21libstdc++: 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)
2024-06-21Build: 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)
2024-06-21tree-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)
2024-06-21tree-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)
2024-06-21Avoid 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)
2024-06-21Daily bump.GCC Administrator4-1/+80
2024-06-20libstdc++: 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)
2024-06-20vshuf-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)
2024-06-20testsuite: 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)
2024-06-20IBM 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)
2024-06-20bitint: 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)
2024-06-20diagnostics: 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)
2024-06-20Daily bump.GCC Administrator1-1/+1
2024-06-19Daily bump.GCC Administrator1-1/+1
2024-06-18Daily bump.GCC Administrator5-1/+116
2024-06-17c-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)
2024-06-17c++: 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)
2024-06-17c++: 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)
2024-06-17c++: 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)
2024-06-17c++: 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)
2024-06-17s390: 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)
2024-06-17s390: 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)
2024-06-17Daily bump.GCC Administrator1-1/+1
2024-06-16Daily bump.GCC Administrator2-1/+11
2024-06-15riscv: 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)
2024-06-14Daily bump.GCC Administrator1-1/+1
2024-06-13Daily bump.GCC Administrator4-1/+30
2024-06-12arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]Andre Vieira1-0/+2
This patch adds missing assembly directives to the CMSE library wrapper to call functions with attribute cmse_nonsecure_call. Without the .type directive the linker will fail to produce the correct veneer if a call to this wrapper function is to far from the wrapper itself. The .size was added for completeness, though we don't necessarily have a usecase for it. libgcc/ChangeLog: PR target/115360 * config/arm/cmse_nonsecure_call.S: Add .type and .size directives. (cherry picked from commit c559353af49fe5743d226ac3112a285b27a50f6a)
2024-06-12testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]Torbjörn SVENSSON1-6/+56
For Armv8.1-M, the clearing of the registers is handled differently than for Armv8-M, so update the test case accordingly. gcc/testsuite/ChangeLog: PR target/115253 * gcc.target/arm/cmse/extend-return.c: Update test case condition for Armv8.1-M. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Co-authored-by: Yvan ROUX <yvan.roux@foss.st.com> (cherry picked from commit cf5f9171bae1f5f3034dc9a055b77446962f1a8c)
2024-06-12arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]Torbjörn SVENSSON1-8/+68
Properly handle zero and sign extension for Armv8-M.baseline as Cortex-M23 can have the security extension active. Currently, there is an internal compiler error on Cortex-M23 for the epilog processing of sign extension. This patch addresses the following CVE-2024-0151 for Armv8-M.baseline. gcc/ChangeLog: PR target/115253 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Sign extend for Thumb1. (thumb1_expand_prologue): Add zero/sign extend. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Co-authored-by: Yvan ROUX <yvan.roux@foss.st.com> (cherry picked from commit 65bd0655ece268895e5018e393bafb769e201c78)
2024-06-12Daily bump.GCC Administrator4-1/+27
2024-06-11Fix building JIT with musl libc [PR115442]Andrew Pinski1-1/+1
Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc. Pushed as obvious after a quick build to make sure jit still builds. gcc/jit/ChangeLog: PR jit/115442 * jit-recording.cc: Define INCLUDE_SSTREAM before including system.h and don't directly incldue sstream. Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com> (cherry picked from commit e4244b88d75124f6957bfa080c8ad34017364e53)
2024-06-11ira: Fix go_through_subreg offset calculation [PR115281]Richard Sandiford2-1/+41
go_through_subreg used: else if (!can_div_trunc_p (SUBREG_BYTE (x), REGMODE_NATURAL_SIZE (GET_MODE (x)), offset)) to calculate the register offset for a pseudo subreg x. In the blessed days before poly-int, this was: *offset = (SUBREG_BYTE (x) / REGMODE_NATURAL_SIZE (GET_MODE (x))); But I think this is testing the wrong natural size. If we exclude paradoxical subregs (which will get an offset of zero regardless), it's the inner register that is being split, so it should be the inner register's natural size that we use. This matters in the testcase because we have an SFmode lowpart subreg into the last of three variable-sized vectors. The SUBREG_BYTE is therefore equal to the size of two variable-sized vectors. Dividing by the vector size gives a register offset of 2, as expected, but dividing by the size of a scalar FPR would give a variable offset. I think something similar could happen for fixed-size targets if REGMODE_NATURAL_SIZE is different for vectors and integers (say), although that case would trade an ICE for an incorrect offset. gcc/ PR rtl-optimization/115281 * ira-conflicts.cc (go_through_subreg): Use the natural size of the inner mode rather than the outer mode. gcc/testsuite/ PR rtl-optimization/115281 * gfortran.dg/pr115281.f90: New test. (cherry picked from commit 46d931b3dd31cbba7c3355ada63f155aa24a4e2b)
2024-06-11Daily bump.GCC Administrator6-1/+100
2024-06-10c++: lambda in pack expansion [PR115378]Patrick Palka5-4/+20
Here find_parameter_packs_r is incorrectly treating the 'auto' return type of a lambda as a parameter pack due to Concepts-TS specific logic added in r6-4517, leading to confusion later when expanding the pattern. Since we intend on removing Concepts TS support soon anyway, this patch fixes this by restricting the problematic logic with flag_concepts_ts. Doing so revealed that add_capture was relying on this logic to set TEMPLATE_TYPE_PARAMETER_PACK for the 'auto' type of an pack expansion init-capture, which we now need to do explicitly. PR c++/115378 gcc/cp/ChangeLog: * lambda.cc (lambda_capture_field_type): Set TEMPLATE_TYPE_PARAMETER_PACK on the auto type of an init-capture pack expansion. * pt.cc (find_parameter_packs_r) <case TEMPLATE_TYPE_PARM>: Restrict TEMPLATE_TYPE_PARAMETER_PACK promotion with flag_concepts_ts. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/decltype-auto-103497.C: Adjust expected diagnostic. * g++.dg/template/pr95672.C: Likewise. * g++.dg/cpp2a/lambda-targ5.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 5c761395402a730535983a5e49ef1775561ebc61)
2024-06-10Fix crash on access-to-incomplete typeEric Botcazou2-0/+28
This just adds the missing guard. gcc/ada/ PR ada/114708 * exp_util.adb (Finalize_Address): Add guard for incomplete types. gcc/testsuite/ * gnat.dg/incomplete8.adb: New test.
2024-06-10Add testcase for PR ada/114398Eric Botcazou1-0/+80
gcc/testsuite/ PR ada/114398 * gnat.dg/access11.adb: New test.
2024-06-10ada: Storage_Error in indirect call to function returning limited typeJavier Miranda2-8/+15
At runtime the code generated by the compiler reports the exception Storage_Error in an indirect call through an access-to-subprogram variable that references a function returning a limited tagged type object. gcc/ada/ * sem_ch6.adb (Might_Need_BIP_Task_Actuals): Add support for access-to-subprogram parameter types. * exp_ch6.adb (Add_Task_Actuals_To_Build_In_Place_Call): Add dummy BIP parameters to access-to-subprogram types that may reference a function that has BIP parameters.
2024-06-10libgcc/aarch64: also provide AT_HWCAP2 fallbackJan Beulich1-0/+3
Much like AT_HWCAP is already provided in case the platform headers don't have the value (yet). libgcc/ * config/aarch64/cpuinfo.c: Provide AT_HWCAP2.
2024-06-10libstdc++: Fix simd<char> conversion for -fno-signed-char for ClangMatthias Kretz1-18/+27
The special case for Clang in the trait producing a signed integer type lead to the trait returning 'char' where it should have been 'signed char'. This workaround was introduced because on Clang the return type of vector compares was not convertible to '_SimdWrapper< __int_for_sizeof_t<...' unless '__int_for_sizeof_t<char>' was an alias for 'char'. In order to not rewrite the complete mask type code (there is code scattered around the implementation assuming signed integers), this needs to be 'signed char'; so the special case for Clang needs to be removed. The conversion issue is now solved in _SimdWrapper, which now additionally allows conversion from vector types with compatible integral type. Signed-off-by: Matthias Kretz <m.kretz@gsi.de> libstdc++-v3/ChangeLog: PR libstdc++/115308 * include/experimental/bits/simd.h (__int_for_sizeof): Remove special cases for __clang__. (_SimdWrapper): Change constructor overload set to allow conversion from vector types with integral conversions via bit reinterpretation. (cherry picked from commit 8e36cf4c5c9140915d0019999db132a900b48037)
2024-06-10libstdc++: Avoid MMX return types from __builtin_shufflevectorMatthias Kretz1-11/+28
This resolves a regression on i686 that was introduced with r15-429-gfb1649f8b4ad50. Signed-off-by: Matthias Kretz <m.kretz@gsi.de> libstdc++-v3/ChangeLog: PR libstdc++/115247 * include/experimental/bits/simd.h (__as_vector): Don't use vector_size(8) on __i386__. (__vec_shuffle): Never return MMX vectors, widen to 16 bytes instead. (concat): Fix padding calculation to pick up widening logic from __as_vector. (cherry picked from commit 241a6cc88d866fb36bd35ddb3edb659453d6322e)
2024-06-10libstdc++: Use __builtin_shufflevector for simd split and concatMatthias Kretz4-192/+145
Signed-off-by: Matthias Kretz <m.kretz@gsi.de> libstdc++-v3/ChangeLog: PR libstdc++/114958 * include/experimental/bits/simd.h (__as_vector): Return scalar simd as one-element vector. Return vector from single-vector fixed_size simd. (__vec_shuffle): New. (__extract_part): Adjust return type signature. (split): Use __extract_part for any split into non-fixed_size simds. (concat): If the return type stores a single vector, use __vec_shuffle (which calls __builtin_shufflevector) to produce the return value. * include/experimental/bits/simd_builtin.h (__shift_elements_right): Removed. (__extract_part): Return single elements directly. Use __vec_shuffle (which calls __builtin_shufflevector) to for all non-trivial cases. * include/experimental/bits/simd_fixed_size.h (__extract_part): Return single elements directly. * testsuite/experimental/simd/pr114958.cc: New test. (cherry picked from commit fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9)
generated by cgit v1.1 at 2024-08-17 18:01:23 +0000