aboutsummaryrefslogtreecommitdiff
path: root/gcc/testsuite/c-c++-common
AgeCommit message (Collapse)AuthorFilesLines
14 hoursprofile: Another musttail fix [PR119618]Jakub Jelinek1-0/+21
As the following testcase shows, sometimes we can have debug stmts after a musttail call and profile.cc in that case would incorrectly allow the edge from that, causing musttail error and -fcompare-debug failure (because if there are no debug stmts after it, then musttail is found there and the edge is ignored). The following patch uses gsi_last_nondebug_bb instead of gsi_last_bb to find the musttail call. And so that we don't uselessly skip over debug stmts at the end of many bbs, the patch limits it to cfun->has_musttail functions. 2025-04-04 Jakub Jelinek <jakub@redhat.com> PR gcov-profile/119618 * profile.cc (branch_prob): Only check for musttail calls if cfun->has_musttail. Use gsi_last_nondebug_bb instead of gsi_last_bb. * c-c++-common/pr119618.c: New test.
14 hourstailc: Don't reject all tail calls if param has addr taken [PR119616]Jakub Jelinek1-0/+23
Before my PR119376 r15-9145 changes, suitable_for_tail_call_opt_p would return the same value in the same caller, regardless of the calls in it. If it fails, the caller clears opt_tailcalls which is a reference and therefore shared by all calls in the caller and we only do tail recursion, all non-recursive or tail recursion non-optimizable calls are not tail call optimized. For musttail calls we want to allow address taken parameters, but the r15-9145 change effectively resulted in the behavior where if there are just musttail calls considered, they will be tail call optimized, and if there are also other tail call candidates (without musttail), we clear opt_tailcall and then error out on all the musttail calls. The following patch fixes that by moving the address taken parameter discovery from suitable_for_tail_call_opt_p to its single caller. If there are addressable parameters, if !cfun->has_musttail it will work as before, disable all tail calls in the caller but possibly allow tail recursions. If cfun->has_musttail, it will set a new bool automatic flag and reject non-tail recursions. This way musttail calls can be still accepted and normal tail call candidates rejected (and tail recursions accepted). 2025-04-04 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/119616 * tree-tailcall.cc (suitable_for_tail_call_opt_p): Move checking for addressable parameters from here ... (find_tail_calls): ... here. If cfun->has_musttail, don't clear opt_tailcalls for it, instead set a local flag and punt if we can't tail recurse optimize it. * c-c++-common/pr119616.c: New test.
26 hourstailc: Use the IPA-VRP tail call hack even for pointers [PR119614]Jakub Jelinek3-0/+84
As the first two testcases show, even with pointers IPA-VRP can optimize return values from functions if they have singleton ranges into just the exact value, so we need to virtually undo that for tail calls similarly to integers and floats. The third test just adds check that it works even with floats (which it does). 2025-04-04 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/119614 * tree-tailcall.cc (find_tail_calls): Handle also pointer types in the IPA-VRP workaround. * c-c++-common/pr119614-1.c: New test. * c-c++-common/pr119614-2.c: New test. * c-c++-common/pr119614-3.c: New test.
3 daysOpenMP: Require target and/or targetsync init modifier [PR118965]Sandra Loosemore10-111/+179
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.
3 daystailc: Don't fail musttail calls if they use or could use local arguments, ↵Jakub Jelinek12-11/+448
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.
4 daysprofile: Another profiling musttail call fix [PR119535]Jakub Jelinek1-0/+31
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.
4 daysgimple-low: Diagnose assume attr expressions defining labels which are used ↵Jakub Jelinek2-0/+46
as unary && operands outside of those [PR119537] The following testcases ICE on invalid code which defines labels inside of statement expressions and then uses &&label from code outside of the statement expressions. The C++ FE diagnoses that with a warning (not specifically for assume attribute, genericallly about taking address of a label outside of a statement expression so computed goto could violate the requirement that statement expression is not entered from outside of it through a jump into it), the C FE doesn't diagnose anything. Normal direct gotos to such labels are diagnosed by both C and C++. In the assume attribute case it is actually worse than for addresses of labels in normal statement expressions, in that case the labels are still in the current function, so invalid program can still jump to those (and in case of OpenMP/OpenACC where it is also invalid and stuff is moved to a separate function, such movement is done post cfg discovery of FORCED_LABELs and worst case one can run into cases which fail to assemble, but I haven't succeeded in creating ICE for that). For assume at -O0 we'd just throw away the assume expression if it is not a simple condition and so the label is then not defined anywhere and we ICE during cfg pass. The gimplify.cc hunks fix that, as we don't have FORCED_LABELs discovery done yet, it preserves all assume expressions which contain used user labels. With that we ICE during IRA, which is upset about an indirect jump to a label which doesn't exist. So, the gimple-low.cc hunks add diagnostics of the problem, it gathers uids of all the user used labels inside of the assume expressions (usually none) and if it finds any, walks the IL to find uses of those from outside of those expressions now outlined into separate magic functions. 2025-04-01 Jakub Jelinek <jakub@redhat.com> PR middle-end/119537 * gimplify.cc (find_used_user_labels): New function. (gimplify_call_expr): Don't remove complex assume expression at -O0 if it defines any user labels. * gimple-low.cc: Include diagnostic-core.h. (assume_labels): New variable. (diagnose_assume_labels): New function. (lower_function_body): Call it via walk_gimple_seq if assume_labels is non-NULL, then BITMAP_FREE assume_labels. (find_assumption_locals_r): Record in assume_labels uids of user labels defined in assume attribute expressions. * c-c++-common/pr119537-1.c: New test. * c-c++-common/pr119537-2.c: New test.
8 daystailc: Handle musttail noreturn calls [PR119483]Jakub Jelinek2-0/+41
The following (first) testcase is accepted by clang (if clang::musttail) and rejected by gcc, because we discover the call is noreturn and then bail out because we don't want noreturn tailcalls. The general reason not to support noreturn tail calls is for cases like abort where we want nicer backtrace, but if user asks explicitly to musttail a call which either is explicitly noreturn or is implicitly determined to be noreturn, I don't see a reason why we couldn't do that. Both for tail calls and tail recursions. An alternative would be to keep rejecting musttail to explicit noreturn, but not actually implicitly mark anything as noreturn if it has any musttail calls. But it is unclear how we could do that, such marking is I think done typically before IPA and e.g. for LTO we won't know whether some other TU could have musttail calls to it. And keeping around both explicit and implicit noreturn bits would be ugly. Well, I guess we could differentiate between presence of noreturn/_Noreturn attributes and just ECF_NORETURN without those, but then tailc would still need to support it, just error out if it was explicit. 2025-03-28 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/119483 * tree-tailcall.cc (find_tail_calls): Handle noreturn musttail calls. (eliminate_tail_call): Likewise. (tree_optimize_tail_calls_1): If cfun->has_musttail and diag_musttail, handle also basic blocks with no successors with noreturn musttail calls. * calls.cc (can_implement_as_sibling_call_p): Allow ECF_NORETURN calls if they are musttail calls. * c-c++-common/pr119483-1.c: New test. * c-c++-common/pr119483-2.c: New test.
8 daysipa-sra: Don't change return type to void if there are musttail calls [PR119484]Jakub Jelinek1-0/+21
The following testcase is rejected, because IPA-SRA decides to turn bar.constprop call into bar.constprop.isra which returns void. While there is no explicit lhs on the call, as it is a musttail call the tailc pass checks if IPA-VRP returns singleton from that function and the function returns the same value and in that case it still turns it into a tail call. This can't work with IPA-SRA changing it into void returning function though. The following patch fixes this by forcing returning the original type if there are musttail calls. 2025-03-28 Jakub Jelinek <jakub@redhat.com> PR ipa/119484 * ipa-sra.cc (isra_analyze_call): Don't set m_return_ignored if gimple_call_must_tail_p even if it doesn't have lhs. * c-c++-common/pr119484.c: New test.
9 daystestsuite: harmless dg-* whitespace fixesSam James1-1/+1
These just fix inconsistent/unusual style to avoid noise when grepping and also people picking up bad habits when they see it (as similar mistakes can be harmful). gcc/testsuite/ChangeLog: * c-c++-common/goacc/pr69916.c: Fix unusual whitespace in dg-*. * g++.old-deja/g++.abi/vtable2.C: Ditto. * g++.old-deja/g++.bugs/900330_02.C: Ditto. * g++.old-deja/g++.bugs/900406_02.C: Ditto. * g++.old-deja/g++.bugs/900519_13.C: Ditto. * g++.old-deja/g++.mike/p9068.C: Ditto. * gcc.dg/20040203-1.c: Ditto. * gcc.dg/980502-1.c: Ditto. * gcc.dg/ipa/ipa-sra-14.c: Ditto. * gcc.dg/pr35468.c: Ditto. * gcc.dg/pr82597.c: Ditto. * gcc.dg/tree-ssa/phi-opt-7.c: Ditto. * gfortran.dg/assumed_charlen_in_main.f90: Ditto. * gfortran.dg/cray_pointers_2.f90: Ditto.
9 daysOpenMP: Fix declaration in append-args-interop.c test caseSandra Loosemore1-1/+1
I ran into this while backporting my declare variant/dispatch/interop patch f016ee89955ab4da5fe7ef89368e9437bb5ffb13 to the og14 development branch. In C dialects prior to C23 (the default on mainline), functions declared "float f()" and "float g(void)" aren't considered equivalent for the purpose of the C front end code that checks whether a type of a variant matches the base function after accounting for the added interop arguments. Using "(void)" instead of "()" works in all C dialects as well as C++, so do that. gcc/testsuite/ChangeLog * c-c++-common/gomp/append-args-interop.c: Fix declaration of base function to be correct for pre-C23 dialects.
9 daystestsuite, gomp: fix broken dg directivesDavid Malcolm1-1/+1
gcc/testsuite/ChangeLog: * c-c++-common/gomp/metadirective-target-device-2.c: Fix missing trailing " }" on dg-do directive. * gcc.dg/gomp/attrs-21.c: Likewise for dg-options. * gcc.dg/gomp/parallel-2.c: Drop ":" from dg-message. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
10 daystestsuite: i386: Fix c-c++-common/gomp/metadirective-device.c etc. with i?86 ↵Rainer Orth2-2/+2
compiler Two new tests FAIL on both Solaris/x86 and Linux/i686 with a 32-bit-default compiler: FAIL: c-c++-common/gomp/metadirective-device.c -std=c++17 scan-tree-dump-not optimized "__builtin_GOMP_error" FAIL: c-c++-common/gomp/metadirective-device.c -std=c++26 scan-tree-dump-not optimized "__builtin_GOMP_error" FAIL: c-c++-common/gomp/metadirective-device.c -std=c++98 scan-tree-dump-not optimized "__builtin_GOMP_error" FAIL: c-c++-common/gomp/metadirective-target-device-1.c -std=c++17 scan-tree-dump-times optimized "GOMP_error" 0 FAIL: c-c++-common/gomp/metadirective-target-device-1.c -std=c++26 scan-tree-dump-times optimized "GOMP_error" 0 FAIL: c-c++-common/gomp/metadirective-target-device-1.c -std=c++98 scan-tree-dump-times optimized "GOMP_error" 0 FAIL: c-c++-common/gomp/metadirective-device.c scan-tree-dump-not optimized "__builtin_GOMP_error" FAIL: c-c++-common/gomp/metadirective-target-device-1.c scan-tree-dump-times optimized "GOMP_error" 0 They also FAIL on Linux/x86_64 with -mx32. The problem is two-fold: restricting a test to target x86_64-*-* is always wrong: an i?86-*-* compiler can produce 64-bit code with -m64 just as well, so it should always be both. In addition, the -mx32 failure shows that the test seems to be 64-bit only. To fix both issues, this patch uses the new x86 effective-target keyword and restricts the tests to lp64 instead of ! ia32. Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu. 2025-03-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: * c-c++-common/gomp/metadirective-device.c (dg-additional-options): Use on all x86 targets. Restrict to lp64. * c-c++-common/gomp/metadirective-target-device-1.c: Likewise.
10 daysprofile: Don't instrument fake exit edges after musttail [PR118442]Jakub Jelinek1-0/+17
When -fprofile-generate is used musttail often fails because the compiler adds instrumentation after the tail calls. This patch ignores EDGE_FAKE edges added from musttail calls to EXIT. 2025-03-26 Jakub Jelinek <jakub@redhat.com> Andi Kleen <ak@gcc.gnu.org> PR gcov-profile/118442 * profile.cc (branch_prob): Ignore EDGE_FAKE edges from musttail calls to EXIT. * c-c++-common/pr118442.c: New test.
11 daysOpenMP: Create additional interop objects with append_args.Sandra Loosemore3-15/+46
This patch adds support for the case where #pragma omp declare variant with append_args is used inside a #pragma omp dispatch interop that specifies fewer interop args than required by the variant; new interop objects are implicitly created and then destroyed around the call to the variant, using the GOMP_interop builtin. gcc/fortran/ChangeLog * trans-openmp.cc (gfc_trans_omp_declare_variant): Remove accidental redeclaration of pref. gcc/ChangeLog * gimplify.cc (modify_call_for_omp_dispatch): Adjust arguments. Remove the "sorry" for the case where new interop objects must be constructed, and add code to make it work instead. (expand_variant_call_expr): Adjust arguments and call to modify_call_for_omp_dispatch. (gimplify_variant_call_expr): Simplify logic for calling expand_variant_call_expr. gcc/testsuite/ChangeLog * c-c++-common/gomp/append-args-1.c: Adjust expected behavior. * c-c++-common/gomp/append-args-interop.c: New. * c-c++-common/gomp/dispatch-11.c: Adjust expected behavior. * g++.dg/gomp/append-args-1.C: Likewise. * gfortran.dg/gomp/append-args-interop.f90: New. * gfortran.dg/gomp/declare-variant-mod-2.f90: Adjust expected behavior. libgomp/ChangeLog * libgomp.texi (OpenMP 5.1): Mark append_args as fully supported. Co-Authored-By: Tobias Burnus <tburnus@baylibre.com>
2025-03-21OpenMP: 'interop' construct - add ME support + target-independent libgompPaul-Antoine Arras5-12/+74
This patch partially enables use of the OpenMP interop construct by adding middle end support, mostly in the omplower pass, and in the target-independent part of the libgomp runtime. It follows up on previous patches for C, C++ and Fortran front ends support. The full interop feature requires another patch to enable foreign runtime support in libgomp plugins. gcc/ChangeLog: * builtin-types.def (BT_FN_VOID_INT_INT_PTR_PTR_PTR_INT_PTR_INT_PTR_UINT_PTR): New. * gimple-low.cc (lower_stmt): Handle GIMPLE_OMP_INTEROP. * gimple-pretty-print.cc (dump_gimple_omp_interop): New function. (pp_gimple_stmt_1): Handle GIMPLE_OMP_INTEROP. * gimple.cc (gimple_build_omp_interop): New function. (gimple_copy): Handle GIMPLE_OMP_INTEROP. * gimple.def (GIMPLE_OMP_INTEROP): Define. * gimple.h (gimple_build_omp_interop): Declare. (gimple_omp_interop_clauses): New function. (gimple_omp_interop_clauses_ptr): Likewise. (gimple_omp_interop_set_clauses): Likewise. (gimple_return_set_retval): Handle GIMPLE_OMP_INTEROP. * gimplify.cc (gimplify_scan_omp_clauses): Handle OMP_CLAUSE_INIT, OMP_CLAUSE_USE and OMP_CLAUSE_DESTROY. (gimplify_omp_interop): New function. (gimplify_expr): Replace sorry with call to gimplify_omp_interop. * omp-builtins.def (BUILT_IN_GOMP_INTEROP): Define. * omp-low.cc (scan_sharing_clauses): Handle OMP_CLAUSE_INIT, OMP_CLAUSE_USE and OMP_CLAUSE_DESTROY. (scan_omp_1_stmt): Handle GIMPLE_OMP_INTEROP. (lower_omp_interop_action_clauses): New function. (lower_omp_interop): Likewise. (lower_omp_1): Handle GIMPLE_OMP_INTEROP. gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_clause_destroy): Make addressable. (c_parser_omp_clause_init): Make addressable. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_clause_init): Make addressable. gcc/fortran/ChangeLog: * trans-openmp.cc (gfc_trans_omp_clauses): Make OMP_CLAUSE_DESTROY and OMP_CLAUSE_INIT addressable. * types.def (BT_FN_VOID_INT_INT_PTR_PTR_PTR_INT_PTR_INT_PTR_UINT_PTR): New. include/ChangeLog: * gomp-constants.h (GOMP_DEVICE_DEFAULT_OMP_61, GOMP_INTEROP_TARGET, GOMP_INTEROP_TARGETSYNC, GOMP_INTEROP_FLAG_NOWAIT): Define. libgomp/ChangeLog: * icv-device.c (omp_set_default_device): Check GOMP_DEVICE_DEFAULT_OMP_61. * libgomp-plugin.h (struct interop_obj_t): New. (enum gomp_interop_flag): New. (GOMP_OFFLOAD_interop): Declare. (GOMP_OFFLOAD_get_interop_int): Declare. (GOMP_OFFLOAD_get_interop_ptr): Declare. (GOMP_OFFLOAD_get_interop_str): Declare. (GOMP_OFFLOAD_get_interop_type_desc): Declare. * libgomp.h (_LIBGOMP_OMP_LOCK_DEFINED): Define. (struct gomp_device_descr): Add interop_func, get_interop_int_func, get_interop_ptr_func, get_interop_str_func, get_interop_type_desc_func. * libgomp.map: Add GOMP_interop. * libgomp_g.h (GOMP_interop): Declare. * target.c (resolve_device): Handle GOMP_DEVICE_DEFAULT_OMP_61. (omp_get_interop_int): Replace stub with actual implementation. (omp_get_interop_ptr): Likewise. (omp_get_interop_str): Likewise. (omp_get_interop_type_desc): Likewise. (struct interop_data_t): Define. (gomp_interop_internal): New function. (GOMP_interop): Likewise. (gomp_load_plugin_for_device): Load symbols for get_interop_int, get_interop_ptr, get_interop_str and get_interop_type_desc. * testsuite/libgomp.c-c++-common/interop-1.c: New test. gcc/testsuite/ChangeLog: * c-c++-common/gomp/interop-1.c: Remove dg-prune-output "sorry". * c-c++-common/gomp/interop-2.c: Likewise. * c-c++-common/gomp/interop-3.c: Likewise. * c-c++-common/gomp/interop-4.c: Remove dg-message "not supported". * g++.dg/gomp/interop-5.C: Likewise. * gfortran.dg/gomp/interop-4.f90: Likewise. * c-c++-common/gomp/interop-5.c: New test. * gfortran.dg/gomp/interop-5.f90: New test. Co-authored-by: Tobias Burnus <tburnus@baylibre.com>
2025-03-21icf: Punt for musttail call flag differences in ICF [PR119376]Jakub Jelinek1-0/+31
The following testcase shows we were ignoring musttail flags on calls when deciding if two functions are the same. That can result in problems in both directions, either we silently lose musttail attribute because there is a similar function without it earlier and then we e.g. don't diagnose if it can't be tail called or don't try harder to do a tail call, or we get it even in functions which didn't have it before. The following patch for now just punts if it differs. Perhaps we could just merge it and get musttail flag if any of the merged functions had one in such position, but it feels to me that it is now too late in GCC 15 cycle to play with this. 2025-03-21 Jakub Jelinek <jakub@redhat.com> PR ipa/119376 * ipa-icf-gimple.cc (func_checker::compare_gimple_call): Return false for gimple_call_must_tail_p mismatches. * c-c++-common/musttail27.c: New test.
2025-03-21inliner: Silently drop musttail flag on calls during inlining unless the ↵Jakub Jelinek1-0/+33
inlined routine was musttail called [PR119376] As discussed in the PR, some packages fail to build because they use musttail attribute on calls in functions which we inline, and if they are inlined into a middle of the function, that results in an error because we have a musttail call in the middle of a function and so it can't be tail called there. Now, guess the primary intent of the musttail attribute is ensuring we don't get an extra stack frame in the backtrace. Inlining itself removes one extra stack frame from the backtrace as well (sure, not counting virtual backtraces in gdb), so I think erroring out on that is unnecessary. Except when we are inlining a musttail call which has musttail calls in it, in that case we are being asked to remove 2 stack frames from the backtrace, inlining removes one, so we need to keep musttail on the calls so that another stack frame is removed through a tail call. The following patch implements that, keeping previous behavior when id->call_stmt is NULL (i.e. when versioning/cloning etc.). 2025-03-21 Jakub Jelinek <jakub@redhat.com> PR ipa/119376 * tree-inline.cc (remap_gimple_stmt): Silently clear gimple_call_must_tail_p on inlined call stmts if id->call_stmt is a call without that flag set. * c-c++-common/musttail26.c: New test.
2025-03-18c: Fix handling of [[gnu::musttail] return in if and else bodies [PR119311]Jakub Jelinek2-3/+31
The following new testcase FAILs with C (and succeeds with C++). c_parser_handle_musttail is used in c_parser_compound_statement_nostart where it is directly passed to c_parser_statement_after_labels, and in c_parser_all_labels where it is returned. Now, out of the 3 c_parser_all_labels callers, c_parser_statement passes it down to c_parser_statement_after_labels, but c_parser_if_body and c_parser_else_body don't, so if there are return statements with [[gnu::musttail]] or [[clang::musttail]] directly in if or else bodies rather than wrapped with {}s, we throw that information away. 2025-03-18 Jakub Jelinek <jakub@redhat.com> PR c/119311 * c-parser.cc (c_parser_if_body): Pass result of c_parser_all_labels as last argument to c_parser_statement_after_labels. (c_parser_else_body): Likewise. * c-c++-common/musttail14.c: Use * instead of \* in the regexps. * c-c++-common/musttail25.c: New test.
2025-03-18c, c++: Support musttail attribute even using __attribute__ form [PR116545]Jakub Jelinek11-2/+273
Apparently some programs in the wild use #if __has_attribute(musttail) __attribute__((musttail)) return foo (); #else return foo (); #endif clang supports musttail both as a standard attribute ([[clang::musttail]] which we also support for compatibility) and the above worked just fine with GCC 14 which had __has_attribute(musttail) 0. Now that it is 0, this doesn't compile anymore. So, either we need to ensure that __has_attribute(musttail) is 0 and just __has_c{,pp}_attribute({gnu,clang}::musttail) are non-zero, or IMHO better we just make it work in the attribute form, especially for C < C23 I can see why some projects would prefer that form. While [[gnu::musttail]] is rejected as an error in C11 etc. before GCC 15, rather than just handled as an unknown attribute. I view this as both a regression and compatibility issue. The patch handles it in similar spots to fallthrough/assume attributes inside of __attribute__ for C, and for C++ enables mixing of standard [[]] and GNU __attribute__(()) attributes at the start of statements in any order. While working on it, I've noticed we weren't diagnosing arguments to the clang::musttail attribute (fixed by the c-attribs.cc hunk) and newly on the __attribute__ form attribute (in that case the arguments aren't just skipped, they are always parsed and because we don't call decl_attributes etc., it wouldn't be diagnosed without a manual check). 2025-03-18 Jakub Jelinek <jakub@redhat.com> PR c/116545 gcc/ * doc/extend.texi (musttail statement attribute): Document that musttail GNU attribute can be used as well. gcc/c-family/ * c-attribs.cc (c_common_clang_attributes): Add musttail. gcc/c/ * c-parser.cc (c_parser_declaration_or_fndef): Parse __attribute__((musttail)) return. (c_parser_handle_musttail): Diagnose attribute arguments. (c_parser_statement_after_labels): Parse __attribute__((musttail)) return. gcc/cp/ * parser.cc (cp_parser_statement): Call cp_parser_attributes_opt rather than cp_parser_std_attribute_spec_seq. (cp_parser_jump_statement): Diagnose gnu::musttail attributes with no arguments. gcc/testsuite/ * c-c++-common/attr-fallthrough-2.c: Adjust expected diagnostics for C++. * c-c++-common/musttail15.c: New test. * c-c++-common/musttail16.c: New test. * c-c++-common/musttail17.c: New test. * c-c++-common/musttail18.c: New test. * c-c++-common/musttail19.c: New test. * c-c++-common/musttail20.c: New test. * c-c++-common/musttail21.c: New test. * c-c++-common/musttail22.c: New test. * c-c++-common/musttail23.c: New test. * c-c++-common/musttail24.c: New test. * g++.dg/musttail7.C: New test. * g++.dg/musttail8.C: New test. * g++.dg/musttail12.C: New test. * g++.dg/musttail13.C: New test. * g++.dg/musttail14.C: New test. * g++.dg/ext/pr116545.C: New test.
2025-03-16discriminators: Fix assigning discriminators on edge [PR113546]Andrew Pinski1-0/+8
The problem here is there was a compare debug since the discriminators would still take into account debug statements. For the edge we would look at the first statement after the labels and that might have been a debug statement. So we need to skip over debug statements otherwise we could get different discriminators # with and without -g. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR middle-end/113546 gcc/ChangeLog: * tree-cfg.cc (first_non_label_stmt): Rename to ... (first_non_label_nondebug_stmt): This and use gsi_start_nondebug_after_labels_bb. (assign_discriminators): Update call to first_non_label_nondebug_stmt. gcc/testsuite/ChangeLog: * c-c++-common/torture/pr113546-1.c: New test. Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
2025-03-14c, c++: Set DECL_NOT_GIMPLE_REG_P on *PART_EXPR operand on lhs of ↵Jakub Jelinek1-0/+40
MODIFY_EXPR [PR119120] The PR119190 patch I've posted regresses the PR119120 testcase (not adding to testsuite, as it is fairly hard to scan for that problem). The issue is that for the partial setting of _Complex floating vars through __real__ on it first and __imag__ later (or vice versa) and since we forced all complex vars into SSA form we often have undefined (D) arguments of those COMPLEX_EXPRs. When we don't DCE them (for -O0 debug info reasons), their expansion will copy both the real and imag parts using the floating mode and on some targets like 387 that copying alone can unfortunately trigger exceptions on sNaNs or other problematic bit patterns and for uninitialized memory it can be triggered randomly based on whatever is on the stack before. The following patch sets DECL_NOT_GIMPLE_REG_P flag in the FEs during genericization. I think Fortran doesn't have a way to modify just real or just complex part separately. The patch is for code like _ComplexT __t; __real__ __t = __z.real(); __imag__ __t = __z.imag(); _M_value *= __t; return *this; at -O0 which used to appear widely even in libstdc++ before GCC 9 and happens in real-world code. At -O0 for debug info reasons (see PR119190) we don't want to aggressively DCE statements and when we since r0-100845 try to rewrite vars with COMPLEX_TYPE into SSA form aggressively, the above results in copying of uninitialized data when expanding COMPLEX_EXPRs added so that the vars can be in SSA form. The patch detects during genericization the partial initialization and doesn't rewrite such vars to SSA at -O0. This has to be done before gimplification starts, otherwise e.g. the attached testcase ICEs. 2025-03-14 Jakub Jelinek <jakub@redhat.com> PR target/119120 * c-gimplify.cc (c_genericize_control_r): Set DECL_NOT_GIMPLE_REG_P on {REAL,IMAG}PART_EXPR is_gimple_reg operand at -O0 if it is lhs of a MODIFY_EXPR. * cp-gimplify.cc (cp_genericize_r): Set DECL_NOT_GIMPLE_REG_P on {REAL,IMAG}PART_EXPR is_gimple_reg operand at -O0 if it is lhs of a MODIFY_EXPR. * c-c++-common/pr119120.c: New test.
2025-03-14analyzer: Fix ICE in cmp_csts_same_type on RAW_DATA_CST [PR119278]Jakub Jelinek1-0/+20
The following testcase ICEs in cmp_csts_same_type because RAW_DATA_CST isn't handled there. As TREE_TYPE (cst1) in that case is INTEGER_TYPE, e.g. char/signed char/unsigned char, the type itself doesn't imply the size, so the length is compared first, followed by comparing the data. While at it, I've noticed STRING_CST handling is wrong, because STRING_CST can represent even string literals with embedded nul characters. We shouldn't stop at those, hence memcmp. While for STRING_CST TREE_TYPE should likely already imply the length and so same type should imply same TREE_STRING_LENGTH, I've repeated the comparisons in there just in case. 2025-03-14 Jakub Jelinek <jakub@redhat.com> PR analyzer/119278 * svalue.cc (cmp_csts_same_type): For STRING_CST, compare TREE_STRING_LENGTH first just in case and use memcmp rather than strcmp. Handle RAW_DATA_CST. * c-c++-common/analyzer/pr119278.c: New test.
2025-03-12analyzer: support RAW_DATA_CST [PR117262]David Malcolm2-0/+53
gcc/analyzer/ChangeLog: PR analyzer/117262 * region-model-manager.cc (region_model_manager::get_or_create_constant_svalue): Use NULL_TREE for the types of constant_svalue for RAW_DATA_CST. (region_model_manager::maybe_fold_sub_svalue): Generalize STRING_CST logic to also handle RAW_DATA_CST. (region_model_manager::maybe_get_char_from_cst): New. (region_model_manager::maybe_get_char_from_raw_data_cst): New. * region-model-manager.h (region_model_manager::maybe_get_char_from_cst): New decl. (region_model_manager::maybe_get_char_from_raw_data_cst): New decl. * region-model.cc (region_model::get_rvalue_1): Handle RAW_DATA_CST. * store.cc (get_subregion_within_ctor_for_ctor_pair): New. (binding_map::apply_ctor_pair_to_child_region): Call get_subregion_within_ctor_for_ctor_pair so that we handle RAW_DATA_CST. gcc/testsuite/ChangeLog: PR analyzer/117262 * c-c++-common/analyzer/raw-data-cst-pr117262-1.c: New test. * c-c++-common/analyzer/raw-data-cst-pr117262-2.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2025-03-11OpenMP/C: Store location in cp_parser_omp_var_list for kind=0 [PR118579]Sandra Loosemore1-0/+25
This patch is the C equivalent of commit r15-6512-gcf94ba812ca496 for C++, to improve the location information for individual items in an OpenMP variable list. gcc/c/ChangeLog PR c/118579 * c-parser.cc (c_parser_omp_variable_list): Capture location information when KIND is OMP_CLAUSE_ERROR. (c_parser_oacc_data_clause_deviceptr): Use the improved location for diagnostics, and remove the FIXME. (c_finish_omp_declare_variant): Likewise. (c_parser_omp_threadprivate): Likewise. gcc/testsuite/ChangeLog PR c/118579 * c-c++-common/gomp/pr118579.c: New testcase.
2025-03-10gimple-ssa-warn-access: Adjust maybe_warn_nonstring_arg for nonstring ↵Jakub Jelinek2-6/+16
multidimensional arrays [PR117178] The following patch fixes 4 xfails in attr-nonstring-11.c (and results in 2 false positive warnings in attr-nonstring-12.c not being produced either). The thing is that maybe_warn_nonstring_arg simply assumed that nonstring arrays must be single-dimensional, so when it sees a nonstring decl with ARRAY_TYPE, it just used its dimension. With multi-dimensional arrays that is not the right dimension to use though, it can be dimension of some outer dimension, e.g. if we have char a[5][6][7] __attribute__((nonstring)) if decl is a[5] it would assume maximum non-NUL terminated string length of 5 rather than 7, if a[5][6] it would assume 6 and only for a[5][6][0] it would assume the correct 7. So, the following patch looks through all the outer dimensions to reach the innermost one (which for attribute nonstring is guaranteed to have char/unsigned char/signed char element type). 2025-03-10 Jakub Jelinek <jakub@redhat.com> PR c/117178 * gimple-ssa-warn-access.cc (maybe_warn_nonstring_arg): Look through multi-dimensional array types, stop at the innermost ARRAY_TYPE. * c-c++-common/attr-nonstring-11.c: Remove xfails. * c-c++-common/attr-nonstring-12.c (warn_strcmp_cst_1, warn_strcmp_cst_2): Don't expect any warnings here. (warn_strcmp_cst_3, warn_strcmp_cst_4): New functions with expected warnings.
2025-03-09OpenMP: Integrate dynamic selectors with dispatch argument handling [PR118457]Sandra Loosemore4-39/+109
Support for dynamic selectors in "declare variant" was developed in parallel with support for the adjust_args/append_args clauses and the dispatch construct; they collided in a bad way. This patch fixes the "sorry" for calls that need both by removing the adjust_args/append_args code from gimplify_call_expr and invoking it from the new variant substitution code instead. It's handled as a tree -> tree transformation rather than tree -> gimple because eventually this code may end up being invoked from the front ends instead of the gimplifier (see PR115076). gcc/ChangeLog PR middle-end/118457 * gimplify.cc (modify_call_for_omp_dispatch): New, containing code split from gimplify_call_expr and modified to emit tree instead of gimple. Remove the error for falling through to a call to the base function. (expand_variant_call_expr): New, split from gimplify_variant_call_expr. Call modify_call_for_omp_dispatch on calls to variants in a dispatch construct context. (gimplify_variant_call_expr): Make it call expand_variant_call_expr to do the actual work. (gimplify_call_expr): Remove sorry for calls involving both dynamic/late selectors and adjust_args/append_args, and adjust for new interface. Move adjust_args/append_args code to modify_call_for_omp_dispatch. (gimplify_omp_dispatch): Add some comments. gcc/testsuite/ChangeLog PR middle-end/118457 * c-c++-common/gomp/adjust-args-6.c: Remove xfails and adjust expected output. * c-c++-common/gomp/append-args-5.c: Adjust expected output. * c-c++-common/gomp/append-args-dynamic.c: New. * c-c++-common/gomp/dispatch-11.c: Adjust expected output. * gfortran.dg/gomp/dispatch-11.f90: Likewise.
2025-03-08c-family, tree: Allow nonstring attribute on multidimensional arrays [PR117178]Jakub Jelinek9-1/+1224
As requested in the PR117178 thread, the following patch allows nonstring attribute also on multi-dimensional arrays (with cv char/signed char/unsigned char as innermost element type) and pointers to such multi-dimensional arrays or pointers to single-dimensional cv char/signed char/unsigned char arrays. Given that (unfortunately) nonstring is a decl attribute rather than type attribute, I think restricting it to single-dimensional arrays makes no sense, even multi-dimensional ones can be used for storage of non-nul terminated strings. I really don't know what the kernel plans are, whether they'll go with -Wno-unterminated-string-initialization added in Makefiles, or whether the plan is to use nonstring attributes to quiet the warning. In the latter case, some of the nonstring attributes will need to be conditional on gcc version, because gcc before this patch will reject it on multidimensional arrays. 2025-03-08 Jakub Jelinek <jakub@redhat.com> PR c/117178 gcc/ * tree.cc (get_attr_nonstring_decl): Look through all ARRAY_REFs, not just one and handle COMPONENT_REF and MEM_REF after skipping those rather than only when there wasn't ARRAY_REF. Formatting fix. gcc/c-family/ * c-attribs.cc (handle_nonstring_attribute): Allow the attribute also on multi-dimensional arrays with char/signed char/unsigned char element type or pointers to such single and multi-dimensional arrays. gcc/testsuite/ * c-c++-common/attr-nonstring-7.c: Remove one xfail. * c-c++-common/attr-nonstring-9.c: New test. * c-c++-common/attr-nonstring-10.c: New test. * c-c++-common/attr-nonstring-11.c: New test. * c-c++-common/attr-nonstring-12.c: New test. * c-c++-common/attr-nonstring-13.c: New test. * c-c++-common/attr-nonstring-14.c: New test. * c-c++-common/attr-nonstring-15.c: New test. * c-c++-common/attr-nonstring-16.c: New test.
2025-03-01testsuite: Fix up toplevel-asm-1.c for LoongArchXi Ruoyao1-1/+1
Like RISC-V, on LoongArch we don't really support %cN for SYMBOL_REFs even with -fno-pic. gcc/testsuite/ChangeLog: * c-c++-common/toplevel-asm-1.c: Use %cc3 %cc4 instead of %c3 %c4 on LoongArch.
2025-02-25openmp: Mark OpenMP atomic write expression as read [PR119000]Jakub Jelinek1-0/+16
The following testcase was emitting false positive warning that the rhs of #pragma omp atomic write was stored but not read, when the atomic actually does read it. The following patch fixes that by calling default_function_array_read_conversion on it, so that it is marked as read as well as converted from lvalue to rvalue. Furthermore, the code had if (code == NOP_EXPR) ... else ... if (code == NOP_EXPR) ... with none of ... parts changing code, so I've merged the two ifs. 2025-02-25 Jakub Jelinek <jakub@redhat.com> PR c/119000 * c-parser.cc (c_parser_omp_atomic): For omp write call default_function_array_read_conversion on the rhs expression. Merge the two adjacent if (code == NOP_EXPR) blocks. * c-c++-common/gomp/pr119000.c: New test.
2025-02-24openmp: Fix diagnostics typo [PR118993]Jakub Jelinek1-4/+4
There is a typo in one of the OpenMP gimplification diagnostics messages. The following patch fixes that and adjusts tests which just copied that message including typo to dg-warning regexps in 2 tests. 2025-02-24 Jakub Jelinek <jakub@redhat.com> PR middle-end/118993 * gimplify.cc (gimplify_scan_omp_clauses): Fix diagnostics typo, undfined -> undefined. * c-c++-common/gomp/allocate-18.c: Adjust dg-warning regex for diagnostics typo fix. * gfortran.dg/gomp/allocate-clause.f90: Likewise.
2025-02-24Use nonnull_if_nonzero attribute rather than nonnull on various builtins ↵Jakub Jelinek1-2/+1
[PR117023] On top of the https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668699.html https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668700.html patches the following patch adds nonnull_if_nonzero attribute(s) to various builtins instead of or in addition to nonnull attribute. The patch adjusts builtins (when we have them) corresponding to the APIs mentioned in the C2Y N3322 paper: 1) strndup and memset get one nonnull_if_nonzero attribute instead of nonnull 2) memcpy, memmove, strncpy, memcmp, strncmp get two nonnull_if_nonzero attributes instead of nonnull 3) strncat has nonnull without argument changed to nonnull (1) and gets one nonnull_if_nonzero for the src argument (maybe it needs to be clarified in C2Y, but I really think first argument to strncat and wcsncat shouldn't be NULL even for n == 0, because NULL doesn't point to NULL terminated string and one can't append anything to it; and various implementations in the wild including glibc will crash with NULL first argument (x86_64 avx+ doesn't though) Such changes are done also to the _chk suffixed counterparts of the builtins. Furthermore I've changed a couple of builtins for POSIX functions which aren't covered by ISO C, but I'd expect if/when POSIX incorporates C2Y it would do the same changes. In particular 4) strnlen gets one nonnull_if_nonzero instead of nonnull 5) mempcpy and stpncpy get two nonnull_if_nonzero instead of nonnull and lose returns_nonnull attribute; this is kind of unfortunate but I think in the spirit of N3322 mempcpy (NULL, src, 0) should return NULL (i.e. dest + n aka NULL + 0, now valid) and it is hard to express returns non-NULL if first argument is non-NULL or third argument is non-zero I'm not really sure about fread/fwrite, N3322 doesn't mention those, can the first argument be NULL if third argument is 0? What about if second argument is 0? Can the fourth argument be NULL in such cases? And of course, when not using builtins the glibc headers will affect stuff too, so we'll need to wait for N3322 implementation there too (possibly by dropping the nonnull attributes and perhaps conditionally replacing them with this new one if the compiler supports them). 2025-02-24 Jakub Jelinek <jakub@redhat.com> PR c/117023 gcc/ * builtin-attrs.def (ATTR_NONNULL_IF_NONZERO): New DEF_ATTR_IDENT. (ATTR_NOTHROW_NONNULL_IF12_LEAF, ATTR_NOTHROW_NONNULL_IF13_LEAF, ATTR_NOTHROW_NONNULL_IF123_LEAF, ATTR_NOTHROW_NONNULL_IF23_LEAF, ATTR_NOTHROW_NONNULL_1_IF23_LEAF, ATTR_PURE_NOTHROW_NONNULL_IF12_LEAF, ATTR_PURE_NOTHROW_NONNULL_IF13_LEAF, ATTR_PURE_NOTHROW_NONNULL_IF123_LEAF, ATTR_WARN_UNUSED_RESULT_NOTHROW_NONNULL_IF12_LEAF, ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL_IF12_LEAF): New DEF_ATTR_TREE_LIST. * builtins.def (BUILT_IN_STRNDUP): Use ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL_IF12_LEAF instead of ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL_LEAF. (BUILT_IN_STRNCAT, BUILT_IN_STRNCAT_CHK): Use ATTR_NOTHROW_NONNULL_1_IF23_LEAF instead of ATTR_NOTHROW_NONNULL_LEAF. (BUILT_IN_BCOPY, BUILT_IN_MEMCPY, BUILT_IN_MEMCPY_CHK, BUILT_IN_MEMMOVE, BUILT_IN_MEMMOVE_CHK, BUILT_IN_STRNCPY, BUILT_IN_STRNCPY_CHK): Use ATTR_NOTHROW_NONNULL_IF123_LEAF instead of ATTR_NOTHROW_NONNULL_LEAF. (BUILT_IN_MEMPCPY, BUILT_IN_MEMPCPY_CHK, BUILT_IN_STPNCPY, BUILT_IN_STPNCPY_CHK): Use ATTR_NOTHROW_NONNULL_IF123_LEAF instead of ATTR_RETNONNULL_NOTHROW_LEAF. (BUILT_IN_BZERO, BUILT_IN_MEMSET, BUILT_IN_MEMSET_CHK): Use ATTR_NOTHROW_NONNULL_IF13_LEAF instead of ATTR_NOTHROW_NONNULL_LEAF. (BUILT_IN_BCMP, BUILT_IN_MEMCMP, BUILT_IN_STRNCASECMP, BUILT_IN_STRNCMP): Use ATTR_PURE_NOTHROW_NONNULL_IF123_LEAF instead of ATTR_PURE_NOTHROW_NONNULL_LEAF. (BUILT_IN_STRNLEN): Use ATTR_PURE_NOTHROW_NONNULL_IF12_LEAF instead of ATTR_PURE_NOTHROW_NONNULL_LEAF. (BUILT_IN_MEMCHR): Use ATTR_PURE_NOTHROW_NONNULL_IF13_LEAF instead of ATTR_PURE_NOTHROW_NONNULL_LEAF. gcc/testsuite/ * gcc.dg/builtins-nonnull.c (test_memfuncs, test_memfuncs_chk, test_strfuncs, test_strfuncs_chk): Add if (n == 0) return; at the start of the functions. * gcc.dg/Wnonnull-2.c: Copy __builtin_* call statements where appropriate 3 times, once with 0 length, once with n and once with non-zero constant and expect warning only in the third case. Formatting fixes. * gcc.dg/Wnonnull-3.c: Copy __builtin_* call statements where appropriate 3 times, once with 0 length, once with n and once with n guarded with n != 0 and expect warning only in the third case. Formatting fixes. * gcc.dg/nonnull-3.c (foo): Use 16 instead of 0 in the calls added for PR80936. * gcc.dg/nonnull-11.c: New test. * c-c++-common/ubsan/nonnull-1.c: Don't expect runtime diagnostics for the __builtin_memcpy call. * gcc.dg/tree-ssa/pr78154.c (f): Add dn argument and return early if it is NULL. Duplicate cases of builtins which have the first argument changed from nonnull to nonnull_if_nonzero except stpncpy, once with dn as first argument instead of d and once with constant non-zero count rather than n. Disable the stpncpy non-null check. * gcc.dg/Wbuiltin-declaration-mismatch-14.c (test_builtin_calls): Triplicate the strncmp calls, once with 1 last argument and expect warning, once with n last argument and don't expect warning and once with 0 last argument and don't expect warning. * gcc.dg/Wbuiltin-declaration-mismatch-15.c (test_builtin_calls_fe): Likewise.
2025-02-24analyzer: Handle nonnull_if_nonzero attribute [PR117023]Jakub Jelinek2-3/+3
On top of the https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html patch which introduces the nonnull_if_nonzero attribute (because C2Y is allowing NULL arguments on various calls like memcpy, memset, strncpy etc. as long as the count is 0) the following patch adds just limited handling of the attribute in the analyzer. For nonnull attribute(s) we have the get_nonnull_args helper which returns a bitmap, for nonnull_if_nonzero a function would need to return a hash_map or something similar, I think it is better to handle the attributes one by one. This patch just handles the non-zero INTEGER_CST (integer_nonzerop) count arguments, in other places the above patch uses ranger to some extent, but I'm not familiar enough with the analyzer to know if one can use the ranger, or should somehow explain in data structures the conditional nature of the nonnull property, the argument is nonnull only if some other argument is nonzero. Also, analyzer uses get_nonnull_args in another spot when entering a frame, not sure if anything can be done there (note the conditional nonnull somehow, pass from callers if the argument is nonzero, ...). Note, the testsuite changes aren't strictly necessary with just the above and this patch, but will be with a patch I'm going to post soon. 2025-02-24 Jakub Jelinek <jakub@redhat.com> PR c/117023 gcc/analyzer/ * sm-malloc.cc (malloc_state_machine::handle_nonnull): New private method. (malloc_state_machine::on_stmt): Use it for nonnull attribute arguments. Handle also nonnull_if_nonzero attributes. gcc/testsuite/ * c-c++-common/analyzer/call-summaries-malloc.c (test_use_without_check): Pass 4 rather than sz to memset. * c-c++-common/analyzer/strncpy-1.c (test_null_dst, test_null_src): Pass 42 rather than count to strncpy.
2025-02-22Turn test cases into UNSUPPORTED if running into 'sorry, unimplemented: ↵Thomas Schwinge40-51/+8
dynamic stack allocation not supported' In Subversion r217296 (Git commit e2acc079ff125a869159be45371dc0a29b230e92) "Testsuite alloca fixes for ptx", effective-target 'alloca' was added to mark up test cases that run into the nvptx back end's non-support of dynamic stack allocation. (Later, nvptx gained conditional support for that in commit 3861d362ec7e3c50742fc43833fe9d8674f4070e "nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181]", but on the other hand, in commit f93a612fc4567652b75ffc916d31a446378e6613 "bpf: liberate R9 for general register allocation", the BPF back end joined "the list of targets that do not support alloca in target-support.exp". Manually maintaining the list of test cases requiring effective-target 'alloca' is notoriously hard, gets out of date quickly: new test cases added to the test suite may need to be analyzed and annotated, and over time annotations also may need to be removed, in cases where the compiler learns to optimize out 'alloca'/VLA usage, for example. This commit replaces (99 % of) the manual annotations with an automatic scheme: turn test cases into UNSUPPORTED if running into 'sorry, unimplemented: dynamic stack allocation not supported'. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_alloca): Gracefully handle the case that we've not be called (indirectly) from 'dg-test'. * lib/gcc-dg.exp (proc gcc-dg-prune): Turn 'sorry, unimplemented: dynamic stack allocation not supported' into UNSUPPORTED. * c-c++-common/Walloca-larger-than.c: Don't 'dg-require-effective-target alloca'. * c-c++-common/Warray-bounds-9.c: Likewise. * c-c++-common/Warray-bounds.c: Likewise. * c-c++-common/Wdangling-pointer-2.c: Likewise. * c-c++-common/Wdangling-pointer-4.c: Likewise. * c-c++-common/Wdangling-pointer-5.c: Likewise. * c-c++-common/Wdangling-pointer.c: Likewise. * c-c++-common/Wimplicit-fallthrough-7.c: Likewise. * c-c++-common/Wsizeof-pointer-memaccess1.c: Likewise. * c-c++-common/Wsizeof-pointer-memaccess2.c: Likewise. * c-c++-common/Wstringop-truncation.c: Likewise. * c-c++-common/Wunused-var-6.c: Likewise. * c-c++-common/Wunused-var-8.c: Likewise. * c-c++-common/analyzer/alloca-leak.c: Likewise. * c-c++-common/analyzer/allocation-size-multiline-2.c: Likewise. * c-c++-common/analyzer/allocation-size-multiline-3.c: Likewise. * c-c++-common/analyzer/capacity-1.c: Likewise. * c-c++-common/analyzer/capacity-3.c: Likewise. * c-c++-common/analyzer/imprecise-floating-point-1.c: Likewise. * c-c++-common/analyzer/infinite-recursion-alloca.c: Likewise. * c-c++-common/analyzer/malloc-callbacks.c: Likewise. * c-c++-common/analyzer/malloc-paths-8.c: Likewise. * c-c++-common/analyzer/out-of-bounds-5.c: Likewise. * c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise. * c-c++-common/analyzer/uninit-alloca.c: Likewise. * c-c++-common/analyzer/write-to-string-literal-5.c: Likewise. * c-c++-common/asan/alloca_loop_unpoisoning.c: Likewise. * c-c++-common/auto-init-11.c: Likewise. * c-c++-common/auto-init-12.c: Likewise. * c-c++-common/auto-init-15.c: Likewise. * c-c++-common/auto-init-16.c: Likewise. * c-c++-common/builtins.c: Likewise. * c-c++-common/dwarf2/vla1.c: Likewise. * c-c++-common/gomp/pr61486-2.c: Likewise. * c-c++-common/torture/builtin-clear-padding-4.c: Likewise. * c-c++-common/torture/strub-run3.c: Likewise. * c-c++-common/torture/strub-run4.c: Likewise. * c-c++-common/torture/strub-run4c.c: Likewise. * c-c++-common/torture/strub-run4d.c: Likewise. * c-c++-common/torture/strub-run4i.c: Likewise. * g++.dg/Walloca1.C: Likewise. * g++.dg/Walloca2.C: Likewise. * g++.dg/cpp0x/pr70338.C: Likewise. * g++.dg/cpp1y/lambda-generic-vla1.C: Likewise. * g++.dg/cpp1y/vla10.C: Likewise. * g++.dg/cpp1y/vla2.C: Likewise. * g++.dg/cpp1y/vla6.C: Likewise. * g++.dg/cpp1y/vla8.C: Likewise. * g++.dg/debug/debug5.C: Likewise. * g++.dg/debug/debug6.C: Likewise. * g++.dg/debug/pr54828.C: Likewise. * g++.dg/diagnostic/pr70105.C: Likewise. * g++.dg/eh/cleanup5.C: Likewise. * g++.dg/eh/spbp.C: Likewise. * g++.dg/ext/builtin_alloca.C: Likewise. * g++.dg/ext/tmplattr9.C: Likewise. * g++.dg/ext/vla10.C: Likewise. * g++.dg/ext/vla11.C: Likewise. * g++.dg/ext/vla12.C: Likewise. * g++.dg/ext/vla15.C: Likewise. * g++.dg/ext/vla16.C: Likewise. * g++.dg/ext/vla17.C: Likewise. * g++.dg/ext/vla23.C: Likewise. * g++.dg/ext/vla3.C: Likewise. * g++.dg/ext/vla6.C: Likewise. * g++.dg/ext/vla7.C: Likewise. * g++.dg/init/array24.C: Likewise. * g++.dg/init/new47.C: Likewise. * g++.dg/init/pr55497.C: Likewise. * g++.dg/opt/pr78201.C: Likewise. * g++.dg/template/vla2.C: Likewise. * g++.dg/torture/Wsizeof-pointer-memaccess1.C: Likewise. * g++.dg/torture/Wsizeof-pointer-memaccess2.C: Likewise. * g++.dg/torture/pr62127.C: Likewise. * g++.dg/torture/pr67055.C: Likewise. * g++.dg/torture/stackalign/eh-alloca-1.C: Likewise. * g++.dg/torture/stackalign/eh-inline-2.C: Likewise. * g++.dg/torture/stackalign/eh-vararg-1.C: Likewise. * g++.dg/torture/stackalign/eh-vararg-2.C: Likewise. * g++.dg/warn/Wplacement-new-size-5.C: Likewise. * g++.dg/warn/Wsizeof-pointer-memaccess-1.C: Likewise. * g++.dg/warn/Wvla-1.C: Likewise. * g++.dg/warn/Wvla-3.C: Likewise. * g++.old-deja/g++.ext/array2.C: Likewise. * g++.old-deja/g++.ext/constructor.C: Likewise. * g++.old-deja/g++.law/builtin1.C: Likewise. * g++.old-deja/g++.other/crash12.C: Likewise. * g++.old-deja/g++.other/eh3.C: Likewise. * g++.old-deja/g++.pt/array6.C: Likewise. * g++.old-deja/g++.pt/dynarray.C: Likewise. * gcc.c-torture/compile/20000923-1.c: Likewise. * gcc.c-torture/compile/20030224-1.c: Likewise. * gcc.c-torture/compile/20071108-1.c: Likewise. * gcc.c-torture/compile/20071117-1.c: Likewise. * gcc.c-torture/compile/900313-1.c: Likewise. * gcc.c-torture/compile/parms.c: Likewise. * gcc.c-torture/compile/pr17397.c: Likewise. * gcc.c-torture/compile/pr35006.c: Likewise. * gcc.c-torture/compile/pr42956.c: Likewise. * gcc.c-torture/compile/pr51354.c: Likewise. * gcc.c-torture/compile/pr52714.c: Likewise. * gcc.c-torture/compile/pr55851.c: Likewise. * gcc.c-torture/compile/pr77754-1.c: Likewise. * gcc.c-torture/compile/pr77754-2.c: Likewise. * gcc.c-torture/compile/pr77754-3.c: Likewise. * gcc.c-torture/compile/pr77754-4.c: Likewise. * gcc.c-torture/compile/pr77754-5.c: Likewise. * gcc.c-torture/compile/pr77754-6.c: Likewise. * gcc.c-torture/compile/pr78439.c: Likewise. * gcc.c-torture/compile/pr79413.c: Likewise. * gcc.c-torture/compile/pr82564.c: Likewise. * gcc.c-torture/compile/pr87110.c: Likewise. * gcc.c-torture/compile/pr99787-1.c: Likewise. * gcc.c-torture/compile/vla-const-1.c: Likewise. * gcc.c-torture/compile/vla-const-2.c: Likewise. * gcc.c-torture/execute/20010209-1.c: Likewise. * gcc.c-torture/execute/20020314-1.c: Likewise. * gcc.c-torture/execute/20020412-1.c: Likewise. * gcc.c-torture/execute/20021113-1.c: Likewise. * gcc.c-torture/execute/20040223-1.c: Likewise. * gcc.c-torture/execute/20040308-1.c: Likewise. * gcc.c-torture/execute/20040811-1.c: Likewise. * gcc.c-torture/execute/20070824-1.c: Likewise. * gcc.c-torture/execute/20070919-1.c: Likewise. * gcc.c-torture/execute/built-in-setjmp.c: Likewise. * gcc.c-torture/execute/pr22061-1.c: Likewise. * gcc.c-torture/execute/pr43220.c: Likewise. * gcc.c-torture/execute/pr82210.c: Likewise. * gcc.c-torture/execute/pr86528.c: Likewise. * gcc.c-torture/execute/vla-dealloc-1.c: Likewise. * gcc.dg/20001012-2.c: Likewise. * gcc.dg/20020415-1.c: Likewise. * gcc.dg/20030331-2.c: Likewise. * gcc.dg/20101010-1.c: Likewise. * gcc.dg/Walloca-1.c: Likewise. * gcc.dg/Walloca-10.c: Likewise. * gcc.dg/Walloca-11.c: Likewise. * gcc.dg/Walloca-12.c: Likewise. * gcc.dg/Walloca-13.c: Likewise. * gcc.dg/Walloca-14.c: Likewise. * gcc.dg/Walloca-15.c: Likewise. * gcc.dg/Walloca-2.c: Likewise. * gcc.dg/Walloca-3.c: Likewise. * gcc.dg/Walloca-4.c: Likewise. * gcc.dg/Walloca-5.c: Likewise. * gcc.dg/Walloca-6.c: Likewise. * gcc.dg/Walloca-7.c: Likewise. * gcc.dg/Walloca-8.c: Likewise. * gcc.dg/Walloca-9.c: Likewise. * gcc.dg/Walloca-larger-than-2.c: Likewise. * gcc.dg/Walloca-larger-than-3.c: Likewise. * gcc.dg/Walloca-larger-than-4.c: Likewise. * gcc.dg/Walloca-larger-than.c: Likewise. * gcc.dg/Warray-bounds-22.c: Likewise. * gcc.dg/Warray-bounds-41.c: Likewise. * gcc.dg/Warray-bounds-46.c: Likewise. * gcc.dg/Warray-bounds-48-novec.c: Likewise. * gcc.dg/Warray-bounds-48.c: Likewise. * gcc.dg/Warray-bounds-50.c: Likewise. * gcc.dg/Warray-bounds-63.c: Likewise. * gcc.dg/Warray-bounds-66.c: Likewise. * gcc.dg/Wdangling-pointer.c: Likewise. * gcc.dg/Wfree-nonheap-object-2.c: Likewise. * gcc.dg/Wfree-nonheap-object.c: Likewise. * gcc.dg/Wrestrict-17.c: Likewise. * gcc.dg/Wrestrict.c: Likewise. * gcc.dg/Wreturn-local-addr-2.c: Likewise. * gcc.dg/Wreturn-local-addr-3.c: Likewise. * gcc.dg/Wreturn-local-addr-4.c: Likewise. * gcc.dg/Wreturn-local-addr-6.c: Likewise. * gcc.dg/Wsizeof-pointer-memaccess1.c: Likewise. * gcc.dg/Wstack-usage.c: Likewise. * gcc.dg/Wstrict-aliasing-bogus-vla-1.c: Likewise. * gcc.dg/Wstrict-overflow-27.c: Likewise. * gcc.dg/Wstringop-overflow-15.c: Likewise. * gcc.dg/Wstringop-overflow-23.c: Likewise. * gcc.dg/Wstringop-overflow-25.c: Likewise. * gcc.dg/Wstringop-overflow-27.c: Likewise. * gcc.dg/Wstringop-overflow-3.c: Likewise. * gcc.dg/Wstringop-overflow-39.c: Likewise. * gcc.dg/Wstringop-overflow-56.c: Likewise. * gcc.dg/Wstringop-overflow-57.c: Likewise. * gcc.dg/Wstringop-overflow-67.c: Likewise. * gcc.dg/Wstringop-overflow-71.c: Likewise. * gcc.dg/Wstringop-truncation-3.c: Likewise. * gcc.dg/Wvla-larger-than-1.c: Likewise. * gcc.dg/Wvla-larger-than-2.c: Likewise. * gcc.dg/Wvla-larger-than-3.c: Likewise. * gcc.dg/Wvla-larger-than-4.c: Likewise. * gcc.dg/Wvla-larger-than-5.c: Likewise. * gcc.dg/analyzer/boxed-malloc-1.c: Likewise. * gcc.dg/analyzer/call-summaries-2.c: Likewise. * gcc.dg/analyzer/malloc-1.c: Likewise. * gcc.dg/analyzer/malloc-reuse.c: Likewise. * gcc.dg/analyzer/out-of-bounds-diagram-12.c: Likewise. * gcc.dg/analyzer/pr93355-localealias.c: Likewise. * gcc.dg/analyzer/putenv-1.c: Likewise. * gcc.dg/analyzer/taint-alloc-1.c: Likewise. * gcc.dg/analyzer/torture/pr93373.c: Likewise. * gcc.dg/analyzer/torture/ubsan-1.c: Likewise. * gcc.dg/analyzer/vla-1.c: Likewise. * gcc.dg/atomic/stdatomic-vm.c: Likewise. * gcc.dg/attr-alloc_size-6.c: Likewise. * gcc.dg/attr-alloc_size-7.c: Likewise. * gcc.dg/attr-alloc_size-8.c: Likewise. * gcc.dg/attr-alloc_size-9.c: Likewise. * gcc.dg/attr-noipa.c: Likewise. * gcc.dg/auto-init-uninit-36.c: Likewise. * gcc.dg/auto-init-uninit-9.c: Likewise. * gcc.dg/auto-type-1.c: Likewise. * gcc.dg/builtin-alloc-size.c: Likewise. * gcc.dg/builtin-dynamic-alloc-size.c: Likewise. * gcc.dg/builtin-dynamic-object-size-1.c: Likewise. * gcc.dg/builtin-dynamic-object-size-2.c: Likewise. * gcc.dg/builtin-dynamic-object-size-3.c: Likewise. * gcc.dg/builtin-dynamic-object-size-4.c: Likewise. * gcc.dg/builtin-object-size-1.c: Likewise. * gcc.dg/builtin-object-size-2.c: Likewise. * gcc.dg/builtin-object-size-3.c: Likewise. * gcc.dg/builtin-object-size-4.c: Likewise. * gcc.dg/builtins-64.c: Likewise. * gcc.dg/builtins-68.c: Likewise. * gcc.dg/c23-auto-2.c: Likewise. * gcc.dg/c99-const-expr-13.c: Likewise. * gcc.dg/c99-vla-1.c: Likewise. * gcc.dg/fold-alloca-1.c: Likewise. * gcc.dg/gomp/pr30494.c: Likewise. * gcc.dg/gomp/vla-2.c: Likewise. * gcc.dg/gomp/vla-3.c: Likewise. * gcc.dg/gomp/vla-4.c: Likewise. * gcc.dg/gomp/vla-5.c: Likewise. * gcc.dg/graphite/pr99085.c: Likewise. * gcc.dg/guality/guality.c: Likewise. * gcc.dg/lto/pr80778_0.c: Likewise. * gcc.dg/nested-func-10.c: Likewise. * gcc.dg/nested-func-12.c: Likewise. * gcc.dg/nested-func-13.c: Likewise. * gcc.dg/nested-func-14.c: Likewise. * gcc.dg/nested-func-15.c: Likewise. * gcc.dg/nested-func-16.c: Likewise. * gcc.dg/nested-func-17.c: Likewise. * gcc.dg/nested-func-9.c: Likewise. * gcc.dg/packed-vla.c: Likewise. * gcc.dg/pr100225.c: Likewise. * gcc.dg/pr25682.c: Likewise. * gcc.dg/pr27301.c: Likewise. * gcc.dg/pr31507-1.c: Likewise. * gcc.dg/pr33238.c: Likewise. * gcc.dg/pr41470.c: Likewise. * gcc.dg/pr49120.c: Likewise. * gcc.dg/pr50764.c: Likewise. * gcc.dg/pr51491-2.c: Likewise. * gcc.dg/pr51990-2.c: Likewise. * gcc.dg/pr51990.c: Likewise. * gcc.dg/pr59011.c: Likewise. * gcc.dg/pr59523.c: Likewise. * gcc.dg/pr61561.c: Likewise. * gcc.dg/pr78468.c: Likewise. * gcc.dg/pr78902.c: Likewise. * gcc.dg/pr79972.c: Likewise. * gcc.dg/pr82875.c: Likewise. * gcc.dg/pr83844.c: Likewise. * gcc.dg/pr84131.c: Likewise. * gcc.dg/pr87099.c: Likewise. * gcc.dg/pr87320.c: Likewise. * gcc.dg/pr89045.c: Likewise. * gcc.dg/pr91014.c: Likewise. * gcc.dg/pr93986.c: Likewise. * gcc.dg/pr98721-1.c: Likewise. * gcc.dg/pr99122-2.c: Likewise. * gcc.dg/shrink-wrap-alloca.c: Likewise. * gcc.dg/sso-14.c: Likewise. * gcc.dg/strlenopt-62.c: Likewise. * gcc.dg/strlenopt-83.c: Likewise. * gcc.dg/strlenopt-84.c: Likewise. * gcc.dg/strlenopt-91.c: Likewise. * gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Likewise. * gcc.dg/torture/calleesave-sse.c: Likewise. * gcc.dg/torture/pr48953.c: Likewise. * gcc.dg/torture/pr71881.c: Likewise. * gcc.dg/torture/pr71901.c: Likewise. * gcc.dg/torture/pr78742.c: Likewise. * gcc.dg/torture/pr92088-1.c: Likewise. * gcc.dg/torture/pr92088-2.c: Likewise. * gcc.dg/torture/pr93124.c: Likewise. * gcc.dg/torture/pr94479.c: Likewise. * gcc.dg/torture/stackalign/alloca-1.c: Likewise. * gcc.dg/torture/stackalign/inline-2.c: Likewise. * gcc.dg/torture/stackalign/nested-3.c: Likewise. * gcc.dg/torture/stackalign/vararg-1.c: Likewise. * gcc.dg/torture/stackalign/vararg-2.c: Likewise. * gcc.dg/tree-ssa/20030807-2.c: Likewise. * gcc.dg/tree-ssa/20080530.c: Likewise. * gcc.dg/tree-ssa/alias-37.c: Likewise. * gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: Likewise. * gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: Likewise. * gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Likewise. * gcc.dg/tree-ssa/loop-interchange-15.c: Likewise. * gcc.dg/tree-ssa/pr23848-1.c: Likewise. * gcc.dg/tree-ssa/pr23848-2.c: Likewise. * gcc.dg/tree-ssa/pr23848-3.c: Likewise. * gcc.dg/tree-ssa/pr23848-4.c: Likewise. * gcc.dg/uninit-32.c: Likewise. * gcc.dg/uninit-36.c: Likewise. * gcc.dg/uninit-39.c: Likewise. * gcc.dg/uninit-41.c: Likewise. * gcc.dg/uninit-9-O0.c: Likewise. * gcc.dg/uninit-9.c: Likewise. * gcc.dg/uninit-pr100250.c: Likewise. * gcc.dg/uninit-pr101300.c: Likewise. * gcc.dg/uninit-pr101494.c: Likewise. * gcc.dg/uninit-pr98583.c: Likewise. * gcc.dg/vla-2.c: Likewise. * gcc.dg/vla-22.c: Likewise. * gcc.dg/vla-24.c: Likewise. * gcc.dg/vla-3.c: Likewise. * gcc.dg/vla-4.c: Likewise. * gcc.dg/vla-stexp-1.c: Likewise. * gcc.dg/vla-stexp-2.c: Likewise. * gcc.dg/vla-stexp-4.c: Likewise. * gcc.dg/vla-stexp-5.c: Likewise. * gcc.dg/winline-7.c: Likewise. * gcc.target/aarch64/stack-check-alloca-1.c: Likewise. * gcc.target/aarch64/stack-check-alloca-10.c: Likewise. * gcc.target/aarch64/stack-check-alloca-2.c: Likewise. * gcc.target/aarch64/stack-check-alloca-3.c: Likewise. * gcc.target/aarch64/stack-check-alloca-4.c: Likewise. * gcc.target/aarch64/stack-check-alloca-5.c: Likewise. * gcc.target/aarch64/stack-check-alloca-6.c: Likewise. * gcc.target/aarch64/stack-check-alloca-7.c: Likewise. * gcc.target/aarch64/stack-check-alloca-8.c: Likewise. * gcc.target/aarch64/stack-check-alloca-9.c: Likewise. * gcc.target/arc/interrupt-6.c: Likewise. * gcc.target/i386/pr80969-3.c: Likewise. * gcc.target/loongarch/stack-check-alloca-1.c: Likewise. * gcc.target/loongarch/stack-check-alloca-2.c: Likewise. * gcc.target/loongarch/stack-check-alloca-3.c: Likewise. * gcc.target/loongarch/stack-check-alloca-4.c: Likewise. * gcc.target/loongarch/stack-check-alloca-5.c: Likewise. * gcc.target/loongarch/stack-check-alloca-6.c: Likewise. * gcc.target/riscv/stack-check-alloca-1.c: Likewise. * gcc.target/riscv/stack-check-alloca-10.c: Likewise. * gcc.target/riscv/stack-check-alloca-2.c: Likewise. * gcc.target/riscv/stack-check-alloca-3.c: Likewise. * gcc.target/riscv/stack-check-alloca-4.c: Likewise. * gcc.target/riscv/stack-check-alloca-5.c: Likewise. * gcc.target/riscv/stack-check-alloca-6.c: Likewise. * gcc.target/riscv/stack-check-alloca-7.c: Likewise. * gcc.target/riscv/stack-check-alloca-8.c: Likewise. * gcc.target/riscv/stack-check-alloca-9.c: Likewise. * gcc.target/sparc/setjmp-1.c: Likewise. * gcc.target/x86_64/abi/ms-sysv/ms-sysv.c: Likewise. * gcc.c-torture/compile/20001221-1.c: Don't 'dg-skip-if' for '! alloca'. * gcc.c-torture/compile/20020807-1.c: Likewise. * gcc.c-torture/compile/20050801-2.c: Likewise. * gcc.c-torture/compile/920428-4.c: Likewise. * gcc.c-torture/compile/debugvlafunction-1.c: Likewise. * gcc.c-torture/compile/pr41469.c: Likewise. * gcc.c-torture/execute/920721-2.c: Likewise. * gcc.c-torture/execute/920929-1.c: Likewise. * gcc.c-torture/execute/921017-1.c: Likewise. * gcc.c-torture/execute/941202-1.c: Likewise. * gcc.c-torture/execute/align-nest.c: Likewise. * gcc.c-torture/execute/alloca-1.c: Likewise. * gcc.c-torture/execute/pr22061-4.c: Likewise. * gcc.c-torture/execute/pr36321.c: Likewise. * gcc.dg/torture/pr8081.c: Likewise. * gcc.dg/analyzer/data-model-1.c: Don't 'dg-require-effective-target alloca'. XFAIL relevant 'dg-warning's for '! alloca'. * gcc.dg/uninit-38.c: Likewise. * gcc.dg/uninit-pr98578.c: Likewise. * gcc.dg/compat/struct-by-value-22_main.c: Comment on 'dg-require-effective-target alloca'. libstdc++-v3/ * testsuite/lib/prune.exp (proc libstdc++-dg-prune): Turn 'sorry, unimplemented: dynamic stack allocation not supported' into UNSUPPORTED.
2025-02-13driver: -fhardened and -z lazy/-z norelro [PR117739]Marek Polacek6-0/+30
As the manual states, using "-fhardened -fstack-protector" will produce a warning because -fhardened wants to enable -fstack-protector-strong, but it can't since it's been overriden by the weaker -fstack-protector. -fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should produce the same warning. But we don't detect this combination, so this patch fixes it. I also renamed a variable to better reflect its purpose. Also don't check warn_hardened in process_command, since it's always true there. Also tweak wording in the manual as Jon Wakely suggested on IRC. PR driver/117739 gcc/ChangeLog: * doc/invoke.texi: Tweak wording for -Whardened. * gcc.cc (driver_handle_option): If -z lazy or -z norelro was specified, don't enable linker hardening. (process_command): Don't check warn_hardened. gcc/testsuite/ChangeLog: * c-c++-common/fhardened-16.c: New test. * c-c++-common/fhardened-17.c: New test. * c-c++-common/fhardened-18.c: New test. * c-c++-common/fhardened-19.c: New test. * c-c++-common/fhardened-20.c: New test. * c-c++-common/fhardened-21.c: New test. Reviewed-by: Jakub Jelinek <jakub@redhat.com>
2025-02-07Honor dump options for C/C++ '-fdump-tree-original'Thomas Schwinge1-11/+10
In addition to upcoming use of '-fdump-tree-original-lineno', this patch actually resolves XFAILs for 'c-c++-common/goacc/pr92793-1.c', which had gotten added as part of commit fa410314ec94c9df2ad270c1917adc51f9147c2c "[OpenACC] Elaborate testcases that verify column location information [PR92793]". gcc/c-family/ * c-gimplify.cc (c_genericize): Pass 'local_dump_flags' to 'print_c_tree'. * c-pretty-print.cc (c_pretty_printer::statement): Pass 'dump_flags' to 'dump_generic_node'. (c_pretty_printer::c_pretty_printer): Initialize 'dump_flags'. (print_c_tree): Add 'dump_flags_t' formal parameter. (debug_c_tree): Adjust. * c-pretty-print.h (c_pretty_printer): Add 'dump_flags_t dump_flags'. (c_pretty_printer::c_pretty_printer): Add 'dump_flags_t' formal parameter. (print_c_tree): Adjust. gcc/testsuite/ * c-c++-common/goacc/pr92793-1.c: Remove '-fdump-tree-original-lineno' XFAILs.
2025-02-02options: Adjust cl_optimization_compare to avoid checking ICE [PR115913]Lewis Hyatt1-0/+7
At the end of a sequence like: #pragma GCC push_options ... #pragma GCC pop_options the handler for pop_options calls cl_optimization_compare() (as generated by optc-save-gen.awk) to make sure that all global state has been restored to the value it had prior to the push_options call. The verification is performed for almost all entries in the global_options struct. This leads to unexpected checking asserts, as discussed in the PR, in case the state of warnings-related options has been intentionally modified in between push_options and pop_options via a call to #pragma GCC diagnostic. Address that by skipping the verification for CL_WARNING-flagged options. gcc/ChangeLog: PR middle-end/115913 * optc-save-gen.awk (cl_optimization_compare): Skip options with CL_WARNING flag. gcc/testsuite/ChangeLog: PR middle-end/115913 * c-c++-common/cpp/pr115913.c: New test.
2025-01-30OpenMP: append_args clause fixes + Fortran supportTobias Burnus6-10/+266
This fixes a large number of smaller and larger issues with the append_args clause to 'declare variant' and adds Fortran support for it; it also contains a larger number of testcases. In particular, for Fortran, it also handles passing allocatable, pointer, optional arguments to an interop dummy argument with or without value attribute. And it changes the internal representation such that dumping the tree does not lead to an ICE. gcc/c/ChangeLog: * c-parser.cc (c_finish_omp_declare_variant): Modify how append_args is saved internally. gcc/cp/ChangeLog: * parser.cc (cp_finish_omp_declare_variant): Modify how append_args is saved internally. * pt.cc (tsubst_attribute): Likewise. (tsubst_omp_clauses): Remove C_ORT_OMP_DECLARE_SIMD from interop handling as no longer called for it. * decl.cc (omp_declare_variant_finalize_one): Update append_args changes; fixes for ADL input. gcc/fortran/ChangeLog: * gfortran.h (gfc_omp_declare_variant): Add append_args_list. * openmp.cc (gfc_parser_omp_clause_init_modifiers): New; splitt of from ... (gfc_match_omp_init): ... here; call it. (gfc_match_omp_declare_variant): Update to handle append_args clause; some syntax handling fixes. * trans-openmp.cc (gfc_trans_omp_declare_variant): Handle append_args clause; add some diagnostic. gcc/ChangeLog: * gimplify.cc (gimplify_call_expr): For OpenMP's append_args clause processed by 'omp dispatch', update for internal-representation changes; fix handling of hidden arguments, add some comments and handle Fortran's value dummy and optional/pointer/allocatable actual args. libgomp/ChangeLog: * libgomp.texi (Impl. Status): Update for accumpulated changes related to 'dispatch' and interop. gcc/testsuite/ChangeLog: * c-c++-common/gomp/append-args-1.c: Update dg-*. * c-c++-common/gomp/append-args-3.c: Likewise. * g++.dg/gomp/append-args-1.C: Likewise. * gfortran.dg/gomp/adjust-args-1.f90: Likewise. * gfortran.dg/gomp/adjust-args-3.f90: Likewise. * gfortran.dg/gomp/declare-variant-2.f90: Likewise. * c-c++-common/gomp/append-args-6.c: New test. * c-c++-common/gomp/append-args-7.c: New test. * c-c++-common/gomp/append-args-8.c: New test. * c-c++-common/gomp/append-args-9.c: New test. * g++.dg/gomp/append-args-4.C: New test. * g++.dg/gomp/append-args-5.C: New test. * g++.dg/gomp/append-args-6.C: New test. * g++.dg/gomp/append-args-7.C: New test. * gcc.dg/gomp/append-args-1.c: New test. * gfortran.dg/gomp/append_args-1.f90: New test. * gfortran.dg/gomp/append_args-2.f90: New test. * gfortran.dg/gomp/append_args-3.f90: New test. * gfortran.dg/gomp/append_args-4.f90: New test.
2025-01-28Clarify 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P' in ↵Thomas Schwinge4-5/+5
'gcc/tree-pretty-print.cc:dump_omp_clause' In commit b7e20480630e3eeb9eed8b3941da3b3f0c22c969 "openmp: Relax handling of implicit map vs. existing device mappings", 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P' was added next to 'OMP_CLAUSE_MAP_IMPLICIT' with comment: "NOTE: this is different than OMP_CLAUSE_MAP_IMPLICIT". However, dumping it as '[implicit]' doesn't exactly help for telling the two apart; make that '[runtime_implicit]'. Also, prepend a space character, similar to how we're doing with other such attributes. gcc/ * tree-pretty-print.cc (dump_omp_clause): Clarify 'OMP_CLAUSE_MAP_RUNTIME_IMPLICIT_P'. gcc/testsuite/ * c-c++-common/gomp/defaultmap-4.c: Adjust. * c-c++-common/gomp/defaultmap-5.c: Likewise. * c-c++-common/gomp/target-implicit-map-1.c: Likewise. * c-c++-common/gomp/target-implicit-map-2.c: Likewise. * gfortran.dg/gomp/defaultmap-8.f90: Likewise. * gfortran.dg/gomp/defaultmap-9.f90: Likewise. * gfortran.dg/gomp/map-subarray.f90: Likewise. * gfortran.dg/gomp/target-enter-exit-data.f90: Likewise.
2025-01-28Add tests for implied copy of variables in reduction clause.Hafiz Abid Qadeer2-0/+154
The OpenACC reduction clause on compute construct implies a copy clause for each reduction variable [1]. This patch adds tests to check if the implied copy is being generated. The check covers various types and operators as described in the specification. [1] OpenACC 2.7 Specification section 2.5.13 gcc/testsuite/ChangeLog: * c-c++-common/goacc/implied-copy-1.c: New test. * c-c++-common/goacc/implied-copy-2.c: New test. * g++.dg/goacc/implied-copy.C: New test. * gcc.dg/goacc/implied-copy.c: New test. * gfortran.dg/goacc/implied-copy-1.f90: New test. * gfortran.dg/goacc/implied-copy-2.f90: New test.
2025-01-25c: Diagnose ,) at the end of OpenMP clauses [PR118639]Jakub Jelinek2-1/+15
This is something the C++ FE has been diagnosing but C FE only complained if there wasn't an identifier right after opening ( 2025-01-25 Jakub Jelinek <jakub@redhat.com> PR c/118639 * c-parser.cc (c_parser_omp_variable_list): Remove first variable and emit "expected identifier" error regardless of it. * c-c++-common/gomp/pr118639.c: New test. * c-c++-common/goacc/cache-2.c: Remove one xfail for c.
2025-01-21c, c++: Return 1 for __has_builtin(__builtin_va_arg) and ↵Jakub Jelinek1-0/+16
__has_builtin(__builtin_c23_va_start) The Linux kernel uses its own copy of stdarg.h. Now, before GCC 15, our stdarg.h had #if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L #define va_start(v, ...) __builtin_va_start(v, 0) #else #define va_start(v,l) __builtin_va_start(v,l) #endif va_start definition but GCC 15 has: #if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L #define va_start(...) __builtin_c23_va_start(__VA_ARGS__) #else #define va_start(v,l) __builtin_va_start(v,l) #endif I wanted to suggest to the kernel people during their porting to C23 that they'd better use C23 compatible va_start macro definition, but to make it portable, I think they really want something like #if defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L #define va_start(v, ...) __builtin_va_start(v, 0) #ifdef __has_builtin #if __has_builtin(__builtin_c23_va_start) #undef va_start #define va_start(...) __builtin_c23_va_start(__VA_ARGS__) #endif #else #define va_start(v,l) __builtin_va_start(v,l) #endif or so (or with >= 202311L), as GCC 13-14 and clang don't support __builtin_c23_va_start (yet?) and one gets better user experience with that. Except it seems __has_builtin(__builtin_c23_va_start) doesn't actually work, it works for most of the stdarg.h __builtin_va_*, doesn't work for __builtin_va_arg (neither C nor C++) and didn't work for __builtin_c23_va_start if it was available. The following patch wires __has_builtin for those. 2025-01-21 Jakub Jelinek <jakub@redhat.com> gcc/c/ * c-decl.cc (names_builtin_p): Return 1 for RID_C23_VA_START and RID_VA_ARG. gcc/cp/ * cp-objcp-common.cc (names_builtin_p): Return 1 for RID_VA_ARG. gcc/testsuite/ * c-c++-common/cpp/has-builtin-4.c: New test.
2025-01-17testsuite: Make embed-10.c test more robustJakub Jelinek1-1/+1
With the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html hack we get slightly different error wording in one of the errors, given that the test actually does use #embed, I think both wordings are just fine and we should accept them. 2025-01-17 Jakub Jelinek <jakub@redhat.com> * c-c++-common/cpp/embed-10.c: Allow a different error wording for C++.
2025-01-17OpenMP: Fix metadirective test failures on x86_64 with -m32Sandra Loosemore2-2/+2
gcc/testsuite/ChangeLog * c-c++-common/gomp/metadirective-device.c: Don't add extra options for target ia32. * c-c++-common/gomp/metadirective-target-device-1.c: Likewise.
2025-01-17RISC-V: Add -fcf-protection=[full|branch|return] to enable zicfiss, zicfilp.Monk Chiang7-0/+7
gcc/ChangeLog: * config/riscv/riscv.cc (is_zicfilp_p): New function. (is_zicfiss_p): New function. * config/riscv/riscv-zicfilp.cc: Update. * config/riscv/riscv.h: Update. * config/riscv/riscv.md: Update. * config/riscv/riscv-c.cc: Add CFI predefine marco. gcc/testsuite/ChangeLog: * c-c++-common/fcf-protection-1.c: Update. * c-c++-common/fcf-protection-2.c: Update. * c-c++-common/fcf-protection-3.c: Update. * c-c++-common/fcf-protection-4.c: Update. * c-c++-common/fcf-protection-5.c: Update. * c-c++-common/fcf-protection-6.c: Update. * c-c++-common/fcf-protection-7.c: Update. * gcc.target/riscv/ssp-1.c: Update. * gcc.target/riscv/ssp-2.c: Update. * gcc.target/riscv/zicfilp-call.c: Update. * gcc.target/riscv/interrupt-no-lpad.c: Update.
2025-01-16OpenMP: Improve error message for invalid directive in "assumes".Sandra Loosemore3-15/+15
gcc/c/ChangeLog * c-parser.cc (c_parser_omp_assumption_clauses): Give a more specific error message for invalid directives vs unknown names. gcc/cp/ChangeLog * parser.cc (cp_parser_omp_assumption_clauses): Give a more specific error message for invalid directives vs unknown names. gcc/fortran/ChangeLog * openmp.cc (gfc_omp_absent_contains_clause): Use an Oxford comma in the message. gcc/testsuite/ChangeLog * c-c++-common/gomp/assume-2.c: Adjust expected diagnostics. * c-c++-common/gomp/assumes-2.c: Likewise. * c-c++-common/gomp/begin-assumes-2.c: Likewise. * gfortran.dg/gomp/allocate-6.f90: Likewise. * gfortran.dg/gomp/assumes-2.f90: Likewise.
2025-01-16OpenMP: Update "declare target"/OpenMP context interactionSandra Loosemore3-8/+8
The code and test case previously implemented the OpenMP 5.0 spec, which said in section 2.3.1: "For functions within a declare target block, the target trait is added to the beginning of the set..." In OpenMP 5.1, this was changed to "For device routines, the target trait is added to the beginning of the set..." In OpenMP 5.2 and TR12, it says: "For procedures that are determined to be target function variants by a declare target directive..." The definition of "device routine" in OpenMP 5.1 is confusing, but certainly the intent of the later versions of the spec is clear that it doesn't just apply to functions within a begin declare target/end declare target block. The only use of the "omp declare target block" function attribute was to support the 5.0 language, so it can be removed. This patch changes the context augmentation to use the "omp declare target" attribute instead. gcc/c-family/ChangeLog * c-attribs.cc (c_common_gnu_attributes): Delete "omp declare target block". gcc/c/ChangeLog * c-decl.cc (c_decl_attributes): Don't add "omp declare target block". gcc/cp/ChangeLog * decl2.cc (cplus_decl_attributes): Don't add "omp declare target block". gcc/ChangeLog * omp-general.cc (omp_complete_construct_context): Check "omp declare target" attribute, not "omp declare target block". gcc/testsuite/ChangeLog * c-c++-common/gomp/declare-target-indirect-2.c : Adjust expected output for removal of "omp declare target block". * c-c++-common/gomp/declare-variant-8.c: Likewise, the variant call to f20 is now resolved differently. * c-c++-common/gomp/reverse-offload-1.c: Adjust expected output. * gfortran.dg/gomp/declare-variant-8.f90: Likewise, both f18 and f20 now resolve to the variant. Delete obsolete comments.
2025-01-16OpenMP: Shared metadirective/dynamic selector tests for C and C++Sandra Loosemore25-0/+1434
gcc/testsuite/ChangeLog * c-c++-common/gomp/adjust-args-6.c: New. * c-c++-common/gomp/attrs-metadirective-1.c: New. * c-c++-common/gomp/attrs-metadirective-2.c: New. * c-c++-common/gomp/attrs-metadirective-3.c: New. * c-c++-common/gomp/attrs-metadirective-4.c: New. * c-c++-common/gomp/attrs-metadirective-5.c: New. * c-c++-common/gomp/attrs-metadirective-6.c: New. * c-c++-common/gomp/attrs-metadirective-7.c: New. * c-c++-common/gomp/attrs-metadirective-8.c: New. * c-c++-common/gomp/declare-variant-arg-exprs.c: New. * c-c++-common/gomp/declare-variant-dynamic-1.c: New. * c-c++-common/gomp/declare-variant-dynamic-2.c: New. * c-c++-common/gomp/metadirective-1.c: New. * c-c++-common/gomp/metadirective-2.c: New. * c-c++-common/gomp/metadirective-3.c: New. * c-c++-common/gomp/metadirective-4.c: New. * c-c++-common/gomp/metadirective-5.c: New. * c-c++-common/gomp/metadirective-6.c: New. * c-c++-common/gomp/metadirective-7.c: New. * c-c++-common/gomp/metadirective-8.c: New. * c-c++-common/gomp/metadirective-construct.c: New. * c-c++-common/gomp/metadirective-device.c: New. * c-c++-common/gomp/metadirective-no-score.c: New. * c-c++-common/gomp/metadirective-target-device-1.c: New. * c-c++-common/gomp/metadirective-target-device-2.c: New. libgomp/ChangeLog * testsuite/libgomp.c-c++-common/metadirective-1.c: New. * testsuite/libgomp.c-c++-common/metadirective-2.c: New. * testsuite/libgomp.c-c++-common/metadirective-3.c: New. * testsuite/libgomp.c-c++-common/metadirective-4.c: New. * testsuite/libgomp.c-c++-common/metadirective-5.c: New. * testsuite/libgomp.c-c++-common/metadirective-late-1.c: New. * testsuite/libgomp.c-c++-common/metadirective-late-2.c: New. * testsuite/libgomp.c-c++-common/metadirective-target-device.c: New. Co-Authored-By: Kwok Cheung Yeung <kcy@codesourcery.com> Co-Authored-By: Sandra Loosemore <sandra@codesourcery.com>
2025-01-16OpenMP: C++ support for metadirectives and dynamic selectors.Sandra Loosemore1-3/+1
Additional shared C/C++ testcases are included in a subsequent patch in this series. gcc/cp/ChangeLog PR middle-end/112779 PR middle-end/113904 * cp-tree.h (struct saved_scope): Add new field x_processing_omp_trait_property_expr. (processing_omp_trait_property_expr): New. * parser.cc (cp_parser_skip_to_end_of_block_or_statement): Add metadirective_p parameter and handle skipping over the parentheses in a "for" statement. (struct omp_metadirective_parse_data): New. (mangle_metadirective_region_label): New. (cp_parser_label_for_labeled_statement): Mangle label names in a metadirective body. (cp_parser_jump_statement): Likewise. (cp_parser_omp_context_selector): Allow arbitrary expressions in device_num and condition properties. (cp_parser_omp_assumption_clauses): Handle C_OMP_DIR_META. (analyze_metadirective_body): New. (cp_parser_omp_metadirective): New. (cp_parser_pragma): Handle PRAGMA_OMP_METADIRECTIVE. * parser.h (struct cp_parser): Add omp_metadirective_state field. * pt.cc (tsubst_omp_context_selector): New. (tsubst_stmt): Handle OMP_METADIRECTIVE. * semantics.cc (finish_id_expression_1): Don't diagnose use of parameter outside function body in dynamic selector expressions here. gcc/testsuite/ PR middle-end/112779 PR middle-end/113904 * c-c++-common/gomp/declare-variant-2.c: Adjust output for C++. * g++.dg/gomp/declare-variant-class-1.C: New. * g++.dg/gomp/declare-variant-class-2.C: New. * g++.dg/gomp/metadirective-template-1.C: New. libgomp/ PR middle-end/112779 PR middle-end/113904 * testsuite/libgomp.c++/metadirective-template-1.C: New. * testsuite/libgomp.c++/metadirective-template-2.C: New. * testsuite/libgomp.c++/metadirective-template-3.C: New. Co-Authored-By: Kwok Cheung Yeung <kcy@codesourcery.com> Co-Authored-By: Sandra Loosemore <sandra@codesourcery.com>
2025-01-16OpenMP: Add C support for metadirectives and dynamic selectors.Sandra Loosemore1-2/+4
Additional shared C/C++ testcases are included in a subsequent patch in this series. gcc/c-family/ChangeLog PR middle-end/112779 PR middle-end/113904 * c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META. (c_omp_expand_variant_construct): Declare. * c-gimplify.cc: Include omp-general.h. (genericize_omp_metadirective_stmt): New. (c_genericize_control_stmt): Add case for OMP_METADIRECTIVE. * c-omp.cc (c_omp_directives): Fix entries for metadirective. (c_omp_expand_variant_construct_r): New. (c_omp_expand_variant_construct): New. * c-pragma.cc (omp_pragmas): Add metadirective. * c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_METADIRECTIVE. gcc/c/ChangeLog PR middle-end/112779 PR middle-end/113904 * c-parser.cc (struct c_parser): Add omp_metadirective_state field. (c_parser_skip_to_end_of_block_or_statement): Add metadirective_p parameter and handle skipping over the parentheses in a "for" statement. (struct omp_metadirective_parse_data): New. (mangle_metadirective_region_label): New. (c_parser_label): Mangle label names in a metadirective body. (c_parser_statement_after_labels): Likewise. (c_parser_pragma): Handle PRAGMA_OMP_METADIRECTIVE. (c_parser_omp_context_selector): Allow arbitrary expressions in device_num and condition properties. (c_parser_omp_assumption_clauses): Handle C_OMP_DIR_META. (analyze_metadirective_body): New. (c_parser_omp_metadirective): New. gcc/testsuite/ PR middle-end/112779 * c-c++-common/gomp/declare-variant-2.c: Adjust expected output for C. * gcc.dg/gomp/metadirective-1.c: New. Co-Authored-By: Kwok Cheung Yeung <kcy@codesourcery.com> Co-Authored-By: Sandra Loosemore <sandra@codesourcery.com>
generated by cgit v1.1 at 2025-04-05 08:56:15 +0000