aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-01-31c: Fix ICE for nested enum redefinitions with/without fixed underlying type ↵Joseph Myers3-2/+19
[PR112571] Bug 112571 reports an ICE-on-invalid for cases where an enum is defined, without a fixed underlying type, inside the enum type specifier for a definition of that same enum with a fixed underlying type. The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a case where it is NULL. Avoid this by clearing ENUM_FIXED_UNDERLYING_TYPE_P in thie case of inconsistent definitions. Bootstrapped wth no regressions for x86_64-pc-linux-gnu. PR c/112571 gcc/c/ * c-decl.cc (start_enum): Clear ENUM_FIXED_UNDERLYING_TYPE_P when defining without a fixed underlying type an enumeration previously declared with a fixed underlying type. gcc/testsuite/ * gcc.dg/c23-enum-9.c, gcc.dg/c23-enum-10.c: New tests.
2024-01-31match: Fix vcond into conditional op folding [PR113607].Robin Dapp4-5/+58
In PR113607 we see an invalid fold of _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, ... }); vect_prephitmp_129.51_282 = _429; vect_iftmp.55_287 = VEC_COND_EXPR <mask_patt_209.54_286, vect_prephitmp_129.51_282, vect_cst__262>; to Applying pattern match.pd:9607, gimple-match-10.cc:3817 gimple_simplified to vect_iftmp.55_287 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, ... }); where we essentially use COND_SHL's else instead of VEC_COND_EXPR's. This patch adjusts the corresponding match.pd pattern and makes it only match when the else values are the same. That, however, causes the exact test case for which this pattern was introduced for to fail. Therefore XFAIL it for now. gcc/ChangeLog: PR middle-end/113607 * match.pd: Make sure else values match when folding a vec_cond into a conditional operation. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/pre_cond_share_1.c: XFAIL. * gcc.target/riscv/rvv/autovec/pr113607-run.c: New test. * gcc.target/riscv/rvv/autovec/pr113607.c: New test.
2024-01-31c++: add deprecation notice for -fconcepts-tsMarek Polacek2-1/+8
We plan to remove -fconcepts-ts in GCC 15 and thus remove the flag_concepts_ts code. This note is an admonishing reminder to convert the Concepts TS code to C++20 Concepts. gcc/c-family/ChangeLog: * c-opts.cc (c_common_post_options): Add an inform saying that -fconcepts-ts is deprecated and will be removed in GCC 15. gcc/ChangeLog: * doc/invoke.texi: Mention that -fconcepts-ts was deprecated in GCC 14.
2024-01-31Fix ICE with -g and -std=c23 when forming composite types [PR113438]Martin Uecker2-0/+12
Set TYPE_STUB_DECL to an artificial decl when creating a new structure as a composite type. PR c/113438 gcc/c/ * c-typeck.cc (composite_type_internal): Set TYPE_STUB_DECL. gcc/testsuite/ * gcc.dg/pr113438.c: New test.
2024-01-31uninit-pr108968-register.c: use __UINTPTR_TYPE__ for LLP64Jonathan Yong1-1/+1
Ensure sp variable is long enough by using __UINTPTR_TYPE__ for rsp. gcc/testsuite/ChangeLog: * c-c++-common/analyzer/uninit-pr108968-register.c: Use __UINTPTR_TYPE__ instead of unsigned long for LLP64.
2024-01-31modula2: tidyup patchGaius Mulley2-3/+3
This patch improves a comment and also adds the location tokenno to possibly exported idents as they are encountered. gcc/m2/ChangeLog: * gm2-compiler/M2Comp.mod (Pass0CheckMod): Tidy up comment. * gm2-compiler/P1Build.bnf (PossiblyExportIdent): Replace PushTF with PushTFtok. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
2024-01-31PR modula2/111627 Excess test fails with a case-preserving-case-insensitive ↵Gaius Mulley4-8/+8
source tree This patch renames gm2 testsuite modules whose names conflict with library modules. The conflict is not seen on case preserving case sensitive file systems. gcc/testsuite/ChangeLog: PR modula2/111627 * gm2/pim/pass/stdio.mod: Moved to... * gm2/pim/pass/teststdio.mod: ...here. * gm2/pim/run/pass/builtins.mod: Moved to... * gm2/pim/run/pass/testbuiltins.mod: ...here. * gm2/pim/run/pass/math.mod: Moved to... * gm2/pim/run/pass/testmath.mod: ...here. * gm2/pim/run/pass/math2.mod: Moved to... * gm2/pim/run/pass/testmath2.mod: ...here. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
2024-01-31AArch64: relax cbranch tests to accepted inverted branches [PR113502]Tamar Christina2-12/+12
Recently something in the midend had started inverting the branches by inverting the condition and the branches. While this is fine, it makes it hard to actually test. In RTL I disable scheduling and BB reordering to prevent this. But in GIMPLE there seems to be nothing I can do. __builtin_expect seems to have no impact on the change since I suspect this is happening during expand where conditions can be flipped regardless of probability during compare_and_branch. Since the mid-end has plenty of correctness tests, this weakens the backend tests to just check that a correct looking sequence is emitted. gcc/testsuite/ChangeLog: PR testsuite/113502 * gcc.target/aarch64/sve/vect-early-break-cbranch.c: Ignore exact branch. * gcc.target/aarch64/vect-early-break-cbranch.c: Likewise.
2024-01-31hwasan: Remove testsuite check for a complaint message [PR112644]Tamar Christina1-1/+0
With recent updates to hwasan runtime libraries, the error reporting for this particular check is has been reworked. I would question why it has lost this message. To me it looks strange that num_descriptions_printed is incremented whenever we call PrintHeapOrGlobalCandidate whether that function prints anything or not. (See PrintAddressDescription in libsanitizer/hwasan/hwasan_report.cpp). The message is no longer printed because we increment this num_descriptions_printed variable indicating that we have found some description. I would like to question this upstream, but it doesn't look that much of a problem and if pressed for time we should just change our testsuite. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. gcc/testsuite/ChangeLog: PR sanitizer/112644 * c-c++-common/hwasan/hwasan-thread-clears-stack.c: Update testcase.
2024-01-31hwasan: instrument new memory and string functions [PR112644]Tamar Christina3-11/+17
Recent libhwasan updates[1] intercept various string and memory functions. These functions have checking in them, which means there's no need to inline the checking. This patch marks said functions as intercepted, and adjusts a testcase to handle the difference. It also looks for HWASAN in a check in expand_builtin. This check originally is there to avoid using expand to inline the behaviour of builtins like memset which are intercepted by ASAN and hence which we rely on the function call staying as a function call. With the new reliance on function calls in HWASAN we need to do the same thing for HWASAN too. HWASAN and ASAN don't seem to however instrument the same functions. Looking into libsanitizer/sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc it looks like the common ones are memset, memmove and memcpy. The rest of the routines for asan seem to be defined in compiler-rt/lib/asan/asan_interceptors.h however compiler-rt/lib/hwasan/ does not have such a file but it does have compiler-rt/lib/hwasan/hwasan_platform_interceptors.h which it looks like is forcing off everything but memset, memmove, memcpy, memcmp and bcmp. As such I've taken those as the final list that hwasan currently supports. This also means that on future updates this list should be cross checked. [1] https://discourse.llvm.org/t/hwasan-question-about-the-recent-interceptors-being-added/75351 gcc/ChangeLog: PR sanitizer/112644 * asan.h (asan_intercepted_p): Incercept memset, memmove, memcpy and memcmp. * builtins.cc (expand_builtin): Include HWASAN when checking for builtin inlining. gcc/testsuite/ChangeLog: PR sanitizer/112644 * c-c++-common/hwasan/builtin-special-handling.c: Update testcase. Co-Authored-By: Matthew Malcomson <matthew.malcomson@arm.com>
2024-01-31libsanitizer: Sync fixes for asan interceptors from upstreamTamar Christina1-13/+12
This cherry-picks and squashes the differences between commits d3e5c20ab846303874a2a25e5877c72271fc798b..76e1e45922e6709392fb82aac44bebe3dbc2ea63 from LLVM upstream from compiler-rt/lib/hwasan/ to GCC on the changes relevant for GCC. This is required to fix the linked PR. As mentioned in the PR the last sync brought in a bug from upstream[1] where operations became non-recoverable and as such the tests in AArch64 started failing. This cherry picks the fix and there are minor updates needed to GCC after this to fix the cases. [1] https://github.com/llvm/llvm-project/pull/74000 PR sanitizer/112644 Cherry-pick llvm-project revision 672b71cc1003533460a82f06b7d24fbdc02ffd58, 5fcf3bbb1acfe226572474636714ede86fffcce8, 3bded112d02632209bd55fb28c6c5c234c23dec3 and 76e1e45922e6709392fb82aac44bebe3dbc2ea63.
2024-01-31middle-end/110176 - wrong zext (bool) <= (int) 4294967295u foldingRichard Biener2-6/+52
The following fixes a wrong pattern that didn't match the behavior of the original fold_widened_comparison in that get_unwidened returned a constant always in the wider type. But here we're using (int) 4294967295u without the conversion applied. Fixed by doing as earlier in the pattern - matching constants only if the conversion was actually applied. PR middle-end/110176 * match.pd (zext (bool) <= (int) 4294967295u): Make sure to match INTEGER_CST only without outstanding conversion. * gcc.dg/torture/pr110176.c: New testcase.
2024-01-31aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]Alex Coplan2-1/+29
The PR shows us ICEing due to an unrecognizable TFmode save emitted by aarch64_process_components. The problem is that for T{I,F,D}mode we conservatively require mems to be in range for x-register ldp/stp. That is because (at least for TImode) it can be allocated to both GPRs and FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is a q-register load/store. As Richard pointed out in the PR, aarch64_get_separate_components already checks that the offsets are suitable for a single load, so we just need to choose a mode in aarch64_reg_save_mode that gives the full q-register range. In this patch, we choose V16QImode as an alternative 16-byte "bag-of-bits" mode that doesn't have the artificial range restrictions imposed on T{I,F,D}mode. For T{F,D}mode in GCC 15 I think we could consider relaxing the restriction imposed in aarch64_classify_address, as typically T{F,D}mode should be allocated to FPRs. But such a change seems too invasive to consider for GCC 14 at this stage (let alone backports). Fortunately the new flexible load/store pair patterns in GCC 14 allow this mode change to work without further changes. The backports are more involved as we need to adjust the load/store pair handling to cater for V16QImode in a few places. Note that for the testcase we are relying on the torture options to add -funroll-loops at -O3 which is necessary to trigger the ICE on trunk (but not on the 13 branch). gcc/ChangeLog: PR target/111677 * config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use V16QImode for the full 16-byte FPR saves in the vector PCS case. gcc/testsuite/ChangeLog: PR target/111677 * gcc.target/aarch64/torture/pr111677.c: New test.
2024-01-31testsuite: i386: Disable .eh_frame in gcc.target/i386/auto-init-5.c etc.Rainer Orth2-2/+2
The gcc.target/i386/auto-init-5.c and gcc.target/i386/auto-init-6.c tests FAIL on 64-bit Solaris/x86 with the native assembler: FAIL: gcc.target/i386/auto-init-5.c scan-assembler-times \\\\.long\\t0 14 FAIL: gcc.target/i386/auto-init-6.c scan-assembler-times long\\t0 8 /bin/as doesn't fully support the CFI directives, so the .eh_frame sections are emitted directly and contain .long. Since .eh_frame doesn't matter for those tests, this patch disables its generation in the first place. Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu. 2024-01-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: * gcc.target/i386/auto-init-5.c: Add -fno-asynchronous-unwind-tables to dg-options. * gcc.target/i386/auto-init-6.c: Likewise.
2024-01-31tree-optimization/111444 - avoid insertions when skipping defsRichard Biener2-9/+39
The following avoids inserting expressions for IPA CP discovered equivalences into the VN hashtables when we are optimistically skipping may-defs in the attempt to prove it's redundant. PR tree-optimization/111444 * tree-ssa-sccvn.cc (vn_reference_lookup_3): Do not use vn_reference_lookup_2 when optimistically skipping may-defs. * gcc.dg/torture/pr111444.c: New testcase.
2024-01-31testsuite: Require ucn in g++.dg/cpp0x/udlit-extended-id-1.CRainer Orth1-0/+1
g++.dg/cpp0x/udlit-extended-id-1.C FAILs on Solaris/SPARC and x86 with the native assembler: UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++14 compilation failed to produce executable FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 (test for excess errors) UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 compilation failed to produce executable FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 (test for excess errors) UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 compilation failed to produce executable /bin/as doesn't support UCN identifiers: /usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: invalid character (0xcf) /usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: invalid character (0x80) /usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: statement syntax /usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: statement syntax [...] To avoid this, this patch requires ucn support. Tested on i386-pc-solaris2.11 (as and gas), sparc-sun-solaris2.11 (as and gas), and i686-pc-linux-gnu. 2024-01-30 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: * g++.dg/cpp0x/udlit-extended-id-1.C: Require ucn support.
2024-01-31tree-optimization/113630 - invalid code hoistingRichard Biener2-0/+18
The following avoids code hoisting (but also PRE insertion) of expressions that got value-numbered to another one that are not a valid replacement (but still compute the same value). This time because the access path ends in a structure with different size, meaning we consider a related access as not trapping because of the size of the base of the access. PR tree-optimization/113630 * tree-ssa-pre.cc (compute_avail): Avoid registering a reference with a representation with not matching base access size. * gcc.dg/torture/pr113630.c: New testcase.
2024-01-31simplify-rtx: Fix up last argument to simplify_gen_unary [PR113656]Jakub Jelinek2-1/+13
When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF)) or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into (float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call simplify_gen_unary with incorrect op_mode argument, it should be the argument's mode, but we call it with the outer mode instead. As these are all floating point operations, the argument always has non-VOIDmode and so we can just use that mode (as done in similar simplifications a few lines later), but neither FLOAT_TRUNCATE nor FLOAT_EXTEND are operations that should have the same modes of operand and result. This bug hasn't been a problem for years because normally op_mode is used only if the mode of op is VOIDmode, otherwise it is redundant, but r10-2139 added an assertion in some spots that op_mode is right even in such cases. 2024-01-31 Jakub Jelinek <jakub@redhat.com> PR rtl-optimization/113656 * simplify-rtx.cc (simplify_context::simplify_unary_operation_1) <case FLOAT_TRUNCATE>: Fix up last argument to simplify_gen_unary. * gcc.target/i386/pr113656.c: New test.
2024-01-31dwarf2out: Fix ICE on large _BitInt in loc_list_from_tree_1 [PR113637]Jakub Jelinek2-0/+16
This spot uses SCALAR_INT_TYPE_MODE which obviously ICEs for large/huge BITINT_TYPE types which have BLKmode. But such large BITINT_TYPEs certainly don't fit into DWARF2_ADDR_SIZE either, so we can just assume it would be false if type has BLKmode. 2024-01-31 Jakub Jelinek <jakub@redhat.com> PR debug/113637 * dwarf2out.cc (loc_list_from_tree_1): Assume integral types with BLKmode are larger than DWARF2_ADDR_SIZE. * gcc.dg/bitint-80.c: New test.
2024-01-31lower-bitint: Fix up VIEW_CONVERT_EXPR handling in handle_operand_addr ↵Jakub Jelinek2-0/+18
[PR113639] Yet another spot where we need to treat VIEW_CONVERT_EXPR differently from NOP_EXPR/CONVERT_EXPR. 2024-01-31 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113639 * gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr): For VIEW_CONVERT_EXPR set rhs1 to its operand. * gcc.dg/bitint-79.c: New test.
2024-01-31libstdc++: Enable std::text_encoding for darwin and FreeBSDJonathan Wakely3-0/+9
The <xlocale.h> header is needed for newlocale and locale_t on these targets. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_CHECK_TEXT_ENCODING): Use <xlocale.h> if needed for newlocale. * configure: Regenerate. * src/c++26/text_encoding.cc: Use <xlocale.h>. Reviewed-by: Iain Sandoe <iain@sandoe.co.uk>
2024-01-31libstdc++: Add "ASCII" as an alias for std::text_encoding::id::ASCIIJonathan Wakely3-2/+30
As noted in LWG 4043, "ASCII" is not an alias for any known registered character encoding, so std::text_encoding("ASCII").mib() == id::other. Add the alias "ASCII" to the implementation-defined superset of aliases for that encoding. libstdc++-v3/ChangeLog: * include/bits/text_encoding-data.h: Regenerate. * scripts/gen_text_encoding_data.py: Add extra_aliases dict containing "ASCII". * testsuite/std/text_encoding/cons.cc: Check "ascii" is known. Co-authored-by: Ewan Higgs <ewan.higgs@gmail.com> Signed-off-by: Ewan Higgs <ewan.higgs@gmail.com>
2024-01-31libstdc++: Add all supported headers to lists in the manualJonathan Wakely3-32/+191
libstdc++-v3/ChangeLog: * doc/xml/manual/using.xml: Update tables of supported headers. * doc/html/*: Regenerate.
2024-01-31libstdc++: Fix -Wshift-count-overflow warning in std::bitsetJonathan Wakely1-6/+7
This shift only happens if the unsigned long long type is wider than unsigned long but the compiler warns when it sees the shift, without caring if it's reachable. Use the preprocessor to compare the sizes and just reuse _M_to_ulong() if sizeof(long) == sizeof(long long). libstdc++-v3/ChangeLog: * include/std/bitset (_Base_bitset::_M_do_to_ullong): Avoid -Wshift-count-overflow warning.
2024-01-31tree-optimization/113670 - gather/scatter to/from hard registersRichard Biener2-0/+21
The following makes sure we're not taking the address of hard registers when vectorizing appearant gathers or scatters to/from them. PR tree-optimization/113670 * tree-vect-data-refs.cc (vect_check_gather_scatter): Make sure we can take the address of the reference base. * gcc.target/i386/pr113670.c: New testcase.
2024-01-31AVR: Add AVR64DU and some older devices.Georg-Johann Lay2-4/+10
gcc/ * config/avr/avr-mcus.def: Add AVR64DU28, AVR64DU32, ATA5787, ATA5835, ATtiny64AUTO, ATA5700M322. * doc/avr-mmcu.texi: Rebuild.
2024-01-31strub: drop nonaliased parm from build_ref_type_for [PR113394]Alexandre Oliva2-26/+11
Variant type copies can't have their own alias sets any more, and it's not like setting them affected the pointed-to objects anyway. for gcc/ChangeLog PR debug/113394 * ipa-strub.cc (build_ref_type_for): Drop nonaliased. Adjust caller. for gcc/testsuite/ChangeLog PR debug/113394 * gcc.dg/strub-internal-pr113394.c: New.
2024-01-310From: Alexandre Oliva <oliva@adacore.com>Alexandre Oliva5-4/+68
strub: introduce STACK_ADDRESS_OFFSET Since STACK_POINTER_OFFSET is not necessarily at the boundary between caller- and callee-owned stack, as desired by __builtin_stack_address(), and using it as if it were or not causes problems, introduce a new macro so that ports can define it suitably, without modifying STACK_POINTER_OFFSET. for gcc/ChangeLog PR middle-end/112917 PR middle-end/113100 * builtins.cc (expand_builtin_stack_address): Use STACK_ADDRESS_OFFSET. * doc/extend.texi (__builtin_stack_address): Adjust. * config/sparc/sparc.h (STACK_ADDRESS_OFFSET): Define. * doc/tm.texi.in (STACK_ADDRESS_OFFSET): Document. * doc/tm.texi: Rebuilt.
2024-01-31c: Fix ICEs casting expressions with integer constant operands to bool ↵Joseph Myers17-9/+130
[PR111059, PR111911] C front-end bugs 111059 and 111911 both report ICEs with conversions to boolean of expressions with integer constant operands that can appear in an integer constant expression as long as they are not evaluated (such as division by zero). The issue is a nested C_MAYBE_CONST_EXPR, with the inner one generated in build_binary_op to indicate that a subexpression has been fully folded and should not be folded again, and the outer one in build_c_cast to indicate that the expression has integer constant operands. To avoid the inner one from build_binary_op, c_objc_common_truthvalue_conversion should be given an argument properly marked as having integer constant operands rather than that information having been removed by the caller - but because c_convert would then also wrap a C_MAYBE_CONST_EXPR with a NOP_EXPR converting to boolean, it seems most convenient to have c_objc_common_truthvalue_conversion produce the NE_EXPR directly in the desired type (boolean in this case), before generating any C_MAYBE_CONST_EXPR there, rather than it always producing a comparison in integer_type_node and doing a conversion to boolean in the caller. The same issue as in those PRs also applies for conversion to enums with a boolean fixed underlying type; that case is also fixed and tests added for it. Note that not all the tests added failed before the patch (in particular, the issue was specific to casts and did not apply for implicit conversions, but some tests of those are added as well). Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/111059 PR c/111911 gcc/c/ * c-tree.h (c_objc_common_truthvalue_conversion): Add third argument. * c-convert.cc (c_convert): For conversions to boolean, pass third argument to c_objc_common_truthvalue_conversion rather than converting here. * c-typeck.cc (build_c_cast): Ensure arguments with integer operands are marked as such for conversion to boolean. (c_objc_common_truthvalue_conversion): Add third argument TYPE. gcc/testsuite/ * gcc.c-torture/compile/pr111059-1.c, gcc.c-torture/compile/pr111059-2.c, gcc.c-torture/compile/pr111059-3.c, gcc.c-torture/compile/pr111059-4.c, gcc.c-torture/compile/pr111059-5.c, gcc.c-torture/compile/pr111059-6.c, gcc.c-torture/compile/pr111059-7.c, gcc.c-torture/compile/pr111059-8.c, gcc.c-torture/compile/pr111059-9.c, gcc.c-torture/compile/pr111059-10.c, gcc.c-torture/compile/pr111059-11.c, gcc.c-torture/compile/pr111059-12.c, gcc.c-torture/compile/pr111911-1.c, gcc.c-torture/compile/pr111911-2.c: New tests.
2024-01-30analyzer: handle null "var" in state_change_event::get_desc [PR113509]David Malcolm2-18/+49
Avoid ICE with -fanalyzer-verbose-state-changes when region_model::get_representative_tree returns nullptr in state_change_event::get_desc. gcc/analyzer/ChangeLog: PR analyzer/113509 * checker-event.cc (state_change_event::get_desc): Don't assume "var" is non-NULL. gcc/testsuite/ChangeLog: PR analyzer/113509 * c-c++-common/analyzer/stdarg-pr113509.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-01-31RISC-V: Fix VSETLV PASS compile-time issueJuzhe-Zhong1-124/+60
The compile time issue was discovered in SPEC 2017 wrf: Use time and -ftime-report to analyze the profile data of SPEC 2017 wrf compilation . Before this patch (Lazy vsetvl): scheduling : 121.89 ( 15%) 0.53 ( 11%) 122.72 ( 15%) 13M ( 1%) machine dep reorg : 424.61 ( 53%) 1.84 ( 37%) 427.44 ( 53%) 5290k ( 0%) real 13m27.074s user 13m19.539s sys 0m5.180s Simple vsetvl: machine dep reorg : 0.10 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 4138k ( 0%) real 6m5.780s user 6m2.396s sys 0m2.373s The machine dep reorg is the compile time of VSETVL PASS (424 seconds) which counts 53% of the compilation time, spends much more time than scheduling. After investigation, the critical patch of VSETVL pass is compute_lcm_local_properties which is called every iteration of phase 2 (earliest fusion) and phase 3 (global lcm). This patch optimized the codes of compute_lcm_local_properties to reduce the compilation time. After this patch: scheduling : 117.51 ( 27%) 0.21 ( 6%) 118.04 ( 27%) 13M ( 1%) machine dep reorg : 80.13 ( 18%) 0.91 ( 26%) 81.26 ( 18%) 5290k ( 0%) real 7m25.374s user 7m20.116s sys 0m3.795s The optimization of this patch is very obvious, lazy VSETVL PASS: 424s (53%) -> 80s (18%) which spend less time than scheduling. Tested on both RV32 and RV64 no regression. Ok for trunk ? PR target/113495 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (extract_single_source): Remove. (pre_vsetvl::compute_vsetvl_def_data): Fix compile time issue. (pre_vsetvl::compute_transparent): New function. (pre_vsetvl::compute_lcm_local_properties): Fix compile time time issue.
2024-01-31Daily bump.GCC Administrator8-1/+1261
2024-01-30i386: Add "Ws" constraint for symbolic address/label reference [PR105576]Fangrui Song3-0/+21
Printing the raw symbol is useful in inline asm (e.g. in C++ to get the mangled name). Similar constraints are available in other targets (e.g. "S" for aarch64/riscv, "Cs" for m68k). There isn't a good way for x86 yet, e.g. "i" doesn't work for PIC/-mcmodel=large. This patch adds "Ws". Here are possible use cases: ``` namespace ns { extern int var; } asm (".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "Ws"(&var)); asm (".reloc ., BFD_RELOC_NONE, %0" :: "Ws"(&var)); ``` gcc/ChangeLog: PR target/105576 * config/i386/constraints.md: Define constraint "Ws". * doc/md.texi: Document it. gcc/testsuite/ChangeLog: PR target/105576 * gcc.target/i386/asm-raw-symbol.c: New testcase.
2024-01-30c++: avoid -Wdangling-reference for std::span-like classes [PR110358]Marek Polacek5-0/+125
Real-world experience shows that -Wdangling-reference triggers for user-defined std::span-like classes a lot. We can easily avoid that by considering classes like template<typename T> struct Span { T* data_; std::size len_; }; to be std::span-like, and not warning for them. Unlike the previous patch, this one considers a non-union class template that has a pointer data member and a trivial destructor as std::span-like. PR c++/110358 PR c++/109640 gcc/cp/ChangeLog: * call.cc (reference_like_class_p): Don't warn for std::span-like classes. gcc/ChangeLog: * doc/invoke.texi: Update -Wdangling-reference description. gcc/testsuite/ChangeLog: * g++.dg/warn/Wdangling-reference18.C: New test. * g++.dg/warn/Wdangling-reference19.C: New test. * g++.dg/warn/Wdangling-reference20.C: New test.
2024-01-30xtensa: Make full transition to LRATakayuki 'January June' Suwa5-74/+26
gcc/ChangeLog: * config/xtensa/constraints.md (R, T, U): Change define_constraint to define_memory_constraint. * config/xtensa/predicates.md (move_operand): Don't check that a constant pool operand size is a multiple of UNITS_PER_WORD. * config/xtensa/xtensa.cc (xtensa_lra_p, TARGET_LRA_P): Remove. (xtensa_emit_move_sequence): Remove "if (reload_in_progress)" clause as it can no longer be true. (fixup_subreg_mem): Drop function. (xtensa_output_integer_literal_parts): Consider 16-bit wide constants. (xtensa_legitimate_constant_p): Add short-circuit path for integer load instructions. Don't check that mode size is at least UNITS_PER_WORD. * config/xtensa/xtensa.md (movsf): Use can_create_pseudo_p() rather reload_in_progress and reload_completed. (doloop_end): Drop operand 2. (movhi_internal): Add alternative loading constant from a literal pool. (define_split for DI register_operand): Don't limit to !TARGET_AUTO_LITPOOLS. * config/xtensa/xtensa.opt (mlra): Change to no effect.
2024-01-30c++: add original testcase [PR67898]Patrick Palka1-0/+14
The original testcase from this PR (fixed by r14-8291) seems rather different from the others, so let's add it to the testsuite. PR c++/67898 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/temp_default8.C: New test.
2024-01-30testsuite: fix anon6 mangling [PR112846]Jason Merrill2-0/+21
As with r14-6796-g2fa122cae50cd8, avoid mangling compatibility aliases in mangling tests, and test the new mangling. PR c++/112846 gcc/testsuite/ChangeLog: * g++.dg/abi/anon6.C: Specify ABI v18. * g++.dg/abi/anon6a.C: New test for ABI v19.
2024-01-30testsuite: mangle-reparm1a options [PR113451]Jason Merrill1-1/+1
When I added -fabi-compat-version=8 to avoid mangling aliases it also suppressed the -Wabi warning. PR c++/113451 gcc/testsuite/ChangeLog: * g++.dg/abi/mangle-regparm1a.C: Use -Wabi=0.
2024-01-30c++: duplicated side effects of xobj arg [PR113640]Patrick Palka2-1/+28
We miscompile the below testcase because keep_unused_object_arg thinks the object argument of an xobj member function is unused, and so it ends up duplicating the argument's side effects. PR c++/113640 gcc/cp/ChangeLog: * call.cc (keep_unused_object_arg): Punt for an xobj member function. gcc/testsuite/ChangeLog: * g++.dg/cpp23/explicit-obj-lambda14.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com>
2024-01-30c++: unifying integer parm with type-dep arg [PR113644]Patrick Palka2-1/+15
Here when trying to unify P=42 A=T::value we ICE due to the latter's empty type, which same_type_p dislikes. PR c++/113644 gcc/cp/ChangeLog: * pt.cc (unify) <case INTEGER_CST>: Handle NULL_TREE type. gcc/testsuite/ChangeLog: * g++.dg/template/nontype30.C: New test.
2024-01-30libstdc++: Fix check in testsuite/std/time/clock/gps/io.ccJonathan Wakely1-1/+2
The test_format() function contained an incorrect assertion but wasn't actually being called from main. libstdc++-v3/ChangeLog: * testsuite/std/time/clock/gps/io.cc: Fix expected result in assertion and call test_format() from main.
2024-01-30RISC-V: Bugfix for vls mode aggregated in GPR calling conventionPan Li18-0/+1559
According to the issue as below. https://hub.fgit.cf/riscv-non-isa/riscv-elf-psabi-doc/pull/416 When the mode size of vls integer mode is less than 2 * XLEN, we will take the gpr for both the args and the return values. Instead of the reference. For example the below code: typedef short v8hi __attribute__ ((vector_size (16))); v8hi __attribute__((noinline)) add (v8hi a, v8hi b) { v8hi r = a + b; return r; } Before this patch: add: vsetivli zero,8,e16,m1,ta,ma vle16.v v1,0(a1) <== arg by reference vle16.v v2,0(a2) <== arg by reference vadd.vv v1,v1,v2 vse16.v v1,0(a0) <== return by reference ret After this patch: add: addi sp,sp,-32 sd a0,0(sp) <== arg by register a0 - a3 sd a1,8(sp) sd a2,16(sp) sd a3,24(sp) addi a5,sp,16 vsetivli zero,8,e16,m1,ta,ma vle16.v v2,0(sp) vle16.v v1,0(a5) vadd.vv v1,v1,v2 vse16.v v1,0(sp) ld a0,0(sp) <== return by a0 - a1. ld a1,8(sp) addi sp,sp,32 jr ra For vls floating point, we take the same rules as integer and passed by the gpr or reference. The riscv regression passed for this patch. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_v_vls_mode_aggregate_gpr_count): New function to calculate the gpr count required by vls mode. (riscv_v_vls_to_gpr_mode): New function convert vls mode to gpr mode. (riscv_pass_vls_aggregate_in_gpr): New function to return the rtx of gpr for vls mode. (riscv_get_arg_info): Add vls mode handling. (riscv_pass_by_reference): Return false if arg info has no zero gpr count. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vls/def.h: Add new helper macro. * gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-10.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-5.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-6.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-8.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-9.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-run-1.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-run-2.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-run-3.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-run-4.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-run-5.c: New test. * gcc.target/riscv/rvv/autovec/vls/calling-convention-run-6.c: New test. Signed-off-by: Pan Li <pan2.li@intel.com>
2024-01-30analyzer: fix -Wanalyzer-allocation-size false +ve on Linux kernel's ↵David Malcolm2-2/+125
round_up macro [PR113654] gcc/analyzer/ChangeLog: PR analyzer/113654 * region-model.cc (is_round_up): New. (is_multiple_p): New. (is_dubious_capacity): New. (region_model::check_region_size): Move usage of size_visitor into is_dubious_capacity. gcc/testsuite/ChangeLog: PR analyzer/113654 * c-c++-common/analyzer/allocation-size-pr113654-1.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-01-30analyzer: add SARIF property bag to -Wanalyzer-allocation-sizeDavid Malcolm1-10/+21
This is useful for debugging the analyzer. gcc/analyzer/ChangeLog: * region-model.cc (dubious_allocation_size::dubious_allocation_size): Add "capacity_sval" param. Drop unused ctor. (dubious_allocation_size::maybe_add_sarif_properties): New. (dubious_allocation_size::m_capacity_sval): New field. (region_model::check_region_size): Pass capacity svalue to dubious_allocation_size ctor. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-01-30gccrs: Fix output line ending patterns.Arthur Cohen6-6/+6
gcc/testsuite/ChangeLog: * rust/execute/torture/builtin_macros1.rs: Fix output pattern. * rust/execute/torture/coercion3.rs: Likewise. * rust/execute/torture/issue-2080.rs: Likewise. * rust/execute/torture/issue-2179.rs: Likewise. * rust/execute/torture/issue-2180.rs: Likewise. * rust/execute/torture/iter1.rs: Likewise.
2024-01-30gccrs: Remove TraitImplItemOwen Avery8-42/+26
gcc/rust/ChangeLog: * ast/rust-ast-full-decls.h (class TraitImplItem): Remove forward declaration. (class AssociatedItem): Add forward declaration. * ast/rust-ast.h (class TraitImplItem): Remove. (class TraitItem): Inherit from AssociatedItem. (SingleASTNode::take_trait_impl_item): Return std::unique_ptr<AssociatedItem> instead of std::unique_ptr<TraitImplItem>. * ast/rust-item.h (class Function): Inherit from AssociatedItem instead of TraitImplItem. (class TypeAlias): Likewise. (class ConstantItem): Likewise. (class TraitImpl): Store items as AssociatedItem. * expand/rust-derive-clone.cc (DeriveClone::clone_fn): Return std::unique_ptr<AssociatedItem>. (DeriveClone::clone_impl): Take std::unique_ptr<AssociatedItem>. * expand/rust-derive-clone.h (DeriveClone::clone_fn): Return std::unique_ptr<AssociatedItem>. (DeriveClone::clone_impl): Take std::unique_ptr<AssociatedItem>. * expand/rust-expand-visitor.cc (ExpandVisitor::visit): Handle changes to SingleASTNode::take_trait_impl_item. * parse/rust-parse-impl.h (Parser::parse_impl): Parse TraitImpl as containing AssociatedItem. (Parser::parse_trait_impl_item): Return std::unique_ptr<AssociatedItem>. (Parser::parse_trait_impl_function_or_method): Likewise. * parse/rust-parse.h (Parser::parse_trait_impl_item): Return std::unique_ptr<AssociatedItem>. (Parser::parse_trait_impl_function_or_method): Likewise. Signed-off-by: Owen Avery <powerboat9.gamer@gmail.com>
2024-01-30gccrs: Add improved error when no fields in initializerRobert Goss4-5/+76
If a struct type with a variant that has fields is initialized with some fields the expression HIR StructExprStructFields is checked that all the fields are assigned. However, if no fields are initialized the HIR StructExprStruct is generated. This doesn't check if the struct is a unit during typechekc and only fails at the compile stage with a ICE. Add a check at the typecheck stage that makes sure the struct does not have a variant with fields and give an error message based on the rustc one. We have also updated the message given in the case where one field was present to list the missing fields and match more closely the new message. gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit) Add additional check * typecheck/rust-hir-type-check-struct-field.h: A helper method to make error added * typecheck/rust-hir-type-check-struct.cc (TypeCheckStructExpr::resolve) Update message gcc/testsuite/ChangeLog: * rust/compile/missing_constructor_fields.rs: Added case with no initializers Signed-off-by: Robert Goss <goss.robert@gmail.com>
2024-01-30gccrs: Test: check implemented for lifetime handlingJakub Dupak1-0/+19
gcc/testsuite/ChangeLog: * rust/compile/for_lifetimes.rs: New test. Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
2024-01-30gccrs: AST: Fix for lifetime loweringJakub Dupak1-4/+17
gcc/rust/ChangeLog: * hir/rust-ast-lower-type.cc (ASTLoweringTypeBounds::visit): fix for lifetimes (ASTLowerWhereClauseItem::visit): fix for lifetimes Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
2024-01-30gccrs: AST: Fix for lifetime parsingJakub Dupak2-16/+27
gcc/rust/ChangeLog: * parse/rust-parse-impl.h (Parser::parse_where_clause): fix parsing (Parser::parse_where_clause_item): fix parsing (Parser::parse_type_bound_where_clause_item): fix parsing (Parser::parse_trait_bound): fix parsing * parse/rust-parse.h: fix parsing Signed-off-by: Jakub Dupak <dev@jakubdupak.com>