aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2025-04-03vect: Relax scan-tree-dump strict pattern matching [PR118597]Victor Do Nascimento1-5/+3
Using specific SSA names in pattern matching in `dg-final' makes tests "unstable", in that changes in passes prior to the pass whose dump is analyzed in the particular test may change the numbering of the SSA variables, causing the test to start failing spuriously. We thus switch from specific SSA names to the use of a multi-line regular expression making use of capture groups for matching particular variables across different statements, ensuring the test will pass more consistently across different versions of GCC. PR testsuite/118597 gcc/testsuite/ChangeLog: * gcc.dg/vect/vect-fncall-mask.c: Update test directives.
2025-04-03cobol: New testcases for INSPECT statement.Bob Dubner41-0/+1475
gcc/testsuite * cobol.dg/group2/INSPECT_BACKWARD_REPLACING_LEADING.cob: New testcase. * cobol.dg/group2/INSPECT_BACKWARD_REPLACING_TRAILING.cob: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_simple_CONVERTING.cob: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_simple_REPLACING.cob: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_simple_TALLYING.cob: Likewise. * cobol.dg/group2/INSPECT_CONVERTING_NULL.cob: Likewise. * cobol.dg/group2/INSPECT_CONVERTING_TO_figurative_constant.cob: Likewise. * cobol.dg/group2/INSPECT_CONVERTING_TO_figurative_constants.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_1.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_2.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_3.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_4.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_5.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_5-f.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_5-r.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_6.cob: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_7.cob: Likewise. * cobol.dg/group2/INSPECT_No_repeat_conversion_check.cob: Likewise. * cobol.dg/group2/INSPECT_REPLACING_figurative_constant.cob: Likewise. * cobol.dg/group2/INSPECT_REPLACING_LEADING_ZEROS_BY_SPACES.cob: Likewise. * cobol.dg/group2/INSPECT_TALLYING_AFTER.cob: Likewise. * cobol.dg/group2/INSPECT_TALLYING_BEFORE.cob: Likewise. * cobol.dg/group2/INSPECT_TALLYING_REPLACING_ISO_Example.cob: Likewise. * cobol.dg/group2/INSPECT_TRAILING.cob: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_REPLACING_LEADING.out: New known-good result. * cobol.dg/group2/INSPECT_BACKWARD_REPLACING_TRAILING.out: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_simple_CONVERTING.out: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_simple_REPLACING.out: Likewise. * cobol.dg/group2/INSPECT_BACKWARD_simple_TALLYING.out: Likewise. * cobol.dg/group2/INSPECT_CONVERTING_TO_figurative_constants.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_1.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_2.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_3.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_4.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_5-f.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_5.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_5-r.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_6.out: Likewise. * cobol.dg/group2/INSPECT_ISO_Example_7.out: Likewise. * cobol.dg/group2/INSPECT_TALLYING_REPLACING_ISO_Example.out: Likewise. * cobol.dg/group2/INSPECT_TRAILING.out: Likewise.
2025-04-03c++: Fix typo in RAW_DATA_CST build_list_conv subsubconv hanling [PR119563]Jakub Jelinek3-1/+143
The following testcase ICEs (the embed one actually doesn't but dereferences random uninitialized pointer far after allocated memory) because of a typo. In the RAW_DATA_CST handling of list conversion where there are conversions to something other than initializer_list<{{,un}signed ,}char>, the code now calls implicit_conversion for all the RAW_DATA_CST elements and stores them into subsubconvs array. The next loop (done in a separate loop because subsubconvs[0] is handled differently) attempts to do the for (i = 0; i < len; ++i) { conversion *sub = subconvs[i]; if (sub->rank > t->rank) t->rank = sub->rank; if (sub->user_conv_p) t->user_conv_p = true; if (sub->bad_p) t->bad_p = true; } rank/user_conv_p/bad_p merging, but I mistyped the index, the loop iterates with j iterator and i is subconvs index, so the loop effectively doesn't do anything interesting except for merging from one of the subsubconvs element, if lucky within the subsubconvs array, if unlucky not even from inside of the array. The following patch fixes that. 2025-04-03 Andrew Pinski <quic_apinski@quicinc.com> Jakub Jelinek <jakub@redhat.com> PR c++/119563 * call.cc (build_list_conv): Fix a typo in loop gathering summary information from subsubconvs. * g++.dg/cpp0x/pr119563.C: New test. * g++.dg/cpp/embed-26.C: New test.
2025-04-03Fix costs of x86 move instructions at -OsJan Hubicka1-26/+31
This patch fixes problem with size costs declaring all moves to have equal size (which was caught by the sanity check I tried in prologue move cost hook). Costs are relative to reg-reg move which is two. Coincidentally it is also size of the encoding, so the costs should represent typical size of move instruction. The patch reduces cc1plus text size 26391115->26205707 (0.7%) and similar changes also happens to other binaries build during bootstrap. Bootsrapped/regtested x86_64-linux, plan to commit it tomorrow if there are no complains There are other targets that define some load/store costs to be 2 that probably should be fixed too, but they are mostly very old ones and I don't have way of benchmarking them. * config/i386/x86-tune-costs.h (ix86_size_cost): Fix sizes of move instructions
2025-04-03testsuite: Remove guality xfails for aarch64*-*-*Christophe Lyon2-3/+3
Since r15-7878-ge1c49f413c8, these tests appear as XPASS on aarch64, so we can remove the xfails introduced by r12-102-gf31ddad8ac8f11. gcc/testsuite/ChangeLog: * gcc.dg/guality/pr90074.c: Remove xfail for aarch64. * gcc.dg/guality/pr90716.c: Likewise.
2025-04-03testsuite: i386: Fix gcc.target/i386/pr82142?.c etc. on Solaris/x86Rainer Orth3-3/+3
Three tests FAIL on Solaris/x86 in similar ways: FAIL: gcc.target/i386/pr111673.c check-function-bodies advance FAIL: gcc.target/i386/pr82142a.c check-function-bodies assignzero FAIL: gcc.target/i386/pr82142b.c check-function-bodies assignzero All tests FAIL as is because they lack either or both of the .LFB0 label and the .cfi_startproc directive: * The 32-bit pr82142b.c test lacks both, whether as or gas is in use: as lacks full support for the cfi directives and the .LFB0 label is only emitted with -fasynchronous-unwind-tables. * The 64-bit tests pr111673.c and pr82142a.c already work with gas, but with as the cfi directives are again missing. In addition, the 32-bit test (pr82142b.c) still FAILs because 32-bit Solaris/x86 defaults to -mstackrealign. To fix all this, this patch adds -fasynchronous-unwind-tables -fdwarf2-cfi-asm to all tests to force the generation of both the .LFB0 label and .cfi_startproc (which is ok since they are compile tests). In addition, pr82142b.c is compiled with -mno-stackrealign to avoid platform differences. Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu. 2025-03-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: * gcc.target/i386/pr111673.c (dg-options): Add -fasynchronous-unwind-tables -fdwarf2-cfi-asm. * gcc.target/i386/pr82142a.c: Likewise. * gcc.target/i386/pr82142b.c (dg-options): Add -mno-stackrealign -fasynchronous-unwind-tables -fdwarf2-cfi-asm.
2025-04-03c-family: Regenerate c.opt.urlsJakub Jelinek1-1/+1
On Sun, Mar 30, 2025 at 02:48:43PM +0200, Martin Uecker wrote: > The warning -Wzero-as-null-pointer-constant is now not only supported > in C++ but also in C. Change the documentation accordingly. This change didn't include make regenerate-opt-urls changes, because moving option documentation to different section can affect the *.urls files. 2025-04-03 Jakub Jelinek <jakub@redhat.com> * c.opt.urls: Regenerate.
2025-04-03fold-const, cobol: Add native_encode_wide_int and use it in COBOL FE [PR119242]Jakub Jelinek3-17/+26
As has been mentioned earlier, various parts of the COBOL FE and the library aren't endian clean. In the library that means that for now we have to live with no support for big endian targets, but in the FE that means that as well as not being able to build cross-compilers from big endian or pdp endian hosts to little endian targets which are otherwise supported. The following patch attempts to fix one such spot, where it wants to encode in target byte ordering wide_int constants into 1, 2, 4, 8 or 16 bytes. We could wide_int_to_tree and then native_encode_expr, but so that we don't need to build the constants, the following patch exports from fold-const.cc a helper for native_encode_int which takes type and const wide_int_ref reference rather than an expression. 2025-04-03 Jakub Jelinek <jakub@redhat.com> PR cobol/119242 gcc/ * fold-const.h (native_encode_wide_int): Declare. * fold-const.cc (native_encode_wide_int): New function. (native_encode_int): Use it. gcc/cobol/ * genapi.cc (binary_initial_from_float128): Use native_encode_wide_int.
2025-04-03[testsuite] [riscv] limit vwaddsub-1.c to rv64Alexandre Oliva1-1/+1
The desired vw{add,sub}.wx instructions don't come up on rv32 for the first two functions, we get v{add,sub}.vx instead. I suppose this is an oversight, and something about the test is meant for rv64 only, but the fact that the instruction is spelled out in the intrinsic name and a different instruction is generated suggests something may be wrong after all. for gcc/testsuite/ChangeLog * gcc.target/riscv/rvv/base/vwaddsub-1.c: Require rv64.
2025-04-03[testsuite] [riscv] limit mcpu-xiangshan-nanhu.c to rv64Alexandre Oliva1-2/+2
The testcase makes the -march option conditional on rv64, and #errors out if the desired CPU properties are not active. This makes the test fail on rv32. Arrange to skip the test on rv32 instead, moving the rv64 conditional. for gcc/testsuite/ChangeLog * gcc.target/riscv/mcpu-xiangshan-nanhu.c: Skip on non-rv64.
2025-04-03[testsuite] [riscv] xfail some [PR113281] testsAlexandre Oliva3-3/+3
Some of the tests regressed with a fix for the vectorization of shifts. The riscv cost models need to be adjusted to avoid the unprofitable optimization. The failure of these tests has been known since 2024-03-13, without a forthcoming fix, so I suggest we consider it expected by now. Adjust the tests to reflect that expectation. for gcc/testsuite/ChangeLog PR tree-optimization/113281 * gcc.dg/vect/costmodel/riscv/rvv/pr113281-1.c: XFAIL. * gcc.dg/vect/costmodel/riscv/rvv/pr113281-2.c: Likewise. * gcc.dg/vect/costmodel/riscv/rvv/pr113281-5.c: Likewise.
2025-04-03[testsuite] [riscv] xfail ssa-dom-cse-2 on riscv64Alexandre Oliva1-1/+1
For the same reasons that affect alpha and other targets, gcc.dg/tree-ssa/ssa-dom-cse-2.c fails to be optimized to the expected return statement: the array initializer is vectorized into pairs, and DOM cannot see through that. Add riscv*-*-* to the list of affected lp64 platforms. riscv32 is not affected. for gcc/testsuite/ChangeLog * gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL on riscv lp64.
2025-04-03LoongArch: Make gen-evolution.awk compatible with FreeBSD awkXi Ruoyao1-3/+5
Avoid using gensub that FreeBSD awk lacks, use gsub and split those each of gawk, mawk, and FreeBSD awk provides. Reported-by: mpysw@vip.163.com Link: https://man.freebsd.org/cgi/man.cgi?query=awk gcc/ChangeLog: * config/loongarch/genopts/gen-evolution.awk: Avoid using gensub that FreeBSD awk lacks.
2025-04-03APX: Emit nf variant for rotl splitter with mask [PR 119539]Hongyu Wang2-3/+25
For spiltter after *<rotate_insn><mode>3_mask it now splits the pattern to *<rotate_insn><mode>3_mask with flag reg clobber, and it doesn't generate nf variant of rotate. Directly emit nf pattern when TARGET_APX_NF enabled in these define_insn_and_split. gcc/ChangeLog: PR target/119539 * config/i386/i386.md (*<insn><mode>3_mask): Emit NF variant of rotate when APX_NF enabled, and use force_lowpart_subreg. (*<insn><mode>3_mask_1): Likewise. gcc/testsuite/ChangeLog: PR target/119539 * gcc.target/i386/apx-nf-pr119539.c: New test.
2025-04-03Doc: Clarify use of access attribute [PR101440]Sandra Loosemore1-19/+22
This issue was specifically about a confusing mention of the "second and third arguments to the memcpy function" when only the second one is a pointer affected by the attribute, but reading through the entire discussion I found other things confusing as well; e.g. in some cases it wasn't clear whether the "arguments" were the arguments to the attribute or the function, or exactly what a "positional argument" was. I've tried to rewrite that part to straighten it out, as well as some light copy-editing throughout. gcc/ChangeLog PR c/101440 * doc/extend.texi (Common Function Attributes): Clean up some confusing language in the description of the "access" attribute.
2025-04-03Daily bump.GCC Administrator8-1/+254
2025-04-02Doc: Improve wording of -Werror documentation [PR58973]Sandra Loosemore2-5/+5
gcc/ChangeLog PR driver/58973 * common.opt (Werror, Werror=): Use less awkward wording in description. (pedantic-errors): Likewise. * doc/invoke.texi (Warning Options): Likewise for -Werror and -Werror= here. Co-Authored-By: GUO Yixuan <culu.gyx@gmail.com>
2025-04-02d: Fix error using UFCS in a speculative contextIain Buclaw5-9/+97
This reverts a change in the upstream D implementation of the compiler, as it is no longer necessary since another fix for opDispatch got applied in the same area (merged in r12-6003-gfd43568cc54e17). gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd ed17b3e95d. Reviewed-on: https://github.com/dlang/dmd/pull/21132
2025-04-02RISC-V: Fix vec_duplicate[bimode] expander [PR119572].Robin Dapp1-1/+9
Since r15-9062-g70391e3958db79 we perform vector bitmask initialization via the vec_duplicate expander directly. This triggered a latent bug in ours where we missed to mask out the single bit which resulted in an execution FAIL of pr119114.c The attached patch adds the 1-masking of the broadcast operand. PR target/119572 gcc/ChangeLog: * config/riscv/autovec.md: Mask broadcast value.
2025-04-02[PATCH v2] RISC-V: Fixbug for slli + addw + zext.w into sh[123]add + zext.wJin Ma3-1/+36
Assuming we have the following variables: unsigned long long a0, a1; unsigned int a2; For the expression: a0 = (a0 << 50) >> 49; // slli a0, a0, 50 + srli a0, a0, 49 a2 = a1 + a0; // addw a2, a1, a0 + slli a2, a2, 32 + srli a2, a2, 32 In the optimization process of ZBA (combine pass), it would be optimized to: a2 = a0 << 1 + a1; // sh1add a2, a0, a1 + zext.w a2, a2 This is clearly incorrect, as it overlooks the fact that a0=a0&0x7ffe, meaning that the bits a0[32:14] are set to zero. gcc/ChangeLog: * config/riscv/bitmanip.md: The optimization can only be applied if the high bit of operands[3] is set to 1. gcc/testsuite/ChangeLog: * gcc.target/riscv/zba-shNadd-09.c: New test. * gcc.target/riscv/zba-shNadd-10.c: New test.
2025-04-02xfail __tcf_ZL1b assembler check on hppa*-*-hpux* in g++.dg/modules/pr98893_b.CJohn David Anglin1-1/+1
2025-04-02 John David Anglin <danglin@gcc.gnu.org> gcc/testsuite/ChangeLog: * g++.dg/modules/pr98893_b.C: xfail __tcf_ZL1b assembler check on hppa*-*-hpux*.
2025-04-02Skip g++.dg/abi/abi-tag18a.C on hppa*-*-hpux*John David Anglin1-1/+1
2025-04-02 John David Anglin <danglin@gcc.gnu.org> gcc/testsuite/ChangeLog: * g++.dg/abi/abi-tag18a.C: Skip on hppa*-*-hpux*.
2025-04-02cobol: Plug memory leak caused by intermediate_e stack-frame variables. ↵Bob Dubner5-85/+85
[PR119521] COBOL variables with attribute intermediate_e are being allocated on the stack frame, but their data was assigned using malloc(), without a corresponding call to free(). For numerics, the problem is solved with a fixed allocation of sixteen bytes for the cblc_field_t::data member (sixteen is big enough for all data types) and with a fixed allocation of 8,192 bytes for the alphanumeric type. In use, the intermediate numeric data types are "shrunk" to the minimum applicable size. The intermediate alphanumerics, generally used as destination targets for functions, are trimmed as well. gcc/cobol PR cobol/119521 * genapi.cc: (parser_division): Change comment. (parser_symbol_add): Change intermediate_t handling. * parse.y: Multiple changes to new_alphanumeric() calls. * parse_ante.h: Establish named constant for date function calls. Change declaration of new_alphanumeric() function. * symbols.cc: (new_temporary_impl): Use named constant for default size of temporary alphanumerics. * symbols.h: Establish MAXIMUM_ALPHA_LENGTH constant. libgcobol PR cobol/119521 * intrinsic.cc: (__gg__reverse): Trim final result for intermediate_e. * libgcobol.cc: (__gg__adjust_dest_size): Abort on attempt to increase the size of a result. (__gg__module_name): Formatting. __gg__reverse(): Resize only intermediates
2025-04-02Doc: #pragma pack documentation cleanup [PR114957] [PR78008] [PR60972]Sandra Loosemore1-29/+58
This patch addresses a number of issues with the documentation of - None of the things in this section had @cindex entries [PR114957]. - The document formatting didn't match that of other #pragma documentation sections. - The effect of #pragma pack(0) wasn't documented [PR78008]. - There's a long-standing bug [PR60972] reporting that #pragma pack and the __attribute__(packed) don't get along well. It seems worthwhile to warn users about that since elsewhere pragmas are cross-referenced with related or equivalent attributes. gcc/ChangeLog PR c/114957 PR c/78008 PR c++/60972 * doc/extend.texi (Structure-Layout Pragmas): Add @cindex entries and reformat the pragma descriptions to match the markup used for other pragmas. Document what #pragma pack(0) does. Add cross-references to similar attributes.
2025-04-02tailc: Deal with trivially useless EH cleanups [PR119491]Jakub Jelinek4-23/+207
The following testcases FAIL, because EH cleanup is performed only before IPA and then right before musttail pass. At -O2 etc. (except for -O0/-Og) we handle musttail calls in the tailc pass though, and we can fail at that point because the calls might appear to throw internal exceptions which just don't do anything interesting (perhaps have debug statements or clobber statements in them) before they continue with resume of the exception (i.e. throw it externally). As Richi said in the PR (and I agree) that moving passes is risky at this point, the following patch instead teaches the tail{r,c} and musttail passes to deal with such extra EDGE_EH edges. It is fairly simple thing, if we see an EDGE_EH edge from the call we just look up where it lands and if there are no non-debug/non-clobber/non-label statements before resx which throws externally, such edge can be ignored for tail call optimization or tail recursion. At other spots I just need to avoid using single_succ/single_succ_edge because the bb might have another edge - EDGE_EH. To make this less risky, this is done solely for the musttail calls for now. 2025-04-02 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/119491 * tree-tailcall.cc (single_non_eh_succ_edge): New function. (independent_of_stmt_p): Use single_non_eh_succ_edge (bb)->dest instead of single_succ (bb). (empty_eh_cleanup): New function. (find_tail_calls): Diagnose throwing of exceptions which do not propagate only if there are no EDGE_EH successor edges. If there are and the call is musttail, use empty_eh_cleanup to find if the cleanup is not empty. If not or the call is not musttail, use different diagnostics. Set is_noreturn even if there are successor edges. Use single_non_eh_succ_edge (abb) instead of single_succ_edge (abb). Punt on internal noreturn calls. (decrease_profile): Don't assert 0 or 1 successor edges. (eliminate_tail_call): Use single_non_eh_succ_edge (gsi_bb (t->call_gsi)) instead of single_succ_edge (gsi_bb (t->call_gsi)). (tree_optimize_tail_calls_1): Also look into basic blocks with single succ edge which is EDGE_EH for noreturn musttail calls. * g++.dg/opt/musttail3.C: New test. * g++.dg/opt/musttail4.C: New test. * g++.dg/opt/musttail5.C: New test.
2025-04-02c: Fix ICEs with -fsanitize=pointer-{subtract,compare} [PR119582]Jakub Jelinek2-4/+27
The following testcase ICEs because c_fully_fold isn't performed on the arguments of __sanitizer_ptr_{sub,cmp} builtins and so e.g. C_MAYBE_CONST_EXPR can leak into the gimplifier where it ICEs. 2025-04-02 Jakub Jelinek <jakub@redhat.com> PR c/119582 * c-typeck.cc (pointer_diff, build_binary_op): Call c_fully_fold on __sanitizer_ptr_sub or __sanitizer_ptr_cmp arguments. * gcc.dg/asan/pr119582.c: New test.
2025-04-02OpenMP: Require target and/or targetsync init modifier [PR118965]Sandra Loosemore29-312/+442
As noted in PR 118965, the initial interop implementation overlooked the requirement in the OpenMP spec that at least one of the "target" and "targetsync" modifiers is required in both the interop construct init clause and the declare variant append_args clause. Adding the check was fairly straightforward, but it broke about a gazillion existing test cases. In particular, things like "init (x, y)" which were previously accepted (and tested for being accepted) aren't supposed to be allowed by the spec, much less things like "init (target)" where target was previously interpreted as a variable name instead of a modifier. Since one of the effects of the change is that at least one modifier is always required, I found that deleting all the code that was trying to detect and handle the no-modifier case allowed for better diagnostics. gcc/c/ChangeLog PR middle-end/118965 * c-parser.cc (c_parser_omp_clause_init_modifiers): Adjust error message. (c_parser_omp_clause_init): Remove code for recognizing clauses without modifiers. Diagnose missing target/targetsync modifier. (c_finish_omp_declare_variant): Diagnose missing target/targetsync modifier. gcc/cp/ChangeLog PR middle-end/118965 * parser.cc (c_parser_omp_clause_init_modifiers): Adjust error message. (cp_parser_omp_clause_init): Remove code for recognizing clauses without modifiers. Diagnose missing target/targetsync modifier. (cp_finish_omp_declare_variant): Diagnose missing target/targetsync modifier. gcc/fortran/ChangeLog PR middle-end/118965 * openmp.cc (gfc_parser_omp_clause_init_modifiers): Fix some inconsistent code indentation. Remove code for recognizing clauses without modifiers. Diagnose prefer_type without a following paren. Adjust error message for an unrecognized modifier. Diagnose missing target/targetsync modifier. (gfc_match_omp_init): Fix more inconsistent code indentation. gcc/testsuite/ChangeLog PR middle-end/118965 * c-c++-common/gomp/append-args-1.c: Add target/targetsync modifiers so tests do what they were previously supposed to do. Adjust expected output. * c-c++-common/gomp/append-args-7.c: Likewise. * c-c++-common/gomp/append-args-8.c: Likewise. * c-c++-common/gomp/append-args-9.c: Likewise. * c-c++-common/gomp/interop-1.c: Likewise. * c-c++-common/gomp/interop-2.c: Likewise. * c-c++-common/gomp/interop-3.c: Likewise. * c-c++-common/gomp/interop-4.c: Likewise. * c-c++-common/gomp/pr118965-1.c: New. * c-c++-common/gomp/pr118965-2.c: New. * g++.dg/gomp/append-args-1.C: Add target/targetsync modifiers and adjust expected output. * g++.dg/gomp/append-args-2.C: Likewise. * g++.dg/gomp/append-args-6.C: Likewise. * g++.dg/gomp/append-args-7.C: Likewise. * g++.dg/gomp/append-args-8.C: Likewise. * g++.dg/gomp/interop-5.C: Likewise. * gfortran.dg/gomp/append_args-1.f90: Add target/targetsync modifiers and adjust expected output. * gfortran.dg/gomp/append_args-2.f90: Likewise. * gfortran.dg/gomp/append_args-3.f90: Likewise. * gfortran.dg/gomp/append_args-4.f90: Likewise. * gfortran.dg/gomp/interop-1.f90: Likewise. * gfortran.dg/gomp/interop-2.f90: Likewise. * gfortran.dg/gomp/interop-3.f90: Likewise. * gfortran.dg/gomp/interop-4.f90: Likewise. * gfortran.dg/gomp/pr118965-1.f90: New. * gfortran.dg/gomp/pr118965-2.f90: New.
2025-04-02tree-optimization/119586 - aligned access to unaligned dataRichard Biener2-8/+34
The following reverts parts of r15-8047 which assesses alignment analysis for VMAT_STRIDED_SLP is correct by using aligned accesses where allowed by it. As the PR shows this analysis is still incorrect, so revert back to assuming we got it wrong. PR tree-optimization/119586 * tree-vect-stmts.cc (vectorizable_load): Assume we got alignment analysis for VMAT_STRIDED_SLP wrong. (vectorizable_store): Likewise. * gcc.dg/vect/pr119586.c: New testcase.
2025-04-02switch-3.c: Fix llp64 warningsJonathan Yong1-1/+1
mtrr_ioctl() uses long and casts it to a pointer. Fix warnings for llp64 platforms. Signed-off-by: Jonathan Yong <10walls@gmail.com> gcc/testsuite/ChangeLog: * gcc.dg/analyzer/torture/switch-3.c: Fix llp64 warnings.
2025-04-02doc: Extend musttail attribute docsJakub Jelinek1-0/+25
On Wed, Apr 02, 2025 at 10:32:20AM +0200, Richard Biener wrote: > I wonder if we can amend the documentation to suggest to end lifetime > of variables explicitly by proper scoping? In the -Wmaybe-musttail-local-addr attribute description I've already tried to show that in the example, but if you think something like the following would make it clearer. 2025-04-02 Jakub Jelinek <jakub@redhat.com> * doc/extend.texi (musttail statement attribute): Hint how to avoid -Wmaybe-musttail-local-addr warnings.
2025-04-02cobol: Fix incorrect use of std::remove_ifJonathan Wakely1-5/+4
The call to std::remove_if used here doesn't remove any elements, it just overwrites the "removed" elements with later elements, leaving the total number of elements unchanged. Use std::list::remove_if to actually remove those unwanted elements from the list. gcc/cobol/ChangeLog: * symfind.cc (finalize_symbol_map2): Use std::list::remove_if instead of std::remove_if.
2025-04-02tailc: Don't fail musttail calls if they use or could use local arguments, ↵Jakub Jelinek20-24/+760
instead warn [PR119376] As discussed here and in bugzilla, [[clang::musttail]] attribute in clang not just strongly asks for tail call or error, but changes behavior. To quote: https://clang.llvm.org/docs/AttributeReference.html#musttail "The lifetimes of all local variables and function parameters end immediately before the call to the function. This means that it is undefined behaviour to pass a pointer or reference to a local variable to the called function, which is not the case without the attribute. Clang will emit a warning in common cases where this happens." The GCC behavior was just to error if we can't prove the musttail callee could not have dereferenced escaped pointers to local vars or parameters of the caller. That is still the case for variables with non-trivial destruction (even in clang), like vars with C++ non-trivial destructors or variables with cleanup attribute. The following patch changes the behavior to match that of clang, for all of [[clang::musttail]], [[gnu::musttail]] and __attribute__((musttail)). clang 20 actually added warning for some cases of it in https://github.com/llvm/llvm-project/pull/109255 but it is under -Wreturn-stack-address warning. Now, gcc doesn't have that warning, but -Wreturn-local-addr instead, and IMHO it is better to have this under new warnings, because this isn't about returning local address, but about passing it to a musttail call, or maybe escaping to a musttail call. And perhaps users will appreciate they can control it separately as well. The patch introduces 2 new warnings. -Wmusttail-local-addr which is turn on by default and warns for the always dumb cases of passing an address of a local variable or parameter to musttail call's argument. And then -Wmaybe-musttail-local-addr which is only diagnosed if -Wmusttail-local-addr was not diagnosed and diagnoses at most one (so that we don't emit 100s of warnings for one call if 100s of vars can escape) case where an address of a local var could have escaped to the musttail call. This is less severe, the code doesn't have to be obviously wrong, so the warning is only enabled in -Wextra. And I've adjusted also the documentation for this change and addition of new warnings. 2025-04-02 Jakub Jelinek <jakub@redhat.com> PR ipa/119376 * common.opt (Wmusttail-local-addr, Wmaybe-musttail-local-addr): New. * tree-tailcall.cc (suitable_for_tail_call_opt_p): Don't fail for TREE_ADDRESSABLE PARM_DECLs for musttail calls if diag_musttail. Emit -Wmusttail-local-addr warnings. (maybe_error_musttail): Use gimple_location instead of directly accessing location member. (find_tail_calls): For musttail calls if diag_musttail, don't fail if address of local could escape to the call, instead emit -Wmaybe-musttail-local-addr warnings. Emit -Wmaybe-musttail-local-addr warnings also for address taken parameters. * common.opt.urls: Regenerate. * doc/extend.texi (musttail statement attribute): Clarify local variables without non-trivial destruction are considered out of scope before the tail call instruction. * doc/invoke.texi (-Wno-musttail-local-addr, -Wmaybe-musttail-local-addr): Document. * c-c++-common/musttail8.c: Expect a warning rather than error in one case. (f4): Add int * argument. * c-c++-common/musttail15.c: Don't disallow for C++98. * c-c++-common/musttail16.c: Likewise. * c-c++-common/musttail17.c: Likewise. * c-c++-common/musttail18.c: Likewise. * c-c++-common/musttail19.c: Likewise. Expect a warning rather than error in one case. (f4): Add int * argument. * c-c++-common/musttail20.c: Don't disallow for C++98. * c-c++-common/musttail21.c: Likewise. * c-c++-common/musttail28.c: New test. * c-c++-common/musttail29.c: New test. * c-c++-common/musttail30.c: New test. * c-c++-common/musttail31.c: New test. * g++.dg/ext/musttail1.C: New test. * g++.dg/ext/musttail2.C: New test. * g++.dg/ext/musttail3.C: New test.
2025-04-02testsuite: arm: Fix dg-final in short-vfp-1.c [PR119556]Christophe Lyon1-6/+6
Recent syntactic fixes enabled the test, but the result was failing. It turns out it was missing a space between the register arguments in the scan-assembler-times directives. gcc/testsuite/ChangeLog: PR target/119556 * gcc.target/arm/short-vfp-1.c: Add missing spaces.
2025-04-01PR119482: Avoid mispredictions in bitmap_set_bitAndi Kleen1-2/+2
bitmap_set_bit checks the original value of the bit to return it to the caller and then only writes the new value back if it changes. Most callers of bitmap_set_bit don't need the return value, but with the conditional store the CPU still has to predict it correctly since gcc doesn't know how to do that without APX on x86 (even though CMOV could do it with a dummy target). Really if-conversion should handle this case, but for now we can fix it. This simple patch improves runtime by 15% for the test case in the PR. Which is more than I expected given it only has ~1.44% of the cycles, but I guess the mispredicts caused some down stream effects. cc1plus-bitmap -std=gnu++20 -O2 pr119482.cc -quiet ran 1.15 ± 0.01 times faster than cc1plus -std=gnu++20 -O2 pr119482.cc -quiet At least with this test case the total number of branches decreases drastically. Even though the mispredict rate goes up slightly it is still a big win. $ perf stat -e branches,branch-misses,uncore_imc/cas_count_read/,uncore_imc/cas_count_write/ \ -a ../obj-fast/gcc/cc1plus -std=gnu++20 -O2 pr119482.cc -quiet -w Performance counter stats for 'system wide': 41,932,957,091 branches 686,117,623 branch-misses # 1.64% of all branches 43,690.47 MiB uncore_imc/cas_count_read/ 12,362.56 MiB uncore_imc/cas_count_write/ 49.328633365 seconds time elapsed $ perf stat -e branches,branch-misses,uncore_imc/cas_count_read/,uncore_imc/cas_count_write/ \ -a ../obj-fast/gcc/cc1plus-bitmap -std=gnu++20 -O2 pr119482.cc -quiet -w Performance counter stats for 'system wide': 37,092,113,179 branches 663,641,708 branch-misses # 1.79% of all branches 43,196.52 MiB uncore_imc/cas_count_read/ 12,369.33 MiB uncore_imc/cas_count_write/ 42.632458350 seconds time elapsed gcc/ChangeLog: PR middle-end/119482 * bitmap.cc (bitmap_set_bit): Write back value unconditionally
2025-04-02Doc: Cross-reference constructor and init_priority attributes [PR118982]Sandra Loosemore1-19/+32
Per the issue, the discussion of these two attributes needed to be better integrated. I also did some editing for style and readability, and clarified that almost all targets support this feature (it is enabled by default unless the back end disables it), not just "some". Co-Authored_by: Jonathan Wakely <jwakely@redhat.com> gcc/ChangeLog PR c++/118982 * doc/extend.texi (Common Function Attributes): For the constructor/destructory attribute, be more explicit about the relationship between the constructor attribute and the C++ init_priority attribute, and add a cross-reference. Also document that most targets support this. (C++ Attributes): Similarly for the init_priority attribute.
2025-04-02Daily bump.GCC Administrator5-1/+281
2025-04-01Doc: Document _Bool type as C90 extension [PR118118]Sandra Loosemore1-0/+12
gcc/ChangeLog PR c/118118 * doc/extend.texi (Boolean Type): New section.
2025-04-01cobol: Change some dubious sprintf() calls to xasprintf in genapi.ccBob Dubner1-57/+41
These calls were into fixed-length arrays that might be too small. gcc/cobol * genapi.cc: (section_label): Use xasprintf() instead of sprintf(). (paragraph_label): Likewise. (leave_procedure): Likewise. (find_procedure): Likewise. (parser_goto): Likewise. (parser_enter_file): Likewise.
2025-04-01Doc: Document enum with underlying type extension [PR117689]Sandra Loosemore1-12/+50
This is a C23/C++11 feature that is supported as an extension with earlier -std= options too, but was never previously documented. It interacts with the already-documented forward enum definition extension, so I have merged discussion of the two extensions into the same section. gcc/ChangeLog PR c/117689 * doc/extend.texi (Incomplete Enums): Rename to.... (Enum Extensions): This. Document support for specifying the underlying type of an enum as an extension in all earlier C and C++ standards. Document that a forward declaration with underlying type is not an incomplete type, and which dialects GCC supports that in.
2025-04-02c++/modules: Forbid exposures of TU-local entities in inline variables ↵Nathaniel Shead6-4/+68
[PR119551] An inline variable has vague linkage, and needs to be conditionally emitted in TUs that reference it. Unfortunately this clashes with [basic.link] p14.2, which says that we ignore the initialisers of all variables (including inline ones), since importers will not have access to the referenced TU-local entities to write the definition. This patch makes such exposures be ill-formed. One case that continues to work is if the exposure is part of the dynamic initialiser of an inline variable; in such cases, the definition has been built as part of the module interface unit anyway, and importers don't need to write it out again, so such exposures are "harmless". PR c++/119551 gcc/cp/ChangeLog: * module.cc (trees_out::write_var_def): Only ignore non-inline variable initializers. gcc/testsuite/ChangeLog: * g++.dg/modules/internal-5_a.C: Add cases that should be ignored. * g++.dg/modules/internal-5_b.C: Test these new cases, and make the testcase more robust. * g++.dg/modules/internal-11.C: New test. * g++.dg/modules/internal-12_a.C: New test. * g++.dg/modules/internal-12_b.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
2025-04-02c++: Rename -fmodules-ts to -fmodules in diagnosticsNathaniel Shead1-3/+3
This replaces some usages of the old -fmodules-ts flag with the new -fmodules flag made in r15-5112-gd9c3c3c85665b2. gcc/cp/ChangeLog: * parser.cc (cp_parser_diagnose_invalid_type_name): Replace fmodules-ts with fmodules. (cp_parser_template_declaration): Likewise. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
2025-04-01Further use of mod_scope in modified_type_dieTom Tromey1-4/+4
I am working on some changes to GNAT to emit hierarchical DWARF -- i.e., where entities will have simple names nested in a DW_TAG_module. While working on this I found a couple of paths in modified_type_die where "mod_scope" should be used, but is not. I suspect these cases are only reachable by Ada code, as in both spots (subrange types and base types), I believe that other languages don't generally have named types in a non-top-level scope, and in these other situations, mod_scope will still be correct. gcc * dwarf2out.cc (modified_type_die): Use mod_scope for ranged types, base types, and array types.
2025-04-01tailc: Improve tail recursion handling [PR119493]Jakub Jelinek2-14/+104
This is a partial step towards fixing that PR. For musttail recursive calls which have non-is_gimple_reg_type typed parameters, the only case we've handled was if the exact parameter was passed through (perhaps modified, but still the same PARM_DECL). That isn't necessary, we can copy the argument to the parameter as well (just need to watch for the use of the parameter in later arguments, say musttail recursive call which swaps 2 structure arguments). The patch attempts to play safe and punts if any of the parameters are addressable (like we do for all normal tail calls and tail recursions, except for musttail in the posted unreviewed patch). With this patch (at least when early inlining isn't done on not yet optimized body) inlining should see already tail recursion optimized body and will not have problems with SRA breaking musttail. This version of the patch limits this for musttail tail recursions, with intent to enable for all tail recursions in GCC 16. 2025-04-01 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/119493 * tree-tailcall.cc (find_tail_calls): Don't punt on tail recusion if some arguments don't have is_gimple_reg_type, only punt if they have non-POD types, or volatile, or addressable or (for now) it is not a musttail call. Set tailr_arg_needs_copy in those cases too. (eliminate_tail_call): Copy call arguments to params if they don't have is_gimple_reg_type, use temporaries if the argument is used later. (tree_optimize_tail_calls_1): Skip !is_gimple_reg_type tailr_arg_needs_copy parameters. Formatting fix. * gcc.dg/pr119493-1.c: New test.
2025-04-01combine: Use reg_used_between_p rather than modified_between_p in two spots ↵Jakub Jelinek2-7/+42
[PR119291] The following testcase is miscompiled on x86_64-linux at -O2 by the combiner. We have from earlier combinations (insn 22 21 23 4 (set (reg:SI 104 [ _7 ]) (const_int 0 [0])) "pr119291.c":25:15 96 {*movsi_internal} (nil)) (insn 23 22 24 4 (set (reg/v:SI 117 [ e ]) (reg/v:SI 116 [ e ])) 96 {*movsi_internal} (expr_list:REG_DEAD (reg/v:SI 116 [ e ]) (nil))) (note 24 23 25 4 NOTE_INSN_DELETED) (insn 25 24 26 4 (parallel [ (set (reg:CCZ 17 flags) (compare:CCZ (neg:SI (reg:SI 104 [ _7 ])) (const_int 0 [0]))) (set (reg/v:SI 116 [ e ]) (neg:SI (reg:SI 104 [ _7 ]))) ]) "pr119291.c":26:13 977 {*negsi_2} (expr_list:REG_DEAD (reg:SI 104 [ _7 ]) (nil))) (note 26 25 27 4 NOTE_INSN_DELETED) (insn 27 26 28 4 (set (reg:DI 128 [ _9 ]) (ne:DI (reg:CCZ 17 flags) (const_int 0 [0]))) "pr119291.c":26:13 1447 {*setcc_di_1} (expr_list:REG_DEAD (reg:CCZ 17 flags) (nil))) and try_combine is called on i3 25 and i2 22 (second time) and reach the hunk being patched with simplified i3 (insn 25 24 26 4 (parallel [ (set (pc) (pc)) (set (reg/v:SI 116 [ e ]) (const_int 0 [0])) ]) "pr119291.c":28:13 977 {*negsi_2} (expr_list:REG_DEAD (reg:SI 104 [ _7 ]) (nil))) and (insn 22 21 23 4 (set (reg:SI 104 [ _7 ]) (const_int 0 [0])) "pr119291.c":27:15 96 {*movsi_internal} (nil)) Now, the try_combine code there attempts to split two independent sets in newpat by moving one of them to i2. And among other tests it checks !modified_between_p (SET_DEST (set1), i2, i3) which is certainly needed, if there would be say (set (reg/v:SI 116 [ e ]) (const_int 42 [0x2a])) in between i2 and i3, we couldn't do that, as that set would overwrite the value set by set1 we want to move to the i2 position. But in this case pseudo 116 isn't set in between i2 and i3, but used (and additionally there is a REG_DEAD note for it). This is equally bad for the move, because while the i3 insn and later will see the pseudo value that we set, the insn in between which uses the value will see a different value from the one that it should see. As we don't check for that, in the end try_combine succeeds and changes the IL to: (insn 22 21 23 4 (set (reg/v:SI 116 [ e ]) (const_int 0 [0])) "pr119291.c":27:15 96 {*movsi_internal} (nil)) (insn 23 22 24 4 (set (reg/v:SI 117 [ e ]) (reg/v:SI 116 [ e ])) 96 {*movsi_internal} (expr_list:REG_DEAD (reg/v:SI 116 [ e ]) (nil))) (note 24 23 25 4 NOTE_INSN_DELETED) (insn 25 24 26 4 (set (pc) (pc)) "pr119291.c":28:13 2147483647 {NOOP_MOVE} (nil)) (note 26 25 27 4 NOTE_INSN_DELETED) (insn 27 26 28 4 (set (reg:DI 128 [ _9 ]) (const_int 0 [0])) "pr119291.c":28:13 95 {*movdi_internal} (nil)) (note, the i3 got turned into a nop and try_combine also modified insn 27). The following patch replaces the modified_between_p tests with reg_used_between_p, my understanding is that modified_between_p is a subset of reg_used_between_p, so one doesn't need both. Looking at this some more today, I think we should special case set_noop_p because that can be put into i2 (except for the JUMP_P violations), currently both modified_between_p (pc_rtx, i2, i3) and reg_used_between_p (pc_rtx, i2, i3) returns false. I'll post a patch incrementally for that (but that feels like new optimization, so probably not something that should be backported). On Tue, Apr 01, 2025 at 11:27:25AM +0200, Richard Biener wrote: > Can we constrain SET_DEST (set1/set0) to a REG_P in combine? Why > does the comment talk about memory? I was worried about making too risky changes this late in stage4 (and especially also for backports). Most of this code is 1992-ish. I think many of the functions are just misnamed, the reg_ in there doesn't match what those functions do (bet they initially supported just REGs and later on support for other kinds of expressions was added, but haven't done git archeology to prove that). What we know for sure is: && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != ZERO_EXTRACT && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != STRICT_LOW_PART && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 1))) != ZERO_EXTRACT && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 1))) != STRICT_LOW_PART that is checked earlier in the condition. Then it calls && ! reg_referenced_p (SET_DEST (XVECEXP (newpat, 0, 1)), XVECEXP (newpat, 0, 0)) && ! reg_referenced_p (SET_DEST (XVECEXP (newpat, 0, 0)), XVECEXP (newpat, 0, 1)) While it has reg_* in it, that function mostly calls reg_overlap_mentioned_p which is also misnamed, that function handles just fine all of REG, MEM, SUBREG of REG, (SUBREG of MEM not, see below), ZERO_EXTRACT, STRICT_LOW_PART, PC and even some further cases. So, IMHO SET_DEST (set0) or SET_DEST (set0) can be certainly a REG, SUBREG of REG, PC (at least the REG and PC cases are triggered on the testcase) and quite possibly also MEM (SUBREG of MEM not, see below). Now, the code uses !modified_between_p (SET_SRC (set{1,0}), i2, i3) where that function for constants just returns false, for PC returns true, for REG returns reg_set_between_p, for MEM recurses on the address, for MEM_READONLY_P otherwise returns false, otherwise checks using alias.cc code whether the memory could have been modified in between, for all other rtxes recurses on the subrtxes. This part didn't change in my patch. I've only changed those - && !modified_between_p (SET_DEST (set{1,0}), i2, i3) + && !reg_used_between_p (SET_DEST (set{1,0}), i2, i3) where the former has been described above and clearly handles all of REG, SUBREG of REG, PC, MEM and SUBREG of MEM among other things. The replacement reg_used_between_p calls reg_overlap_mentioned_p on each instruction in between i2 and i3. So, there is clearly a difference in behavior if SET_DEST (set{1,0}) is pc_rtx, in that case modified_between_p returns unconditionally true even if there are no instructions in between, but reg_used_between_p if there are no non-debug insns in between returns false. Sorry for missing that, guess I should check for that (with the exception of the noop moves which are often (set (pc) (pc)) and handled by the incremental patch). In fact not just that, reg_used_between_p will only return true for PC if it is mentioned anywhere in the insns in between. Anyway, except for that, for REG it calls refers_to_regno_p and so should find any occurrences of any of the REG or parts of it for hard registers, for MEM returns true if it sees any MEMs in insns in between (conservatively), for SUBREGs apparently it relies on it being SUBREG of REG (so doesn't handle SUBREG of MEM) and handles SUBREG of REG like the SUBREG_REG, PC I've already described. Now, because reg_overlap_mentioned_p doesn't handle SUBREG of MEM, I think already the initial && ! reg_referenced_p (SET_DEST (XVECEXP (newpat, 0, 1)), XVECEXP (newpat, 0, 0)) && ! reg_referenced_p (SET_DEST (XVECEXP (newpat, 0, 0)), XVECEXP (newpat, 0, 1)) calls would have failed --enable-checking=rtl or would have misbehaved, so I think there is no need to check for it further. To your question why I don't use reg_referenced_p, that is because reg_referenced_p is something to call on one insn pattern, while reg_used_between_p is pretty much that on all insns in between two instructions (excluding the boundaries). So, I think it would be safer to add && SET_DEST (set{1,0} != pc_rtx checks to preserve former behavior, like in the following version. 2025-04-01 Jakub Jelinek <jakub@redhat.com> PR rtl-optimization/119291 * combine.cc (try_combine): For splitting of PARALLEL with 2 independent SETs into i2 and i3 sets check reg_used_between_p of the SET_DESTs rather than just modified_between_p. * gcc.c-torture/execute/pr119291.c: New test.
2025-04-01RISC-V: Tweak testcase for PIEKito Cheng33-56/+56
Linux toolchain may configured with --enable-default-pie, and that will cause lots of regression test failures because the function name will append with @plt suffix (e.g. `call foo` become `call foo@plt`), also some code generation will different due to the code model like the address generation for global variable, so we may add -fno-pie to those testcases to prevent that. We may consider just drop @plt suffix to prevent that at all, because it's not difference between w/ and w/o @plt suffix, the linker will pick the right one to do, however it's late stage of GCC development, so just tweak the testcase should be the best way to do now. Changes from v1: - Add more testcase for PIE (from rvv.exp). - Tweak the rule for match @plt. gcc/testsuite/ChangeLog: * gcc.target/riscv/rv32i_zcmp.c: Tweak testcase for PIE. * gcc.target/riscv/rv32e_zcmp.c: Likewise. * gcc.target/riscv/zcmp_stack_alignment.c: Likewise. * gcc.target/riscv/cm_mv_rv32.c: Likewise. * gcc.target/riscv/cpymem-64.c: Likewise. * gcc.target/riscv/fmax-snan.c: Likewise. * gcc.target/riscv/fmaxf-snan.c: Likewise. * gcc.target/riscv/fmin-snan.c: Likewise. * gcc.target/riscv/fminf-snan.c: Likewise. * gcc.target/riscv/large-model.c: Likewise. * gcc.target/riscv/predef-1.c: Likewise. * gcc.target/riscv/predef-4.c: Likewise. * gcc.target/riscv/predef-7.c: Likewise. * gcc.target/riscv/predef-9.c: Likewise. * gcc.target/riscv/rvv/base/abi-callee-saved-2-save-restore.c: Likewise. * gcc.target/riscv/rvv/base/abi-callee-saved-2-zcmp.c: Likewise. * gcc.target/riscv/rvv/base/abi-callee-saved-2.c: Likewise. * gcc.target/riscv/rvv/base/cmpmem-1.c: Likewise. * gcc.target/riscv/rvv/base/cmpmem-3.c: Likewise. * gcc.target/riscv/rvv/base/cmpmem-4.c: Likewise. * gcc.target/riscv/rvv/base/cpymem-1.c: Likewise. * gcc.target/riscv/rvv/base/movmem-1.c: Likewise. * gcc.target/riscv/rvv/base/pr114352-3.c: Likewise. * gcc.target/riscv/rvv/base/setmem-1.c: Likewise. * gcc.target/riscv/rvv/base/setmem-2.c: Likewise. * gcc.target/riscv/rvv/base/setmem-3.c: Likewise. * gcc.target/riscv/rvv/base/spill-9.c: Likewise. * g++.target/riscv/mv-symbols1.C: Likewise. * g++.target/riscv/mv-symbols3.C: Likewise. * g++.target/riscv/mv-symbols4.C: Likewise. * g++.target/riscv/mv-symbols5.C: Likewise. * g++.target/riscv/mvc-symbols1.C: Likewise. * g++.target/riscv/mvc-symbols3.C: Likewise.
2025-04-01tree-optimization/119534 - reject bogus emulated vectorized gatherRichard Biener2-0/+12
The following makes sure to reject the attempts to emulate a vector gather when the discovered index vector type is a vector mask. PR tree-optimization/119534 * tree-vect-stmts.cc (get_load_store_type): Reject VECTOR_BOOLEAN_TYPE_P offset vector type for emulated gathers. * gcc.dg/vect/pr119534.c: New testcase.
2025-04-01c++: fix missing lifetime extension [PR119383]Marek Polacek5-10/+55
Since r15-8011 cp_build_indirect_ref_1 won't do the *&TARGET_EXPR -> TARGET_EXPR folding not to change its value category. That fix seems correct but it made us stop extending the lifetime in this testcase, causing a wrong-code issue -- extend_ref_init_temps_1 did not see through the extra *& because it doesn't use a tree walk. This patch reverts r15-8011 and instead handles the problem in build_over_call by calling force_lvalue in the is_really_empty_class case as well as in the general case. PR c++/119383 gcc/cp/ChangeLog: * call.cc (build_over_call): Use force_lvalue to ensure op= returns an lvalue. * cp-tree.h (force_lvalue): Declare. * cvt.cc (force_lvalue): New. * typeck.cc (cp_build_indirect_ref_1): Revert r15-8011. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/temp-extend3.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com>
2025-04-01Doc: -Wzero-as-null-pointer-constant is also available for C [PR119173]Martin Uecker1-6/+7
The warning -Wzero-as-null-pointer-constant is now not only supported in C++ but also in C. Change the documentation accordingly. PR c/119173 gcc/ChangeLog: * doc/invoke.texi (Warning Options): Move to general options.
2025-04-01profile: Another profiling musttail call fix [PR119535]Jakub Jelinek2-3/+33
As the following testcase shows, EDGE_FAKE edges from musttail calls to EXIT aren't the only edges we should ignore, we need to ignore also edges created by the splitting of blocks for the EDGE_FAKE creation that point from the musttail calls to the fallthrough block, which typically does the return or with PHIs for the return value. 2025-04-01 Jakub Jelinek <jakub@redhat.com> PR gcov-profile/119535 * profile.cc (branch_prob): Ignore any edges from bbs ending with musttail call, rather than only EDGE_FAKE edges from those to EXIT. * c-c++-common/pr119535.c: New test.
2025-04-01tailr: Punt on tail recursions that would break musttail [PR119493]Jakub Jelinek2-0/+54
While working on the previous tailc patch, I've noticed the following problem. The testcase below fails, because we decide to tail recursion optimize the call, but tail recursion (as documented in tree-tailcall.cc) needs to add some result multiplication and/or addition if any tail recursion uses accumulator, which is added right before the return. So, if there are musttail non-recurive calls in the function, successful tail recursion optimization will mean we'll later error on the musttail calls. musttail recursive calls are ok, those would be tail recursion optimized. So, the following patch punts on all tail recursion optimizations if it needs accumulators (add and/or mult) if there is at least one non-recursive musttail call. 2025-04-01 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/119493 * tree-tailcall.cc (tree_optimize_tail_calls_1): Ignore tail recursion candidates which need accumulators if there is at least one musttail non-recursive call. * gcc.dg/pr119493-2.c: New test.
generated by cgit v1.1 at 2025-09-22 07:35:15 +0000