aboutsummaryrefslogtreecommitdiff
path: root/gcc/c
AgeCommit message (Collapse)AuthorFilesLines
2022-09-16Daily bump.GCC Administrator1-0/+4
2022-09-15Move void_list_node init to common codeRichard Biener1-8/+0
All frontends replicate this, so move it. gcc/ * tree.cc (build_common_tree_nodes): Initialize void_list_node here. gcc/ada/ * gcc-interface/trans.cc (gigi): Do not initialize void_list_node. gcc/c-family/ * c-common.h (build_void_list_node): Remove. * c-common.cc (c_common_nodes_and_builtins): Do not initialize void_list_node. gcc/c/ * c-decl.cc (build_void_list_node): Remove. gcc/cp/ * decl.cc (cxx_init_decl_processing): Inline last build_void_list_node call. (build_void_list_node): Remove. gcc/d/ * d-builtins.cc (d_build_c_type_nodes): Do not initialize void_list_node. gcc/fortran/ * f95-lang.cc (gfc_init_decl_processing): Do not initialize void_list_node. gcc/go/ * go-lang.cc (go_langhook_init): Do not initialize void_list_node. gcc/jit/ * dummy-frontend.cc (jit_langhook_init): Do not initialize void_list_node. gcc/lto/ * lto-lang.cc (lto_build_c_type_nodes): Do not initialize void_list_node.
2022-09-15Daily bump.GCC Administrator1-0/+5
2022-09-14OpenMP/OpenACC: mapping group list-handling improvementsJulian Brown1-1/+23
This patch adjusts OpenMP/OpenACC clause list handling in a couple of places, in preparation for the following mapping-clause expansion rework patch. Firstly mapping groups are removed as a whole in the C and C++ front-ends when an error is detected, which avoids leaving "badly-formed" mapping clause groups in the list. Secondly, reindexing of the omp_mapping_group hashmap (during omp_build_struct_sibling_lists) has been reimplemented, fixing some tricky corner-cases where mapping groups are removed from a list at the same time as it is being reordered. Thirdly, code to check if a different clause on the same directive maps the whole of a struct that we have a component mapping for (for example) has been outlined, removing a bit of code duplication. 2022-09-13 Julian Brown <julian@codesourcery.com> gcc/ * gimplify.cc (omp_group_last): Allow GOMP_MAP_ATTACH_DETACH after GOMP_MAP_STRUCT (for reindexing). (omp_gather_mapping_groups): Reimplement using... (omp_gather_mapping_groups_1): This new function. Stop processing at GATHER_SENTINEL. (omp_group_base): Allow GOMP_MAP_TO_PSET without any following node. (omp_index_mapping_groups): Reimplement using... (omp_index_mapping_groups_1): This new function. Handle REINDEX_SENTINEL. (omp_reindex_mapping_groups, omp_mapped_by_containing_struct): New functions. (omp_tsort_mapping_groups_1): Adjust handling of base group being the same as current group. Use omp_mapped_by_containing_struct. (omp_build_struct_sibling_lists): Use omp_mapped_by_containing_struct and omp_reindex_mapping_groups. Robustify group deletion for reordered lists. (gimplify_scan_omp_clauses): Update calls to omp_build_struct_sibling_lists. gcc/c/ * c-typeck.cc (c_finish_omp_clauses): Remove whole mapping node group on error. gcc/cp/ * semantics.cc (finish_omp_clauses): Likewise.
2022-09-08Daily bump.GCC Administrator1-0/+7
2022-09-07c: New C2x keywordsJoseph Myers1-8/+22
C2x follows C++ in making alignas, alignof, bool, false, static_assert, thread_local and true keywords; implement this accordingly. This implementation makes them normal keywords in C2x mode just like any other keyword (C2x leaves open the possibility of implementation using predefined macros instead - thus, there aren't any testcases asserting that they aren't macros). As in C++ and previous versions of C, true and false are handled like signed 1 and 0 in #if (there was an intermediate state in some C2x drafts where they had different macro expansions that were unsigned in #if). Bootstrapped with no regressions for x86_64-pc-linux-gnu. As with the removal of unprototyped functions, this change has a high risk of breaking some old code and people doing GNU/Linux distribution builds may wish to see how much is broken in a build with a -std=gnu2x default. gcc/ * ginclude/stdalign.h [defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L]: Disable all content. * ginclude/stdbool.h [defined __STDC_VERSION__ && __STDC_VERSION__ > 201710L] (bool, true, false): Do not define. gcc/c-family/ * c-common.cc (c_common_reswords): Use D_C2X instead of D_CXXONLY for alignas, alignof, bool, false, static_assert, thread_local and true. gcc/c/ * c-parser.cc (c_parser_static_assert_declaration_no_semi) (c_parser_alignas_specifier, c_parser_alignof_expression): Allow for C2x spellings of keywords. (c_parser_postfix_expression): Handle RID_TRUE and RID_FALSE. gcc/testsuite/ * gcc.dg/c11-keywords-1.c, gcc.dg/c2x-align-1.c, gcc.dg/c2x-align-6.c, gcc.dg/c2x-bool-2.c, gcc.dg/c2x-static-assert-3.c, gcc.dg/c2x-static-assert-4.c, gcc.dg/c2x-thread-local-1.c: New tests. * gcc.dg/c2x-bool-1.c: Update expectations. libcpp/ * include/cpplib.h (struct cpp_options): Add true_false. * expr.cc (eval_token): Check true_false not cplusplus to determine whether to handle true and false keywords. * init.cc (struct lang_flags): Add true_false. (lang_defaults): Update. (cpp_set_lang): Set true_false.
2022-09-07Daily bump.GCC Administrator1-0/+5
2022-09-06openmp: Be consistent on parsing offsets between normal sink vector and ↵Jakub Jelinek1-2/+1
omp_cur_iteration - 1 For normal sink vectors, we just check that the token is CPP_NUMBER and with INTEGER_CST value, while for omp_cur_iteration I was additionally requiring integer_type_node type (so only 1, 001, 0x0001 but not 1L or 1ULL etc.). I think we need to clarify what we actually should allow in the standard, until then it is better to be consistent. 2022-09-06 Jakub Jelinek <jakub@redhat.com> gcc/c/ * c-parser.cc (c_parser_omp_clause_doacross_sink): Don't verify val in omp_cur_iteration - 1 has integer_type_node type. gcc/cp/ * parser.cc (cp_parser_omp_clause_doacross_sink): Don't verify val in omp_cur_iteration - 1 has integer_type_node type. gcc/testsuite/ * c-c++-common/gomp/doacross-6.c (corge): Don't expect an error here. Add a few further tests.
2022-09-04Daily bump.GCC Administrator1-0/+27
2022-09-03openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration supportJakub Jelinek2-52/+125
The following patch implements part of the OpenMP 5.2 changes related to ordered loops and with the assumed resolution of https://github.com/OpenMP/spec/issues/3302 issues. The changes are: 1) the depend clause on stand-alone ordered constructs has been renamed to doacross (because depend clause has different syntax on other constructs) with some syntax changes below, depend clause is deprecated (we'll deprecate stuff on the GCC side only when we have everything else from 5.2 implemented) depend(source) -> doacross(source:) or doacross(source:omp_cur_iteration) depend(sink:vec) -> doacross(sink:vec) (where vec has the same syntax as before) 2) in 5.1 and before it has been significant whether ordered clause has or doesn't have an argument, if it didn't, only block-associated ordered could appear in the body, if it did, only stand-alone ordered could appear in the body, all loops had to be perfectly nested, no associated range-based for loops, no linear clause on work-sharing loop and ordered clause with an argument wasn't allowed on composite for simd. In 5.2, whether ordered clause has or doesn't have an argument is insignificant (except for bugs in the standard, #3302 mentions those), if the argument is missing, it is simply treated as equal to collapse argument (if any, otherwise 1). The implementation better should be able to differentiate between ordered and doacross loops at compile time which previously was through the absence or presence of the argument, now it is done through looking at the body of the construct lexically and looking for stand-alone ordered constructs. If there are any, it is to be handled as doacross loop, otherwise it is ordered loop (but in that case ordered argument if present must be equal to collapse argument - 5.2 says instead it must be one, but that is clearly wrong and mentioned in #3302) - stand-alone ordered constructs must appear lexically in the body (and had to before as well). For the restrictions mentioned above, the for simd restriction is gone (stand-alone ordered can't appear in simd construct, so that is enough), and the other rules are expected to be changed into something related to presence of stand-alone ordered constructs in the body 3) 5.2 allows a new syntax, doacross(sink:omp_cur_iteration-1), which means wait for previous iteration in the iteration space of all the associated loops The following patch implements that, except that we sorry for now on the doacross(sink:omp_cur_iteration-1) syntax during omp expansion because library side isn't done yet for it. It doesn't implement it for the Fortran FE either. Incrementally, I'd like to change the way we differentiate between stand-alone and block-associated ordered constructs, because the current way of looking for presence of doacross clause doesn't work well if those clauses are removed because they had been invalid (wrong syntax or unknown variables in it etc.) and of course implement doacross(sink:omp_cur_iteration-1). 2022-09-03 Jakub Jelinek <jakub@redhat.com> gcc/ * tree-core.h (enum omp_clause_code): Add OMP_CLAUSE_DOACROSS. (enum omp_clause_depend_kind): Remove OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK, add OMP_CLAUSE_DEPEND_INVALID. (enum omp_clause_doacross_kind): New type. (struct tree_omp_clause): Add subcode.doacross_kind member. * tree.h (OMP_CLAUSE_DEPEND_SINK_NEGATIVE): Remove. (OMP_CLAUSE_DOACROSS_KIND): Define. (OMP_CLAUSE_DOACROSS_SINK_NEGATIVE): Define. (OMP_CLAUSE_DOACROSS_DEPEND): Define. (OMP_CLAUSE_ORDERED_DOACROSS): Define. * tree.cc (omp_clause_num_ops, omp_clause_code_name): Add OMP_CLAUSE_DOACROSS entries. * tree-nested.cc (convert_nonlocal_omp_clauses, convert_local_omp_clauses): Handle OMP_CLAUSE_DOACROSS. * tree-pretty-print.cc (dump_omp_clause): Don't handle OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK. Handle OMP_CLAUSE_DOACROSS. * gimplify.cc (gimplify_omp_depend): Don't handle OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK. (gimplify_scan_omp_clauses): Likewise. Handle OMP_CLAUSE_DOACROSS. (gimplify_adjust_omp_clauses): Handle OMP_CLAUSE_DOACROSS. (find_standalone_omp_ordered): New function. (gimplify_omp_for): When OMP_CLAUSE_ORDERED is present, search body for OMP_ORDERED with OMP_CLAUSE_DOACROSS and if found, set OMP_CLAUSE_ORDERED_DOACROSS. (gimplify_omp_ordered): Don't handle OMP_CLAUSE_DEPEND_SINK or OMP_CLAUSE_DEPEND_SOURCE, instead check OMP_CLAUSE_DOACROSS, adjust diagnostics that presence or absence of ordered clause parameter is irrelevant. Handle doacross(sink:omp_cur_iteration-1). Use actual user name of the clause - doacross or depend - in diagnostics. * omp-general.cc (omp_extract_for_data): Don't set fd->ordered if !OMP_CLAUSE_ORDERED_DOACROSS (t). If OMP_CLAUSE_ORDERED_DOACROSS (t) but !OMP_CLAUSE_ORDERED_EXPR (t), set fd->ordered to -1 and set it after the loop in that case to fd->collapse. * omp-low.cc (check_omp_nesting_restrictions): Don't handle OMP_CLAUSE_DEPEND_SOURCE nor OMP_CLAUSE_DEPEND_SINK, instead check OMP_CLAUSE_DOACROSS. Use actual user name of the clause - doacross or depend - in diagnostics. Diagnose mixing of stand-alone and block associated ordered constructs binding to the same loop. (lower_omp_ordered_clauses): Don't handle OMP_CLAUSE_DEPEND_SINK, instead handle OMP_CLAUSE_DOACROSS. (lower_omp_ordered): Look for OMP_CLAUSE_DOACROSS instead of OMP_CLAUSE_DEPEND. (lower_depend_clauses): Don't handle OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK. * omp-expand.cc (expand_omp_ordered_sink): Emit a sorry for doacross(sink:omp_cur_iteration-1). (expand_omp_ordered_source_sink): Use OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of OMP_CLAUSE_DEPEND_SINK_NEGATIVE. Use actual user name of the clause - doacross or depend - in diagnostics. (expand_omp): Look for OMP_CLAUSE_DOACROSS clause instead of OMP_CLAUSE_DEPEND. (build_omp_regions_1): Likewise. (omp_make_gimple_edges): Likewise. * lto-streamer-out.cc (hash_tree): Handle OMP_CLAUSE_DOACROSS. * tree-streamer-in.cc (unpack_ts_omp_clause_value_fields): Likewise. * tree-streamer-out.cc (pack_ts_omp_clause_value_fields): Likewise. gcc/c-family/ * c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_DOACROSS. * c-omp.cc (c_finish_omp_depobj): Check also for OMP_CLAUSE_DOACROSS clause and diagnose it. Don't handle OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK. Assert kind is not OMP_CLAUSE_DEPEND_INVALID. gcc/c/ * c-parser.cc (c_parser_omp_clause_name): Handle doacross. (c_parser_omp_clause_depend_sink): Renamed to ... (c_parser_omp_clause_doacross_sink): ... this. Add depend_p argument. Handle parsing of doacross(sink:omp_cur_iteration-1). Use OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of OMP_CLAUSE_DEPEND_SINK_NEGATIVE, build OMP_CLAUSE_DOACROSS instead of OMP_CLAUSE_DEPEND and set OMP_CLAUSE_DOACROSS_DEPEND flag on it. (c_parser_omp_clause_depend): Use OMP_CLAUSE_DOACROSS_SINK and OMP_CLAUSE_DOACROSS_SOURCE instead of OMP_CLAUSE_DEPEND_SINK and OMP_CLAUSE_DEPEND_SOURCE, build OMP_CLAUSE_DOACROSS for depend(source) and set OMP_CLAUSE_DOACROSS_DEPEND on it. (c_parser_omp_clause_doacross): New function. (c_parser_omp_all_clauses): Handle PRAGMA_OMP_CLAUSE_DOACROSS. (c_parser_omp_depobj): Use OMP_CLAUSE_DEPEND_INVALID instead of OMP_CLAUSE_DEPEND_SOURCE. (c_parser_omp_for_loop): Don't diagnose here linear clause together with ordered with argument. (c_parser_omp_simd): Don't diagnose ordered clause with argument on for simd. (OMP_ORDERED_DEPEND_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_DOACROSS. (c_parser_omp_ordered): Handle also doacross and adjust for it diagnostic wording. * c-typeck.cc (c_finish_omp_clauses): Handle OMP_CLAUSE_DOACROSS. Don't handle OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK. gcc/cp/ * parser.cc (cp_parser_omp_clause_name): Handle doacross. (cp_parser_omp_clause_depend_sink): Renamed to ... (cp_parser_omp_clause_doacross_sink): ... this. Add depend_p argument. Handle parsing of doacross(sink:omp_cur_iteration-1). Use OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of OMP_CLAUSE_DEPEND_SINK_NEGATIVE, build OMP_CLAUSE_DOACROSS instead of OMP_CLAUSE_DEPEND and set OMP_CLAUSE_DOACROSS_DEPEND flag on it. (cp_parser_omp_clause_depend): Use OMP_CLAUSE_DOACROSS_SINK and OMP_CLAUSE_DOACROSS_SOURCE instead of OMP_CLAUSE_DEPEND_SINK and OMP_CLAUSE_DEPEND_SOURCE, build OMP_CLAUSE_DOACROSS for depend(source) and set OMP_CLAUSE_DOACROSS_DEPEND on it. (cp_parser_omp_clause_doacross): New function. (cp_parser_omp_all_clauses): Handle PRAGMA_OMP_CLAUSE_DOACROSS. (cp_parser_omp_depobj): Use OMP_CLAUSE_DEPEND_INVALID instead of OMP_CLAUSE_DEPEND_SOURCE. (cp_parser_omp_for_loop): Don't diagnose here linear clause together with ordered with argument. (cp_parser_omp_simd): Don't diagnose ordered clause with argument on for simd. (OMP_ORDERED_DEPEND_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_DOACROSS. (cp_parser_omp_ordered): Handle also doacross and adjust for it diagnostic wording. * pt.cc (tsubst_omp_clause_decl): Use OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of OMP_CLAUSE_DEPEND_SINK_NEGATIVE. (tsubst_omp_clauses): Handle OMP_CLAUSE_DOACROSS. (tsubst_expr): Use OMP_CLAUSE_DEPEND_INVALID instead of OMP_CLAUSE_DEPEND_SOURCE. * semantics.cc (cp_finish_omp_clause_depend_sink): Rename to ... (cp_finish_omp_clause_doacross_sink): ... this. (finish_omp_clauses): Handle OMP_CLAUSE_DOACROSS. Don't handle OMP_CLAUSE_DEPEND_SOURCE and OMP_CLAUSE_DEPEND_SINK. gcc/fortran/ * trans-openmp.cc (gfc_trans_omp_clauses): Use OMP_CLAUSE_DOACROSS_SINK_NEGATIVE instead of OMP_CLAUSE_DEPEND_SINK_NEGATIVE, build OMP_CLAUSE_DOACROSS clause instead of OMP_CLAUSE_DEPEND and set OMP_CLAUSE_DOACROSS_DEPEND on it. gcc/testsuite/ * c-c++-common/gomp/doacross-2.c: Adjust expected diagnostics. * c-c++-common/gomp/doacross-5.c: New test. * c-c++-common/gomp/doacross-6.c: New test. * c-c++-common/gomp/nesting-2.c: Adjust expected diagnostics. * c-c++-common/gomp/ordered-3.c: Likewise. * c-c++-common/gomp/sink-3.c: Likewise. * gfortran.dg/gomp/nesting-2.f90: Likewise.
2022-09-03Daily bump.GCC Administrator1-0/+18
2022-09-02c/c++: new warning: -Wxor-used-as-pow [PR90885]David Malcolm3-0/+21
PR c/90885 notes various places in real-world code where people have written C/C++ code that uses ^ (exclusive or) where presumbably they meant exponentiation. For example https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=2%5E32&search=Search currently finds 11 places using "2^32", and all of them appear to be places where the user means 2 to the power of 32, rather than 2 exclusive-orred with 32 (which is 34). This patch adds a new -Wxor-used-as-pow warning to the C and C++ frontends to complain about ^ when the left-hand side is the decimal constant 2 or the decimal constant 10. This is the same name as the corresponding clang warning: https://clang.llvm.org/docs/DiagnosticsReference.html#wxor-used-as-pow As per the clang warning, the warning suggests converting the left-hand side to a hexadecimal constant if you really mean xor, which suppresses the warning (though this patch implements a fix-it hint for that, whereas the clang implementation only has a fix-it hint for the initial suggestion of exponentiation). I initially tried implementing this without checking for decimals, but this version had lots of false positives. Checking for decimals requires extending the lexer to capture whether or not a CPP_NUMBER token was decimal. I added a new DECIMAL_INT flag to cpplib.h for this. Unfortunately, c_token and cp_tokens both have only an unsigned char for their flags (as captured by c_lex_with_flags), whereas this would add the 12th flag to cpp_tokens. Of the first 8 flags, all but BOL are used in the C or C++ frontends, but BOL is not, so I moved that to a higher position, using its old value for the new DECIMAL_INT flag, so that it is representable within an unsigned char. Example output: demo.c:5:13: warning: result of '2^8' is 10; did you mean '1 << 8' (256)? [-Wxor-used-as-pow] 5 | int t2_8 = 2^8; | ^ | -- | 1<< demo.c:5:12: note: you can silence this warning by using a hexadecimal constant (0x2 rather than 2) 5 | int t2_8 = 2^8; | ^ | 0x2 demo.c:21:15: warning: result of '10^6' is 12; did you mean '1e6'? [-Wxor-used-as-pow] 21 | int t10_6 = 10^6; | ^ | --- | 1e demo.c:21:13: note: you can silence this warning by using a hexadecimal constant (0xa rather than 10) 21 | int t10_6 = 10^6; | ^~ | 0xa gcc/c-family/ChangeLog: PR c/90885 * c-common.h (check_for_xor_used_as_pow): New decl. * c-lex.cc (c_lex_with_flags): Add DECIMAL_INT to flags as appropriate. * c-warn.cc (check_for_xor_used_as_pow): New. * c.opt (Wxor-used-as-pow): New. gcc/c/ChangeLog: PR c/90885 * c-parser.cc (c_parser_string_literal): Clear ret.m_decimal. (c_parser_expr_no_commas): Likewise. (c_parser_conditional_expression): Likewise. (c_parser_binary_expression): Clear m_decimal when popping the stack. (c_parser_unary_expression): Clear ret.m_decimal. (c_parser_has_attribute_expression): Likewise for result. (c_parser_predefined_identifier): Likewise for expr. (c_parser_postfix_expression): Likewise for expr. Set expr.m_decimal when handling a CPP_NUMBER that was a decimal token. * c-tree.h (c_expr::m_decimal): New bitfield. * c-typeck.cc (parser_build_binary_op): Clear result.m_decimal. (parser_build_binary_op): Call check_for_xor_used_as_pow. gcc/cp/ChangeLog: PR c/90885 * cp-tree.h (class cp_expr): Add bitfield m_decimal. Clear it in existing ctors. Add ctor that allows specifying its value. (cp_expr::decimal_p): New accessor. * parser.cc (cp_parser_expression_stack_entry::flags): New field. (cp_parser_primary_expression): Set m_decimal of cp_expr when handling numbers. (cp_parser_binary_expression): Extract flags from token when populating stack. Call check_for_xor_used_as_pow. gcc/ChangeLog: PR c/90885 * doc/invoke.texi (Warning Options): Add -Wxor-used-as-pow. gcc/testsuite/ChangeLog: PR c/90885 * c-c++-common/Wxor-used-as-pow-1.c: New test. * c-c++-common/Wxor-used-as-pow-fixits.c: New test. * g++.dg/parse/expr3.C: Convert 2 to 0x2 to suppress -Wxor-used-as-pow. * g++.dg/warn/Wparentheses-10.C: Likewise. * g++.dg/warn/Wparentheses-18.C: Likewise. * g++.dg/warn/Wparentheses-19.C: Likewise. * g++.dg/warn/Wparentheses-9.C: Likewise. * g++.dg/warn/Wxor-used-as-pow-named-op.C: New test. * gcc.dg/Wparentheses-6.c: Convert 2 to 0x2 to suppress -Wxor-used-as-pow. * gcc.dg/Wparentheses-7.c: Likewise. * gcc.dg/precedence-1.c: Likewise. libcpp/ChangeLog: PR c/90885 * include/cpplib.h (BOL): Move macro to 1 << 12 since it is not used by C/C++'s unsigned char token flags. (DECIMAL_INT): New, using 1 << 6, so that it is visible as part of C/C++'s 8 bits of token flags. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-09-02Daily bump.GCC Administrator1-0/+5
2022-09-01c: C2x removal of unprototyped functionsJoseph Myers1-3/+2
C2x has completely removed unprototyped functions, so that () now means the same as (void) in both function declarations and definitions, where previously that change had been made for definitions only. Implement this accordingly. This is a change where GNU/Linux distribution builders might wish to try builds with a -std=gnu2x default to start early on getting old code fixed that still has () declarations for functions taking arguments, in advance of GCC moving to -std=gnu2x as default maybe in GCC 14 or 15; I don't know how much such code is likely to be in current use. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-decl.cc (grokparms): Handle () in a function declaration the same as (void) for C2X. gcc/testsuite/ * gcc.dg/c11-unproto-3.c, gcc.dg/c2x-unproto-3.c, gcc.dg/c2x-unproto-4.c: New tests. * gcc.dg/c2x-old-style-definition-6.c, gcc.dg/c2x-unproto-1.c, gcc.dg/c2x-unproto-2.c: Update for removal of unprototyped functions.
2022-09-01Daily bump.GCC Administrator1-0/+6
2022-08-31c: C2x attributes fixes and updatesJoseph Myers2-6/+6
Implement some changes to the currently supported C2x standard attributes that have been made to the specification since they were first implemented in GCC, and some consequent changes: * maybe_unused is now supported on labels. In fact that was already accidentally supported in GCC as a result of sharing the implementation with __attribute__ ((unused)), but needed to be covered in the tests. * As part of the support for maybe_unused on labels, its __has_c_attribute value changed. * The issue of maybe_unused accidentally being already supported on labels showed up the lack of tests for other standard attributes being incorrectly applied to labels; add such tests. * Use of fallthrough or nodiscard attributes on labels already properly resulted in a pedwarn. For the deprecated attribute, however, there was only a warning, and the wording "'deprecated' attribute ignored for 'void'" included an unhelpful "for 'void'". Arrange for the case of the deprecated attribute on a label to be checked for separately and result in a pedwarn. As with inappropriate uses of fallthrough (see commit 6c80b1b56dec2691436f3e2676e3d1b105b01b89), it seems reasonable for this pedwarn to apply regardless of whether [[]] or __attribute__ was used and regardless of whether C or C++ is being compiled. * Attributes on case or default labels (the standard syntax supports attributes on all kinds of labels) were quietly ignored, whether or not appropriate for use in such a context, because they weren't passed to decl_attributes at all. (Note where I'm changing the do_case prototype that such a function is actually only defined in the C front end, not for C++, despite the declaration being in c-common.h.) * A recent change as part of the editorial review in preparation for the C2x CD ballot has changed the __has_c_attribute value for fallthrough to 201910 to reflect when that attribute was actually voted into the working draft. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c-family/ * c-attribs.cc (handle_deprecated_attribute): Check and pedwarn for LABEL_DECL. * c-common.cc (c_add_case_label): Add argument ATTRS. Call decl_attributes. * c-common.h (do_case, c_add_case_label): Update declarations. * c-lex.cc (c_common_has_attribute): For C, produce a result of 201910 for fallthrough and 202106 for maybe_unused. gcc/c/ * c-parser.cc (c_parser_label): Pass attributes to do_case. * c-typeck.cc (do_case): Add argument ATTRS. Pass it to c_add_case_label. gcc/testsuite/ * gcc.dg/c2x-attr-deprecated-2.c, gcc.dg/c2x-attr-fallthrough-2.c, gcc.dg/c2x-attr-maybe_unused-1.c, gcc.dg/c2x-attr-nodiscard-2.c: Add tests of attributes on labels. * gcc.dg/c2x-has-c-attribute-2.c: Update expected results for maybe_unused and fallthrough.
2022-08-27Daily bump.GCC Administrator1-0/+4
2022-08-26Implement __builtin_issignalingJakub Jelinek1-0/+1
The following patch implements a new builtin, __builtin_issignaling, which can be used to implement the ISO/IEC TS 18661-1 issignaling macro. It is implemented as type-generic function, so there is just one builtin, not many with various suffixes. This patch doesn't address PR56831 nor PR58416, but I think compared to using glibc issignaling macro could make some cases better (as the builtin is expanded always inline and for SFmode/DFmode just reinterprets a memory or pseudo register as SImode/DImode, so could avoid some raising of exception + turning sNaN into qNaN before the builtin can analyze it). For floading point modes that do not have NaNs it will return 0, otherwise I've tried to implement this for all the other supported real formats. It handles both the MIPS/PA floats where a sNaN has the mantissa MSB set and the rest where a sNaN has it cleared, with the exception of format which are known never to be in the MIPS/PA form. The MIPS/PA floats are handled using a test like (x & mask) == mask, the other usually as ((x ^ bit) & mask) > val where bit, mask and val are some constants. IBM double double is done by doing DFmode test on the most significant half, and Intel/Motorola extended (12 or 16 bytes) and IEEE quad are handled by extracting 32-bit/16-bit words or 64-bit parts from the value and testing those. On x86, XFmode is handled by a special optab so that even pseudo numbers are considered signaling, like in glibc and like the i386 specific testcase tests. 2022-08-26 Jakub Jelinek <jakub@redhat.com> gcc/ * builtins.def (BUILT_IN_ISSIGNALING): New built-in. * builtins.cc (expand_builtin_issignaling): New function. (expand_builtin_signbit): Don't overwrite target. (expand_builtin): Handle BUILT_IN_ISSIGNALING. (fold_builtin_classify): Likewise. (fold_builtin_1): Likewise. * optabs.def (issignaling_optab): New. * fold-const-call.cc (fold_const_call_ss): Handle BUILT_IN_ISSIGNALING. * config/i386/i386.md (issignalingxf2): New expander. * doc/extend.texi (__builtin_issignaling): Document. (__builtin_isinf, __builtin_isnan): Clarify behavior with -ffinite-math-only. * doc/md.texi (issignaling<mode>2): Likewise. gcc/c-family/ * c-common.cc (check_builtin_function_arguments): Handle BUILT_IN_ISSIGNALING. gcc/c/ * c-typeck.cc (convert_arguments): Handle BUILT_IN_ISSIGNALING. gcc/fortran/ * f95-lang.cc (gfc_init_builtin_functions): Initialize BUILT_IN_ISSIGNALING. gcc/testsuite/ * gcc.dg/torture/builtin-issignaling-1.c: New test. * gcc.dg/torture/builtin-issignaling-2.c: New test. * gcc.dg/torture/float16-builtin-issignaling-1.c: New test. * gcc.dg/torture/float32-builtin-issignaling-1.c: New test. * gcc.dg/torture/float32x-builtin-issignaling-1.c: New test. * gcc.dg/torture/float64-builtin-issignaling-1.c: New test. * gcc.dg/torture/float64x-builtin-issignaling-1.c: New test. * gcc.dg/torture/float128-builtin-issignaling-1.c: New test. * gcc.dg/torture/float128x-builtin-issignaling-1.c: New test. * gcc.target/i386/builtin-issignaling-1.c: New test.
2022-08-26Daily bump.GCC Administrator1-0/+35
2022-08-25c: Implement C23 nullptr (N3042)Marek Polacek4-10/+88
This patch implements the C23 nullptr literal: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm> (with wording fixes from N3047), which is intended to replace the problematic definition of NULL which might be either of integer type or void*. Since C++ has had nullptr for over a decade now, it was relatively easy to just move the built-in node definitions from the C++ FE to the C/C++ common code. Also, our DWARF emitter already handles NULLPTR_TYPE by emitting DW_TAG_unspecified_type. However, I had to handle a lot of contexts such as ?:, comparison, conversion, etc. There are some minor differences, e.g. in C you can do bool b = nullptr; but in C++ you have to use direct-initialization: bool b{nullptr}; And I think that nullptr_t n = 0; is only valid in C++. Of course, C doesn't have to handle mangling, RTTI, substitution, overloading, ... This patch also defines nullptr_t in <stddef.h>. However, it does not define __STDC_VERSION_STDDEF_H__ yet, because we don't know yet what value it should be defined to. gcc/c-family/ChangeLog: * c-common.cc (c_common_reswords): Enable nullptr in C2X. (c_common_nodes_and_builtins): Create the built-in node for nullptr. * c-common.h (enum c_tree_index): Add CTI_NULLPTR, CTI_NULLPTR_TYPE. (struct c_common_resword): Resize the disable member. (D_C2X): Add. (nullptr_node): Define. (nullptr_type_node): Define. (NULLPTR_TYPE_P): Define. * c-pretty-print.cc (c_pretty_printer::simple_type_specifier): Handle NULLPTR_TYPE. (c_pretty_printer::direct_abstract_declarator): Likewise. (c_pretty_printer::constant): Likewise. gcc/c/ChangeLog: * c-convert.cc (c_convert) <case POINTER_TYPE>: Handle NULLPTR_TYPE. Give a better diagnostic when converting to nullptr_t. * c-decl.cc (c_init_decl_processing): Perform C-specific nullptr initialization. * c-parser.cc (c_parse_init): Maybe OR D_C2X into mask. (c_parser_postfix_expression): Handle RID_NULLPTR. * c-typeck.cc (null_pointer_constant_p): Return true when expr is nullptr_node. (build_unary_op) <case TRUTH_NOT_EXPR>: Handle NULLPTR_TYPE. (build_conditional_expr): Handle the case when the second/third operand is NULLPTR_TYPE and third/second operand is POINTER_TYPE. (convert_for_assignment): Handle converting an expression of type nullptr_t to pointer/bool. (build_binary_op) <case TRUTH_XOR_EXPR>: Handle NULLPTR_TYPE. <case EQ_EXPR>: Handle comparing operands of type nullptr_t. gcc/cp/ChangeLog: * cp-tree.h (enum cp_tree_index): Remove CTI_NULLPTR, CTI_NULLPTR_TYPE. Move it to c_tree_index. (nullptr_node): No longer define here. (nullptr_type_node): Likewise. (NULLPTR_TYPE_P): Likewise. * decl.cc (cxx_init_decl_processing): Only keep C++-specific nullptr initialization; move the shared code to c_common_nodes_and_builtins. gcc/ChangeLog: * ginclude/stddef.h: Define nullptr_t. gcc/testsuite/ChangeLog: * gcc.dg/c11-nullptr-1.c: New test. * gcc.dg/c17-nullptr-1.c: New test. * gcc.dg/c17-nullptr-2.c: New test. * gcc.dg/c2x-nullptr-1.c: New test. * gcc.dg/c2x-nullptr-2.c: New test. * gcc.dg/c2x-nullptr-3.c: New test. * gcc.dg/c2x-nullptr-4.c: New test. * gcc.dg/c2x-nullptr-5.c: New test.
2022-08-25c: Support C2x empty initializer bracesJoseph Myers3-33/+34
ISO C2x standardizes empty initializer braces {}. Implement this feature accordingly. The basic case was already supported and so just needed diagnostic adjustments. However, the standard feature also includes two cases that were not previously supported: empty initializer braces for scalars, and empty initializer braces for VLAs. Thus, add support for those features as well, updating existing tests that expected them to be diagnosed. There was already some gimplifier support for converting variable-sized initializations with empty CONSTRUCTORs to memset. However, it didn't apply here; code earlier in gimplify_modify_expr ended up calling gimplify_init_constructor via gimplify_modify_expr_rhs, which ended up handling the CONSTRUCTOR in a way that generated an ICE later. Add a check for this case earlier in gimplify_modify_expr to avoid that issue. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/ * gimplify.cc (gimplify_modify_expr): Convert initialization from a variable-size CONSTRUCTOR to memset before call to gimplify_modify_expr_rhs. gcc/c/ * c-decl.cc (start_decl): Do not diagnose initialization of variable-sized objects here. * c-parser.cc (c_parser_braced_init): Add argument DECL. All callers changed. (c_parser_initializer): Diagnose initialization of variable-sized objects other than with braced initializer. (c_parser_braced_init): Use pedwarn_c11 for empty initializer braces and update diagnostic text. Diagnose initialization of variable-sized objects with nonempty braces. * c-typeck.cc (digest_init): Update diagnostic for initialization of variable-sized objects. (really_start_incremental_init, set_designator) (process_init_element): Update comments. (pop_init_level): Allow scalar empty initializers. gcc/testsuite/ * gcc.dg/c11-empty-init-1.c, gcc.dg/c11-empty-init-2.c, gcc.dg/c11-empty-init-3.c, gcc.dg/c2x-empty-init-1.c, gcc.dg/c2x-empty-init-2.c, gcc.dg/c2x-empty-init-3.c, gcc.dg/gnu2x-empty-init-1.c, gcc.dg/gnu2x-empty-init-2.c: New tests. * gcc.dg/torture/dfp-default-init-1.c: Also test empty initializers. * gcc.dg/init-bad-1.c, gcc.dg/noncompile/pr71583.c, gcc.dg/pr61096-1.c, gcc.dg/vla-init-2.c, gcc.dg/vla-init-3.c, gcc.target/i386/sse2-bfloat16-scalar-typecheck.c: Update expected diagnostics. * gcc.dg/ubsan/c-shift-1.c: Use nonempty initializers for VLA initializations expected to be diagnosed.
2022-08-18Daily bump.GCC Administrator1-0/+8
2022-08-17OpenMP/C++: Allow classes with static members to be mappable [PR104493]Tobias Burnus2-7/+6
As this is the last lang-specific user of the omp_mappable_type hook, the hook is removed, keeping only a generic omp_mappable_type for incomplete types (or error_node). PR c++/104493 gcc/c/ChangeLog: * c-decl.cc (c_decl_attributes, finish_decl): Call omp_mappable_type instead of removed langhook. * c-typeck.cc (c_finish_omp_clauses): Likewise. gcc/cp/ChangeLog: * cp-objcp-common.h (LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. * cp-tree.h (cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. * decl2.cc (cp_omp_mappable_type_1, cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. (cplus_decl_attributes): Call omp_mappable_type instead of removed langhook. * decl.cc (cp_finish_decl): Likewise; call cxx_incomplete_type_inform in lieu of cp_omp_emit_unmappable_type_notes. * semantics.cc (finish_omp_clauses): Likewise. gcc/ChangeLog: * gimplify.cc (omp_notice_variable): Call omp_mappable_type instead of removed langhook. * omp-general.h (omp_mappable_type): New prototype. * omp-general.cc (omp_mappable_type): New; moved from ... * langhooks.cc (lhd_omp_mappable_type): ... here. * langhooks-def.h (lhd_omp_mappable_type, LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Remote the latter. * langhooks.h (struct lang_hooks_for_types): Remove omp_mappable_type. gcc/testsuite/ChangeLog: * g++.dg/gomp/unmappable-1.C: Remove dg-error; remove dg-note no longer shown as TYPE_MAIN_DECL is NULL. * c-c++-common/gomp/map-incomplete-type.c: New test. Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com>
2022-08-12Daily bump.GCC Administrator1-0/+9
2022-08-11c-family: Honor -Wno-init-self for cv-qual vars [PR102633]Marek Polacek1-4/+15
Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r conversion by creating a NOP_EXPR. For e.g. const int i = i; that means that the DECL_INITIAL is '(int) i' and not 'i' anymore. Consequently, we don't suppress_warning here: 711 case DECL_EXPR: 715 if (VAR_P (DECL_EXPR_DECL (*expr_p)) 716 && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p)) 717 && !TREE_STATIC (DECL_EXPR_DECL (*expr_p)) 718 && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL (*expr_p)) 719 && !warn_init_self) 720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self); because of the check on line 718 -- (int) i is not i. So -Wno-init-self doesn't disable the warning as it's supposed to. The following patch fixes it by moving the suppress_warning call from c_gimplify_expr to the front ends, at points where we haven't created the NOP_EXPR yet. PR middle-end/102633 gcc/c-family/ChangeLog: * c-gimplify.cc (c_gimplify_expr) <case DECL_EXPR>: Don't call suppress_warning here. gcc/c/ChangeLog: * c-parser.cc (c_parser_initializer): Add new tree parameter. Use it. Call suppress_warning. (c_parser_declaration_or_fndef): Pass d down to c_parser_initializer. (c_parser_omp_declare_reduction): Pass omp_priv down to c_parser_initializer. gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call suppress_warning. gcc/testsuite/ChangeLog: * c-c++-common/Winit-self1.c: New test. * c-c++-common/Winit-self2.c: New test.
2022-08-09Daily bump.GCC Administrator1-0/+8
2022-08-08C: Implement C2X N2653 char8_t and UTF-8 string literal changesTom Honermann2-3/+15
This patch implements the core language and compiler dependent library changes adopted for C2X via WG14 N2653. The changes include: - Change of type for UTF-8 string literals from array of const char to array of const char8_t (unsigned char). - A new atomic_char8_t typedef. - A new ATOMIC_CHAR8_T_LOCK_FREE macro defined in terms of the existing __GCC_ATOMIC_CHAR8_T_LOCK_FREE predefined macro. gcc/ChangeLog: * ginclude/stdatomic.h (atomic_char8_t, ATOMIC_CHAR8_T_LOCK_FREE): New typedef and macro. gcc/c/ChangeLog: * c-parser.cc (c_parser_string_literal): Use char8_t as the type of CPP_UTF8STRING when char8_t support is enabled. * c-typeck.cc (digest_init): Allow initialization of an array of character type by a string literal with type array of char8_t. gcc/c-family/ChangeLog: * c-lex.cc (lex_string, lex_charconst): Use char8_t as the type of CPP_UTF8CHAR and CPP_UTF8STRING when char8_t support is enabled. * c-opts.cc (c_common_post_options): Set flag_char8_t if targeting C2x. gcc/testsuite/ChangeLog: * gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test. * gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test. * gcc.dg/c11-utf8str-type.c: New test. * gcc.dg/c17-utf8str-type.c: New test. * gcc.dg/c2x-utf8str-type.c: New test. * gcc.dg/c2x-utf8str.c: New test. * gcc.dg/gnu2x-utf8str-type.c: New test. * gcc.dg/gnu2x-utf8str.c: New test.
2022-08-02Daily bump.GCC Administrator1-0/+7
2022-08-01c: improvements to address space diagnosticsDavid Malcolm1-8/+19
This adds a clarifying "note" to address space mismatch diagnostics. For example, it improves the diagnostic for gcc.target/i386/addr-space-typeck-2.c from: addr-space-typeck-2.c: In function 'test_bad_call': addr-space-typeck-2.c:12:22: error: passing argument 2 of 'expects_seg_gs' from pointer to non-enclosed address space 12 | expects_seg_gs (0, ptr, 1); | ^~~ to: addr-space-typeck-2.c: In function 'test_bad_call': addr-space-typeck-2.c:12:22: error: passing argument 2 of 'expects_seg_gs' from pointer to non-enclosed address space 12 | expects_seg_gs (0, ptr, 1); | ^~~ addr-space-typeck-2.c:7:51: note: expected '__seg_gs void *' but argument is of type 'void *' 7 | extern void expects_seg_gs (int i, void __seg_gs *param, int j); | ~~~~~~~~~~~~~~~^~~~~ I took the liberty of adding the test coverage to i386 since we need a specific target to test this on. gcc/c/ChangeLog: * c-typeck.cc (build_c_cast): Quote names of address spaces in diagnostics. (convert_for_assignment): Add a note to address space mismatch diagnostics, specifying the expected and actual types. gcc/testsuite/ChangeLog: * gcc.target/i386/addr-space-typeck-1.c: New test. * gcc.target/i386/addr-space-typeck-2.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
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.