aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2025-08-08diagnostics: minor cleanupsDavid Malcolm5-7/+8
No functional change intended. gcc/ChangeLog: * diagnostic.h (diagnostics::get_cwe_url): Move decl to diagnostics/metadata.h. (diagnostics::maybe_line_and_column): Move into diagnostics::text_sink. * diagnostics/context.cc: Update for maybe_line_and_column becoming a static member of text_sink. * diagnostics/metadata.h (diagnostics::get_cwe_url): Move decl here from diagnostic.h. * diagnostics/text-sink.cc (maybe_line_and_column): Convert to... (text_sink::maybe_line_and_column): ...this. * diagnostics/text-sink.h (text_sink::maybe_line_and_column): Move here from diagnostic.h. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2025-08-08diagnostics: update signature of some callbacksDavid Malcolm4-8/+8
No functional change intended. gcc/cp/ChangeLog: * error.cc (cp_adjust_diagnostic_info): Convert "context" arg from ptr to const &. gcc/ChangeLog: * diagnostics/context.cc (context::get_any_inlining_info): Convert "context" arg of m_set_locations_cb from ptr to const &. (context::report_diagnostic): Convert "context" arg of m_adjust_diagnostic_info from ptr to const &. * diagnostics/context.h (context::set_locations_callback_t): Likewise. (context::set_adjust_diagnostic_info_callback): Likewise. (context::m_adjust_diagnostic_info): Likewise. * tree-diagnostic.cc (set_inlining_locations): Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2025-08-08diagnostics: introduce struct column_optionsDavid Malcolm8-40/+89
Consolidate 3 fields in diagnostics::context and diagnostics::column_policy into a new struct diagnostics::column_options. No functional change intended; reduces the number of public fields in diagnostics::context. gcc/c-family/ChangeLog: * c-indentation.cc (should_warn_for_misleading_indentation): Update for moving diagnostics::context::m_tabstop into diagnostics::column_options. * c-opts.cc (c_common_post_options): Likewise. gcc/ChangeLog: * diagnostics/column-options.h: New file, adding struct diagnostics::column_options, taken from fields in diagnostics::context and diagnostics::column_policy. * diagnostics/context.cc (context::initialize): Update for moving fields of diagnostics::context into diagnostics::column_options. (column_policy::column_policy): Likewise. (column_policy::converted_column): Move implementation to... (column_options::convert_column): ...this new function. (context::report_diagnostic): Update for moving fields of diagnostics::context into diagnostics::column_options. (assert_location_text): Likewise. * diagnostics/context.h: Include "diagnostics/column-options.h". (class column_policy): Replace fields m_column_unit, m_column_origin, and m_tabstop with m_column_options. (context::get_column_options): New accessors. (context::m_column_unit): Move to struct column_options and replace with m_column_options. (context::m_column_origin): Likewise. (context::m_tabstop): Likewise. * diagnostics/sarif-sink.cc (sarif_builder::sarif_builder): Update for moving fields of diagnostics::context into diagnostics::column_options. * diagnostics/source-printing.cc: Likewise. * opts.cc (common_handle_option): Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2025-08-08arm: Fix CMSE nonecure calls [PR 120977]Christophe Lyon6-27/+42
As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685733.html the operand of the call should be a mem rather than an unspec. This patch moves the unspec to an additional argument of the parallel and adjusts cmse_nonsecure_call_inline_register_clear accordingly. The scan-rtl-dump in cmse-18.c needs a fix since we no longer emit the 'unspec' part. In addition, I noticed that since arm_v8_1m_mve_ok is always true in the context of the test (we know we support CMSE as per cmse.exp, and arm_v8_1m_mve_ok finds the adequate options), we actually only use the more permissive regex. To improve that, the patch duplicates the test, such that cmse-18.c forces -march=armv8-m.main+fp (so FPCXP is disabled), and cmse-19.c forces -march=armv8.1-m.main+mve (so FPCXP is enabled). Each test uses the appropriate scan-rtl-dump, and also checks we are using UNSPEC_NONSECURE_MEM (we need to remove -slim for that). The tests enable an FPU via -march so that the test passes whether the testing harness forces -mfloat-abi or not. 2025-07-08 Christophe Lyon <christophe.lyon@linaro.org> PR target/120977 gcc/ * config/arm/arm.md (call): Move unspec parameter to parallel. (nonsecure_call_internal): Likewise. (call_value): Likewise. (nonsecure_call_value_internal): Likewise. * config/arm/thumb1.md (nonsecure_call_reg_thumb1_v5): Likewise. (nonsecure_call_value_reg_thumb1_v5): Likewise. * config/arm/thumb2.md (nonsecure_call_reg_thumb2_fpcxt): Likewise. (nonsecure_call_reg_thumb2): Likewise. (nonsecure_call_value_reg_thumb2_fpcxt): Likewise. (nonsecure_call_value_reg_thumb2): Likewise. * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Likewise. gcc/testsuite * gcc.target/arm/cmse/cmse-18.c: Check only the case when FPCXT is not enabled. * gcc.target/arm/cmse/cmse-19.c: New test.
2025-08-08AArch64: Fix invalid immediate offsets in SVE gather/scatter [PR121449]Pengfei Li2-32/+76
This patch fixes incorrect constraints in RTL patterns for AArch64 SVE gather/scatter with type widening/narrowing and vector-plus-immediate addressing. The bug leads to below "immediate offset out of range" errors during assembly, eventually causing compilation failures. /tmp/ccsVqBp1.s: Assembler messages: /tmp/ccsVqBp1.s:54: Error: immediate offset out of range 0 to 31 at operand 3 -- `ld1b z1.d,p0/z,[z1.d,#64]' Current RTL patterns for such instructions incorrectly use vgw or vgd constraints for the immediate operand, base on the vector element type in Z registers (zN.s or zN.d). However, for gather/scatter with type conversions, the immediate range for vector-plus-immediate addressing is determined by the element type in memory, which differs from that in vector registers. Using the wrong constraint can produce out-of-range offset values that cannot be encoded in the instruction. This patch corrects the constraints used in these patterns. A test case that reproduces the issue is also included. Bootstrapped and regression-tested on aarch64-linux-gnu. gcc/ChangeLog: PR target/121449 * config/aarch64/aarch64-sve.md (mask_gather_load<mode><v_int_container>): Use vg<Vesize> constraints for alternatives with immediate offset. (mask_scatter_store<mode><v_int_container>): Likewise. gcc/testsuite/ChangeLog: PR target/121449 * g++.target/aarch64/sve/pr121449.C: New test.
2025-08-08Add subsections for vectorization and OpenMP/OpenACC target hooksRichard Biener2-0/+20
Currently they are grouped under Addressing Modes which is quite misleading. gcc/ * doc/tm.texi.in: Add Vectorization and OpenMP and OpenACC sub-sections to the list of target macros and functions. * doc/tm.texi: Re-generate.
2025-08-08Remove setting of STMT_VINFO_VECTYPE on non-dataref stmtsRichard Biener2-176/+11
The following removes early setting of STMT_VINFO_VECTYPE and as side-effect early failing if we fail to compute a vector type. The latter is now ensured by SLP build. The former is still temporarily copied from the SLP tree during stmt analysis, and data reference stmts will still have STMT_VINFO_VECTYPE given existing uses in dependence and alignment analysis and peeling. * tree-vect-loop.cc (vect_determine_vectype_for_stmt_1): Remove. (vect_determine_vectype_for_stmt): Likewise. (vect_set_stmts_vectype): Likewise. (vect_analyze_loop_2): Do not call vect_set_stmts_vectype. * tree-vect-stmts.cc (vect_mark_stmts_to_be_vectorized): Detect irregular stmts early here.
2025-08-08aarch64: Relax fpm_t assert to allow const_ints [PR120986]Alex Coplan2-2/+10
This relaxes an overzealous assert that required the fpm_t argument to be in DImode when expanding FP8 intrinsics. Of course this fails to account for modeless const_ints. gcc/ChangeLog: PR target/120986 * config/aarch64/aarch64-sve-builtins.cc (function_expander::expand): Relax fpm_t assert to allow modeless const_ints. gcc/testsuite/ChangeLog: PR target/120986 * gcc.target/aarch64/torture/pr120986-2.c: New test.
2025-08-08aarch64: Fix predication of FP8 FDOT insns [PR120986]Alex Coplan3-8/+24
The predication of the SVE2 FP8 dot product insns was relying on the architectural dependency: FEAT_FP8DOT2 => FEAT_FP8DOT4 which was relaxed in GCC as of r15-7480-g299a8e2dc667e795991bc439d2cad5ea5bd379e2, thus leading to unrecognisable insn ICEs when compiling a two-way FDOT with just +fp8dot2. This patch introduces a new mode iterator which selectively enables the appropriate mode(s) depending on which of the FP8DOT{2,4} features are available, and uses it to fix the predication of the patterns. gcc/ChangeLog: PR target/120986 * config/aarch64/aarch64-sve2.md (@aarch64_sve_dot<mode>): Switch mode iterator from SVE_FULL_HSF to new iterator; remove insn predicate as this is now taken care of by conditions in the mode iterator. (@aarch64_sve_dot_lane<mode>): Likewise. * config/aarch64/iterators.md (SVE_FULL_HSF_FP8_FDOT): New. gcc/testsuite/ChangeLog: PR target/120986 * gcc.target/aarch64/pr120986-1.c: New test.
2025-08-08tree-optimization/121454 - ICE building libgoRichard Biener1-9/+18
The following avoids building BIT_FIELD_REFs of reference trees that are unexpected by nonoverlapping_refs_since_match_p and while being there also those declared invalid by IL verification. PR tree-optimization/121454 * tree-ssa-sccvn.cc (visit_nary_op): Avoid unexpected BIT_FIELD_REFs.
2025-08-08tailc: Handle other forms of finally_tmp.N conditional cleanups after ↵Jakub Jelinek5-46/+357
musttail [PR121389] My earlier r16-1886 PR120608 change incorrectly assumed that the finally_tmp.N vars introduced by eh pass will be only initialized to values 0 and 1 and there will be only EQ_EXPR/NE_EXPR comparisons of those. The following testcases show that is a bad assumption, the eh pass sets finally_tmp.N vars to 0 up to some highest index depending on hoiw many different exits there are from the finally region. And it emits then switch (finally_tmp.N) statement for all the different cases. So, if it uses more than 0/1 indexes, the lowering of the switch can turn it into a series of GIMPLE_CONDs, if (finally_tmp.N_M > 15) goto ... else goto ... if (finally_tmp.N_M > 7) goto ... else goto ... etc. (and that also means no longer single uses). And if unlucky, we can see a non-lowered GIMPLE_SWITCH as well. So, the following patch removes the assumption that it has to be 0/1 and EQ_EXPR/NE_EXPR, allows all the normal integral comparisons and handles GIMPLE_SWITCH too. 2025-08-08 Jakub Jelinek <jakub@redhat.com> PR middle-end/121389 * tree-tailcall.cc (find_tail_calls): For finally_tmp.N handle not just GIMPLE_CONDs with EQ_EXPR/NE_EXPR and only values 0 and 1, but arbitrary non-negative values, arbitrary comparisons in conditions and also GIMPLE_SWITCH next to GIMPLE_CONDs. * c-c++-common/asan/pr121389-1.c: New test. * c-c++-common/asan/pr121389-2.c: New test. * c-c++-common/asan/pr121389-3.c: New test. * c-c++-common/asan/pr121389-4.c: New test.
2025-08-08Modernize vectorizable_lane_reducingRichard Biener1-6/+7
The following avoids STMT_VINFO_VECTYPE usage in vect_is_emulated_mixed_dot_prod and makes sure to register the SLP node when costing in vectorizable_lane_reducing. * tree-vect-loop.cc (vect_is_emulated_mixed_dot_prod): Get the SLP node rather than the stmt_info. (vectorizable_lane_reducing): Adjust, pass SLP node to costing. (vect_transform_reduction): Adjust.
2025-08-08Pass SLP node to promotion/demotion costingRichard Biener1-11/+4
This one was forgotten. Also constants/externals are costed explicitly with SLP. * tree-vect-stmts.cc (vect_model_promotion_demotion_cost): Pass in SLP node and drop unused dr argument. Use SLP node for costing, drop costing of constant/external operands. (vectorizable_conversion): Adjust.
2025-08-08Fix typo in getting SLP_TREE_VECTYPERichard Biener1-1/+1
It was applied on the stmt_info rather than the slp_node. * tree-vect-stmts.cc (vectorizable_store): Apply SLP_TREE_VECTYPE to slp_node rather than stmt_info.
2025-08-08Daily bump.GCC Administrator7-1/+228
2025-08-07cobol: Improve binary-to-string conversion.Robert Dubner6-9/+9
COBOL often requires the conversion of binary integers to string of characters. These changes replace a naive routine that peels decimal digits from a binary value one digit at a time, with a divide-and-conquer algorithm that is twice as fast even for a couple of digits, and is about eight times faster past ten digits. Included here are some minor fixes to the lexer and parser. gcc/cobol/ChangeLog: * cbldiag.h (location_dump): Source code formatting. * parse.y: error_msg formatting. * scan.l: Remove UTF-8 character from regex pattern. * scan_ante.h (numstr_of): error_msg formatting. * show_parse.h (class ANALYZE): Suppress cppcheck error. * util.cc (cbl_field_t::report_invalid_initial_value): error_msg formatting. libgcobol/ChangeLog: * Makefile.am: Include new stringbin.cc file. * Makefile.in: Regenerated. * libgcobol.cc (__gg__power_of_ten): Improve error message. (__gg__binary_to_string): Deleted. (__gg__binary_to_string_internal): Deleted. (int128_to_field): Use new conversion routine. (__gg__move): Use new conversion routine. * stringbin.cc: New file. Implements new conversion routine. * stringbin.h: New file. Likewise.
2025-08-07c++: extract_call_expr and C++20 rewritten opsPatrick Palka1-22/+0
After r16-2519-gba5a6787374dea, we'll never express a C++20 rewritten comparison operator as a built-in operator acting on an operator<=> call, e.g. operator<=>(x, y) @ 0. This is because operator<=> always returns a class type (std::foo_ordering), so the outer operator@ will necessarily resolve to a non-built-in operator@ for that class type (even in the non-dependent templated case, after that commit). So the corresponding handling in extract_call_expr is basically dead code, except for the TRUTH_NOT_EXPR case where we can plausibly still have !(operator==(x, y)), but it doesn't make sense to recognize just that one special case of operator rewriting. So let's just remove it altogether; apparently it's no longer needed. Also, the handling is imprecise: it recognizes expressions such as 0 < f() which never corresponded to a call in the first place. All the more reason to remove it. gcc/cp/ChangeLog: * call.cc (extract_call_expr): Remove handling of C++20 rewritten comparison operators. Reviewed-by: Jason Merrill <jason@redhat.com>
2025-08-07c++: Implement C++26 P1061R10 - Structured Bindings can introduce a Pack ↵Jakub Jelinek15-42/+1990
[PR117783] The following patch implements the C++26 P1061R10 - Structured Bindings can introduce a Pack paper. One thing unresolved in the patch is mangling, I've raised https://github.com/itanium-cxx-abi/cxx-abi/issues/200 for that but no comments there yet. One question is if it is ok not to mention the fact that there is a structured binding pack in the mangling of the structured bindings but more important is in case of std::tuple* we might need to mangle individual structured binding pack elements separately (each might need an exported name for the var itself and perhaps its guard variable as well). The patch just uses the normal mangling for the whole structured bindings and emits sorry if we need to mangle the structured binding pack elements. The patch just marks the structured binding pack specially (considered e.g. using some bit on it, but in the end I'm identifying it using a made up type which causes DECL_PACK_P to be true; it is kind of self-referential solution, because the type on the pack mentions the DECL_DECOMPOSITION_P VAR_DECL on which the type is attached as its pack, so it needs to be handled carefully during instantiation to avoid infinite recursion, but it is the type that should be used if something else actually needs to use the same type as the structured binding pack, e.g. a capture proxy), and stores the pack elements when actually processed through cp_finish_decomp with non-dependent initializer into a TREE_VEC used as DECL_VALUE_EXPR of the pack; though because several spots use the DECL_VALUE_EXPR and assume it is ARRAY_REF from which they can find out the base variable and the index, it stores the base variable and index in the first 2 TREE_VEC elts and has the structured binding elements only after that. https://eel.is/c++draft/temp.dep.expr#3.6 says the packs are type dependent regardless of whether the initializer of the structured binding is type dependent or not, so I hope having a dependent type on the structured binding VAR_DECL is ok. The paper also has an exception for sizeof... which is then not value dependent when the structured bindings are initialized with non-dependent initializer: https://eel.is/c++draft/temp.dep.constexpr#4 The patch special cases that in 3 spots (I've been wondering if e.g. during parsing I couldn't just fold the sizeof... to the INTEGER_CST right away, but guess I'd need to repeat that also during partial instantiation). And one thing still unresolved is debug info, I've just added DECL_IGNORED_P on the structured binding pack VAR_DECL because there were ICEs with -g for now, hope it can be fixed incrementally but am not sure what exactly we should emit in the debug info for that. Speaking of which, I see DW_TAG_GNU_template_parameter_pack DW_TAG_GNU_formal_parameter_pack etc. DIEs emitted regardless of DWARF version, shouldn't we try to upstream those into DWARF 6 or check what other compilers emit for the packs? And bet we'd need DW_TAG_GNU_structured_binding_pack as well. 2025-08-07 Jakub Jelinek <jakub@redhat.com> PR c++/117783 gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Change __cpp_structured_bindings predefined value for C++26 from 202403L to 202411L. gcc/cp/ * parser.cc: Implement C++26 P1061R10 - Structured Bindings can introduce a Pack. (cp_parser_range_for): Also handle TREE_VEC as DECL_VALUE_EXPR instead of ARRAY_REF. (cp_parser_decomposition_declaration): Use sb-identifier-list instead of identifier-list in comments. Parse structured bindings with structured binding pack. Don't emit pedwarn about structured binding attributes in structured bindings inside of a condition. (cp_convert_omp_range_for): Also handle TREE_VEC as DECL_VALUE_EXPR instead of ARRAY_REF. * decl.cc (get_tuple_element_type): Change i argument type from unsigned to unsigned HOST_WIDE_INT. (get_tuple_decomp_init): Likewise. (set_sb_pack_name): New function. (cp_finish_decomp): Handle structured binding packs. * pt.cc (tsubst_pack_expansion): Handle structured binding packs and capture proxies for them. Formatting fixes. (tsubst_decl): For structured binding packs don't tsubst TREE_TYPE first, instead recreate the type after r is created. (tsubst_omp_for_iterator): Also handle TREE_VEC as DECL_VALUE_EXPR instead of ARRAY_REF. (tsubst_expr): Handle sizeof... on non-dependent structure binding packs. (value_dependent_expression_p): Return false for sizeof... on non-dependent structure binding packs. (instantiation_dependent_r): Don't recurse on sizeof... on non-dependent structure binding packs. * constexpr.cc (potential_constant_expression_1): Also handle TREE_VEC on DECL_VALUE_EXPR of structure binding packs. gcc/testsuite/ * g++.dg/cpp26/decomp13.C: New test. * g++.dg/cpp26/decomp14.C: New test. * g++.dg/cpp26/decomp15.C: New test. * g++.dg/cpp26/decomp16.C: New test. * g++.dg/cpp26/decomp17.C: New test. * g++.dg/cpp26/decomp18.C: New test. * g++.dg/cpp26/decomp19.C: New test. * g++.dg/cpp26/decomp20.C: New test. * g++.dg/cpp26/decomp21.C: New test. * g++.dg/cpp26/feat-cxx26.C (__cpp_structured_bindings): Expect 202411 rather than 202403.
2025-08-07aarch64: Mark SME functions as .variant_pcs [PR121414]Richard Sandiford2-8/+56
Unlike base PCS functions, __arm_streaming and __arm_streaming_compatible functions allow/require PSTATE.SM to be 1 on entry, so they need to be treated as STO_AARCH64_VARIANT_PCS. Similarly, functions that share ZA or ZT0 with their callers require ZA to be active on entry, whereas the base PCS requires ZA to be dormant or off. These functions too need to be marked as having a variant PCS. gcc/ PR target/121414 * config/aarch64/aarch64.cc (aarch64_is_variant_pcs): New function, split out from... (aarch64_asm_output_variant_pcs): ...here. Handle various types of SME function type. gcc/testsuite/ PR target/121414 * gcc.target/aarch64/sme/pr121414_1.c: New test.
2025-08-07Remove MODE_COMPOSITE_P test from simplify_gen_subreg [PR120718]Richard Sandiford2-8/+16
simplify_gen_subreg rejected subregs of literal constants if MODE_COMPOSITE_P. This was added by the fix for PR96648 in g:c0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f. Jakub said: As for the simplify_gen_subreg change, I think it would be desirable to just avoid creating SUBREGs of constants on all targets and for all constants, if simplify_immed_subreg simplified, fine, otherwise punt, but as we are late in GCC11 development, the patch instead guards this behavior on MODE_COMPOSITE_P (outermode) - i.e. only conversions to powerpc{,64,64le} double double long double - and only for the cases where simplify_immed_subreg was called. I'm not sure about relaxing the codes further, since subregs might be wanted for CONST, SYMBOL_REF and LABEL_REF. But removing the MODE_COMPOSITE_P is needed to fix PR120718, where we get an ICE from generating a subreg of a V2SI const_vector. gcc/ PR rtl-optimization/120718 * simplify-rtx.cc (simplify_context::simplify_gen_subreg): Remove MODE_COMPOSITE_P condition. gcc/testsuite/ PR rtl-optimization/120718 * gcc.target/aarch64/sve/acle/general/pr120718.c: New test.
2025-08-07tree-optimization/121405 - missed VN with aggregate copyRichard Biener3-5/+53
The following handles value-numbering of a BIT_FIELD_REF of a register that's defined by a load by looking up a subset load similar to how we handle bit-and masked loads. This allows the testcase to be simplified by two FRE passes, the first one will create the BIT_FIELD_REF. PR tree-optimization/121405 * tree-ssa-sccvn.cc (visit_nary_op): Handle BIT_FIELD_REF with reference def by looking up a combination of both. * gcc.dg/tree-ssa/ssa-fre-107.c: New testcase. * gcc.target/i386/pr90579.c: Adjust.
2025-08-07vect: Extend peeling and versioning for alignment to VLA modesPengfei Li11-97/+291
This patch extends the support for peeling and versioning for alignment from VLS modes to VLA modes. The key change is allowing the DR target alignment to be set to a non-constant poly_int. Since the value must be a power-of-two, for variable VFs, the power-of-two check is deferred to runtime through loop versioning. The vectorizable check for speculative loads is also refactored in this patch to handle both constant and variable target alignment values. Additional changes for VLA modes include: 1) Peeling In VLA modes, we use peeling with masking - using a partial vector in the first iteration of the vectorized loop to ensure aligned DRs in subsequent iterations. It was already enabled for VLS modes to avoid scalar peeling. This patch reuses most of the existing logic and just fixes a small issue of incorrect IV offset in VLA code path. This also removes a power-of-two rounding when computing the number of iterations to peel, as power-of-two VF has been guaranteed by a new runtime check. 2) Versioning The type of the mask for runtime alignment check is updated to poly_int to support variable VFs. After this change, both standalone versioning and peeling with versioning are available in VLA modes. This patch also introduces another runtime check for speculative read amount, to ensure that all speculative loads remain within current valid memory page. We plan to remove these runtime checks in the future by introducing capped VF - using partial vectors to limit the actual VF value at runtime. 3) Speculative read flag DRs whose scalar accesses are known to be in-bounds will be considered unaligned unsupported with a variable target alignment. But in fact, speculative reads can be naturally avoided for in-bounds DRs as long as partial vectors are used. Therefore, this patch clears the speculative flags and sets the "must use partial vectors" flag for these cases. This patch is bootstrapped and regression-tested on x86_64-linux-gnu, arm-linux-gnueabihf and aarch64-linux-gnu with bootstrap-O3. gcc/ChangeLog: * tree-vect-data-refs.cc (vect_compute_data_ref_alignment): Allow DR target alignment to be a poly_int. (vect_enhance_data_refs_alignment): Support peeling and versioning for VLA modes. * tree-vect-loop-manip.cc (get_misalign_in_elems): Remove power-of-two rounding in peeling. (vect_create_cond_for_align_checks): Update alignment check logic for poly_int mask. (vect_create_cond_for_vla_spec_read): New runtime checks. (vect_loop_versioning): Support new runtime checks. * tree-vect-loop.cc (_loop_vec_info::_loop_vec_info): Add a new loop_vinfo field. (vectorizable_induction): Fix wrong IV offset issue. * tree-vect-stmts.cc (get_load_store_type): Refactor vectorizable checks for speculative loads. * tree-vectorizer.h (LOOP_VINFO_MAX_SPEC_READ_AMOUNT): New macro for new runtime checks. (LOOP_REQUIRES_VERSIONING_FOR_SPEC_READ): Likewise (LOOP_REQUIRES_VERSIONING): Update macro for new runtime checks. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/peel_ind_11.c: New test. * gcc.target/aarch64/sve/peel_ind_11_run.c: New test. * gcc.target/aarch64/sve/peel_ind_12.c: New test. * gcc.target/aarch64/sve/peel_ind_12_run.c: New test. * gcc.target/aarch64/sve/peel_ind_13.c: New test. * gcc.target/aarch64/sve/peel_ind_13_run.c: New test.
2025-08-07c++: Add testcase for CWG2577 [PR120778]Jakub Jelinek5-0/+62
And here is the last part of the paper. Contrary what the paper claims (clearly they haven't tried -pedantic nor -pedantic-errors), I think we already diagnose everything we should. 2025-08-07 Jakub Jelinek <jakub@redhat.com> PR preprocessor/120778 * g++.dg/DRs/dr2577-1.C: New test. * g++.dg/DRs/dr2577-2.C: New test. * g++.dg/DRs/dr2577-2.h: New file. * g++.dg/DRs/dr2577-3.C: New test. * g++.dg/DRs/dr2577-3.h: New file.
2025-08-07c++: Add testcase for CWG2575 [PR120778]Jakub Jelinek1-0/+51
From the paper it isn't clear what caused the decision changes, not to drop the "the token defined is generated as a result of this replacement process or" part and make [cpp.cond]/10 violations IFNDR rather than ill-formed (the latter maybe so that the extension to handle e.g. !A(A) below etc. can be accepted). Anyway, because that case hasn't been dropped and we pedwarn on it already, and diagnose everything else the way it should, the following patch just adds testcase for it. 2025-08-07 Jakub Jelinek <jakub@redhat.com> PR preprocessor/120778 * g++.dg/DRs/dr2575.C: New test.
2025-08-07c++: Add testcase for CWG2576 [PR120778]Jakub Jelinek1-0/+47
Another part of the C++26 P2843R3, this time in https://eel.is/c++draft/cpp.include#7 changing former (compile time) undefined behavior to IFNDR. With IFNDR we wouldn't have to test anything I guess, but this still adds the cases from the 3.4 section of the paper plus related tests. The paper wonders about implementation divergence between most compilers and gcc in the case of glueing tokens together with <> around from multiple macros, GCC doesn't add CPP_PADDING macros in that case (and even if it would, it would ignore them through get_token_no_padding). But I think this behavior is allowed by https://eel.is/c++draft/cpp.include#7.sentence-3 and changing it now after 25+ years of such behavior might break real-world stuff, especially making it really hard to construct the <> includes from some name and adding < and > from some other macro around that. We handle #define A <cstd def> #include A like clang++ and try to open 'cstd def' file. But not adding spaces for all the padding means handling even stuff where nothing else can help, while for cstd def coming from different macros one can use token pasting to combine them together, e.g. < and following identifier or identifier followed by . or . followed by identifier or identifier followed by > can't be pasted together. 2025-08-07 Jakub Jelinek <jakub@redhat.com> PR preprocessor/120778 * g++.dg/DRs/dr2576.C: New test.
2025-08-07c++, c: Introduce -Wkeyword-macro warning/pedwarn - part of C++26 P2843R3 ↵Jakub Jelinek29-8/+1098
[PR120778] The following patch introduces a -Wkeyword-macro warning that clang has since 2014 to implement part of C++26 P2843R3 Preprocessing is never undefined paper. The relevant change in the paper is moving [macro.names]/2 paragraph to https://eel.is/c++draft/cpp.replace.general#9 : "A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 4, or to the attribute-tokens described in [dcl.attr], except that the names likely and unlikely may be defined as function-like macros." Now, my understanding of the paper is that in [macro.names] and surrounding sections the word shall bears different meaning from [cpp.replace.general], where only the latter location implies ill-formed, diagnostic required. The warning in clang when introduced diagnosed all #define/#undef directives on keywords, but shortly after introduction has been changed not to diagnose #undef at all (with "#undef a keyword is generally harmless but used often in configuration scripts" message) and later on even the #define part tweaked - not warn about say #define inline (or const, extern, static), or #define keyword keyword or #define keyword __keyword or #define keyword __keyword__ Later on the warning has been moved to be only pedantic diagnostic unless requested by users. Clearly some code in the wild does e.g. #define private public and similar games, or e.g. Linux kernel (sure, C) does #define inline __inline__ __attribute__((__always_inline__)) etc. Now, I believe at least with the current C++26 wording such exceptions aren't allowed (unless it is changed to IFNDR). But given that this is just pedantic stuff, the following patch makes the warning off by default for C and C++ before C++26 and even for C++26 it enables it by default only if -pedantic/-pedantic-errors (in that case it pedwarns, otherwise it warns). And it diagnoses both #define and #undef without exceptions. From what I can see, all the current NODE_WARN cases are macros starting with __ with one exception (_Pragma). As the NODE_* flags seem to be a limited resource, I chose to just use NODE_WARN as well and differentiate on the node names (if they don't start with __ or _P, they are considered to be -Wkeyword-macro registered ones, otherwise old NODE_WARN cases, typically builtin macros or __STDC* macros). 2025-08-07 Jakub Jelinek <jakub@redhat.com> PR preprocessor/120778 gcc/ * doc/invoke.texi (Wkeyword-macro): Document. gcc/c-family/ * c.opt (Wkeyword-macro): New option. * c.opt.urls: Regenerate. * c-common.h (cxx_dialect): Comment formatting fix. * c-opts.cc (c_common_post_options): Default to -Wkeyword-macro for C++26 if pedantic. gcc/c/ * c-decl.cc (c_init_decl_processing): Mark cpp nodes corresponding to keywords as NODE_WARN if warn_keyword_macro. gcc/cp/ * lex.cc (cxx_init): Mark cpp nodes corresponding to keywords, identifiers with special meaning and standard attribute identifiers as NODE_WARN if warn_keyword_macro. gcc/testsuite/ * gcc.dg/Wkeyword-macro-1.c: New test. * gcc.dg/Wkeyword-macro-2.c: New test. * gcc.dg/Wkeyword-macro-3.c: New test. * gcc.dg/Wkeyword-macro-4.c: New test. * gcc.dg/Wkeyword-macro-5.c: New test. * gcc.dg/Wkeyword-macro-6.c: New test. * gcc.dg/Wkeyword-macro-7.c: New test. * gcc.dg/Wkeyword-macro-8.c: New test. * gcc.dg/Wkeyword-macro-9.c: New test. * g++.dg/warn/Wkeyword-macro-1.C: New test. * g++.dg/warn/Wkeyword-macro-2.C: New test. * g++.dg/warn/Wkeyword-macro-3.C: New test. * g++.dg/warn/Wkeyword-macro-4.C: New test. * g++.dg/warn/Wkeyword-macro-5.C: New test. * g++.dg/warn/Wkeyword-macro-6.C: New test. * g++.dg/warn/Wkeyword-macro-7.C: New test. * g++.dg/warn/Wkeyword-macro-8.C: New test. * g++.dg/warn/Wkeyword-macro-9.C: New test. * g++.dg/warn/Wkeyword-macro-10.C: New test. * g++.dg/opt/pr82577.C: Don't #define register to nothing for C++17 and later. Instead define reg macro to nothing for C++17 and later or to register and use it instead of register. * g++.dg/modules/atom-preamble-3.C: Add -Wno-keyword-macro to dg-additional-options. * g++.dg/template/sfinae17.C (static_assert): Rename macro to ... (my_static_assert): ... this. (main): Use my_static_assert instead of static_assert. libcpp/ * include/cpplib.h (struct cpp_options): Add cpp_warn_keyword_macro. (enum cpp_warning_reason): Add CPP_W_KEYWORD_MACRO enumerator. (cpp_keyword_p): New inline function. * directives.cc (do_undef): Support -Wkeyword-macro diagnostics. * macro.cc (warn_of_redefinition): Ignore NODE_WARN flag on nodes registered for -Wkeyword-macro. (_cpp_create_definition): Support -Wkeyword-macro diagnostics. Formatting fixes.
2025-08-07s390: Add _BitInt supportStefan Schulze Frielinghaus5-8/+243
gcc/ChangeLog: * config/s390/s390.cc (print_operand): Allow arbitrary wide_int constants for _BitInt. (s390_bitint_type_info): Implement target hook TARGET_C_BITINT_TYPE_INFO. libgcc/ChangeLog: * config/s390/libgcc-glibc.ver: Export _BitInt support functions. * config/s390/t-softfp (softfp_extras): Add fixtfbitint floatbitinttf. gcc/testsuite/ChangeLog: * gcc.target/s390/bitint-1.c: New test. * gcc.target/s390/bitint-2.c: New test. * gcc.target/s390/bitint-3.c: New test. * gcc.target/s390/bitint-4.c: New test.
2025-08-07Daily bump.GCC Administrator7-1/+407
2025-08-06testsuite: fix escaping of square bracketsSam James1-1/+1
This fails for me as: +ERROR: g++.dg/cpp26/constexpr-new3.C -std=c++26: unknown dg option: 2 for " dg-error 40 "accessing value of 'int [2]' object through a 'long int' glvalue in a constant expression" " otherwise. Escape '[' and ']'. gcc/testsuite/ChangeLog: * g++.dg/cpp26/constexpr-new3.C: Escape '[' and ']'.
2025-08-07i386: Fix invalid RTX mode in the unnamed rotate splitter.Uros Bizjak2-8/+12
The following splitter from the commit r11-5747: (define_split [(set (match_operand:SWI 0 "register_operand") (any_rotate:SWI (match_operand:SWI 1 "const_int_operand") (subreg:QI (and (match_operand 2 "int248_register_operand") (match_operand 3 "const_int_operand")) 0)))] "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (<MODE>mode) - 1)) == GET_MODE_BITSIZE (<MODE>mode) - 1" [(set (match_dup 4) (match_dup 1)) (set (match_dup 0) (any_rotate:SWI (match_dup 4) (subreg:QI (and:SI (match_dup 2) (match_dup 3)) 0)))] "operands[4] = gen_reg_rtx (<MODE>mode);") matches any mode of (and ...) on input, but hard-codes (and:SI ...) in the output. This causes an ICE if the incoming (and ...) is DImode rather than SImode. Co-developed-by: Richard Sandiford <richard.sandiford@arm.com> PR target/96226 gcc/ChangeLog: * config/i386/predicates.md (and_operator): New operator. * config/i386/i386.md (splitter after *<rotate_insn><mode>3_mask): Use and_operator to match AND RTX and use its mode in the split pattern.
2025-08-06[hardbool] implement OP=, ++ and --, volatile and atomicsAlexandre Oliva6-21/+164
hardbools didn't behave quite like bools when incremented, decremented, or otherwise modified using their previous value, as in += et al. Fix that. Also fix some checking errors that come up when using qualified base types. for gcc/c-family/ChangeLog * c-attribs.cc (handle_hardbool_attribute): Create distinct enumeration types, with structural equality. Handle base type qualifiers. for gcc/c/ChangeLog * c-tree.h (C_BOOLEAN_TYPE_P): Cover hardbools as well. * c-typeck.cc (convert_lvalue_to_rvalue): New overload and wrapper. (build_atomic_assign, build_modify_expr): Use it. (build_asm_expr, handle_omp-array_sections_1): Simplify with it. (build_unary_op): Handle hardbools. for gcc/testsuite/ChangeLog * gcc.dg/torture/hardbool-ai.c: New. * gcc.dg/torture/hardbool-vi.c: New. * gcc.dg/torture/hardbool.c: Handle NO_BITFIELDS. (add1, preinc, postinc, sub1, predec, postdec): New. (main): Exercise them.
2025-08-06install: Replace bzip2 by xzGerald Pfeifer1-1/+1
In addition to gzip format our snapshots and releases have been using xz instead of bzip2 for a while. gcc: PR target/69374 * doc/install.texi (Prerequisites): Replace bzip2 by xz.
2025-08-06i386: Add missing PTA_POPCNT and PTA_LZCNT with PTA_ABMYangyu Chen1-17/+17
This patch adds the missing PTA_POPCNT and PTA_LZCNT with the PTA_ABM bitmask definition for the bdver1, btver1, and lujiazui architectures in the i386 architecture configuration file. Although these two features were not present in the original definition, their absence does not affect the functionality of these architectures because the POPCNT and LZCNT bits are set when ABM is enabled in the ix86_option_override_internal function. However, including them in these definitions improves consistency and clarity. This issue was discovered while writing a script to extract these bitmasks from the i386.h file referenced in [1]. Additionally, the PTA_YONGFENG bitmask appears incorrect as it includes PTA_LZCNT while already inheriting PTA_ABM from PTA_LUJIAZUI. This seems to be a typo and should be corrected. [1] https://github.com/cyyself/x86-pta gcc/ChangeLog: * config/i386/i386.h (PTA_BDVER1): Add missing PTA_POPCNT and PTA_LZCNT with PTA_ABM. (PTA_ZNVER1): Ditto. (PTA_BTVER1): Ditto. (PTA_LUJIAZUI): Ditto. (PTA_YONGFENG): Do not include extra PTA_LZCNT. Signed-off-by: Yangyu Chen <cyy@cyyself.name>
2025-08-06gcc: drop placement new workaround for old bootstrap compilersSam James4-74/+3
Since r15-4719-ga9ec1bc06bd3cc, we require GCC 5.4, so a workaround for < GCC 4.3 is long-obsolete. Before that, we required GCC 4.8.3 too. i.e. it shouldn't be possible to build GCC with such a compiler for quite some time. gcc/ChangeLog: PR libstdc++/29286 * Makefile.in (ALIASING_FLAGS): Drop. * configure: Regenerate. * configure.ac: Drop -fno-strict-aliasing workaround for < GCC 4.3. gcc/d/ChangeLog: * Make-lang.in (ALL_DFLAGS): Don't use ALIASING_FLAGS.
2025-08-06c2y: Evaluate size expression only in the active branch of conditional ↵Martin Uecker2-45/+370
operator [PR108931] For size expressions in the branches of the conditional operator should be evaluated only for the active branch. To achieve this, construct also the size expressions for the composite type as conditional expressions depending on the condition of the conditional operator. The change avoids some undefined behavior removed by N3652, but the new constraints for C2Y are not yet implemented. PR c/108931 gcc/c/ChangeLog: * c-typeck.cc (composite_type_cond): Renamed from composite_type with argument for condition (composite_type): New function. (composite_type_internal): Implement new logic. (build_conditional_expr): Pass condition. (common_pointer_type): Adapt. (pointer_diff): Adapt. (build_binary_op): Adapt. gcc/testsuite/ChangeLog: * gcc.dg/vla-tert-1.c: New test.
2025-08-06Simplify vect_supportable_dr_alignmentRichard Biener1-34/+3
The following simplifies vect_supportable_dr_alignment based on the observation that we always dereference dr_info so it cannot be NULL, likewise we always dereference dr so that cannot be NULL either. * tree-vect-data-refs.cc (vect_supportable_dr_alignment): Prune dead code.
2025-08-06c++: mangling cNTTP object w/ implicit non-trailing zeros [PR121231]Patrick Palka5-2/+171
Here the results of A::make(0, 0, 1), (0, 1, 0) and (1, 0, 0) are each represented as a single-element CONSTRUCTOR with CONSTRUCTOR_NO_CLEARING cleared, and when used as as a class NTTP argument we end up mangling them all as A{1}, i.e. eliding both the implicit initial and trailing zeros. Mangling them all the same seems clearly wrong since they're logically different values. It turns out the mangling also omits intermediate zeros, e.g. A::make(1, 0, 1) is mangled as A{1, 1}, the same as A::make(1, 1, 0). It seems we can't omit both trailing and non-trailing implicit zeros without introducing mangling ambiguities. This patch makes us include non-trailing zeros in these manglings (while continuing to omit trailing zeros). This also manifests as a wrong-code bug where the specializations table would conflate different specializations that are in terms of different class NTTP arguments, since the identity of such arguments is tied to their mangling. PR c++/121231 PR c++/119688 PR c++/94511 gcc/ChangeLog: * common.opt: Document additional ABI version 21 change. * doc/invoke.texi: Likewise. gcc/cp/ChangeLog: * mangle.cc (write_expression): Write out implicit non-trailing zeroes of a CONSTRUCTOR when the ABI version is at least 21. gcc/testsuite/ChangeLog: * g++.dg/abi/mangle82.C: New test. * g++.dg/cpp2a/nontype-class73.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com>
2025-08-06c++: improve constexpr type mismatch diagnosticJason Merrill2-5/+18
This diagnostic failed to specify the actual type of the object being accessed through a glvalue of an incompatible type, and could also use to indicate where that object comes from. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_indirect_ref): Improve diagnostic. gcc/testsuite/ChangeLog: * g++.dg/cpp26/constexpr-new3.C: Tweak diagnostic.
2025-08-06Record gather/scatter scale and base in the SLP treeRichard Biener4-27/+79
The main gather/scatter discovery happens at SLP discovery time, the base address and the offset scale are currently not explicitly represented in the SLP tree. This requires re-discovery of them during vectorizable_store/load. The following fixes this by recording this info into the SLP tree. This allows the main vect_check_gather_scatter call to be elided from get_load_store_type and replaced with target support checks for IFN/decl or fallback emulated mode. There's vect_check_gather_scatter left in the path using gather/scatter for strided load/store. I hope to deal with this later. * tree-vectorizer.h (_slp_tree::gs_scale): New. (_slp_tree::gs_base): Likewise. (SLP_TREE_GS_SCALE): Likewise. (SLP_TREE_GS_BASE): Likewise. (vect_describe_gather_scatter_call): Declare. * tree-vect-slp.cc (_slp_tree::_slp_tree): Initialize new members. (vect_build_slp_tree_2): Record gather/scatter base and scale. (vect_get_and_check_slp_defs): For gather/scatter IFNs describe the call to first_gs_info. * tree-vect-data-refs.cc (vect_gather_scatter_fn_p): Add mode of operation with fixed offset vector type. (vect_describe_gather_scatter_call): Export. * tree-vect-stmts.cc (get_load_store_type): Do not call vect_check_gather_scatter to fill gs_info, instead populate from the SLP tree. Check which of, IFN, decl or fallback is supported and record that decision.
2025-08-06Use proper alias type for gather/scatter with SLPRichard Biener1-10/+10
Both vectorizable_load and vectorizable_store compute an alias type commoning differences between SLP lanes. The following makes sure to use that for gather/scatter rather than the random one from the representative created during scalar stmt gather/scatter analysis. * tree-vect-stmts.cc (vectorizable_store): Build proper alias + align pointer value for gather/scatter and SLP and use it. (vectorizable_load): Likewise.
2025-08-06Allow fully masked loops with legacy gather/scatterRichard Biener2-4/+5
The following removes the redundant check on supported gather/scatter IFN in check_load_store_for_partial_vectors which is already done and adjusts those to check the recorded ifn, also allowing legacy gather/scatter which all handle masking. * tree-vect-stmts.cc (check_load_store_for_partial_vectors): Remove redundant gather/scatter target support check, instead check the recorded ifns. Also allow legacy gather/scatter with loop masking. * gcc.dg/vect/vect-gather-1.c: Adjust to hide N.
2025-08-06bitint: Fix build [PR121413]Jakub Jelinek1-1/+2
Sorry, my bootstrap failed last night because of this, I've fixed it up and it bootstrapped/regtested fine overnight, but in the morning forgot to adjust the patch before committing. Without this there is .../gimple-lower-bitint.cc:7678:36: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 7678 | if (min_prec > limb_prec && abi_limb_prec > limb_prec) | ~~~~~~~~~^~~~~~~~~~~ 2025-08-06 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/121413 * gimple-lower-bitint.cc (gimple_lower_bitint): Fix up last commit, cast limb_prec to unsigned before comparison.
2025-08-06AArch64: Fix test for vector length safetyTejas Belagod1-4/+4
The test was unsafe when tested on different vector lengths. This patch fixes it to work on all lengths. gcc/testsuite/ChangeLog * gcc.target/aarch64/sve/acle/general/cops.c: Fix test.
2025-08-06bitint: Do not optimize away conversion to _BitInt before a VCEYang Yujie2-2/+35
A _BitInt value may rely on a conversion to become properly extended. So a conversion to _BitInt is not trivially removable even if the types of the result and the operand have the same precision and size. This patch fixes gcc.dg/torture/bitint-64.c at -O2 on LoongArch, which fails because extension of the result is dropped in a compare-and-swap loop generated for incrementing an _Atomic _BitInt, causing an ABI violation. * match.pd: Preserve conversion to _BitInt before a VCE if the _BitInt is extended. * gcc.dg/torture/bitint-84.c: New test.
2025-08-06bitint: Zero-extend the result of a signed->unsigned widening castYang Yujie2-0/+59
A widening cast from a signed _BitInt operand to an unsigned _BitInt type involves filling the extra limb(s) with sign extension. On a target that wants _BitInts extended in memory, if this unsigned type has a partial limb, the unused part of it should be zeroed. e.g. Assuming limb_mode == E_DImode, at the end of void test (unsigned _BitInt(519) *t, _BitInt(512) x) { *t = -x; } the most significant limb of *t should be masked with 0x7f. This patch also fixes gcc.dg/torture/bitint-16.c, which aborts at -O2 when the extension on load is optimized away. * gimple-lower-bitint.cc (bitint_large_huge::lower_mergeable_stmt): Zero-extend the partial limb of any unsigned _BitInt LHS assigned with a widening sign-extension. * gcc.dg/torture/bitint-83.c: New test.
2025-08-06bitint: Make sure BEXTC checks extension when optimizedYang Yujie1-15/+13
In BEXTC, whether a _BitInt object is properly extended is examined by a value comparison against a copied object in a wider _BitInt type that utilizes all of the partial limb. Since the (implicit) conversion to the wider type may be optimized away now and cause the result of the comparison to always be true, we need to cast the copied object down to the original type to force a extension, so that it can serve as our reference. * gcc.dg/bitintext.h (BEXTC1): Define. Convert the copied object back to the original type before comparison. (BEXTC): Use BEXTC1 for both the signed and the unsigned case.
2025-08-06bitint: Avoid extending ABI-extended large/huge _BitInts on loadYang Yujie1-8/+27
This patch also make casts of ABI-extended large/huge _BitInts behave the same as the small/middle case, i.e. no-op for casts to a higher precision _BitInt with the same number of limbs / extension for casts that turns a full top limb into a partial limb. This conveniently helps keep some code with implementation-specific extension semantics (e.g. BEXTC from gcc.dg/bitintext.h) the same for _BitInts of any precision. * gimple-lower-bitint.cc (bitint_large_huge::limb_access): Add a parameter abi_load_p. If set, load a limb directly in its actual precision without casting from m_limb_type. (struct bitint_large_huge): Same. (bitint_large_huge::handle_load): Use.
2025-08-06bitint: Fix up INTEGER_CST PHI handling [PR121413]Jakub Jelinek2-3/+52
The following testcase is miscompiled on aarch64-linux. The problem is in the optimization to shorten large constants in PHI arguments. In a couple of places during bitint lowering we compute minimal precision of constant and if it is significantly smaller than the precision of the type, store smaller constant in memory and extend it at runtime (zero or all ones). Now, in most places that works fine, we handle the stored number of limbs by loading them from memory and then the rest is extended. In the PHI INTEGER_CST argument handling we do it differently, we don't form there any loops (because we insert stmt sequences on the edges). The problem is that we copy the whole _BitInt variable from memory to the PHI VAR_DECL + initialize the rest to = {} or memset to -1. It has min_prec = CEIL (min_prec, limb_prec) * limb_prec; precision, so e.g. on x86_64 there is no padding and it works just fine. But on aarch64 which has abi_limb_mode TImode and limb_mode DImode it doesn't in some cases. In the testcase the constant has 408 bits min precision, rounded up to limb_prec (64) is 448, i.e. 7 limbs. But aarch64 with TImode abi_limb_mode will actually allocate 8 limbs and the most significant limb is solely padding. As we want to extend the constant with all ones, copying the padding (from memory, so 0s) will result in 64 0 bits where 1 bits were needed. The following patch fixes it by detecting this case and setting min_prec to a multiple of abi limb precision so that it has no padding. 2025-08-06 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/121413 * gimple-lower-bitint.cc (abi_limb_prec): New variable (bitint_precision_kind): Initialize it. (gimple_lower_bitint): Clear it at the start. For min_prec > limb_prec descreased precision vars for INTEGER_CST PHI arguments ensure min_prec is either prec or multiple of abi_limb_prec. * gcc.dg/torture/bitint-85.c: New test.
2025-08-06bitint: Fix up handling of uninitialized mul/div/float cast operands [PR121127]Jakub Jelinek2-3/+27
handle_operand_addr (used for the cases where we use libgcc APIs, so multiplication, division, modulo, casts of _BitInt to float/dfp) when it sees default definition of an SSA_NAME which is not PARM_DECL (i.e. uninitialized one) just allocates single uninitialized limb, there is no need to waste more memory on it, it can just tell libgcc that it has 64-bit precision, not say 1024 bit etc. Unfortunately, doing this runs into some asserts when we have a narrowing cast of the uninitialized SSA_NAME (but still large/huge _BitInt). The following patch fixes that by using a magic value in *prec_stored for the uninitialized cases (0) and just don't do any *prec tweaks for narrowing casts from that. precs still needs to be maintained as before, that one is used for big endian adjustment. 2025-08-06 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/121127 * gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr): For uninitialized SSA_NAME, set *prec_stored to 0 rather than *prec. Handle that case in narrowing casts. If prec_stored is non-NULL, set *prec_stored to prec_stored_val. * gcc.dg/bitint-125.c: New test.
2025-08-06gengtype: Include system.h earlier in gengtype-lex.cc [PR121386]Jakub Jelinek2-11/+3
OpenBSD headers apparently instead of just #define SIZE_MAX something do #ifndef SIZE_MAX #define SIZE_MAX something #endif This causes problem with gengtype-lex.cc, where the flex generated code has #ifndef SIZE_MAX #define SIZE_MAX (~(size_t)0) #endif and system.h is included only after that and since my changes for host size_t *printf printing SIZE_MAX is used in preprocessor expressions, #if SIZE_MAX <= UINT_MAX etc. In the preprocessor, identifiers are replaced with 0 and so it is (~(0)0) <= 0xffffffffU or so and thus invalid. Now, normally we want to include system.h early, ideally immediately after config.h or bconfig.h, but in gengtype-lex.cc case we have #ifdef HOST_GENERATOR_FILE #include "config.h" #define GENERATOR_FILE 1 #else #include "bconfig.h" #endif // flex generated start of file, including #include <stdio.h> #include <string.h> #include <errno.h> #include <stdlib.h> #include <inttypes.h> #ifndef SIZE_MAX #define SIZE_MAX (~(size_t)0) #endif // start of gengtype-lex.l %{} section #ifdef HOST_GENERATOR_FILE #include "config.h" #define GENERATOR_FILE 1 #else #include "bconfig.h" #endif #include "system.h" #define malloc xmalloc #define realloc xrealloc #include "gengtype.h" As I'm not sure what flex we require for building gcc (%top{} which COBOL FE *.l uses is only in flex from 2003-04-01), the patch keeps using the %top{} done by hand in Makefile.in, but includes system.h in the top part, with FLEX_SCANNER temporarily defined (I'm undefining it afterwards because flex generated code defines it again and I don't want to guarantee it is defined to the same value) so that malloc/realloc poisoning doesn't happen and #define malloc xmalloc and realloc xrealloc are done in system.h. Note, system.h already includes all the 5 headers flex generated code includes. 2025-08-06 Jakub Jelinek <jakub@redhat.com> PR bootstrap/121386 * Makefile.in (gengtype-lex.cc): Append #define FLEX_SCANNER, #include "system.h" and #undef FLEX_SCANNER to the prepended lines. * gengtype-lex.l: Remove inclusion of config.h or bconfig.h, system.h and definition of malloc/realloc from %{} section.