aboutsummaryrefslogtreecommitdiff
path: root/gcc/c
AgeCommit message (Collapse)AuthorFilesLines
2022-07-11Daily bump.GCC Administrator1-0/+6
2022-07-10c: Fix location for _Pragma tokens [PR97498]Lewis Hyatt1-0/+1
The handling of #pragma GCC diagnostic uses input_location, which is not always as precise as needed; in particular the relative location of some tokens and a _Pragma directive will crucially determine whether a given diagnostic is enabled or suppressed in the desired way. PR97498 shows how the C frontend ends up with input_location pointing to the beginning of the line containing a _Pragma() directive, resulting in the wrong behavior if the diagnostic to be modified pertains to some tokens found earlier on the same line. This patch fixes that by addressing two issues: a) libcpp was not assigning a valid location to the CPP_PRAGMA token generated by the _Pragma directive. b) C frontend was not setting input_location to something reasonable. With this change, the C frontend is able to change input_location to point to the _Pragma token as needed. This is just a two-line fix (one for each of a) and b)), the testsuite changes were needed only because the location on the tested warnings has been somewhat improved, so the tests need to look for the new locations. gcc/c/ChangeLog: PR preprocessor/97498 * c-parser.cc (c_parser_pragma): Set input_location to the location of the pragma, rather than the start of the line. libcpp/ChangeLog: PR preprocessor/97498 * directives.cc (destringize_and_run): Override the location of the CPP_PRAGMA token from a _Pragma directive to the location of the expansion point, as is done for the tokens lexed from it. gcc/testsuite/ChangeLog: PR preprocessor/97498 * c-c++-common/pr97498.c: New test. * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations. * c-c++-common/gomp/pragma-5.c: Likewise. * gcc.dg/pragma-message.c: Likewise. libgomp/ChangeLog: * testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for improved warning locations. * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
2022-07-05Daily bump.GCC Administrator1-0/+9
2022-07-04OpenMP: Move omp requires checks to libgompTobias Burnus1-3/+16
Handle reverse_offload, unified_address, and unified_shared_memory requirements in libgomp by saving them alongside the offload table. When the device lto1 runs, it extracts the data for mkoffload. The latter than passes the value on to GOMP_offload_register_ver. lto1 (either the host one, with -flto [+ ENABLE_OFFLOADING], or in the offload-device lto1) also does the the consistency check is done, erroring out when the 'omp requires' clause use is inconsistent. For all in-principle supported devices, if a requirement cannot be fulfilled, the device is excluded from the (supported) devices list. Currently, none of those requirements are marked as supported for any of the non-host devices. gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_target_data, c_parser_omp_target_update, c_parser_omp_target_enter_data, c_parser_omp_target_exit_data): Set OMP_REQUIRES_TARGET_USED. (c_parser_omp_requires): Remove sorry. gcc/ChangeLog: * config/gcn/mkoffload.cc (process_asm): Write '#include <stdint.h>'. (process_obj): Pass omp_requires_mask to GOMP_offload_register_ver. (main): Ask lto1 to obtain omp_requires_mask and pass it on. * config/nvptx/mkoffload.cc (process, main): Likewise. * lto-cgraph.cc (omp_requires_to_name): New. (input_offload_tables): Save omp_requires_mask. (output_offload_tables): Read it, check for consistency, save value for mkoffload. * omp-low.cc (lower_omp_target): Force output_offloadtables call for OMP_REQUIRES_TARGET_USED. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_target_data, cp_parser_omp_target_enter_data, cp_parser_omp_target_exit_data, cp_parser_omp_target_update): Set OMP_REQUIRES_TARGET_USED. (cp_parser_omp_requires): Remove sorry. gcc/fortran/ChangeLog: * openmp.cc (gfc_match_omp_requires): Remove sorry. * parse.cc (decode_omp_directive): Don't regard 'declare target' as target usage for 'omp requires'; add more flags to omp_requires_mask. include/ChangeLog: * gomp-constants.h (GOMP_VERSION): Bump to 2. (GOMP_REQUIRES_UNIFIED_ADDRESS, GOMP_REQUIRES_UNIFIED_SHARED_MEMORY, GOMP_REQUIRES_REVERSE_OFFLOAD, GOMP_REQUIRES_TARGET_USED): New defines. libgomp/ChangeLog: * libgomp-plugin.h (GOMP_OFFLOAD_get_num_devices): Add omp_requires_mask arg. * plugin/plugin-gcn.c (GOMP_OFFLOAD_get_num_devices): Likewise; return -1 when device available but omp_requires_mask != 0. * plugin/plugin-nvptx.c (GOMP_OFFLOAD_get_num_devices): Likewise. * oacc-host.c (host_get_num_devices, host_openacc_get_property): Update call. * oacc-init.c (resolve_device, acc_init_1, acc_shutdown_1, goacc_attach_host_thread_to_device, acc_get_num_devices, acc_set_device_num, get_property_any): Likewise. * target.c (omp_requires_mask): New global var. (gomp_requires_to_name): New. (GOMP_offload_register_ver): Handle passed omp_requires_mask. (gomp_target_init): Handle omp_requires_mask. * libgomp.texi (OpenMP 5.0): Update requires impl. status. (OpenMP 5.1): Add a missed item. (OpenMP 5.2): Mark linear-clause change as supported in C/C++. * testsuite/libgomp.c-c++-common/requires-1-aux.c: New test. * testsuite/libgomp.c-c++-common/requires-1.c: New test. * testsuite/libgomp.c-c++-common/requires-2-aux.c: New test. * testsuite/libgomp.c-c++-common/requires-2.c: New test. * testsuite/libgomp.c-c++-common/requires-3-aux.c: New test. * testsuite/libgomp.c-c++-common/requires-3.c: New test. * testsuite/libgomp.c-c++-common/requires-4-aux.c: New test. * testsuite/libgomp.c-c++-common/requires-4.c: New test. * testsuite/libgomp.c-c++-common/requires-5-aux.c: New test. * testsuite/libgomp.c-c++-common/requires-5.c: New test. * testsuite/libgomp.c-c++-common/requires-6.c: New test. * testsuite/libgomp.c-c++-common/requires-7-aux.c: New test. * testsuite/libgomp.c-c++-common/requires-7.c: New test. * testsuite/libgomp.fortran/requires-1-aux.f90: New test. * testsuite/libgomp.fortran/requires-1.f90: New test. liboffloadmic/ChangeLog: * plugin/libgomp-plugin-intelmic.cpp (GOMP_OFFLOAD_get_num_devices): Return -1 when device available but omp_requires_mask != 0. gcc/testsuite/ChangeLog: * c-c++-common/gomp/requires-4.c: Update dg-*. * c-c++-common/gomp/reverse-offload-1.c: Likewise. * c-c++-common/gomp/target-device-ancestor-2.c: Likewise. * c-c++-common/gomp/target-device-ancestor-3.c: Likewise. * c-c++-common/gomp/target-device-ancestor-4.c: Likewise. * c-c++-common/gomp/target-device-ancestor-5.c: Likewise. * gfortran.dg/gomp/target-device-ancestor-3.f90: Likewise. * gfortran.dg/gomp/target-device-ancestor-4.f90: Likewise. * gfortran.dg/gomp/target-device-ancestor-5.f90: Likewise. * gfortran.dg/gomp/target-device-ancestor-2.f90: Likewise. Move post-FE checks to ... * gfortran.dg/gomp/target-device-ancestor-2a.f90: ... this new file. * gfortran.dg/gomp/requires-8.f90: Update as we don't regard 'declare target' for the 'requires' usage requirement. Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com> Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
2022-07-02Daily bump.GCC Administrator1-0/+6
2022-07-01OpenMP: Handle tofrom with target enter/exit dataTobias Burnus1-3/+19
In 5.2, a map clause can be map-entering or map-exiting, either containing 'tofrom'. The main reason for this is permit 'map(x)' with 'omp target enter/exit data', avoiding to specify 'to:/from:' explicitly. (OpenMP defaults to 'tofrom'.) gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_target_enter_data, c_parser_omp_target_exit_data): Accept tofrom map-type modifier but use 'to' / 'from' internally. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_target_enter_data, cp_parser_omp_target_exit_data): Accept tofrom map-type modifier but use 'to' / 'from' internally. gcc/fortran/ChangeLog: * dump-parse-tree.cc (show_omp_namelist): For the map-type, also handle the always modifer and release/delete. * openmp.cc (resolve_omp_clauses): Accept tofrom map-type modifier for target enter/exit data, but use 'to' / 'from' internally. libgomp/ChangeLog: * libgomp.texi (OpenMP 5.2): Mark target enter/exit data with fromto as implemented. gcc/testsuite/ChangeLog: * c-c++-common/gomp/target-data-2.c: New test. * c-c++-common/gomp/target-data-3.c: New test. * gfortran.dg/gomp/target-data-1.f90: New test. * gfortran.dg/gomp/target-data-2.f90: New test.
2022-06-17Daily bump.GCC Administrator1-0/+23
2022-06-16c-decl: fix "inform" grouping and conditionalizationDavid Malcolm1-23/+42
Whilst working on SARIF output I noticed some places where followup notes weren't being properly associated with their errors/warnings in c-decl.cc. Whilst fixing those I noticed some places where we "inform" after a "warning" without checking that the warning was actually emitted. Fixed the various issues seen in gcc/c/c-decl.cc thusly. gcc/c/ChangeLog: * c-decl.cc (implicitly_declare): Add auto_diagnostic_group to group the warning with any note. (warn_about_goto): Likewise to group error or warning with note. Bail out if the warning wasn't emitted, to avoid emitting orphan notes. (lookup_label_for_goto): Add auto_diagnostic_group to group the error with the note. (check_earlier_gotos): Likewise. (c_check_switch_jump_warnings): Likewise for any error/warning. Conditionalize emission of the notes. (diagnose_uninitialized_cst_member): Likewise for warning, conditionalizing emission of the note. (grokdeclarator): Add auto_diagnostic_group to group the "array type has incomplete element type" error with any note. (parser_xref_tag): Add auto_diagnostic_group to group warnings with their notes. Conditionalize emission of notes. (start_struct): Add auto_diagnostic_group to group the "redefinition of" errors with any note. (start_enum): Likewise for "redeclaration of %<enum %E%>" error. (check_for_loop_decls): Likewise for pre-C99 error. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-06-08Daily bump.GCC Administrator1-0/+10
2022-06-07openmp: Add support for OpenMP 5.2 linear clause syntax for C/C++Jakub Jelinek2-11/+106
The syntax for linear clause changed in 5.2, the original syntax which is still valid is: linear (var1, var2) linear (var3, var4 : step1) The 4.5 syntax with modifiers like: linear (val (var5, var6)) linear (val (var7, var8) : step2) is still supported in 5.2, but is deprecated there. Instead, one can use a new syntax: linear (var9, var10 : val) linear (var11, var12 : step (step3), val) As val, ref, uval or step (someexpr) can be valid expressions (and especially in C++ can be const / constexpr / consteval), the spec says that when the whole step expression is val (or ref or uval) or step ( ... ) then it is the new modifier syntax, one can use + 0 or 0 + or 1 * or * 1 or ()s to say it is the old step expression. Also, 5.2 now allows val modifier to be specified even outside of declare simd (but not the other modifiers). I've implemented this for the new modifier syntax only, the old one keeps the old restriction (which is why OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER flag has been introduced). 2022-06-07 Jakub Jelinek <jakub@redhat.com> gcc/ * tree.h (OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER): Define. * tree-pretty-print.cc (dump_omp_clause) <case OMP_CLAUSE_LINEAR>: Adjust clause printing style depending on OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER. gcc/c/ * c-parser.cc (c_parser_omp_clause_linear): Parse OpenMP 5.2 style linear clause modifiers. Set OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER flag on the clauses when old style modifiers are used. * c-typeck.cc (c_finish_omp_clauses): Only reject linear clause with val modifier on simd or for if the old style modifiers are used. gcc/cp/ * parser.cc (cp_parser_omp_clause_linear): Parse OpenMP 5.2 style linear clause modifiers. Set OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER flag on the clauses when old style modifiers are used. * semantics.cc (finish_omp_clauses): Only reject linear clause with val modifier on simd or for if the old style modifiers are used. gcc/fortran/ * trans-openmp.cc (gfc_trans_omp_clauses): Set OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER on OMP_CLAUSE_LINEAR clauses unconditionally for now. gcc/testsuite/ * c-c++-common/gomp/linear-2.c: New test. * c-c++-common/gomp/linear-3.c: New test. * g++.dg/gomp/linear-3.C: New test. * g++.dg/gomp/linear-4.C: New test. * g++.dg/gomp/linear-5.C: New test.
2022-06-03Daily bump.GCC Administrator1-0/+6
2022-06-02diagnostics: add SARIF output formatDavid Malcolm2-0/+14
This patch adds support to gcc's diagnostic subsystem for emitting diagnostics in SARIF, aka the Static Analysis Results Interchange Format: https://sarifweb.azurewebsites.net/ by extending -fdiagnostics-format= to add two new options: -fdiagnostics-format=sarif-stderr and: -fdiagnostics-format=sarif-file The patch targets SARIF v2.1.0 This is a JSON-based format suited for capturing the results of static analysis tools (like GCC's -fanalyzer), but it can also be used for plain GCC warnings and errors. SARIF supports per-event metadata in diagnostic paths such as ["acquire", "resource"] and ["release", "lock"] (specifically, the threadFlowLocation "kinds" property: SARIF v2.1.0 section 3.38.8), so the patch extends GCC"s diagnostic_event subclass with a "struct meaning" with similar purpose. The patch implements this for -fanalyzer so that the various state-machine-based warnings set these in the SARIF output. The heart of the implementation is in the new file diagnostic-format-sarif.cc. Much of the rest of the patch is interface classes, isolating the diagnostic subsystem (which has no knowledge of e.g. tree or langhook) from the "client" code in the compiler proper cc1 etc). The patch adds a langhook for specifying the SARIF v2.1.0 "artifact.sourceLanguage" property, based on the list in SARIF v2.1.0 Appendix J. The patch adds automated DejaGnu tests to our testsuite via new scan-sarif-file and scan-sarif-file-not directives (although these merely use regexps, rather than attempting to use a proper JSON parser). I've tested the patch by hand using the validator at: https://sarifweb.azurewebsites.net/Validation and the react-based viewer at: https://microsoft.github.io/sarif-web-component/ which successfully shows most of the information (although not paths, and not CWE IDs), and I've fixed all validation errors I've seen (though bugs no doubt remain). I've also tested the generated SARIF using the VS Code extension linked to from the SARIF website; I'm a novice with VS Code, but it seems to be able to handle my generated SARIF files (e.g. showing the data in the SARIF tab, and showing squiggly underlines under issues, and when I click on them, it visualizes the events in the path inline within the source window). Has anyone written an Emacs mode for SARIF files? (pretty please) gcc/ChangeLog: * Makefile.in (OBJS): Add tree-diagnostic-client-data-hooks.o and tree-logical-location.o. (OBJS-libcommon): Add diagnostic-format-sarif.o; reorder. (CFLAGS-tree-diagnostic-client-data-hooks.o): Add TARGET_NAME. * common.opt (fdiagnostics-format=): Add sarif-stderr and sarif-file. (sarif-stderr, sarif-file): New enum values. * diagnostic-client-data-hooks.h: New file. * diagnostic-format-sarif.cc: New file. * diagnostic-path.h (enum diagnostic_event::verb): New enum. (enum diagnostic_event::noun): New enum. (enum diagnostic_event::property): New enum. (struct diagnostic_event::meaning): New struct. (diagnostic_event::get_logical_location): New vfunc. (diagnostic_event::get_meaning): New vfunc. (simple_diagnostic_event::get_logical_location): New vfunc impl. (simple_diagnostic_event::get_meaning): New vfunc impl. * diagnostic.cc: Include "diagnostic-client-data-hooks.h". (diagnostic_initialize): Initialize m_client_data_hooks. (diagnostic_finish): Clean up m_client_data_hooks. (diagnostic_event::meaning::dump_to_pp): New. (diagnostic_event::meaning::maybe_get_verb_str): New. (diagnostic_event::meaning::maybe_get_noun_str): New. (diagnostic_event::meaning::maybe_get_property_str): New. (get_cwe_url): Make non-static. (diagnostic_output_format_init): Handle DIAGNOSTICS_OUTPUT_FORMAT_SARIF_STDERR and DIAGNOSTICS_OUTPUT_FORMAT_SARIF_FILE. * diagnostic.h (enum diagnostics_output_format): Add DIAGNOSTICS_OUTPUT_FORMAT_SARIF_STDERR and DIAGNOSTICS_OUTPUT_FORMAT_SARIF_FILE. (class diagnostic_client_data_hooks): New forward decl. (class logical_location): New forward decl. (diagnostic_context::m_client_data_hooks): New field. (diagnostic_output_format_init_sarif_stderr): New decl. (diagnostic_output_format_init_sarif_file): New decl. (get_cwe_url): New decl. * doc/invoke.texi (-fdiagnostics-format=): Add sarif-stderr and sarif-file. * doc/sourcebuild.texi (Scan a particular file): Add scan-sarif-file and scan-sarif-file-not. * langhooks-def.h (lhd_get_sarif_source_language): New decl. (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): New macro. (LANG_HOOKS_INITIALIZER): Add LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE. * langhooks.cc (lhd_get_sarif_source_language): New. * langhooks.h (lang_hooks::get_sarif_source_language): New field. * logical-location.h: New file. * plugin.cc (struct for_each_plugin_closure): New. (for_each_plugin_cb): New. (for_each_plugin): New. * plugin.h (for_each_plugin): New decl. * tree-diagnostic-client-data-hooks.cc: New file. * tree-diagnostic.cc: Include "diagnostic-client-data-hooks.h". (tree_diagnostics_defaults): Populate m_client_data_hooks. * tree-logical-location.cc: New file. * tree-logical-location.h: New file. gcc/ada/ChangeLog: * gcc-interface/misc.cc (gnat_get_sarif_source_language): New. (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine. gcc/analyzer/ChangeLog: * checker-path.cc (checker_event::get_meaning): New. (function_entry_event::get_meaning): New. (state_change_event::get_desc): Add dump of meaning of the event to the -fanalyzer-verbose-state-changes output. (state_change_event::get_meaning): New. (cfg_edge_event::get_meaning): New. (call_event::get_meaning): New. (return_event::get_meaning): New. (start_consolidated_cfg_edges_event::get_meaning): New. (warning_event::get_meaning): New. * checker-path.h: Include "tree-logical-location.h". (checker_event::checker_event): Construct m_logical_loc. (checker_event::get_logical_location): New. (checker_event::get_meaning): New decl. (checker_event::m_logical_loc): New. (function_entry_event::get_meaning): New decl. (state_change_event::get_meaning): New decl. (cfg_edge_event::get_meaning): New decl. (call_event::get_meaning): New decl. (return_event::get_meaning): New decl. (start_consolidated_cfg_edges_event::get_meaning): New. (warning_event::get_meaning): New decl. * pending-diagnostic.h: Include "diagnostic-path.h". (pending_diagnostic::get_meaning_for_state_change): New vfunc. * sm-file.cc (file_diagnostic::get_meaning_for_state_change): New vfunc impl. * sm-malloc.cc (malloc_diagnostic::get_meaning_for_state_change): Likewise. * sm-sensitive.cc (exposure_through_output_file::get_meaning_for_state_change): Likewise. * sm-taint.cc (taint_diagnostic::get_meaning_for_state_change): Likewise. * varargs.cc (va_list_sm_diagnostic::get_meaning_for_state_change): Likewise. gcc/c/ChangeLog: * c-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine. (c_get_sarif_source_language): New. * c-tree.h (c_get_sarif_source_language): New decl. gcc/cp/ChangeLog: * cp-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine. (cp_get_sarif_source_language): New. gcc/d/ChangeLog: * d-lang.cc (d_get_sarif_source_language): New. (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine. gcc/fortran/ChangeLog: * f95-lang.cc (gfc_get_sarif_source_language): New. (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine. gcc/go/ChangeLog: * go-lang.cc (go_get_sarif_source_language): New. (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine. gcc/objc/ChangeLog: * objc-act.h (objc_get_sarif_source_language): New decl. * objc-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine. (objc_get_sarif_source_language): New. gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-sarif-file-1.c: New test. * c-c++-common/diagnostic-format-sarif-file-2.c: New test. * c-c++-common/diagnostic-format-sarif-file-3.c: New test. * c-c++-common/diagnostic-format-sarif-file-4.c: New test. * gcc.dg/analyzer/file-meaning-1.c: New test. * gcc.dg/analyzer/malloc-meaning-1.c: New test. * gcc.dg/analyzer/malloc-sarif-1.c: New test. * gcc.dg/plugin/analyzer_gil_plugin.c (gil_diagnostic::get_meaning_for_state_change): New vfunc impl. * gcc.dg/plugin/diagnostic-test-paths-5.c: New test. * gcc.dg/plugin/plugin.exp (plugin_test_list): Add diagnostic-test-paths-5.c to tests for diagnostic_plugin_test_paths.c. * lib/gcc-dg.exp: Load scansarif.exp. * lib/scansarif.exp: New test. libatomic/ChangeLog: * testsuite/lib/libatomic.exp: Add load_gcc_lib of scansarif.exp. libgomp/ChangeLog: * testsuite/lib/libgomp.exp: Add load_gcc_lib of scansarif.exp. libitm/ChangeLog: * testsuite/lib/libitm.exp: Add load_gcc_lib of scansarif.exp. libphobos/ChangeLog: * testsuite/lib/libphobos-dg.exp: Add load_gcc_lib of scansarif.exp. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-06-01Daily bump.GCC Administrator1-0/+9
2022-05-31build: TAGS and .cc transitionJason Merrill1-1/+1
A few globs missed in the .c -> .cc transition. Some targets were looking at both *.c and *.cc, but there are no longer any .c files to scan. gcc/ChangeLog: * Makefile.in (TAGS): Look at libcpp/*.cc. gcc/c/ChangeLog: * Make-lang.in (c.tags): Look at *.cc. gcc/cp/ChangeLog: * Make-lang.in (c++.tags): Just look at *.cc. gcc/d/ChangeLog: * Make-lang.in (d.tags): Just look at *.cc. gcc/fortran/ChangeLog: * Make-lang.in (fortran.tags): Look at *.cc. gcc/go/ChangeLog: * Make-lang.in (go.tags): Look at *.cc. gcc/objc/ChangeLog: * Make-lang.in (objc.tags): Look at *.cc. gcc/objcp/ChangeLog: * Make-lang.in (obj-c++.tags): Look at *.cc.
2022-05-31openmp: Add support for firstprivate and allocate clauses on scope constructJakub Jelinek1-0/+2
OpenMP 5.2 adds support for firstprivate and allocate clauses on the scope construct and this patch adds that support to GCC. 5.2 unfortunately (IMNSHO mistakenly) marked scope construct as worksharing, which implies that it isn't possible to nest inside of it other scope, worksharing loop, sections, explicit barriers, single etc. which would make scope far less useful. I'm not implementing that part, keeping the 5.1 behavior here, and will file an issue to revert that for OpenMP 6.0. But, for firstprivate it keeps the restriction that is now implied from worksharing construct that listed var can't be private in outer context, where for reduction 5.1 had similar restriction explicit even for scope and 5.2 has it implicitly through worksharing construct. 2022-05-31 Jakub Jelinek <jakub@redhat.com> gcc/ * omp-low.cc (build_outer_var_ref): For code == OMP_CLAUSE_ALLOCATE allow var to be private in the outer context. (lower_private_allocate): Pass OMP_CLAUSE_ALLOCATE as last argument to build_outer_var_ref. gcc/c/ * c-parser.cc (OMP_SCOPE_CLAUSE_MASK): Add firstprivate and allocate clauses. gcc/cp/ * parser.cc (OMP_SCOPE_CLAUSE_MASK): Add firstprivate and allocate clauses. gcc/testsuite/ * c-c++-common/gomp/scope-5.c: New test. * c-c++-common/gomp/scope-6.c: New test. * g++.dg/gomp/attrs-1.C (bar): Add firstprivate and allocate clauses to scope construct. * g++.dg/gomp/attrs-2.C (bar): Likewise. libgomp/ * testsuite/libgomp.c-c++-common/allocate-1.c (foo): Add testcase for scope construct with allocate clause. * testsuite/libgomp.c-c++-common/allocate-3.c (foo): Likewise. * testsuite/libgomp.c-c++-common/scope-2.c: New test.
2022-05-29Daily bump.GCC Administrator1-0/+7
2022-05-28openmp: Adjust diagnostics about same variable in link and to/enter clausesJakub Jelinek1-3/+8
On Fri, May 27, 2022 at 04:52:17PM +0200, Tobias Burnus wrote: > The 'TO'/'ENTER' usage is first stored in a linked list – and > then as attribute to the symbol. I am not sure how to handle it best. This reminds me I've left the C/C++ FE diagnostics about mixing link and to/enter on the same variable in separate directives as is, so it always talked about mixing link and to clauses. This patch adjusts it, so that if link is first, it talks about the clause actually used and if link is later, uses to or enter together in the wording. 2022-05-28 Jakub Jelinek <jakub@redhat.com> gcc/c/ * c-parser.cc (c_parser_omp_declare_target): If OMP_CLAUSE_LINK was seen first, use "%<to%>" or "%<enter%>" depending on OMP_CLAUSE_ENTER_TO of the current clause, otherwise use "%<to%> or %<enter%>" wording. gcc/cp/ * parser.cc (handle_omp_declare_target_clause): If OMP_CLAUSE_LINK was seen first, use "%<to%>" or "%<enter%>" depending on OMP_CLAUSE_ENTER_TO of the current clause, otherwise use "%<to%> or %<enter%>" wording. gcc/testsuite/ * c-c++-common/gomp/declare-target-2.c: Add further tests for mixing of link and to/enter clauses on separate directives.
2022-05-28Daily bump.GCC Administrator1-0/+14
2022-05-27openmp: Add support for enter clause on declare targetJakub Jelinek2-13/+31
OpenMP 5.1 and earlier had 2 different uses of to clause, one for target update construct with one semantics, and one for declare target directive with a different semantics. Under the hood we were using OMP_CLAUSE_TO_DECLARE to represent the latter. OpenMP 5.2 renamed the declare target clause to to enter, the old one is kept as a deprecated alias. As we are far from having full OpenMP 5.2 support, this patch adds support for the enter clause (and renames OMP_CLAUSE_TO_DECLARE to OMP_CLAUSE_ENTER with a flag to tell the spelling of the clause for better diagnostics), but doesn't deprecate the to clause on declare target just yet (that should be done as one of the last steps in 5.2 support). 2022-05-27 Jakub Jelinek <jakub@redhat.com> gcc/ * tree-core.h (enum omp_clause_code): Rename OMP_CLAUSE_TO_DECLARE to OMP_CLAUSE_ENTER. * tree.h (OMP_CLAUSE_ENTER_TO): Define. * tree.cc (omp_clause_num_ops, omp_clause_code_name): Rename OMP_CLAUSE_TO_DECLARE to OMP_CLAUSE_ENTER. * tree-pretty-print.cc (dump_omp_clause): Handle OMP_CLAUSE_ENTER instead of OMP_CLAUSE_TO_DECLARE, if OMP_CLAUSE_ENTER_TO, print "to" instead of "enter". * tree-nested.cc (convert_nonlocal_omp_clauses, convert_local_omp_clauses): Handle OMP_CLAUSE_ENTER instead of OMP_CLAUSE_TO_DECLARE. gcc/c-family/ * c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_ENTER. gcc/c/ * c-parser.cc (c_parser_omp_clause_name): Parse enter clause. (c_parser_omp_all_clauses): For to clause on declare target, use OMP_CLAUSE_ENTER clause with OMP_CLAUSE_ENTER_TO instead of OMP_CLAUSE_TO_DECLARE clause. Handle PRAGMA_OMP_CLAUSE_ENTER. (OMP_DECLARE_TARGET_CLAUSE_MASK): Add enter clause. (c_parser_omp_declare_target): Use OMP_CLAUSE_ENTER instead of OMP_CLAUSE_TO_DECLARE. * c-typeck.cc (c_finish_omp_clauses): Handle OMP_CLAUSE_ENTER instead of OMP_CLAUSE_TO_DECLARE, to OMP_CLAUSE_ENTER_TO use "to" as clause name in diagnostics instead of omp_clause_code_name[OMP_CLAUSE_CODE (c)]. gcc/cp/ * parser.cc (cp_parser_omp_clause_name): Parse enter clause. (cp_parser_omp_all_clauses): For to clause on declare target, use OMP_CLAUSE_ENTER clause with OMP_CLAUSE_ENTER_TO instead of OMP_CLAUSE_TO_DECLARE clause. Handle PRAGMA_OMP_CLAUSE_ENTER. (OMP_DECLARE_TARGET_CLAUSE_MASK): Add enter clause. (cp_parser_omp_declare_target): Use OMP_CLAUSE_ENTER instead of OMP_CLAUSE_TO_DECLARE. * semantics.cc (finish_omp_clauses): Handle OMP_CLAUSE_ENTER instead of OMP_CLAUSE_TO_DECLARE, to OMP_CLAUSE_ENTER_TO use "to" as clause name in diagnostics instead of omp_clause_code_name[OMP_CLAUSE_CODE (c)]. gcc/testsuite/ * c-c++-common/gomp/clauses-3.c: Add tests with enter clause instead of to or modify some existing to clauses to enter. * c-c++-common/gomp/declare-target-1.c: Likewise. * c-c++-common/gomp/declare-target-2.c: Likewise. * c-c++-common/gomp/declare-target-3.c: Likewise. * g++.dg/gomp/attrs-9.C: Likewise. * g++.dg/gomp/declare-target-1.C: Likewise. libgomp/ * testsuite/libgomp.c-c++-common/target-40.c: Modify some existing to clauses to enter. * testsuite/libgomp.c/target-41.c: Likewise.
2022-05-26Daily bump.GCC Administrator1-0/+12
2022-05-25c: Improve build_component_ref diagnostics [PR91134]Jakub Jelinek4-18/+40
On the following testcase (the first dg-error line) we emit a weird diagnostics and even fixit on pointerpointer->member where pointerpointer is pointer to pointer to struct and we say 'pointerpointer' is a pointer; did you mean to use '->'? The first part is indeed true, but suggesting -> when the code already does use -> is confusing. The following patch adjusts callers so that they tell it if it is from . parsing or from -> parsing and in the latter case suggests to dereference the left operand instead by adding (* before it and ) after it (before ->). Or would a suggestion to add [0] before -> be better? 2022-05-25 Jakub Jelinek <jakub@redhat.com> PR c/91134 gcc/c/ * c-tree.h (build_component_ref): Add ARROW_LOC location_t argument. * c-typeck.cc (build_component_ref): Likewise. If DATUM is INDIRECT_REF and ARROW_LOC isn't UNKNOWN_LOCATION, print a different diagnostic and fixit hint if DATUM has pointer type. * c-parser.cc (c_parser_postfix_expression, c_parser_omp_variable_list): Adjust build_component_ref callers. * gimple-parser.cc (c_parser_gimple_postfix_expression_after_primary): Likewise. gcc/objc/ * objc-act.cc (objc_build_component_ref): Adjust build_component_ref caller. gcc/testsuite/ * gcc.dg/pr91134.c: New test.
2022-05-25Daily bump.GCC Administrator1-0/+5
2022-05-24openmp: Add taskwait nowait depend support [PR105378]Jakub Jelinek1-1/+2
This patch adds support for (so far C/C++) #pragma omp taskwait nowait depend(...) directive, which is like #pragma omp task depend(...) ; but slightly optimized on the library side, so that it creates the task only for the purpose of dependency tracking and doesn't actually schedule it and wait for it when the dependencies are satisfied, instead makes its dependencies satisfied right away. 2022-05-24 Jakub Jelinek <jakub@redhat.com> PR c/105378 gcc/ * omp-builtins.def (BUILT_IN_GOMP_TASKWAIT_DEPEND_NOWAIT): New builtin. * gimplify.cc (gimplify_omp_task): Diagnose taskwait with nowait clause but no depend clauses. * omp-expand.cc (expand_taskwait_call): Use BUILT_IN_GOMP_TASKWAIT_DEPEND_NOWAIT rather than BUILT_IN_GOMP_TASKWAIT_DEPEND if nowait clause is present. gcc/c/ * c-parser.cc (OMP_TASKWAIT_CLAUSE_MASK): Add nowait clause. gcc/cp/ * parser.cc (OMP_TASKWAIT_CLAUSE_MASK): Add nowait clause. gcc/testsuite/ * c-c++-common/gomp/taskwait-depend-nowait-1.c: New test. libgomp/ * libgomp_g.h (GOMP_taskwait_depend_nowait): Declare. * libgomp.map (GOMP_taskwait_depend_nowait): Export at GOMP_5.1.1. * task.c (empty_task): New function. (gomp_task_run_post_handle_depend_hash): Declare earlier. (gomp_task_run_post_handle_depend): Declare. (GOMP_task): Optimize fn == empty_task if there is nothing to wait for. (gomp_task_run_post_handle_dependers): Optimize task->fn == empty_task. (GOMP_taskwait_depend_nowait): New function. * testsuite/libgomp.c-c++-common/taskwait-depend-nowait-1.c: New test.
2022-05-19Daily bump.GCC Administrator1-0/+8
2022-05-18c: Implement new -Wenum-int-mismatch warning [PR105131]Marek Polacek3-3/+13
In C, an enumerated type is compatible with char, a signed integer type, or an unsigned integer type (6.7.2.2/5). Therefore this code compiles: enum E { l = -1, z = 0, g = 1 }; int foo(void); enum E foo(void) { return z; } if the underlying type of 'enum E' is 'int' (if not, we emit an error). This is different for typedefs, where C11 permits typedefs to be redeclared to the same type, but not to compatible types. In C++, the code above is invalid. It seems desirable to emit a warning in the C case, because it is probably a mistake and definitely a portability error, given that the choice of the underlying type is implementation-defined. To that end, this patch implements a new -Wenum-int-mismatch warning. Conveniently, we already have comptypes_check_enum_int to detect such mismatches. This warning is enabled by either -Wall or -Wc++-compat. PR c/105131 gcc/c-family/ChangeLog: * c.opt (Wenum-int-mismatch): New. gcc/c/ChangeLog: * c-decl.cc (diagnose_mismatched_decls): Warn about enum/integer type mismatches. * c-tree.h (comptypes_check_enum_int): Declare. * c-typeck.cc (comptypes): No longer static. gcc/ChangeLog: * doc/invoke.texi: Document -Wenum-int-mismatch. gcc/testsuite/ChangeLog: * gcc.dg/Wenum-int-mismatch-1.c: New test. * gcc.dg/Wenum-int-mismatch-2.c: New test. * gcc.dg/Wenum-int-mismatch-3.c: New test. * gcc.dg/Wenum-int-mismatch-4.c: New test. * gcc.dg/Wenum-int-mismatch-5.c: New test.
2022-05-18Daily bump.GCC Administrator1-0/+11
2022-05-17c: use CONST_DECL for enumerators in TYPE_VALUESMarek Polacek1-1/+3
The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C FE has only the numerical value of the CONST_DECL there. This has caused me some trouble in my PR105497 patch. Using a CONST_DECL is preferable because a CONST_DECL can track more information (e.g., attributes), and you can always get the value simply by looking at its DECL_INITIAL. This turned out to be a trivial change. One place in godump.cc had to be adjusted. I'm not changing the CONST_DECL check in c_do_switch_warnings because I'll be changing it soon in my next patch. I didn't see any other checks that this patch makes redundant. gcc/c/ChangeLog: * c-decl.cc (finish_enum): Store the CONST_DECL into TREE_VALUE, not its value. gcc/ChangeLog: * godump.cc (go_output_typedef): Use the DECL_INITIAL of the TREE_VALUE.
2022-05-17openmp: Add support for inoutset depend-kindJakub Jelinek1-3/+7
This patch adds support for inoutset depend-kind in depend clauses. It is very similar to the in depend-kind in that a task with a dependency with that depend-kind is dependent on all previously created sibling tasks with matching address unless they have the same depend-kind. In the in depend-kind case everything is dependent except for in -> in dependency, for inoutset everything is dependent except for inoutset -> inoutset dependency. mutexinoutset is also similar (everything is dependent except for mutexinoutset -> mutexinoutset dependency), but there is also the additional restriction that only one task with mutexinoutset for each address can be scheduled at once (i.e. mutual exclusitivty). For now we support mutexinoutset the same as inout/out, but the inoutset support is full. In order not to bump the ABI for dependencies each time (we've bumped it already once, the old ABI supports only inout/out and in depend-kind, the new ABI supports inout/out, mutexinoutset, in and depobj), this patch arranges for inoutset to be at least for the time being always handled as if it was specified through depobj even when it is not. So it uses the new ABI for that and inoutset are represented like depobj - pointer to a pair of pointers where the first one will be the actual address of the object mentioned in depend clause and second pointer will be (void *) GOMP_DEPEND_INOUTSET. 2022-05-17 Jakub Jelinek <jakub@redhat.com> gcc/ * tree-core.h (enum omp_clause_depend_kind): Add OMP_CLAUSE_DEPEND_INOUTSET. * tree-pretty-print.cc (dump_omp_clause): Handle OMP_CLAUSE_DEPEND_INOUTSET. * gimplify.cc (gimplify_omp_depend): Likewise. * omp-low.cc (lower_depend_clauses): Likewise. gcc/c-family/ * c-omp.cc (c_finish_omp_depobj): Handle OMP_CLAUSE_DEPEND_INOUTSET. gcc/c/ * c-parser.cc (c_parser_omp_clause_depend): Parse inoutset depend-kind. (c_parser_omp_depobj): Likewise. gcc/cp/ * parser.cc (cp_parser_omp_clause_depend): Parse inoutset depend-kind. (cp_parser_omp_depobj): Likewise. * cxx-pretty-print.cc (cxx_pretty_printer::statement): Handle OMP_CLAUSE_DEPEND_INOUTSET. gcc/testsuite/ * c-c++-common/gomp/all-memory-1.c (boo): Add test with inoutset depend-kind. * c-c++-common/gomp/all-memory-2.c (boo): Likewise. * c-c++-common/gomp/depobj-1.c (f1): Likewise. (f2): Adjusted expected diagnostics. * g++.dg/gomp/depobj-1.C (f4): Adjust expected diagnostics. include/ * gomp-constants.h (GOMP_DEPEND_INOUTSET): Define. libgomp/ * libgomp.h (struct gomp_task_depend_entry): Change is_in type from bool to unsigned char. * task.c (gomp_task_handle_depend): Handle GOMP_DEPEND_INOUTSET. Ignore dependencies where task->depend[i].is_in && task->depend[i].is_in == ent->is_in rather than just task->depend[i].is_in && ent->is_in. Remember whether GOMP_DEPEND_IN loop is needed and guard the loop with that conditional. (gomp_task_maybe_wait_for_dependencies): Handle GOMP_DEPEND_INOUTSET. Ignore dependencies where elem.is_in && elem.is_in == ent->is_in rather than just elem.is_in && ent->is_in. * testsuite/libgomp.c-c++-common/depend-1.c (test): Add task with inoutset depend-kind. * testsuite/libgomp.c-c++-common/depend-2.c (test): Likewise. * testsuite/libgomp.c-c++-common/depend-3.c (test): Likewise. * testsuite/libgomp.c-c++-common/depend-inoutset-1.c: New test.
2022-05-17Daily bump.GCC Administrator1-0/+4
2022-05-16Use more ARRAY_SIZE.Martin Liska1-5/+3
gcc/ada/ChangeLog: * locales.c (iso_639_1_to_639_3): Use ARRAY_SIZE. (language_name_to_639_3): Likewise. (country_name_to_3166): Likewise. gcc/analyzer/ChangeLog: * engine.cc (exploded_node::get_dot_fillcolor): Use ARRAY_SIZE. * function-set.cc (test_stdio_example): Likewise. * sm-file.cc (get_file_using_fns): Likewise. * sm-malloc.cc (malloc_state_machine::unaffected_by_call_p): Likewise. * sm-signal.cc (get_async_signal_unsafe_fns): Likewise. gcc/ChangeLog: * attribs.cc (diag_attr_exclusions): Use ARRAY_SIZE. (decls_mismatched_attributes): Likewise. * builtins.cc (c_strlen): Likewise. * cfg.cc (DEF_BASIC_BLOCK_FLAG): Likewise. * common/config/aarch64/aarch64-common.cc (aarch64_option_init_struct): Likewise. * config/aarch64/aarch64-builtins.cc (aarch64_lookup_simd_builtin_type): Likewise. (aarch64_init_simd_builtin_types): Likewise. (aarch64_init_builtin_rsqrt): Likewise. * config/aarch64/aarch64.cc (is_madd_op): Likewise. * config/arm/arm-builtins.cc (arm_lookup_simd_builtin_type): Likewise. (arm_init_simd_builtin_types): Likewise. * config/avr/gen-avr-mmcu-texi.cc (mcus[ARRAY_SIZE): Likewise. (c_prefix): Likewise. (main): Likewise. * config/c6x/c6x.cc (N_SAVE_ORDER): Likewise. * config/darwin-c.cc (darwin_register_frameworks): Likewise. * config/gcn/mkoffload.cc (process_obj): Likewise. * config/i386/i386-builtins.cc (get_builtin_code_for_version): Likewise. (fold_builtin_cpu): Likewise. * config/m32c/m32c.cc (PUSHM_N): Likewise. * config/nvptx/mkoffload.cc (process): Likewise. * config/rs6000/driver-rs6000.cc (host_detect_local_cpu): Likewise. * config/s390/s390.cc (NR_C_MODES): Likewise. * config/tilepro/gen-mul-tables.cc (find_sequences): Likewise. (create_insn_code_compression_table): Likewise. * config/vms/vms.cc (NBR_CRTL_NAMES): Likewise. * diagnostic-format-json.cc (json_from_expanded_location): Likewise. * dwarf2out.cc (ARRAY_SIZE): Likewise. * genhooks.cc (emit_documentation): Likewise. (emit_init_macros): Likewise. * gimple-ssa-sprintf.cc (format_floating): Likewise. * gimple-ssa-warn-access.cc (memmodel_name): Likewise. * godump.cc (keyword_hash_init): Likewise. * hash-table.cc (hash_table_higher_prime_index): Likewise. * input.cc (for_each_line_table_case): Likewise. * ipa-free-lang-data.cc (free_lang_data): Likewise. * ipa-inline.cc (sanitize_attrs_match_for_inline_p): Likewise. * optc-save-gen.awk: Likewise. * spellcheck.cc (test_metric_conditions): Likewise. * tree-vect-slp-patterns.cc (sizeof): Likewise. (ARRAY_SIZE): Likewise. * tree.cc (build_common_tree_nodes): Likewise. gcc/c-family/ChangeLog: * c-common.cc (ARRAY_SIZE): Use ARRAY_SIZE. (c_common_nodes_and_builtins): Likewise. * c-format.cc (check_tokens): Likewise. (check_plain): Likewise. * c-pragma.cc (c_pp_lookup_pragma): Likewise. (init_pragma): Likewise. * known-headers.cc (get_string_macro_hint): Likewise. (get_stdlib_header_for_name): Likewise. * c-attribs.cc: Likewise. gcc/c/ChangeLog: * c-decl.cc (match_builtin_function_types): Use ARRAY_SIZE. gcc/cp/ChangeLog: * module.cc (depset::entity_kind_name): Use ARRAY_SIZE. * name-lookup.cc (get_std_name_hint): Likewise. * parser.cc (cp_parser_new): Likewise. gcc/fortran/ChangeLog: * frontend-passes.cc (gfc_code_walker): Use ARRAY_SIZE. * openmp.cc (gfc_match_omp_context_selector_specification): Likewise. * trans-intrinsic.cc (conv_intrinsic_ieee_builtin): Likewise. * trans-types.cc (gfc_get_array_descr_info): Likewise. gcc/jit/ChangeLog: * jit-builtins.cc (find_builtin_by_name): Use ARRAY_SIZE. (get_string_for_type_id): Likewise. * jit-recording.cc (recording::context::context): Likewise. gcc/lto/ChangeLog: * lto-common.cc (lto_resolution_read): Use ARRAY_SIZE. * lto-lang.cc (lto_init): Likewise.
2022-05-13Daily bump.GCC Administrator1-0/+12
2022-05-12openmp: Add omp_all_memory support (C/C++ only so far)Jakub Jelinek2-13/+60
The ugly part is that OpenMP 5.1 made omp_all_memory a reserved identifier which isn't allowed to be used anywhere but in the depend clause, this is against how everything else has been handled in OpenMP so far (where some identifiers could have special meaning in some OpenMP clauses or pragmas but not elsewhere). The patch handles it by making it a conditional keyword (for -fopenmp only) and emitting a better diagnostics when it is used in a primary expression. Having a nicer diagnostics when e.g. trying to do int omp_all_memory; or int *omp_all_memory[10]; etc. would mean changing too many spots and hooking into name lookups to reject declaring any such symbols would be too ugly and I'm afraid there are way too many spots where one can introduce a name (variables, functions, namespaces, struct, enum, enumerators, template arguments, ...). Otherwise, the handling is quite simple, normal depend clauses lower into addresses of variables being handed over to the library, for omp_all_memory I'm using NULL pointers. omp_all_memory can only be used with inout or out depend kinds and means that a task is dependent on all previously created sibling tasks that have any dependency (of any depend kind) and that any later created sibling tasks will be dependent on it if they have any dependency. 2022-05-12 Jakub Jelinek <jakub@redhat.com> gcc/ * gimplify.cc (gimplify_omp_depend): Don't build_fold_addr_expr if null_pointer_node. (gimplify_scan_omp_clauses): Likewise. * tree-pretty-print.cc (dump_omp_clause): Print null_pointer_node as omp_all_memory. gcc/c-family/ * c-common.h (enum rid): Add RID_OMP_ALL_MEMORY. * c-omp.cc (c_finish_omp_depobj): Don't build_fold_addr_expr if null_pointer_node. gcc/c/ * c-parser.cc (c_parse_init): Register omp_all_memory as keyword if flag_openmp. (c_parser_postfix_expression): Diagnose uses of omp_all_memory in postfix expressions. (c_parser_omp_variable_list): Handle omp_all_memory in depend clause. * c-typeck.cc (c_finish_omp_clauses): Handle omp_all_memory keyword in depend clause as null_pointer_node, diagnose invalid uses. gcc/cp/ * lex.cc (init_reswords): Register omp_all_memory as keyword if flag_openmp. * parser.cc (cp_parser_primary_expression): Diagnose uses of omp_all_memory in postfix expressions. (cp_parser_omp_var_list_no_open): Handle omp_all_memory in depend clause. * semantics.cc (finish_omp_clauses): Handle omp_all_memory keyword in depend clause as null_pointer_node, diagnose invalid uses. * pt.cc (tsubst_omp_clause_decl): Pass through omp_all_memory. gcc/testsuite/ * c-c++-common/gomp/all-memory-1.c: New test. * c-c++-common/gomp/all-memory-2.c: New test. * c-c++-common/gomp/all-memory-3.c: New test. * g++.dg/gomp/all-memory-1.C: New test. * g++.dg/gomp/all-memory-2.C: New test. libgomp/ * libgomp.h (struct gomp_task): Add depend_all_memory member. * task.c (gomp_init_task): Initialize depend_all_memory. (gomp_task_handle_depend): Handle omp_all_memory. (gomp_task_run_post_handle_depend_hash): Clear parent->depend_all_memory if equal to current task. (gomp_task_maybe_wait_for_dependencies): Handle omp_all_memory. * testsuite/libgomp.c-c++-common/depend-1.c: New test. * testsuite/libgomp.c-c++-common/depend-2.c: New test. * testsuite/libgomp.c-c++-common/depend-3.c: New test.
2022-05-10Daily bump.GCC Administrator1-0/+6
2022-05-09Come up with {,UN}LIKELY macros.Martin Liska1-2/+2
gcc/c/ChangeLog: * c-parser.cc (c_parser_conditional_expression): Use {,UN}LIKELY macros. (c_parser_binary_expression): Likewise. gcc/cp/ChangeLog: * cp-gimplify.cc (cp_genericize_r): Use {,UN}LIKELY macros. * parser.cc (cp_finalize_omp_declare_simd): Likewise. (cp_finalize_oacc_routine): Likewise. gcc/ChangeLog: * system.h (LIKELY): Define. (UNLIKELY): Likewise. * domwalk.cc (sort_bbs_postorder): Use {,UN}LIKELY macros. * dse.cc (set_position_unneeded): Likewise. (set_all_positions_unneeded): Likewise. (any_positions_needed_p): Likewise. (all_positions_needed_p): Likewise. * expmed.cc (flip_storage_order): Likewise. * genmatch.cc (dt_simplify::gen_1): Likewise. * ggc-common.cc (gt_pch_save): Likewise. * print-rtl.cc: Likewise. * rtl-iter.h (T>::array_type::~array_type): Likewise. (T>::next): Likewise. * rtl-ssa/internals.inl: Likewise. * rtl-ssa/member-fns.inl: Likewise. * rtlanal.cc (T>::add_subrtxes_to_queue): Likewise. (rtx_properties::try_to_add_dest): Likewise. * rtlanal.h (growing_rtx_properties::repeat): Likewise. (vec_rtx_properties_base::~vec_rtx_properties_base): Likewise. * simplify-rtx.cc (simplify_replace_fn_rtx): Likewise. * sort.cc (likely): Likewise. (mergesort): Likewise. * wide-int.h (wi::eq_p): Likewise. (wi::ltu_p): Likewise. (wi::cmpu): Likewise. (wi::bit_and): Likewise. (wi::bit_and_not): Likewise. (wi::bit_or): Likewise. (wi::bit_or_not): Likewise. (wi::bit_xor): Likewise. (wi::add): Likewise. (wi::sub): Likewise.
2022-05-08Daily bump.GCC Administrator1-0/+6
2022-05-07c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]Marek Polacek1-0/+9
Attribute format takes three arguments: archetype, string-index, and first-to-check. The last two specify the position in the function parameter list. r63030 clarified that "Since non-static C++ methods have an implicit this argument, the arguments of such methods should be counted from two, not one, when giving values for string-index and first-to-check." Therefore one has to write struct D { D(const char *, ...) __attribute__((format(printf, 2, 3))); }; However -- and this is the problem in this PR -- ctors with virtual bases also get two additional parameters: the in-charge parameter and the VTT parameter (added in maybe_retrofit_in_chrg). In fact we'll end up with two clones of the ctor: an in-charge and a not-in-charge version (see build_cdtor_clones). That means that the argument position the user specified in the attribute argument will refer to different arguments, depending on which constructor we're currently dealing with. This can cause a range of problems: wrong errors, confusing warnings, or crashes. This patch corrects that; for C we don't have to do anything, and in C++ we can use num_artificial_parms_for. It would be wrong to rewrite the attributes the user supplied, so I've changed POS to be passed by reference so that we don't have to change all the call sites of positional_argument and we still get the default_conversion adjustment. Attribute format_arg is not affected, because it requires that the function returns "const char *" which will never be the case for cdtors. PR c++/101833 PR c++/47634 gcc/c-family/ChangeLog: * c-attribs.cc (positional_argument): Pass POS by reference. Deal with FN being either a function declaration or function type. Use maybe_adjust_arg_pos_for_attribute. * c-common.cc (check_function_arguments): Maybe pass FNDECL down to check_function_format. * c-common.h (maybe_adjust_arg_pos_for_attribute): Declare. (positional_argument): Adjust. * c-format.cc (get_constant): Rename to ... (validate_constant): ... this. Take EXPR by reference. Return bool instead of tree. (handle_format_arg_attribute): Don't overwrite FORMAT_NUM_EXPR by the return value of validate_constant. (decode_format_attr): Don't overwrite FORMAT_NUM_EXPR and FIRST_ARG_NUM_EXPR by the return value of validate_constant. (check_function_format): Adjust a parameter name. (handle_format_attribute): Maybe pass FNDECL down to decode_format_attr. gcc/c/ChangeLog: * c-objc-common.cc (maybe_adjust_arg_pos_for_attribute): New. gcc/cp/ChangeLog: * tree.cc (maybe_adjust_arg_pos_for_attribute): New. gcc/ChangeLog: * tree-core.h (struct attribute_spec): Update comment for HANDLER. gcc/testsuite/ChangeLog: * g++.dg/ext/attr-format-arg1.C: New test. * g++.dg/ext/attr-format1.C: New test. * g++.dg/ext/attr-format2.C: New test. * g++.dg/ext/attr-format3.C: New test.
2022-04-09Daily bump.GCC Administrator1-0/+5
2022-04-08c: Error on va_arg with function type [PR105149]Jakub Jelinek1-0/+6
In the PR Joseph said that the C standard for va_arg talks about pointers to object type and as a function type is not object type, it is invalid. The following patch diagnoses it in the FE, instead of ICEing later on when optimizations are turned on (and with -O0 doing something weird at runtime). 2022-04-08 Jakub Jelinek <jakub@redhat.com> PR c/105149 * c-typeck.cc (c_build_va_arg): Reject function types. * gcc.dg/pr105149.c: New test.
2022-03-23Daily bump.GCC Administrator1-0/+10
2022-03-22c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]Marek Polacek1-4/+6
This patch fixes two kinds of wrong -Wmissing-field-initializers warnings. Our docs say that this warning "does not warn about designated initializers", but we give a warning for 1) the array case: struct S { struct N { int a; int b; } c[1]; } d = { .c[0].a = 1, .c[0].b = 1, // missing initializer for field 'b' of 'struct N' }; we warn because push_init_level, when constructing an array, clears constructor_designated (which the warning relies on), and we forget that we were in a designated initializer context. Fixed by the push_init_level hunk; and 2) the compound literal case: struct T { int a; int *b; int c; }; struct T t = { .b = (int[]){1} }; // missing initializer for field 'c' of 'struct T' where set_designator properly sets constructor_designated to 1, but the compound literal causes us to create a whole new initializer_stack in start_init, which clears constructor_designated. Then, after we've parsed the compound literal, finish_init flushes the initializer_stack entry, but doesn't restore constructor_designated, so we forget we were in a designated initializer context, which causes the bogus warning. (The designated flag is also tracked in constructor_stack, but in this case, we didn't perform push_init_level between set_designator and start_init so it wasn't saved anywhere.) PR c/82283 PR c/84685 gcc/c/ChangeLog: * c-typeck.cc (struct initializer_stack): Add 'designated' member. (start_init): Set it. (finish_init): Restore constructor_designated. (push_init_level): Set constructor_designated to the value of constructor_designated in the upper constructor_stack. gcc/testsuite/ChangeLog: * gcc.dg/Wmissing-field-initializers-1.c: New test. * gcc.dg/Wmissing-field-initializers-2.c: New test. * gcc.dg/Wmissing-field-initializers-3.c: New test. * gcc.dg/Wmissing-field-initializers-4.c: New test. * gcc.dg/Wmissing-field-initializers-5.c: New test.
2022-03-13Daily bump.GCC Administrator1-0/+7
2022-03-12Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]Thomas Schwinge1-2/+2
Re PR65095 "Adapt OpenMP diagnostic messages for OpenACC", move C/C++ front end 'gcc/c-family/c-omp.cc:c_omp_map_clause_name' to generic 'gcc/tree.cc:user_omp_clause_code_name' . No functional change. PR other/65095 gcc/ * tree-core.h (user_omp_claus_code_name): Declare function. * tree.cc (user_omp_clause_code_name): New function. gcc/c/ * c-typeck.cc (handle_omp_array_sections_1) (c_oacc_check_attachments): Call 'user_omp_clause_code_name' instead of 'c_omp_map_clause_name'. gcc/cp/ * semantics.cc (handle_omp_array_sections_1) (cp_oacc_check_attachments): Call 'user_omp_clause_code_name' instead of 'c_omp_map_clause_name'. gcc/c-family/ * c-common.h (c_omp_map_clause_name): Remove. * c-omp.cc (c_omp_map_clause_name): Remove.
2022-03-10Daily bump.GCC Administrator1-0/+13
2022-03-09c: Revert C2x changes to function type compatibilityJoseph Myers1-2/+2
In commit cc806126215c3f4dc187eff3bf923458d8cc6b4f, I implemented changes that C2x had made to compatibility of unprototyped and prototyped function types. C2x has since completely removed unprototyped function types, making () in a function declaration mean (void) as in C++. While that change isn't appropriate at the current development stage for GCC 12, it does mean that it doesn't make sense for GCC 12 to have different rules for unprototyped functions in C2x mode than in other modes or previous and subsequent GCC versions. Thus, revert the previous change to avoid it getting into a GCC release, and update the corresponding tests to expect the same behavior with -std=c2x as with -std=c11 (they will of course need to change again after implementing () as meaning (void)). Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-typeck.cc (function_types_compatible_p): Do not handle C2X differently from earlier standards for unprototyped function type compatibility. gcc/testsuite/ * gcc.dg/c11-unproto-1.c, gcc.dg/c11-unproto-2.c: Update comments. * gcc.dg/c2x-unproto-1.c, gcc.dg/c2x-unproto-2.c: Expect same results as in C11 mode. Update comments.
2022-03-09c, c++, c-family: -Wshift-negative-value and -Wshift-overflow* tweaks for ↵Jakub Jelinek2-1/+3
-fwrapv and C++20+ [PR104711] As mentioned in the PR, different standards have different definition on what is an UB left shift. They all agree on out of bounds (including negative) shift count. The rules used by ubsan are: C99-C2x ((unsigned) x >> (uprecm1 - y)) != 0 then UB C++11-C++17 x < 0 || ((unsigned) x >> (uprecm1 - y)) > 1 then UB C++20 and later everything is well defined Now, for C++20, I've in the P1236R1 implementation added an early exit for -Wshift-overflow* warning so that it never warns, but apparently -Wshift-negative-value remained as is. As it is well defined in C++20, the following patch doesn't enable -Wshift-negative-value from -Wextra anymore for C++20 and later, if users want for compatibility with C++17 and earlier get the warning, they still can by using -Wshift-negative-value explicitly. Another thing is -fwrapv, that is an extension to the standards, so it is up to us how exactly we define that case. Our ubsan code treats TYPE_OVERFLOW_WRAPS (type0) and cxx_dialect >= cxx20 the same as only diagnosing out of bounds shift count and nothing else and IMHO it is most sensical to treat -fwrapv signed left shifts the same as C++20 treats them, https://eel.is/c++draft/expr.shift#2 "The value of E1 << E2 is the unique value congruent to E1×2^E2 modulo 2^N, where N is the width of the type of the result. [Note 1: E1 is left-shifted E2 bit positions; vacated bits are zero-filled. — end note]" with no UB dependent on the E1 values. The UB is only "The behavior is undefined if the right operand is negative, or greater than or equal to the width of the promoted left operand." Under the hood (except for FEs and ubsan from FEs) GCC middle-end doesn't consider UB in left shifts dependent on the first operand's value, only the out of bounds shifts. While this change isn't a regression, I'd think it is useful for GCC 12, it doesn't add new warnings, but just removes warnings that aren't appropriate. 2022-03-09 Jakub Jelinek <jakub@redhat.com> PR c/104711 gcc/ * doc/invoke.texi (-Wextra): Document that -Wshift-negative-value is enabled by it only for C++11 to C++17 rather than for C++03 or later. (-Wshift-negative-value): Similarly (except here we stated that it is enabled for C++11 or later). gcc/c-family/ * c-opts.cc (c_common_post_options): Don't enable -Wshift-negative-value from -Wextra for C++20 or later. * c-ubsan.cc (ubsan_instrument_shift): Adjust comments. * c-warn.cc (maybe_warn_shift_overflow): Use TYPE_OVERFLOW_WRAPS instead of TYPE_UNSIGNED. gcc/c/ * c-fold.cc (c_fully_fold_internal): Don't emit -Wshift-negative-value warning if TYPE_OVERFLOW_WRAPS. * c-typeck.cc (build_binary_op): Likewise. gcc/cp/ * constexpr.cc (cxx_eval_check_shift_p): Use TYPE_OVERFLOW_WRAPS instead of TYPE_UNSIGNED. * typeck.cc (cp_build_binary_op): Don't emit -Wshift-negative-value warning if TYPE_OVERFLOW_WRAPS. gcc/testsuite/ * c-c++-common/Wshift-negative-value-1.c: Remove dg-additional-options, instead in target selectors of each diagnostic check for exact C++ versions where it should be diagnosed. * c-c++-common/Wshift-negative-value-2.c: Likewise. * c-c++-common/Wshift-negative-value-3.c: Likewise. * c-c++-common/Wshift-negative-value-4.c: Likewise. * c-c++-common/Wshift-negative-value-7.c: New test. * c-c++-common/Wshift-negative-value-8.c: New test. * c-c++-common/Wshift-negative-value-9.c: New test. * c-c++-common/Wshift-negative-value-10.c: New test. * c-c++-common/Wshift-overflow-1.c: Remove dg-additional-options, instead in target selectors of each diagnostic check for exact C++ versions where it should be diagnosed. * c-c++-common/Wshift-overflow-2.c: Likewise. * c-c++-common/Wshift-overflow-5.c: Likewise. * c-c++-common/Wshift-overflow-6.c: Likewise. * c-c++-common/Wshift-overflow-7.c: Likewise. * c-c++-common/Wshift-overflow-8.c: New test. * c-c++-common/Wshift-overflow-9.c: New test. * c-c++-common/Wshift-overflow-10.c: New test. * c-c++-common/Wshift-overflow-11.c: New test. * c-c++-common/Wshift-overflow-12.c: New test.
2022-03-08Daily bump.GCC Administrator1-0/+5
2022-03-07Add missing space in various string literalsJakub Jelinek1-2/+2
After more than 2 years I've run my https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00844.html script again. While it has lots of false positives, it discovered two bugs. 2022-03-07 Jakub Jelinek <jakub@redhat.com> gcc/c/ * c-parser.cc (c_parser_omp_clause_map): Add missing space in string literal. gcc/cp/ * parser.cc (cp_parser_omp_clause_map): Add missing space in string literal.
2022-02-24Daily bump.GCC Administrator1-0/+6
2022-02-23Support SSA name declarations with pointer typeRichard Biener1-6/+28
Currently we fail to parse int * _3; as SSA name and instead get a VAR_DECL because of the way the C frontends declarator specs work. That causes havoc if those supposed SSA names are used in PHIs or in other places where VAR_DECLs are not allowed. The following fixes the pointer case in an ad-hoc way - for more complex type declarators we probably have to find a way to re-use the C frontend grokdeclarator without actually creating a VAR_DECL there (or maybe make it create an SSA name). Pointers appear too often to be neglected though, thus the following ad-hoc fix for this. This also adds verification that we do not end up with SSA names without definitions as can happen when reducing a GIMPLE testcase. Instead of working through segfaults one-by-one we emit errors for all of those at once now. 2022-02-23 Richard Biener <rguenther@suse.de> gcc/c * gimple-parser.cc (c_parser_parse_gimple_body): Diagnose SSA names without definition. (c_parser_gimple_declaration): Handle pointer typed SSA names. gcc/testsuite/ * gcc.dg/gimplefe-49.c: New testcase. * gcc.dg/gimplefe-error-13.c: Likewise.
2022-02-18Daily bump.GCC Administrator1-0/+7