aboutsummaryrefslogtreecommitdiff
path: root/gcc/c
AgeCommit message (Collapse)AuthorFilesLines
2023-10-20c: -Wint-conversion should cover pointer/integer mismatches in ?:Florian Weimer1-2/+2
gcc/c/ PR c/109827 PR other/44209 * c-typeck.cc (build_conditional_expr): Use OPT_Wint_conversion for pointer/integer mismatch warnings. gcc/testsuite/ * gcc.dg/Wint-conversion-3.c: New.
2023-10-20c: -Wincompatible-pointer-types should cover mismatches in ?:Florian Weimer1-8/+8
gcc/c/ PR c/109826 PR other/44209 * c-typeck.cc (build_conditional_expr): Use OPT_Wincompatible_pointer_types for pointer mismatches. Emit location information for the operand. gcc/testsuite/ * gcc.dg/Wincompatible-pointer-types-2.c: New. * gcc.dg/Wincompatible-pointer-types-3.c: New. * gcc.dg/Wincompatible-pointer-types-4.c: New.
2023-10-20Daily bump.GCC Administrator1-0/+12
2023-10-19c: Fix ICE when an argument was an error mark [PR100532]Andrew Pinski1-1/+1
In the case of convert_argument, we would return the same expression back rather than error_mark_node after the error message about trying to convert to an incomplete type. This causes issues in the gimplfier trying to see if another conversion is needed. The code here dates back to before the revision history too so it might be the case it never noticed we should return an error_mark_node. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR c/100532 gcc/c/ChangeLog: * c-typeck.cc (convert_argument): After erroring out about an incomplete type return error_mark_node. gcc/testsuite/ChangeLog: * gcc.dg/pr100532-1.c: New test.
2023-10-19c: Don't warn about converting NULL to different sso endian [PR104822]Andrew Pinski1-0/+1
In a similar way we don't warn about NULL pointer constant conversion to a different named address we should not warn to a different sso endian either. This adds the simple check. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR c/104822 gcc/c/ChangeLog: * c-typeck.cc (convert_for_assignment): Check for null pointer before warning about an incompatible scalar storage order. gcc/testsuite/ChangeLog: * gcc.dg/sso-18.c: New test. * gcc.dg/sso-19.c: New test.
2023-10-19Daily bump.GCC Administrator1-0/+12
2023-10-18[c] Fix PR 101364: ICE after error due to diagnose_arglist_conflict not ↵Andrew Pinski1-1/+2
checking for error When checking to see if we have a function declaration has a conflict due to promotations, there is no test to see if the type was an error mark and then calls c_type_promotes_to. c_type_promotes_to is not ready for error_mark and causes an ICE. This adds a check for error before the call of c_type_promotes_to. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR c/101364 gcc/c/ChangeLog: * c-decl.cc (diagnose_arglist_conflict): Test for error mark before calling of c_type_promotes_to. gcc/testsuite/ChangeLog: * gcc.dg/pr101364-1.c: New test.
2023-10-18Fix ICE due to c_safe_arg_type_equiv_p not checking for error_mark nodeAndrew Pinski1-0/+3
This is a simple error recovery issue when c_safe_arg_type_equiv_p was added in r8-5312-gc65e18d3331aa999. The issue is that after an error, an argument type (of a function type) might turn into an error mark node and c_safe_arg_type_equiv_p was not ready for that. So this just adds a check for error operand for its arguments before getting the main variant. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR c/101285 gcc/c/ChangeLog: * c-typeck.cc (c_safe_arg_type_equiv_p): Return true for error operands early. gcc/testsuite/ChangeLog: * gcc.dg/pr101285-1.c: New test.
2023-10-18Daily bump.GCC Administrator1-0/+5
2023-10-17c: error for function with external and internal linkage [PR111708]Martin Uecker1-0/+21
Declaring a function with both external and internal linkage in the same TU is translation-time UB. Add an error for this case as already done for objects. PR c/111708 gcc/c/ChangeLog: * c-decl.cc (grokdeclarator): Add error. gcc/testsuite/ChangeLog: * gcc.dg/pr111708-1.c: New test. * gcc.dg/pr111708-2.c: New test.
2023-10-04Daily bump.GCC Administrator1-0/+5
2023-10-03diagnostics: add ctors to text_info; add m_ prefixes to fieldsDavid Malcolm1-2/+2
No functional change intended. gcc/ada/ChangeLog: * gcc-interface/misc.cc: Use text_info ctor. gcc/analyzer/ChangeLog: * analyzer-logging.cc (logger::log_va_partial): Use text_info ctor. * analyzer.cc (make_label_text): Likewise. (make_label_text_n): Likewise. * pending-diagnostic.cc (evdesc::event_desc::formatted_print): Likewise. gcc/c/ChangeLog: * c-objc-common.cc (c_tree_printer): Update for "m_" prefixes to text_info fields. gcc/cp/ChangeLog: * error.cc: Update for "m_" prefixes to text_info fields. gcc/d/ChangeLog: * d-diagnostic.cc (d_diagnostic_report_diagnostic): Use text_info ctor. gcc/ChangeLog: * diagnostic.cc (diagnostic_set_info_translated): Update for "m_" prefixes to text_info fields. (diagnostic_report_diagnostic): Likewise. (verbatim): Use text_info ctor. (simple_diagnostic_path::add_event): Likewise. (simple_diagnostic_path::add_thread_event): Likewise. * dumpfile.cc (dump_pretty_printer::decode_format): Update for "m_" prefixes to text_info fields. (dump_context::dump_printf_va): Use text_info ctor. * graphviz.cc (graphviz_out::graphviz_out): Use text_info ctor. (graphviz_out::print): Likewise. * opt-problem.cc (opt_problem::opt_problem): Likewise. * pretty-print.cc (pp_format): Update for "m_" prefixes to text_info fields. (pp_printf): Use text_info ctor. (pp_verbatim): Likewise. (assert_pp_format_va): Likewise. * pretty-print.h (struct text_info): Add ctors. Add "m_" prefix to all fields. * text-art/styled-string.cc (styled_string::from_fmt_va): Use text_info ctor. * tree-diagnostic.cc (default_tree_printer): Update for "m_" prefixes to text_info fields. * tree-pretty-print.h (pp_ti_abstract_origin): Likewise. gcc/fortran/ChangeLog: * error.cc (gfc_format_decoder): Update for "m_" prefixes to text_info fields. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-10-01Daily bump.GCC Administrator1-0/+4
2023-09-29Remove .PHONY targets when building .fda files during autoprofiledbootstrapEugene Rozenfeld1-2/+2
These .PHONY targets are always executed and were breaking `make install` for autoprofiledbootstrap build. Tested on x86_64-pc-linux-gnu. gcc/c/ChangeLog: * Make-lang.in: Make create_fdas_for_cc1 target not .PHONY gcc/cp/ChangeLog: * Make-lang.in: Make create_fdas_for_cc1plus target not .PHONY gcc/lto/ChangeLog: * Make-lang.in: Make create_fdas_for_lto1 target not .PHONY
2023-09-21Daily bump.GCC Administrator1-0/+5
2023-09-20c, c++: Accept __builtin_classify_type (typename)Jakub Jelinek1-0/+23
As mentioned in my stdckdint.h mail, __builtin_classify_type has a problem that argument promotion (the argument is passed to ... prototyped builtin function) means that certain type classes will simply never appear. I think it is too late to change how it behaves, lots of code in the wild might rely on the current behavior. So, the following patch adds option to use a typename rather than expression as the operand to the builtin, making it behave similarly to sizeof, typeof or say the clang _Generic extension where the first argument can be there not just expression, but also typename. I think we have other prior art here, e.g. __builtin_va_arg also expects typename. I've added this to both C and C++, because it would be weird if it supported it only in C and not in C++. 2023-09-20 Jakub Jelinek <jakub@redhat.com> gcc/ * builtins.h (type_to_class): Declare. * builtins.cc (type_to_class): No longer static. Return int rather than enum. * doc/extend.texi (__builtin_classify_type): Document. gcc/c/ * c-parser.cc (c_parser_postfix_expression_after_primary): Parse __builtin_classify_type call with typename as argument. gcc/cp/ * parser.cc (cp_parser_postfix_expression): Parse __builtin_classify_type call with typename as argument. * pt.cc (tsubst_copy_and_build): Handle __builtin_classify_type with dependent typename as argument. gcc/testsuite/ * c-c++-common/builtin-classify-type-1.c: New test. * g++.dg/ext/builtin-classify-type-1.C: New test. * g++.dg/ext/builtin-classify-type-2.C: New test. * gcc.dg/builtin-classify-type-1.c: New test.
2023-09-20Daily bump.GCC Administrator1-0/+16
2023-09-19c/111468 - dump unordered compare operators in their GIMPLE form with -gimpleRichard Biener1-0/+5
The following adjusts -gimple dumping to dump the unordered compare ops and *h in their GIMPLE form. It also adds parsing for __LTGT which I missed before. PR c/111468 gcc/c/ * gimple-parser.cc (c_parser_gimple_binary_expression): Handle __LTGT. gcc/ * tree-pretty-print.h (op_symbol_code): Add defaulted flags argument. * tree-pretty-print.cc (op_symbol): Likewise. (op_symbol_code): Print TDF_GIMPLE variant if requested. * gimple-pretty-print.cc (dump_binary_rhs): Pass flags to op_symbol_code. (dump_gimple_cond): Likewise. gcc/testsuite/ * gcc.dg/gimplefe-50.c: Amend.
2023-09-19c/111468 - add unordered compare and pointer diff to GIMPLE FE parsingRichard Biener1-20/+52
The following adds __UN{LT,LE,GT,GE,EQ}, __UNORDERED and __ORDERED operator parsing support and support for parsing - as POINTER_DIFF_EXPR. PR c/111468 gcc/c/ * gimple-parser.cc (c_parser_gimple_binary_expression): Add return type argument. (c_parser_gimple_statement): Adjust. (c_parser_gimple_paren_condition): Likewise. (c_parser_gimple_binary_expression): Use passed in return type, add support for - as POINTER_DIFF_EXPR, __UN{LT,LE,GT,GE,EQ}, __UNORDERED and __ORDERED. gcc/testsuite/ * gcc.dg/gimplefe-50.c: New testcase. * gcc.dg/gimplefe-51.c: Likewise.
2023-09-13Daily bump.GCC Administrator1-0/+33
2023-09-12OpenMP (C only): For 'omp allocate', really walk tree for 'alloctor' checkTobias Burnus1-41/+61
Walk expression tree of the 'allocator' clause of 'omp allocate' to detect more cases where the allocator expression depends on code between a variable declaration and its associated '#pragma omp allocate'. It also contains the fix for the 'allocator((omp_allocator_handle_t)-1)' ICE, also tested for in previous commit. The changes of this commit were supposed to be part of r14-3863-g35f498d8dfc8e579eaba2ff2d2b96769c632fd58 OpenMP (C only): omp allocate - extend parsing support, improve diagnostic which also contains the associated testcase changes but were left out (oops!). gcc/c/ChangeLog: * c-parser.cc (struct c_omp_loc_tree): New. (c_check_omp_allocate_allocator_r): New; checking moved from ... (c_parser_omp_allocate): ... here. Call it via walk_tree. Avoid ICE with tree_to_shwi for invalid too-large value.
2023-09-12OpenMP (C only): omp allocate - extend parsing support, improve diagnosticTobias Burnus3-13/+129
The 'allocate' directive can be used for both stack and static variables. While the parser in C and C++ was pre-existing, it missed several diagnostics, which this commit adds - for now only for C. While the "sorry, unimplemented" for static variables is still issues during parsing, the sorry for stack variables is now issued in the middle end, preparing for the actual implementation. (Again: only for C.) gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_construct): Move call to c_parser_omp_allocate to ... (c_parser_pragma): ... here. (c_parser_omp_allocate): Avoid ICE is allocator could not be parsed; set 'omp allocate' attribute for stack/automatic variables and only reject static variables; add several additional restriction checks. * c-tree.h (c_mark_decl_jump_unsafe_in_current_scope): New prototype. * c-decl.cc (decl_jump_unsafe): Return true for omp-allocated decls. (c_mark_decl_jump_unsafe_in_current_scope): New. (warn_about_goto, c_check_switch_jump_warnings): Add error for omp-allocated decls. gcc/ChangeLog: * gimplify.cc (gimplify_bind_expr): Check for insertion after variable cleanup. Convert 'omp allocate' var-decl attribute to GOMP_alloc/GOMP_free calls. gcc/testsuite/ChangeLog: * c-c++-common/gomp/allocate-5.c: Fix testcase; make some dg-messages for 'sorry' as c++, only. * c-c++-common/gomp/directive-1.c: Make a 'sorry' c++ only. * c-c++-common/gomp/allocate-9.c: New test. * c-c++-common/gomp/allocate-11.c: New test. * c-c++-common/gomp/allocate-12.c: New test. * c-c++-common/gomp/allocate-14.c: New test. * c-c++-common/gomp/allocate-15.c: New test. * c-c++-common/gomp/allocate-16.c: New test.
2023-09-12c: reorganize recursive type checkingMartin Uecker1-161/+121
Reorganize recursive type checking to use a structure to store information collected during the recursion and returned to the caller (warning_needed, enum_and_init_p, different_types_p). gcc/c: * c-typeck.cc (struct comptypes_data): Add structure. (tagged_types_tu_compatible_p, function_types_compatible_p, type_lists_compatible_p, comptypes_internal): Add structure to interface, change return type to bool, and adapt calls. (comptarget_types): Change return type too bool. (comptypes, comptypes_check_enum_int, comptypes_check_different_types): Adapt calls.
2023-09-07Daily bump.GCC Administrator1-0/+44
2023-09-06C _BitInt incremental fixes [PR102989]Jakub Jelinek2-2/+15
On Wed, Aug 09, 2023 at 09:17:57PM +0000, Joseph Myers wrote: > > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > > mention how those should be passed/returned; in a limited way they are > > supported internally because the internal functions into which > > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > > hack to return 2 values without using references/pointers > > What happens when the usual arithmetic conversions are applied to > operands, one of which is a complex integer type and the other of which is > a wider _BitInt type? I don't see anything in the code to disallow this > case (which would produce an expression with a _Complex _BitInt type), or > any testcases for it. I've added a sorry for that case (+ return the narrower COMPLEX_TYPE). Also added testcase to verify we don't create VECTOR_TYPEs of BITINT_TYPE even if they have mode precision and suitable size (others were rejected already before). > Other testcases I think should be present (along with any corresponding > changes needed to the code itself): > > * Verifying that the new integer constant suffix is rejected for C++. Done. > * Verifying appropriate pedwarn-if-pedantic for the new constant suffix > for versions of C before C2x (and probably for use of _BitInt type > specifiers before C2x as well) - along with the expected -Wc11-c2x-compat > handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. Done. Here is an incremental patch which does that. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/c/ * c-decl.cc (finish_declspecs): Emit pedwarn_c11 on _BitInt. * c-typeck.cc (c_common_type): Emit sorry for common type between _Complex integer and larger _BitInt and return the _Complex integer. gcc/c-family/ * c-attribs.cc (type_valid_for_vector_size): Reject vector types with BITINT_TYPE elements even if they have mode precision and suitable size. gcc/testsuite/ * gcc.dg/bitint-19.c: New test. * gcc.dg/bitint-20.c: New test. * gcc.dg/bitint-21.c: New test. * gcc.dg/bitint-22.c: New test. * gcc.dg/bitint-23.c: New test. * gcc.dg/bitint-24.c: New test. * gcc.dg/bitint-25.c: New test. * gcc.dg/bitint-26.c: New test. * gcc.dg/bitint-27.c: New test. * g++.dg/ext/bitint1.C: New test. * g++.dg/ext/bitint2.C: New test. * g++.dg/ext/bitint3.C: New test. * g++.dg/ext/bitint4.C: New test. libcpp/ * expr.cc (cpp_classify_number): Diagnose wb literal suffixes for -pedantic* before C2X or -Wc11-c2x-compat.
2023-09-06C _BitInt support [PR102989]Jakub Jelinek7-109/+308
This patch adds the C FE support, c-family support, small libcpp change so that 123wb and 42uwb suffixes are handled plus glimits.h change to define BITINT_MAXWIDTH macro. The previous patches really do nothing without this, which enables all the support. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/ * glimits.h (BITINT_MAXWIDTH): Define if __BITINT_MAXWIDTH__ is predefined. gcc/c-family/ * c-common.cc (c_common_reswords): Add _BitInt as keyword. (unsafe_conversion_p): Handle BITINT_TYPE like INTEGER_TYPE. (c_common_signed_or_unsigned_type): Handle BITINT_TYPE. (c_common_truthvalue_conversion, c_common_get_alias_set, check_builtin_function_arguments): Handle BITINT_TYPE like INTEGER_TYPE. (sync_resolve_size): Add ORIG_FORMAT argument. If FETCH && !ORIG_FORMAT, type is BITINT_TYPE, return -1 if size isn't one of 1, 2, 4, 8 or 16 or if it is 16 but TImode is not supported. (atomic_bitint_fetch_using_cas_loop): New function. (resolve_overloaded_builtin): Adjust sync_resolve_size caller. If -1 is returned, use atomic_bitint_fetch_using_cas_loop to lower it. Formatting fix. (keyword_begins_type_specifier): Handle RID_BITINT. * c-common.h (enum rid): Add RID_BITINT enumerator. * c-cppbuiltin.cc (c_cpp_builtins): For C call targetm.c.bitint_type_info and predefine __BITINT_MAXWIDTH__ and for -fbuilding-libgcc also __LIBGCC_BITINT_LIMB_WIDTH__ and __LIBGCC_BITINT_ORDER__ macros if _BitInt is supported. * c-lex.cc (interpret_integer): Handle CPP_N_BITINT. * c-pretty-print.cc (c_pretty_printer::simple_type_specifier, c_pretty_printer::direct_abstract_declarator, c_pretty_printer::direct_declarator, c_pretty_printer::declarator): Handle BITINT_TYPE. (pp_c_integer_constant): Handle printing of large precision wide_ints which would buffer overflow digit_buffer. * c-warn.cc (conversion_warning, warnings_for_convert_and_check, warnings_for_convert_and_check): Handle BITINT_TYPE like INTEGER_TYPE. gcc/c/ * c-convert.cc (c_convert): Handle BITINT_TYPE like INTEGER_TYPE. * c-decl.cc (check_bitfield_type_and_width): Allow BITINT_TYPE bit-fields. (finish_struct): Prefer to use BITINT_TYPE for BITINT_TYPE bit-fields if possible. (declspecs_add_type): Formatting fixes. Handle cts_bitint. Adjust for added union in *specs. Handle RID_BITINT. (finish_declspecs): Handle cts_bitint. Adjust for added union in *specs. * c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs, c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle RID_BITINT. (c_parser_omp_clause_schedule): Handle BITINT_TYPE like INTEGER_TYPE. * c-tree.h (enum c_typespec_keyword): Mention _BitInt in comment. Add cts_bitint enumerator. (struct c_declspecs): Move int_n_idx and floatn_nx_idx into a union and add bitint_prec there as well. * c-typeck.cc (c_common_type, comptypes_internal): Handle BITINT_TYPE. (perform_integral_promotions): Promote BITINT_TYPE bit-fields to their declared type. (build_array_ref, build_unary_op, build_conditional_expr, build_c_cast, convert_for_assignment, digest_init, build_binary_op): Handle BITINT_TYPE. * c-fold.cc (c_fully_fold_internal): Handle BITINT_TYPE like INTEGER_TYPE. * c-aux-info.cc (gen_type): Handle BITINT_TYPE. libcpp/ * expr.cc (interpret_int_suffix): Handle wb and WB suffixes. * include/cpplib.h (CPP_N_BITINT): Define.
2023-09-06c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2XJakub Jelinek1-6/+7
Now that _Float{16,32,64,128,32x,64x,128x} and {f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard, I think it is undesirable to pedwarn about these for -std=c2x, so this patch uses pedwarn_c11 instead. In c-family/, we don't have that function and am not sure it would be very clean to define dummy pedwarn_c11 in the C++ FE, so the patch just does what pedwarn_c11 does using pedwarn/warning. 2023-09-06 Jakub Jelinek <jakub@redhat.com> gcc/c-family/ * c-lex.cc (interpret_float): For C diagnostics on FN and FNx suffixes append " before C2X" to diagnostics text and follow behavior of pedwarn_c11. gcc/c/ * c-decl.cc (declspecs_add_type): Use pedwarn_c11 rather than pedwarn for _FloatN{,x} diagnostics and append " before C2X" to the diagnostic text. gcc/testsuite/ * gcc.dg/c11-floatn-1.c: New test. * gcc.dg/c11-floatn-2.c: New test. * gcc.dg/c11-floatn-3.c: New test. * gcc.dg/c11-floatn-4.c: New test. * gcc.dg/c11-floatn-5.c: New test. * gcc.dg/c11-floatn-6.c: New test. * gcc.dg/c11-floatn-7.c: New test. * gcc.dg/c11-floatn-8.c: New test. * gcc.dg/c2x-floatn-1.c: New test. * gcc.dg/c2x-floatn-2.c: New test. * gcc.dg/c2x-floatn-3.c: New test. * gcc.dg/c2x-floatn-4.c: New test. * gcc.dg/c2x-floatn-5.c: New test. * gcc.dg/c2x-floatn-6.c: New test. * gcc.dg/c2x-floatn-7.c: New test. * gcc.dg/c2x-floatn-8.c: New test.
2023-09-06Daily bump.GCC Administrator1-0/+5
2023-09-05OpenMP: Avoid ICE in c_parser_omp_clause_allocate with invalid exprTobias Burnus1-1/+3
gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_clause_allocate): Handle error_mark_node. gcc/testsuite/ChangeLog: * c-c++-common/gomp/allocate-13.c: New test.
2023-08-26Daily bump.GCC Administrator1-0/+19
2023-08-25OpenMP: C front end support for imperfectly-nested loopsSandra Loosemore1-252/+608
OpenMP 5.0 removed the restriction that multiple collapsed loops must be perfectly nested, allowing "intervening code" (including nested BLOCKs) before or after each nested loop. In GCC this code is moved into the inner loop body by the respective front ends. This patch changes the C front end to use recursive descent parsing on nested loops within an "omp for" construct, rather than an iterative approach, in order to preserve proper nesting of compound statements. New common C/C++ testcases are in a separate patch. gcc/c-family/ChangeLog * c-common.h (c_omp_check_loop_binding_exprs): Declare. * c-omp.cc: Include tree-iterator.h. (find_binding_in_body): New. (check_loop_binding_expr_r): New. (LOCATION_OR): New. (check_looop_binding_expr): New. (c_omp_check_loop_binding_exprs): New. gcc/c/ChangeLog * c-parser.cc (struct c_parser): Add omp_for_parse_state field. (struct omp_for_parse_data): New. (check_omp_intervening_code): New. (add_structured_block_stmt): New. (c_parser_compound_statement_nostart): Recognize intervening code, nested loops, and other things that need special handling in OpenMP loop constructs. (c_parser_while_statement): Error on loop in intervening code. (c_parser_do_statement): Likewise. (c_parser_for_statement): Likewise. (c_parser_postfix_expression_after_primary): Error on calls to the OpenMP runtime in intervening code. (c_parser_pragma): Error on OpenMP pragmas in intervening code. (c_parser_omp_loop_nest): New. (c_parser_omp_for_loop): Rewrite to use recursive descent, calling c_parser_omp_loop_nest to do the heavy lifting. gcc/ChangeLog * omp-api.h: New. * omp-general.cc (omp_runtime_api_procname): New. (omp_runtime_api_call): Moved here from omp-low.cc, and make non-static. * omp-general.h: Include omp-api.h. * omp-low.cc (omp_runtime_api_call): Delete this copy. gcc/testsuite/ChangeLog * c-c++-common/goacc/collapse-1.c: Update for new C error behavior. * c-c++-common/goacc/tile-2.c: Likewise. * gcc.dg/gomp/collapse-1.c: Likewise.
2023-08-25Daily bump.GCC Administrator1-0/+9
2023-08-24c: Add support for [[__extension__ ...]]Richard Sandiford1-16/+48
[[]] attributes are a recent addition to C, but as a GNU extension, GCC allows them to be used in C11 and earlier. Normally this use would trigger a pedwarn (for -pedantic, -Wc11-c2x-compat, etc.). This patch allows the pedwarn to be suppressed by starting the attribute-list with __extension__. Also, :: is not a single lexing token prior to C2X, so it wasn't possible to use scoped attributes in C11, even as a GNU extension. The patch allows two colons to be used in place of :: when __extension__ is used. No attempt is made to check whether the two colons are immediately adjacent. gcc/ * doc/extend.texi: Document the C [[__extension__ ...]] construct. gcc/c/ * c-parser.cc (c_parser_std_attribute): Conditionally allow two colons to be used in place of ::. (c_parser_std_attribute_list): New function, split out from... (c_parser_std_attribute_specifier): ...here. Allow the attribute-list to start with __extension__. When it does, also allow two colons to be used in place of ::. gcc/testsuite/ * gcc.dg/c2x-attr-syntax-6.c: New test. * gcc.dg/c2x-attr-syntax-7.c: Likewise.
2023-08-23Daily bump.GCC Administrator1-0/+5
2023-08-22OpenMP: Handle 'all' as category in defaultmapTobias Burnus1-4/+15
Both, specifying no category and specifying 'all', implies that the implicit-behavior applies to all categories. gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_clause_defaultmap): Parse 'all' as category. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_clause_defaultmap): Parse 'all' as category. gcc/fortran/ChangeLog: * gfortran.h (enum gfc_omp_defaultmap_category): Add OMP_DEFAULTMAP_CAT_ALL. * openmp.cc (gfc_match_omp_clauses): Parse 'all' as category. * trans-openmp.cc (gfc_trans_omp_clauses): Handle it. gcc/ChangeLog: * tree-core.h (enum omp_clause_defaultmap_kind): Add OMP_CLAUSE_DEFAULTMAP_CATEGORY_ALL. * gimplify.cc (gimplify_scan_omp_clauses): Handle it. * tree-pretty-print.cc (dump_omp_clause): Likewise. libgomp/ChangeLog: * libgomp.texi (OpenMP 5.2 status): Add depobj with destroy-var argument as 'N'. Mark defaultmap with 'all' category as 'Y'. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/defaultmap-1.f90: Update dg-error. * c-c++-common/gomp/defaultmap-5.c: New test. * c-c++-common/gomp/defaultmap-6.c: New test. * gfortran.dg/gomp/defaultmap-10.f90: New test. * gfortran.dg/gomp/defaultmap-9.f90: New test.
2023-08-18Daily bump.GCC Administrator1-0/+6
2023-08-17Add warning options -W[no-]compare-distinct-pointer-typesJose E. Marchesi1-3/+3
GCC emits pedwarns unconditionally when comparing pointers of different types, for example: int xdp_context (struct xdp_md *xdp) { void *data = (void *)(long)xdp->data; __u32 *metadata = (void *)(long)xdp->data_meta; __u32 ret; if (metadata + 1 > data) return 0; return 1; } /home/jemarch/foo.c: In function ‘xdp_context’: /home/jemarch/foo.c:15:20: warning: comparison of distinct pointer types lacks a cast 15 | if (metadata + 1 > data) | ^ LLVM supports an option -W[no-]compare-distinct-pointer-types that can be used in order to enable or disable the emission of such warnings. It is enabled by default. This patch adds the same options to GCC. Documentation and testsuite updated included. Regtested in x86_64-linu-gnu. No regressions observed. gcc/ChangeLog: PR c/106537 * doc/invoke.texi (Option Summary): Mention -Wcompare-distinct-pointer-types under `Warning Options'. (Warning Options): Document -Wcompare-distinct-pointer-types. gcc/c-family/ChangeLog: PR c/106537 * c.opt (Wcompare-distinct-pointer-types): New option. gcc/c/ChangeLog: PR c/106537 * c-typeck.cc (build_binary_op): Warning on comparing distinct pointer types only when -Wcompare-distinct-pointer-types. gcc/testsuite/ChangeLog: PR c/106537 * gcc.c-torture/compile/pr106537-1.c: New test. * gcc.c-torture/compile/pr106537-2.c: Likewise. * gcc.c-torture/compile/pr106537-3.c: Likewise.
2023-08-16Daily bump.GCC Administrator1-0/+5
2023-08-15OpenACC 2.7: default clause support for data constructsChung-Lin Tang1-0/+1
This patch implements the OpenACC 2.7 addition of default(none|present) support for data constructs. Now, specifying "default(none|present)" on a data construct turns on same default clause behavior for all lexically enclosed compute constructs (which don't already themselves have a default clause). gcc/c/ChangeLog: * c-parser.cc (OACC_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_DEFAULT. gcc/cp/ChangeLog: * parser.cc (OACC_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_DEFAULT. gcc/fortran/ChangeLog: * openmp.cc (OACC_DATA_CLAUSES): Add OMP_CLAUSE_DEFAULT. gcc/ChangeLog: * gimplify.cc (oacc_region_type_name): New function. (oacc_default_clause): If no 'default' clause appears on this compute construct, see if one appears on a lexically containing 'data' construct. (gimplify_scan_omp_clauses): Upon OMP_CLAUSE_DEFAULT case, set ctx->oacc_default_clause_ctx to current context. gcc/testsuite/ChangeLog: * c-c++-common/goacc/default-3.c: Adjust testcase. * c-c++-common/goacc/default-4.c: Adjust testcase. * c-c++-common/goacc/default-5.c: Adjust testcase. * gfortran.dg/goacc/default-3.f95: Adjust testcase. * gfortran.dg/goacc/default-4.f: Adjust testcase. * gfortran.dg/goacc/default-5.f: Adjust testcase. Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
2023-08-12Daily bump.GCC Administrator1-0/+10
2023-08-11c: Add __typeof_unqual__ and __typeof_unqual supportJakub Jelinek1-1/+2
As I mentioned in my stdckdint.h mail, I think having __ prefixed keywords for the typeof_unqual keyword which can be used in earlier language modes can be useful, not all code can be switched to C23 right away. The following patch implements that. It keeps the non-C23 behavior for it for the _Noreturn functions to stay compatible with how __typeof__ behaves. I think we don't need it for C++, in C++ we have standard traits to remove qualifiers etc. 2023-08-11 Jakub Jelinek <jakub@redhat.com> gcc/ * doc/extend.texi (Typeof): Document typeof_unqual and __typeof_unqual__. gcc/c-family/ * c-common.cc (c_common_reswords): Add __typeof_unqual and __typeof_unqual__ spellings of typeof_unqual. gcc/c/ * c-parser.cc (c_parser_typeof_specifier): Handle __typeof_unqual and __typeof_unqual__ as !is_std. gcc/testsuite/ * gcc.dg/c11-typeof-2.c: New test. * gcc.dg/c11-typeof-3.c: New test. * gcc.dg/gnu11-typeof-3.c: New test. * gcc.dg/gnu11-typeof-4.c: New test.
2023-08-11c: Support for -Wuseless-cast [PR84510]Martin Uecker1-3/+7
Add support for Wuseless-cast C (and ObjC). PR c/84510 gcc/c/: * c-typeck.cc (build_c_cast): Add warning. gcc/c-family/: * c.opt: Enable warning for C and ObjC. gcc/: * doc/invoke.texi: Update. gcc/testsuite/: * gcc.dg/Wuseless-cast.c: New test.
2023-08-06Daily bump.GCC Administrator1-0/+5
2023-08-05c: _Generic should not warn in non-active branches [PR68193,PR97100,PR110703]Martin Uecker1-1/+11
To avoid false diagnostics, use c_inhibit_evaluation_warnings when a generic association is known to not match during parsing. We may still generate false positives if the default branch comes earler than a specific association that matches. PR c/68193 PR c/97100 PR c/110703 gcc/c/: * c-parser.cc (c_parser_generic_selection): Inhibit evaluation warnings branches that are known not be taken during parsing. gcc/testsuite/ChangeLog: * gcc.dg/pr68193.c: New test.
2023-08-05Daily bump.GCC Administrator1-0/+7
2023-08-04frontend: Add novector C pragmaTamar Christina1-39/+80
FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should not be applied to a particular loop. ICC/ICX also has such a pragma for C and C++ called #pragma novector. As part of this patch series I need a way to easily turn off vectorization of particular loops, particularly for testsuite reasons. This patch proposes a #pragma GCC novector that does the same for C as gfortan does for FORTRAN and what ICX/ICX does for C. I added only some basic tests here, but the next patch in the series uses this in the testsuite in about ~800 tests. gcc/c-family/ChangeLog: * c-pragma.h (enum pragma_kind): Add PRAGMA_NOVECTOR. * c-pragma.cc (init_pragma): Use it. gcc/c/ChangeLog: * c-parser.cc (c_parser_while_statement, c_parser_do_statement, c_parser_for_statement, c_parser_statement_after_labels, c_parse_pragma_novector, c_parser_pragma): Wire through novector and default to false. gcc/testsuite/ChangeLog: * gcc.dg/vect/vect-novector-pragma.c: New test.
2023-08-03Daily bump.GCC Administrator1-0/+6
2023-08-02analyzer: stash values for CPython plugin [PR107646]Eric Feng1-0/+24
This patch adds a hook to the end of ana::on_finish_translation_unit which calls relevant stashing-related callbacks registered during plugin initialization. This feature is used to stash named types and global variables for a CPython analyzer plugin [PR107646]. gcc/analyzer/ChangeLog: PR analyzer/107646 * analyzer-language.cc (run_callbacks): New function. (on_finish_translation_unit): New function. * analyzer-language.h (GCC_ANALYZER_LANGUAGE_H): New include. (class translation_unit): New vfuncs. gcc/c/ChangeLog: PR analyzer/107646 * c-parser.cc: New functions on stashing values for the analyzer. gcc/testsuite/ChangeLog: PR analyzer/107646 * gcc.dg/plugin/plugin.exp: Add new plugin and test. * gcc.dg/plugin/analyzer_cpython_plugin.c: New plugin. * gcc.dg/plugin/cpython-plugin-test-1.c: New test. Signed-off-by: Eric Feng <ef2648@columbia.edu>
2023-08-02Daily bump.GCC Administrator1-0/+5
2023-07-31c-family: Implement pragma_lex () for preprocess-only modeLewis Hyatt1-0/+21
In order to support processing #pragma in preprocess-only mode (-E or -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from libcpp. In full compilation modes, this is accomplished by calling pragma_lex (), which is a symbol that must be exported by the frontend, and which is currently implemented for C and C++. Neither of those frontends initializes its parser machinery in preprocess-only mode, and consequently pragma_lex () does not work in this case. Address that by adding a new function c_init_preprocess () for the frontends to implement, which arranges for pragma_lex () to work in preprocess-only mode, and adjusting pragma_lex () accordingly. In preprocess-only mode, the preprocessor is accustomed to controlling the interaction with libcpp, and it only knows about tokens that it has called into libcpp itself to obtain. Since it still needs to see the tokens obtained by pragma_lex () so that they can be streamed to the output, also adjust c_lex_with_flags () and related functions in c-family/c-lex.cc to inform the preprocessor about any tokens it won't be aware of. Currently, there is one place where we are already supporting #pragma in preprocess-only mode, namely the handling of `#pragma GCC diagnostic'. That was done by directly interfacing with libcpp, rather than making use of pragma_lex (). Now that pragma_lex () works, that code is no longer necessary; remove it. gcc/c-family/ChangeLog: * c-common.h (c_init_preprocess): Declare new function. * c-opts.cc (c_common_init): Call it. * c-lex.cc (cb_def_pragma): Add a comment. (get_token): New function wrapping cpp_get_token. (c_lex_with_flags): Use the new wrapper function to support obtaining tokens in preprocess_only mode. (lex_string): Likewise. * c-pragma.cc (pragma_diagnostic_lex_normal): Rename to... (pragma_diagnostic_lex): ...this. (pragma_diagnostic_lex_pp): Remove. (handle_pragma_diagnostic_impl): Call pragma_diagnostic_lex () in all modes. (c_pp_invoke_early_pragma_handler): Adapt to support pragma_lex () usage. * c-pragma.h (pragma_lex_discard_to_eol): Declare. gcc/c/ChangeLog: * c-parser.cc (pragma_lex_discard_to_eol): New function. (c_init_preprocess): New function. gcc/cp/ChangeLog: * parser.cc (c_init_preprocess): New function. (maybe_read_tokens_for_pragma_lex): New function. (pragma_lex): Support preprocess-only mode. (pragma_lex_discard_to_eol): New function.
generated by cgit v1.1 at 2025-08-08 07:02:33 +0000