aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-20testsuite: Add some missing -Wno-psabi optionsJakub Jelinek2-2/+2
The following testcases FAIL on i686-linux due to excess diagnostics for -Wpsabi. 2022-10-20 Jakub Jelinek <jakub@redhat.com> * gcc.target/i386/pr107271.c: Add -Wno-psabi to dg-options. * gcc.dg/debug/btf/btf-function-3.c: Likewise.
2022-10-20passes: Fix a comment typoJakub Jelinek1-1/+1
This patch fixes a single typo in comment. 2022-10-20 Jakub Jelinek <jakub@redhat.com> * passes.cc (pass_manager::register_pass): Fix a comment typo - copmilation -> compilation.
2022-10-20libgomp: Add offload_device_gcn check, add requires-4a.c testTobias Burnus4-1/+65
Duplicate libgomp.c-c++-common/requires-4.c (as ...-4a.c) but with using a heap-allocated instead of static memory for a variable. This change and the added offload_device_gcn check prepare for pseudo-USM, where the device hardware cannot access all host memory but only managed and pinned memory; for those, requires-4.c will fail and the new check permits to add target { ! { offload_device_nvptx || offload_device_gcn } } to requires-4.c; however, it has not been added yet as pseuo-USM support is not yet on mainline. (Review is pending for the USM patches.) include/ChangeLog: * gomp-constants.h (GOMP_DEVICE_HSA): Comment out unused define. libgomp/ChangeLog: * testsuite/lib/libgomp.exp (check_effective_target_offload_device_gcn): New. * testsuite/libgomp.c-c++-common/on_device_arch.h (device_arch_gcn, on_device_arch_gcn): New. * testsuite/libgomp.c-c++-common/requires-4a.c: New test; copied from requires-4.c but using heap-allocated memory.
2022-10-20Avoid PHI - PHI recurrence in vectorizationRichard Biener1-8/+3
The reported regression of libgomp loop-14.C shows that there isn't generally a good reliable place to insert the permute upfront so the following simply restricts recurrence vectorization to the cases where the latch value isn't defined by a PHI. * tree-vect-loop.cc (vect_phi_first_order_recurrence_p): Disallow latch PHI defs. (vectorizable_recurr): Revert previous change.
2022-10-20Add 'libgomp.oacc-c-c++-common/private-big-1.c' [PR105421]Thomas Schwinge1-0/+100
After commit r13-3404-g7c55755d4c760de326809636531478fd7419e1e5 "amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421]", "big" private data now works for GCN offloading, too. PR target/105421 libgomp/ * testsuite/libgomp.oacc-c-c++-common/private-big-1.c: New.
2022-10-20amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421]Julian Brown1-6/+9
The GCN backend uses a heuristic to determine whether to use FLAT or GLOBAL addressing in a particular (offload) function: namely, if a function takes a pointer-to-scalar parameter, it is assumed that the pointer may refer to "flat scratch" space, and thus FLAT addressing must be used instead of GLOBAL. I came up with this heuristic initially whilst working on support for moving OpenACC gang-private variables into local-data share (scratch) memory. The assumption that only scalar variables would be transformed in that way turned out to be wrong. For example, prior to the next patch in the series, Fortran compiler-generated temporary structures were treated as gang private and moved to LDS space, typically overflowing the region allocated for such variables. That will no longer happen after that patch is applied, but there may be other cases of structs moving to LDS space now or in the future that this patch may be needed for. 2022-10-14 Julian Brown <julian@codesourcery.com> PR target/105421 gcc/ * config/gcn/gcn.cc (gcn_detect_incoming_pointer_arg): Any pointer argument forces FLAT addressing mode, not just pointer-to-non-aggregate.
2022-10-20Make 'autoreconf' work for 'gcc', 'libobjc'Thomas Schwinge4-4/+8
With that, we may then run plain 'autoreconf' for all of GCC's subpackages, instead of for some of those (that don't use Automake) manually having to run the applicable combination of 'aclocal', 'autoconf', 'autoheader'. See also 'AC_CONFIG_MACRO_DIRS'/'AC_CONFIG_MACRO_DIR' usage elsewhere. gcc/ * configure.ac (AC_CONFIG_MACRO_DIRS): Instantiate. * configure: Regenerate. libobjc/ * configure.ac (AC_CONFIG_MACRO_DIRS): Instantiate. * configure: Regenerate.
2022-10-20aarch64: Commonise some folding codeRichard Sandiford3-7/+10
Add an aarch64_sve::gimple_folder helper for folding calls to integer constants. SME will make more use of this. gcc/ * config/aarch64/aarch64-sve-builtins.h (gimple_folder::fold_to_cstu): New member function. * config/aarch64/aarch64-sve-builtins.cc (gimple_folder::fold_to_cstu): Define. * config/aarch64/aarch64-sve-builtins-base.cc (svcnt_bhwd_impl::fold): Use it.
2022-10-20aarch64: Use using directives to inherit constructorsRichard Sandiford3-87/+24
Now that the codebase is C++11, we can use using directives to inherit constructors from base classes. gcc/ * config/aarch64/aarch64-sve-builtins-functions.h (quiet) (rtx_code_function, rtx_code_function_rotated, unspec_based_function) (unspec_based_function_rotated, unspec_based_function_exact_insn) (unspec_based_fused_function, unspec_based_fused_lane_function): Replace constructors with using directives. * config/aarch64/aarch64-sve-builtins-base.cc (svcnt_bhwd_pat_impl) (svcreate_impl, svdotprod_lane_impl, svget_impl, svld1_extend_impl) (svld1_gather_extend_impl, svld234_impl, svldff1_gather_extend) (svset_impl, svst1_scatter_truncate_impl, svst1_truncate_impl) (svst234_impl, svundef_impl): Likewise. * config/aarch64/aarch64-sve-builtins-sve2.cc (svldnt1_gather_extend_impl, svmovl_lb_impl): Likewise. (svstnt1_scatter_truncate_impl): Likewise.
2022-10-20aarch64: Replace CONSTEXPR with constexprRichard Sandiford5-83/+83
Move away from the pre-C++11 compatibility macro CONSTEXPR. gcc/ * config/aarch64/aarch64-sve-builtins-base.cc: Replace CONSTEXPR with constexpr throughout. * config/aarch64/aarch64-sve-builtins-functions.h: Likewise. * config/aarch64/aarch64-sve-builtins-shapes.cc: Likewise. * config/aarch64/aarch64-sve-builtins-sve2.cc: Likewise. * config/aarch64/aarch64-sve-builtins.cc: Likewise.
2022-10-20aarch64: Prevent generation of /M BRKAS and BRKBSRichard Sandiford3-18/+16
Bit of a brown-paper-bag bug, but: GCC was generating non-existent merging forms of BRKAS and BRKBS. Those instructions only support zero predication (although BRKA and BRKB support both). gcc/ * config/aarch64/aarch64-sve.md (*aarch64_brk<brk_op>_cc): Remove merging alternative. (*aarch64_brk<brk_op>_ptest): Likewise. gcc/testsuite/ * gcc.target/aarch64/sve/acle/general/brka_1.c: Expect a separate PTEST instruction. * gcc.target/aarch64/sve/acle/general/brkb_1.c: Likewise.
2022-10-20aarch64: Fix matching of BRKNSRichard Sandiford4-10/+90
Unlike other flag-setting SVE instructions, BRKNS sets the flags based on an all-true governing predicate, rather than the GP operand. gcc/ * config/aarch64/iterators.md (SVE_BRKP): New iterator. * config/aarch64/aarch64-sve.md (*aarch64_brkn_cc): New pattern. (*aarch64_brkn_ptest): Likewise. (*aarch64_brk<brk_op>_cc): Restrict to SVE_BRKP. (*aarch64_brk<brk_op>_ptest): Likewise. gcc/testsuite/ * gcc.target/aarch64/sve/acle/general/brkn_1.c: Expect separate PTEST instructions. * gcc.target/aarch64/sve/acle/general/brkn_2.c: New test.
2022-10-20c/107305 - avoid ICEing with invalid GIMPLE input to the GIMPLE FERichard Biener4-8/+35
The GIMPLE FE was designed to defer semantic error checking to the GIMPLE IL verifier. But that can end up causing spurious ICEs earlier and in fact it will report an internal error. The following tries to improve the situation by explicitely calling into the verifier from the parser and intructing it to not ICE but instead zap the parsed body after an error is discovered. PR c/107305 PR c/107306 gcc/c/ * gimple-parser.cc (c_parser_parse_gimple_body): Verify the parsed IL and zap the body on error. gcc/ * tree-cfg.h (verify_gimple_in_seq): Add parameter to indicate whether to emit an ICE. Add return value. (verify_gimple_in_cfg): Likewise. * tree-cfg.cc (verify_gimple_in_seq): Likewise. (verify_gimple_in_cfg): Likewise. gcc/testsuite/ * gcc.dg/gimplefe-error-15.c: New testcase.
2022-10-20vect: Simplify first for shifted value generation [PR107240]Kewen Lin1-5/+6
As PR107240 shows, when both the value to be shifted and the count used for shifting are constants, it can be simplified to one constant value, and doesn't actually require to check if the current target supports vector shift operations or not. This patch uses a canonical way proposed by Richi to generate the shifted value, if it can be simplified, the shift operation would be gone, otherwise it's the same as before. It can help to fix the failures of vect-bitfield-write-{2,3}.c on Power. PR tree-optimization/107240 2022-10-20 Richard Biener <rguenther@suse.de> gcc/ChangeLog: * tree-vect-patterns.cc (vect_recog_bit_insert_pattern): Attempt to simplify shifted value first.
2022-10-20Add C++ library interface dataUlrich Drepper6-547/+2419
This patch adds a CSV file with information about the API of the standard C++ library. This information can be used in multiple ways. So far there are two use cases: - to generate the module export list for the standard C++ library - to create the name hints to compiler emits when symbols in the std namespace are not found Adding more uses can be easily done by potentially adding more columns to the CSV file and adding to the Python script which generates the output file. contrib/ 2022-10-18 Jonathan Wakely <jwakely@redhat.com> Ulrich Drepper <drepper@redhat.com> * gcc_update: Add rule for gcc/cp/std-name-hint.gperf. gcc/cp/ 2022-10-18 Jonathan Wakely <jwakely@redhat.com> Ulrich Drepper <drepper@redhat.com> * Make-lang.in: Add rules to generate std-name-hint.gperf. Adjust rule to generate std-name-hint.h to allow chain rule. * std-name-hint.h: Regenerated. * std-name-hint.gperf: This file is now generated. * cxxapi-data.csv: New file. CSV file with C++ API data. * gen-cxxapi-file.py: New file. Generate std-name-hint.gperf and module export source (in future).
2022-10-19Add assume support to VRP.Andrew MacLeod7-3/+342
This provides an assume_query class using rangers GORI module to determine what ranges would be applied to any SSA NAMES in the function if the return value were [1, 1]. Any parameter ranges are stored in the SSA_NAME_RANGE_INFO field, and ranger's inferred range machinery is then used to look these up and match them to assume call parameteres in the bodies of other functions.. PR c++/106654 gcc/ * gimple-range-gori.h (compute_operand_range): Make public. * gimple-range-infer.cc (gimple_infer_range::check_assume_func): New. (gimple_infer_range::gimple_infer_range): Check for assume calls. * gimple-range-infer.h (check_assume_func): Add prototype. * gimple-range.cc (assume_query::assume_range_p): New. (assume_query::range_of_expr): New. (assume_query::assume_query): New. (assume_query::calculate_op): New. (assume_query::calculate_phi): New. (assume_query::check_taken_edge): New. (assume_query::calculate_stmt): New. (assume_query::dump): New. * gimple-range.h (class assume_query): New. * tree-vrp.cc (pass_assumptions::execute): Add processing. gcc/testsuite/ * g++.dg/cpp23/attr-assume-opt.C: New.
2022-10-20Daily bump.GCC Administrator12-1/+322
2022-10-19c: C2x %wN, %wfN format checkingJoseph Myers8-37/+400
C2x adds printf and scanf wN and wfN length modifiers (wN for int_leastN_t / uint_leastN_t, also usable for intN_t and uintN_t which are now required to be the same type as the "least" versions when both are supported; wfN for int_fastN_t / uint_fastN_t). Add corresponding format checking support for those length modifiers, for all the standard integer conversion speciciers plus the recommended integer specifier %B. Note that, as with the %b support, this only deals with format checking, not other format handling elsewhere in the compiler (in particular, it doesn't add any -Wformat-overflow support; cf. Frolov Daniil's patch <https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600790.html> adding such support for %b and %B, which I think is still pending review). And of course library support is a separate matter for each library implementation (I hope to add corresponding glibc support in due course). None of the tables of format conversions for kinds of formats not supporting the new length modifiers are updated; they don't need updating because the entries not matching some length modifier listed for that kind of format can never be accessed, and the tables generally thus already only explicitly covered a sufficient initial subsequence of the length modifiers, rather than listing a full 13 possibilities before this patch or 21 after it. %w (as used for HOST_WIDE_INT in GCC-internal formats) comes after the new modifiers in the FMT_LEN_* enumeration, but that's not a problem because the tables don't actually use FMT_LEN_w entries; rather, such entries get rewritten at runtime once GCC knows the value of HOST_WIDE_INT in the GCC it's compiling. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c-family/ * c-format.h (enum format_lengths): Add FMT_LEN_w8, FMT_LEN_w16, FMT_LEN_w32, FMT_LEN_w64, FMT_LEN_wf8, FMT_LEN_wf16, FMT_LEN_wf32 and FMT_LEN_wf64. (NOARGUMENTS, NOLENGTHS): Update definitions. (T_I8, T2X_I8, T_I16, T2X_I16, T_I32, T2X_I32, T_I64, T2X_I64) (T_U8, T2X_U8, T_U16, T2X_U16, T_U32, T2X_U32, T_U64, T2X_U64) (T_IF8, T2X_IF8, T_IF16, T2X_IF16, T_IF32, T2X_IF32, T_IF64) (T2X_IF64, T_UF8, T2X_UF8, T_UF16, T2X_UF16, T_UF32, T2X_UF32) (T_UF64, T2X_UF64): New macros. * c-format.cc (printf_length_specs, scanf_length_specs): Add wN and wfN length modifiers. (print_char_table, scan_char_table): Add entries using wN and wfN length modifiers. gcc/testsuite/ * gcc.dg/format/format.h (int_least8_t, int_least16_t) (int_least32_t, int_least64_t, uint_least8_t, uint_least16_t) (uint_least32_t, uint_least64_t, int_fast8_t, int_fast16_t) (int_fast32_t, int_fast64_t, uint_fast8_t, uint_fast16_t) (uint_fast32_t, uint_fast64_t): New typedefs. * gcc.dg/format/c11-printf-1.c, gcc.dg/format/c11-scanf-1.c, gcc.dg/format/c2x-printf-1.c, gcc.dg/format/c2x-scanf-1.c, gcc.dg/format/ext-9.c: Add tests using wN and wfN length modifiers.
2022-10-19Always check result from build_<COND> in range-op-float.ccAldy Hernandez1-21/+26
A result of false from build_<COND> in range-ops means the result is final and needs no further adjustments. This patch documents this, and changes all uses to check the result. There should be no change in functionality. gcc/ChangeLog: * range-op-float.cc (build_le): Document result. (build_lt): Same. (build_ge): Same. (foperator_ge::op2_range): Check result of build_*. (foperator_unordered_le::op1_range): Same. (foperator_unordered_le::op2_range): Same. (foperator_unordered_gt::op1_range): Same. (foperator_unordered_gt::op2_range): Same. (foperator_unordered_ge::op1_range): Same. (foperator_unordered_ge::op2_range): Same.
2022-10-19analyzer: fix ICE on __builtin_ms_va_copy [PR105765]David Malcolm3-16/+897
gcc/analyzer/ChangeLog: PR analyzer/105765 * varargs.cc (get_BT_VALIST_ARG): Rename to... (get_va_copy_arg): ...this, and update logic for determining level of indirection of va_copy's argument to use type of argument, rather than looking at va_list_type_node, to correctly handle __builtin_ms_va_copy. (get_stateful_BT_VALIST_ARG): Rename to... (get_stateful_va_copy_arg): ...this. (va_list_state_machine::on_va_copy): Update for renaming. (region_model::impl_call_va_copy): Likewise. gcc/testsuite/ChangeLog: PR analyzer/105765 * gcc.dg/analyzer/stdarg-1-ms_abi.c: New test, based on stdarg-1.c. * gcc.dg/analyzer/stdarg-1-sysv_abi.c: Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-10-19libstdc++: Implement remaining P2474R2 changes to views::take/dropPatrick Palka2-0/+89
libstdc++-v3/ChangeLog: * include/std/ranges (views::__detail::__is_repeat_view): Define and later define a partial specialization. (views::__detail::__take_of_repeat_view): Declare and later define. (views::__detail::__drop_of_repeat_view): Likewise. (views::_Take::operator()): Return a repeat_view if the argument is a repeat_view as per P2474R2. (views::_Drop::operator()): Likewise. (repeat_view): Befriend __take/drop_of_repeat_view. * testsuite/std/ranges/repeat/1.cc (test04): New test.
2022-10-19c++: Mitigate -Wuseless-cast with classes [PR85043]Marek Polacek4-12/+54
-Wuseless-cast (not part of -Wall/-Wextra) warns here: struct S { }; void g (S&&); void f (S&& arg) { g (S(arg)); // warning: useless cast to type 'struct S' } which is wrong: the code will not compile without the cast because "arg" is an lvalue which cannot bind to S&&. This patch disables the warning when an object that isn't a prvalue is cast to a non-reference type. Therefore we still warn about the useless cast in "X(X{})". PR c++/85043 gcc/cp/ChangeLog: * typeck.cc (maybe_warn_about_useless_cast): Don't warn when a glvalue is cast to a non-reference type. gcc/ChangeLog: * doc/invoke.texi: Update documentation of -Wuseless-cast. gcc/testsuite/ChangeLog: * g++.dg/warn/Wuseless-cast.C: Remove dg-warning. * g++.dg/warn/Wuseless-cast3.C: New test.
2022-10-19testsuite: Default make check-g++ vs. tests for newest C++ standardJakub Jelinek1-1/+10
When adding tests for upcoming C++ version, one always has a dilemma whether to use explicit // { dg-options "-std=c++2b" } or -std=gnu++2b and similar, then the test works in all modes, but it might be forgotten later on to be converted into // { dg-do whatever { target c++23 } } test so that when 23 is tested by default and say 26 or 29 appears too, we test it also in those modes, or just go with // { dg-do whatever { target c++23 } } which has the disadvantage that it is skipped when testing by default and one only tests it if he asks for the newer version. The following patch changes it, such that it is safe to add // { dg-do whatever { target c++23 } } style tests and make those tested even in the default testing mode (when GXX_TESTSUITE_STDS or check-c++-all etc. aren't used). This is by searching for such dg-do lines and if there is an effective target newer than the latest by default tested language version, it will just use that language version instead of the default list. Without this change, the test would be UNSUPPORTED in currently all of 98 14 17 20 versions, with the patch it will be tested with a single 23 version. 2022-10-19 Jakub Jelinek <jakub@redhat.com> * lib/g++-dg.exp (g++-dg-runtest): When using defaulted std_list, if test has { dg-do * { target c++23 } } directive, use { 23 } with which the test will run instead of { 98 14 17 20 } which would make it UNSUPPORTED in all cases.
2022-10-19libstdc++: Fix typo in stride_view's operator- [PR107313]Patrick Palka2-1/+21
PR libstdc++/107313 libstdc++-v3/ChangeLog: * include/std/ranges (stride_view::_Iterator::operator-): Fix typo. * testsuite/std/ranges/adaptors/stride/1.cc (test03): New test.
2022-10-19testsuite: Fix up c2x-enum-1.c for 32-bit arches [PR107311]Jakub Jelinek1-1/+6
On Wed, Oct 19, 2022 at 02:57:59PM +0000, Joseph Myers wrote: > I think the type checked for e5a should be conditional on __LONG_MAX__ > > __INT_MAX__; everything else there should be OK regardless. This patch does that. 2022-10-19 Jakub Jelinek <jakub@redhat.com> PR c/107311 * gcc.dg/c2x-enum-1.c (enum e5): Expect e5a type inside of enum to be int rather than long if long isn't wider than int.
2022-10-19Use Value_Range when applying inferred ranges.Andrew MacLeod1-1/+1
Applying an inferred range is using int_range_ma as the temporary rather than the general purpose Value_Range. This causes it to trap if we have a non-integral inferred range. * gimple-range-cache.cc (ranger_cache::range_from_dom): Use Value_Range not int_range_max.
2022-10-19libstdc++/thread: Implement `_GLIBCXX_NPROCS` for WindowsLIU Hao1-0/+9
This makes `std::thread::hardware_concurrency()` return the number of logical processors, instead of zero. libstdc++-v3/ChangeLog: * src/c++11/thread.cc (get_nprocs): Add new implementation for native Windows targets
2022-10-19[PR tree-optimization/107312] Make range_true_and_false work with 1-bit ↵Aldy Hernandez3-0/+15
signed types. range_true_and_false() returns a range of [0,1], which for a 1-bit signed integer gets passed to the irange setter as [0, -1]. These endpoints are out of order and cause an ICE. Through some dumb luck, the legacy code swaps out of order endpoints, because old VRP would sometimes pass endpoints reversed, depending on the setter to fix them. This swapping does not happen for non-legacy, hence the ICE. The right thing to do (apart from killing legacy and 1-bit signed integers ;-)), is to avoid passing out of order endpoints for 1-bit signed integers. For that matter, a range of [-1, 0] (signed) or [0, 1] (unsigned) is just varying. PR tree-optimization/107312 gcc/ChangeLog: * range.h (range_true_and_false): Special case 1-bit signed types. * value-range.cc (range_tests_misc): New test. gcc/testsuite/ChangeLog: * gcc.target/i386/pr107312.c: New test.
2022-10-19gcc: Add 'mcf' thread model support from mcfgthreadLIU Hao16-15/+98
This patch adds the new thread model `mcf`, which implements mutexes and condition variables with the mcfgthread library. Source code for mcfgthread is available at <https://github.com/lhmouse/mcfgthread>. config/ChangeLog: * gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread model gcc/ChangeLog: * config/i386/mingw-mcfgthread.h: New file * config/i386/mingw32.h: Add builtin macro and default libraries for mcfgthread when thread model is `mcf` * config.gcc: Include 'i386/mingw-mcfgthread.h' when thread model is `mcf` * configure.ac: Recognize `mcf` as a valid thread model * config.in: Regenerate * configure: Regenerate libatomic/ChangeLog: * configure.tgt: Add new case for `mcf` thread model libgcc/ChangeLog: * config.host: Add new cases for `mcf` thread model * config/i386/gthr-mcf.h: New file * config/i386/t-mingw-mcfgthread: New file * config/i386/t-slibgcc-cygming: Add mcfgthread for libgcc DLL * configure: Regenerate libstdc++-v3/ChangeLog: * libsupc++/atexit_thread.cc (__cxa_thread_atexit): Use implementation from mcfgthread if available * libsupc++/guard.cc (__cxa_guard_acquire, __cxa_guard_release, __cxa_guard_abort): Use implementations from mcfgthread if available * configure: Regenerate
2022-10-19pch: Fix streaming of strings with embedded null bytesLewis Hyatt9-10/+68
When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains (whether they live in GC-controlled memory or not) will be marked for PCH output by the routine gt_pch_note_object in ggc-common.cc. This routine special-cases plain char* strings, and in particular it uses strlen() to get their length. Thus it does not handle strings with embedded null bytes, but it is possible for something PCH cares about (such as a string literal token in a macro definition) to contain such embedded nulls. To fix that up, add a new GTY option "string_length" so that gt_pch_note_object can be informed the actual length it ought to use, and use it in the relevant libcpp structs (cpp_string and ht_identifier) accordingly. gcc/ChangeLog: * gengtype.cc (output_escaped_param): Add missing const. (get_string_option): Add missing check for option type. (walk_type): Support new "string_length" GTY option. (write_types_process_field): Likewise. * ggc-common.cc (gt_pch_note_object): Add optional length argument. * ggc.h (gt_pch_note_object): Adjust prototype for new argument. (gt_pch_n_S2): Declare... * stringpool.cc (gt_pch_n_S2): ...new function. * doc/gty.texi: Document new GTY((string_length)) option. libcpp/ChangeLog: * include/cpplib.h (struct cpp_string): Use new "string_length" GTY. * include/symtab.h (struct ht_identifier): Likewise. gcc/testsuite/ChangeLog: * g++.dg/pch/pch-string-nulls.C: New test. * g++.dg/pch/pch-string-nulls.Hs: New test.
2022-10-19Merge branch 'master' into devel/sphinxMartin Liska191-1774/+8326
2022-10-19avr: remove useless @tie{} directivesMartin Liska1-3/+3
gcc/ChangeLog: * doc/extend.texi: Remove useless @tie{} directives.
2022-10-19SRA: Limit replacement creation for accesses propagated from LHSsMartin Jambor2-0/+34
PR 107206 is fallout from the fix to PR 92706 where we started propagating accesses across assignments also from LHS to RHS of assignments so that we would not do harmful total scalarization of the aggregates on the RHS. But this can lead to new scalarization of these aggregates and in the testcase of PR 107206 these can appear in superfluous uses of un-initialized values and spurious warnings. Fixed by making sure the the accesses created by propagation in this direction are only used as a basis for replacements when the structure would be totally scalarized anyway. gcc/ChangeLog: 2022-10-18 Martin Jambor <mjambor@suse.cz> PR tree-optimization/107206 * tree-sra.cc (struct access): New field grp_result_of_prop_from_lhs. (analyze_access_subtree): Do not create replacements for accesses with this flag when not toally scalarizing. (propagate_subaccesses_from_lhs): Set the new flag. gcc/testsuite/ChangeLog: 2022-10-18 Martin Jambor <mjambor@suse.cz> PR tree-optimization/107206 * g++.dg/tree-ssa/pr107206.C: New test.
2022-10-19IBM zSystems: Fix function_ok_for_sibcall [PR106355]Stefan Schulze Frielinghaus5-23/+100
For a parameter with BLKmode we cannot use REG_NREGS in order to determine the number of consecutive registers. Streamlined this with the implementation of s390_function_arg. Fix some indentation whitespace, too. gcc/ChangeLog: PR target/106355 * config/s390/s390.cc (s390_call_saved_register_used): For a parameter with BLKmode fix determining number of consecutive registers. gcc/testsuite/ChangeLog: * gcc.target/s390/pr106355.h: Common code for new tests. * gcc.target/s390/pr106355-1.c: New test. * gcc.target/s390/pr106355-2.c: New test. * gcc.target/s390/pr106355-3.c: New test.
2022-10-19xtensa: Prepare the transition from Reload to LRATakayuki 'January June' Suwa7-24/+99
This patch provides the first step in the transition from Reload to LRA in Xtensa. gcc/ChangeLog: * config/xtensa/xtensa-protos.h (xtensa_split1_finished_p, xtensa_split_DI_reg_imm): New prototypes. * config/xtensa/xtensa.cc (xtensa_split1_finished_p, xtensa_split_DI_reg_imm, xtensa_lra_p): New functions. (TARGET_LRA_P): Replace the dummy hook with xtensa_lra_p. (xt_true_regnum): Rework. * config/xtensa/xtensa.h (CALL_REALLY_USED_REGISTERS): Switch from CALL_USED_REGISTERS, and revise the comment. * config/xtensa/constraints.md (Y): Use !xtensa_split1_finished_p() instead of can_create_pseudo_p(). * config/xtensa/predicates.md (move_operand): Ditto. * config/xtensa/xtensa.md: Add two new split patterns: - splits DImode immediate load into two SImode ones - puts out-of-constraint SImode constants into the constant pool * config/xtensa/xtensa.opt (-mlra): New target-specific option for testing purpose.
2022-10-19s390: Fix bootstrap error with checking and -m31.Robin Dapp1-3/+4
For a while already we hit an ICE when bootstrapping with -m31 and --enable-checking=all. ../../../../libgfortran/ieee/ieee_helper.c: In function 'ieee_class_helper_16': ../../../../libgfortran/ieee/ieee_helper.c:77:3: internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 77 | } | ^ ../../../../libgfortran/ieee/ieee_helper.c:87:1: note: in expansion of macro 'CLASSMACRO' 87 | CLASSMACRO(16) | ^~~~~~~~~~ This patch fixes the problem by first checking for reload_completed and also ensuring that REGNO is only called on reg operands rather than subregs. gcc/ChangeLog: * config/s390/s390.md: Move reload_completed and check operands for REG_P.
2022-10-19expr: Fix ICE on BFmode -> SFmode conversion of constant [PR107262]Jakub Jelinek2-2/+22
I forgot to handle the case where lowpart_subreg returns a VOIDmode CONST_INT, in that case convert_mode_scalar obviously doesn't work. The following patch fixes that. 2022-10-19 Jakub Jelinek <jakub@redhat.com> PR middle-end/107262 * expr.cc (convert_mode_scalar): For BFmode -> SFmode conversions of constants, use simplify_unary_operation if fromi has VOIDmode instead of recursive convert_mode_scalar. * gcc.dg/pr107262.c: New test.
2022-10-19match.pd: Add 2 TYPE_OVERFLOW_SANITIZED checks [PR106990]Jakub Jelinek2-4/+35
As requested in the PR, this adds 2 TYPE_OVERFLOW_SANITIZED checks and corresponding testcase. 2022-10-19 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/106990 * match.pd ((~X - ~Y) -> Y - X, -x & 1 -> x & 1): Guard with !TYPE_OVERFLOW_SANITIZED (type). * c-c++-common/ubsan/pr106990.c: New test.
2022-10-19libstdc++-v3: Implement {,b}float16_t nextafter and some fixes [PR106652]Jakub Jelinek4-9/+223
The following patch implements nextafter for std::{,b}float16_t, though right now only without constexpr support, and adds a testcase for it. The testcase unfortunately relevealed I've screwed up testing of my last patch. I've tested earlier version of the patch with --target_board=unix/-std=c++23 but didn't test the final version with that RUNTESTFLAGS, so missed an invalid call to std::sph_neumann (too many arguments) in the test. And, I've made a typo in the guard for numeric_limits (the reason for the guard is I wanted to avoid defining a large macro that nothing will then use because the std::{,b}float*_t types are C++23 only) and so numeric_limits wasn't specialized for the types at all but testsuite/18_support/headers/limits/synopsis_cxx23.cc test didn't detect that. In the nextafter implementation I'm calling __builtin_nextafterf to get various required side-effects for nextafter from 0/-0, or from max to inf or from min to largest subnormal to avoid needing to set errno inline, or use inline asm specific for each processor to force math evaluation barriers. Dunno if #ifdef __INT16_TYPE__ using __float16_int_type = __INT16_TYPE__; #else using __float16_int_type = short int; #endif isn't too ugly, perhaps we could just blindly use short int and hope or even assert it has the same size as _Float16 or __gnu_cxx::__bfloat16_t? Only aarch64, arm, csky, gcn, x86, nvptx and riscv support these types and all of them have 16-bit short (I think the only target with some other short size is avr with certain command line switches where both short and int are 8-bit, but such mode isn't compatible with C and C++ requirements). 2022-10-19 Jakub Jelinek <jakub@redhat.com> PR c++/106652 * include/std/limits: Fix a typo, 202202L -> 202002L. (numeric_limits::<_Float16>::radix, numeric_limits::<_Float32>::radix, numeric_limits::<_Float64>::radix, numeric_limits::<_Float128>::radix, numeric_limits::<__gnu_cxx::__bfloat16_t>::radix): Use __FLT_RADIX__ macro instead of type specific macros. * include/c_global/cmath (nextafter(_Float16, _Float16)): New overload. (nextafter(__gnu_cxx::__bfloat16_t, __gnu_cxx::__bfloat16_t)): Likewise. * testsuite/26_numerics/headers/cmath/functions_std_c++23.cc (test_functions): Uncomment nextafter test. Fix up sph_neumann call. * testsuite/26_numerics/headers/cmath/nextafter_c++23.cc: New test.
2022-10-19i386: Fix up __bf16 handling on ia32Jakub Jelinek2-10/+9
Last night's testing of the libstdc++ changes revealed a problem in the __bf16 backend registration (while _Float16 seems ok). The problem is that for both BFmode and HFmode we require TARGET_SSE2, the generic code creates {,b}float16_type_node only if that is true at the start of the TU and the builtins for the type are only created in that case (many __builtin_*f16 for HFmode and __builtin_nansf16b for BFmode). Now, for _Float16 I've kept what the code did previously, if float16_type_node from generic code is NULL, create ix86_float16_type_node and register _Float16 for it, but for __bf16 I've changed it so that if bfloat16_type_node from generic code is NULL, ix86_register_bf16_builtin_type makes bfloat16_type_node non-NULL. This has an unfortunate consequence though, __STDCPP_BFLOAT16_T__ is predefined for C++23, __BFLT16_*__ macros are predefined as well, but the type doesn't really work (errors whenever it is used) and the builtin isn't defined. The following patch fixes that by going with what we do for HFmode, bfloat16_type_node stays as initialized by generic code and we have a local type for backend use. On the other side, nothing used ix86_bf16_ptr_type_node so that is now dropped. 2022-10-19 Jakub Jelinek <jakub@redhat.com> * config/i386/i386-builtins.cc (ix86_bf16_ptr_type_node): Remove. (ix86_bf16_type_node): New variable. (ix86_register_bf16_builtin_type): If bfloat16_type_node is NULL from generic code, set only ix86_bf16_type_node to a new REAL_TYPE rather than bfloat16_type_node, otherwise set ix86_bf16_type_node to bfloat16_type_node. Register __bf16 on ix86_bf16_type_node rather than bfloat16_type_node. Don't initialize unused ix86_bf16_ptr_type_node. * config/i386/i386-builtin-types.def (BFLOAT16): Use ix86_bf16_type_node rather than bfloat16_type_node.
2022-10-19tree-optimization/106781 - adjust cgraph lhs removalRichard Biener2-8/+24
The following matches up the cgraph code removing LHS of a noreturn call with what fixup_noreturn_call does which gets along without inserting a definition, fixing the ICE resulting from having no place to actually insert that new def. PR tree-optimization/106781 * cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): Copy LHS removal from fixup_noreturn_call. * gcc.dg/pr106781.c: New testcase.
2022-10-19libsanitizer: regenerate configureMartin Liska1-2/+2
libsanitizer/ChangeLog: * configure: Regenerate.
2022-10-19Canonicalize vec_perm index to make the first index come from the first vector.liuhongt2-0/+33
Fix unexpected non-canon form from gimple vector selector. gcc/ChangeLog: PR target/107271 * config/i386/i386-expand.cc (ix86_vec_perm_index_canon): New. (expand_vec_perm_shufps_shufps): Call ix86_vec_perm_index_canon gcc/testsuite/ChangeLog: * gcc.target/i386/pr107271.c: New test.
2022-10-19Daily bump.GCC Administrator10-1/+413
2022-10-18c: Diagnose "enum tag;" after definition [PR107164]Joseph Myers4-0/+39
As noted in bug 101764, a declaration "enum tag;" is invalid in standard C after a definition, as well as when no definition is visible; we had a pedwarn-if-pedantic for the forward declaration case, but were missing one for the other case. Add that missing diagnostic (if pedantic only). (These diagnostics will need to be appropriately conditioned when support is added for C2x enums with fixed underlying type, since "enum tag : type;" is OK both before and after a definition.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/107164 gcc/c/ * c-decl.cc (shadow_tag_warned): If pedantic, diagnose "enum tag;" with previous declaration visible. gcc/testsuite/ * gcc.dg/c99-tag-4.c, gcc.dg/c99-tag-5.c, gcc.dg/c99-tag-6.c: New tests.
2022-10-18testsuite: Only run -fcf-protection test on i?86/x86_64 [PR107213]Marek Polacek1-0/+1
This test fails on non-i?86/x86_64 targets because on those targets we get error: '-fcf-protection=full' is not supported for this target so this patch limits where the test is run. PR testsuite/107213 gcc/testsuite/ChangeLog: * c-c++-common/pointer-to-fn1.c: Only run on i?86/x86_64.
2022-10-18libiberty: Fix C89-isms in configure testsFlorian Weimer2-6/+22
libiberty/ * acinclude.m4 (ac_cv_func_strncmp_works): Add missing int return type and parameter list to the definition of main. Include <stdlib.h> and <string.h> for prototypes. (ac_cv_c_stack_direction): Add missing int return type and parameter list to the definitions of main, find_stack_direction. Include <stdlib.h> for exit prototype. * configure: Regenerate.
2022-10-18libsanitizer: Avoid implicit function declaration in configure testFlorian Weimer2-3/+5
libsanitizer/ * configure.ac (sanitizer_supported): Include <unistd.h> for syscall prototype. * configure: Regenerate.
2022-10-18c++ modules: stream non-trailing default targs [PR105045]Patrick Palka3-14/+19
This fixes the below testcase in which we neglect to stream the default argument for T only because the subsequent parameter U doesn't also have a default argument. PR c++/105045 gcc/cp/ChangeLog: * module.cc (trees_out::tpl_parms_fini): Don't assume default template arguments must be trailing. (trees_in::tpl_parms_fini): Likewise. gcc/testsuite/ChangeLog: * g++.dg/modules/pr105045_a.C: New test. * g++.dg/modules/pr105045_b.C: New test.
2022-10-18libstdc++: Implement ranges::stride_view from P1899R3Patrick Palka2-0/+424
libstdc++-v3/ChangeLog: * include/std/ranges (stride_view): Define. (stride_view::_Iterator): Define. (views::__detail::__can_stride_view): Define. (views::_Stride, views::stride): Define. * testsuite/std/ranges/adaptors/stride/1.cc: New test.