[upstream] [2024-02-13] Prepare commits #49
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On the following testcase we emit invalid stmt:
error: type mismatch in ‘widen_mult_plus_expr’
6 | foo (int c, int b)
| ^~~
unsigned long
int
unsigned int
unsigned long
_31 = WIDEN_MULT_PLUS_EXPR <b_5(D), 2, _30>;
The recent PR113560 r14-8680 changes tweaked convert_mult_to_widen,
but didn't change convert_plusminus_to_widen for the
TREE_TYPE (rhsN) != typeN cases, but looking at this, it was already
before that change quite weird.
Earlier in those functions it determines actual_precision and from_unsignedN
and wants to use that precision and signedness for the operands and
it used build_and_insert_cast for that (which emits a cast stmt, even for
INTEGER_CSTs) and later on for INTEGER_CST arguments fold_converted them
to typeN (which is unclear to me why, because it seems to have assumed
that TREE_TYPE (rhsN) is typeN, for the actual_precision or from_unsignedN
cases it would be wrong except that build_and_insert_cast forced a SSA_NAME
and so it doesn't trigger anymore).
Now, since r14-8680 it is possible that rhsN also has some other type from
typeN and we again want to cast.
The following patch changes this, so that for the differences in
actual_precision and/or from_unsignedN we actually update typeN and then use
it as the type to convert the arguments to if it isn't useless, for
INTEGER_CSTs by just fold_converting, otherwise using build_and_insert_cast.
And uses useless_type_conversion_p test so that we don't convert unless
necessary. Plus by doing that effectively also doing the important part of
the r14-8680 convert_mult_to_widen changes in convert_plusminus_to_widen.
2024-02-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113759
* tree-ssa-math-opts.cc (convert_mult_to_widen): If actual_precision
or from_unsignedN differs from properties of typeN, update typeN
to build_nonstandard_integer_type. If TREE_TYPE (rhsN) is not
uselessly convertible to typeN, convert it using fold_convert or
build_and_insert_cast depending on if rhsN is INTEGER_CST or not.
(convert_plusminus_to_widen): Likewise.
* gcc.c-torture/compile/pr113759.c: New test.
…PR113736] As discussed in the PR, e.g. build_fold_addr_expr needs TYPE_ADDR_SPACE on the outermost reference rather than just on the base, so the following patch makes sure to propagate the address space from the accessed var to the MEM_REFs and/or VIEW_CONVERT_EXPRs used to access those. 2024-02-06 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113736 * gimple-lower-bitint.cc (bitint_large_huge::limb_access): Use var's address space for MEM_REF or VIEW_CONVERT_EXPRs. * gcc.dg/bitint-86.c: New test.
The UB on the following testcase isn't diagnosed by -fsanitize=address, because we see that the array has a single element and optimize the strlen to 0. I think it is fine to assume e.g. for range purposes the lower bound for the strlen as long as we don't try to optimize strlen (str) where we know that it returns [26, 42] to 26 + strlen (str + 26), but for the upper bound we really want to punt on optimizing that for -fsanitize=address to read all the bytes of the string and diagnose if we run to object end etc. 2024-02-06 Jakub Jelinek <jakub@redhat.com> PR sanitizer/110676 * gimple-fold.cc (gimple_fold_builtin_strlen): For -fsanitize=address reset maxlen to sizetype maximum. * gcc.dg/asan/pr110676.c: New test.
This patch fixes issue reported by Jeff. Testing is running. Ok for trunk if I passed the testing with no regression ? gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): Fix inifinite compilation. (pre_vsetvl::remove_vsetvl_pre_insns): Ditto.
gcc/cp/ChangeLog: * method.cc (early_check_defaulted_comparison): Add auto_diagnostic_group.
std::pair ctor used in tiles constexpr variable is only constexpr in C++14 and later, it works with libstdc++ because it is marked constexpr there even in C++11 mode. The following patch fixes it by using an unnamed local class instead of std::pair, and additionally changes the first element from unsigned int to unsigned char because 0xff has to fit into unsigned char on all hosts. 2024-02-06 Jakub Jelinek <jakub@redhat.com> PR target/113763 * config/aarch64/aarch64.cc (aarch64_output_sme_zero_za): Change tiles element from std::pair<unsigned int, char> to an unnamed struct. Adjust uses of tile range variable.
It would be neater if the middle end for target_clones used a target hook for version name mangling, so we only do version name mangling once. However, that would require more intrusive refactoring that will have to wait till Stage 1. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_mangle_decl_assembler_name): Move before new caller, and add ".default" suffix. (get_suffixed_assembler_name): New. (make_resolver_func): Use get_suffixed_assembler_name. (aarch64_generate_version_dispatcher_body): Redo name mangling. gcc/testsuite/ChangeLog: * g++.target/aarch64/mv-symbols1.C: New test. * g++.target/aarch64/mv-symbols2.C: Ditto. * g++.target/aarch64/mv-symbols3.C: Ditto. * g++.target/aarch64/mv-symbols4.C: Ditto. * g++.target/aarch64/mv-symbols5.C: Ditto. * g++.target/aarch64/mvc-symbols1.C: Ditto. * g++.target/aarch64/mvc-symbols2.C: Ditto. * g++.target/aarch64/mvc-symbols3.C: Ditto. * g++.target/aarch64/mvc-symbols4.C: Ditto.
I was suprised to find out that r14-8759 fixed this accepts-invalid. clang version 17.0.6 rejects the test as well; clang version 19.0.0git crashes for which I opened <llvm/llvm-project#80869>. PR c++/94231 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/deleted17.C: New test.
If we can't find a scratch register for large model profiling, return R10_REG. PR target/113689 * config/i386/i386.cc (x86_64_select_profile_regnum): Return R10_REG after sorry.
…788] The deducing this patchset added parsing of this specifier to cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar this[opt] only appears in the parameter-declaration non-terminal, so rather than checking in all the callers of cp_parser_decl_specifier_seq except for cp_parser_parameter_declaration that this specifier didn't appear I think it is far easier and closer to what the standard says to only parse this specifier when called from cp_parser_parameter_declaration. 2024-02-06 Jakub Jelinek <jakub@redhat.com> PR c++/113788 * parser.cc (CP_PARSER_FLAGS_PARAMETER): New enumerator. (cp_parser_decl_specifier_seq): Parse RID_THIS only if CP_PARSER_FLAGS_PARAMETER is set in flags. (cp_parser_parameter_declaration): Or in CP_PARSER_FLAGS_PARAMETER when calling cp_parser_decl_specifier_seq. * g++.dg/parse/pr113788.C: New test.
There is one corn case when similar as below example:
void test (void)
{
__riscv_vfredosum_tu ();
}
It will meet ICE because of the implement details of overloaded function
in gcc. According to the rvv intrinisc doc, we have no such overloaded
function with empty args. Unfortunately, we register the empty args
function as overloaded for avoiding conflict. Thus, there will be actual
one register function after return NULL_TREE back to the middle-end,
and finally result in ICE when expanding. For example:
1. First we registered void __riscv_vfredmax () as the overloaded function.
2. Then resolve_overloaded_builtin (this func) return NULL_TREE.
3. The functions register in step 1 bypass the args check as empty args.
4. Finally, fall into expand_builtin with empty args and meet ICE.
Here we report error when overloaded function with empty args. For example:
test.c: In function 'foo':
test.c:8:3: error: no matching function call to '__riscv_vfredosum_tu' with empty args
8 | __riscv_vfredosum_tu();
| ^~~~~~~~~~~~~~~~~~~~
Below test are passed for this patch.
* The riscv regression tests.
PR target/113766
gcc/ChangeLog:
* config/riscv/riscv-protos.h (resolve_overloaded_builtin): Adjust
the signature of func.
* config/riscv/riscv-c.cc (riscv_resolve_overloaded_builtin): Ditto.
* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin): Make
overloaded func with empty args error.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: New test.
* gcc.target/riscv/rvv/base/pr113766-2.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
As the following testcases show, the overflow (needs_overflow) and high
handling in wi::mul_internal seem to only work correctly for either
small precisions (less than or equal to 32, that is handled by earlier
simpler code, not the full Knuth's multiplication algorithm) or for
precisions which are multiple of HOST_BITS_PER_WIDE_INT, so it happened
to work fine in most pre-_BitInt era types (and for large bitfields we
probably didn't have good coverage or were lucky and nothing was asking
if there was overflow or not; I think high multiplication is typically
used only when we have optab in corresponding mode).
E.g. on the gcc.dg/bitint-87.c testcase, there were overflow warnings
emitted only the the / 2wb * 3wb _BitInt(128) cases, but not in the
other precisions.
I found 3 issues when prec > HOST_BITS_PER_HALF_WIDE_INT and
(prec % HOST_BITS_PER_WIDE_INT) != 0:
1) the checking for overflow was simply checking the values of the
r array members from half_blocks_needed to 2 * half_blocks_needed - 1,
for UNSIGNED overflow checking if any of them is non-zero, for
SIGNED comparing them if any is different from top where top is computed
from the sign bit of the result (see below); similarly, the highpart
multiplication simply picks the half limbs at r + half_blocks_needed
offset; and furthermore, for SIGNED there is an adjustment if either
operand was negative which also just walks r half-limbs from
half_blocks_needed onwards;
this works great for precisions like 64 or 128, but for precisions like
129, 159, 160 or 161 doesn't, it would need to walk the bits in the
half-limbs starting right above the most significant bit of the base
precision; that can be up to a whole half-limb and all but one bit from
the one below it earlier
2) as the comment says, the multiplication is originally done as unsigned
multiplication, with adjustment of the high bits which subtracts the
other operand once:
if (wi::neg_p (op1))
{
b = 0;
for (i = 0; i < half_blocks_needed; i++)
{
t = (unsigned HOST_WIDE_INT)r[i + half_blocks_needed]
- (unsigned HOST_WIDE_INT)v[i] - b;
r[i + half_blocks_needed] = t & HALF_INT_MASK;
b = t >> (HOST_BITS_PER_WIDE_INT - 1);
}
}
and similarly for the other one. Now, this also only works nicely if
a negative operand has just a single sign bit set in the given precision;
but we were unpacking the operands with wi_unpack (..., SIGNED);, so
say for the negative operand in 129-bit precision, that means the least
significant bit of u[half_blocks_needed - 2] (or v instead of u depending
on which argument it is) is the set sign bit, but then there are 31
further copies of the sign bit in u[half_blocks_needed - 2] and
further 32 copies in u[half_blocks_needed - 1]; the above adjustment
for signed operands doesn't really do the right job in such cases, it
would need to subtract many more times the other operand
3) the computation of top for SIGNED
top = r[(half_blocks_needed) - 1];
top = SIGN_MASK (top << (HOST_BITS_PER_WIDE_INT / 2));
top &= mask;
also uses the most significant bit which fits into prec of the result
only if prec is multiple of HOST_BITS_PER_WIDE_INT, otherwise we need
to look at a different bit and sometimes it can be also a bit in
r[half_blocks_needed - 2]
For 1), while for UNSIGNED overflow it could be fairly easy to check
the bits above prec in r half-limbs for being non-zero, doing all the
shifts also in the SIGNED adjustment code in 2 further locations and finally
for the high handling (unless we want to assert one doesn't do the highpart
multiply for such precisions) would be quite ugly and hard to maintain, so
I instead chose (implemented in the second hunk) to shift the
beyond-precision bits up such that the expectations of the rest of the
code are met, that is the LSB of r[half_blocks_needed] after adjustment
is the bit immediately above the precision, etc. We don't need to care
about the bits it shifts out, because the multiplication will yield at most
2 * prec bits.
For 2), the patch changes the wi_unpack argument from SIGNED to UNSIGNED,
so that we get all zero bits above the precision.
And finally for 3) it does shifts and perhaps picks lower r half-limb so
that it uses the actual MSB of the result within prec.
2024-02-07 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113753
* wide-int.cc (wi::mul_internal): Unpack op1val and op2val with
UNSIGNED rather than SIGNED. If high or needs_overflow and prec is
not a multiple of HOST_BITS_PER_WIDE_INT, shift left bits above prec
so that they start with r[half_blocks_needed] lowest bit. Fix up
computation of top mask for SIGNED.
* gcc.dg/torture/bitint-56.c: New test.
* gcc.dg/bitint-87.c: New test.
gcc.dg/debug/dwarf2/inline5.c has been XPASSing on Solaris (both SPARC and x86, 32 and 64-bit) with the native assembler since 20210429. According to gcc-testresults postings, the same is true on AIX. XPASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not \\\\(DIE \\\\(0x([0-9a-f]*)\\\\) DW_TAG_lexical_block\\\\)[^#/!@;\\\\|]*[#/!@;\\\\|]+ +DW_AT.*DW_TAG_lexical_block\\\\)[^#/!@;\\\\|x]*x\\\\1[^#/!@;\\\\|]*[#/!@;\\\\|] +DW_AT_abstract_origin This is obviously due to commit 16683ce Author: Alexandre Oliva <oliva@adacore.com> Date: Wed Apr 28 14:07:41 2021 -0300 fix asm-not pattern in dwarf2/inline5.c This patch thus removes the xfail. Tested on i386-pc-solaris2.11 (as and gas), sparc-sun-solaris2.11 (as and gas), and i686-pc-linux-gnu. 2024-02-06 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: * gcc.dg/debug/dwarf2/inline5.c: Don't xfail scan-assembler-not on { aix || solaris2 } && !gas.
ABSU_EXPR unary expr is special because it has a signed integer argument and unsigned integer result (of the same precision). The following testcase is miscompiled since ABSU_EXPR handling has been added to range-op because it uses widest_int::from with the result sign (i.e. UNSIGNED) rather than the operand sign (i.e. SIGNED), so e.g. for the 32-bit int argument mask ends up 0xffffffc1 or something similar and even when it has most significant bit in the precision set, in widest_int (tree-ssa-ccp.cc really should stop using widest_int, but that is I think stage1 task) it doesn't appear to be negative and so bit_value_unop ABSU_EXPR doesn't set the resulting mask/value from oring of the argument and its negation. Fixed thusly, not doing that for GIMPLE_BINARY_RHS because I don't know about a binary op that would need something similar. 2024-02-06 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113756 * range-op.cc (update_known_bitmask): For GIMPLE_UNARY_RHS, use TYPE_SIGN (lh.type ()) instead of sign for widest_int::from of lh_bits value and mask. * gcc.dg/pr113756.c: New test.
This just adds an additional runtime testcase for the fixed issue. gcc/testsuite/ChangeLog: PR tree-optimization/113467 * gcc.dg/vect/vect-early-break_110-pr113467.c: New test.
We use gsi_move_before (&stmt_gsi, &dest_gsi); to request that the new statement be placed before any other statement. Typically this then moves the current pointer to be after the statement we just inserted. However it looks like when the BB is empty, this does not happen and the CUR pointer stays NULL. There's a comment in the source of gsi_insert_before that explains: /* If CUR is NULL, we link at the end of the sequence (this case happens This adds a default parameter to gsi_move_before to allow us to control where the insertion happens. gcc/ChangeLog: PR tree-optimization/113731 * gimple-iterator.cc (gsi_move_before): Take new parameter for update method. * gimple-iterator.h (gsi_move_before): Default new param to GSI_SAME_STMT. * tree-vect-loop.cc (move_early_exit_stmts): Call gsi_move_before with GSI_NEW_STMT. gcc/testsuite/ChangeLog: PR tree-optimization/113731 * gcc.dg/vect/vect-early-break_111-pr113731.c: New test.
…l [PR113750] The report shows that if the FE leaves a label as the first thing in the dest BB then we ICE because we move the stores before the label. This is easy to fix if we know that there's still only one way into the BB. We would have already rejected the loop if there was multiple paths into the BB however I added an additional check just for early break in case the other constraints are relaxed later with an explanation. After that we fix the issue just by getting the GSI after the labels and I add a bunch of testcases for different positions the label can be added. Only the vect-early-break_112-pr113750.c one results in the label being kept. gcc/ChangeLog: PR tree-optimization/113750 * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Check for single predecessor when doing early break vect. * tree-vect-loop.cc (move_early_exit_stmts): Get gsi at the start but after labels. gcc/testsuite/ChangeLog: PR tree-optimization/113750 * gcc.dg/vect/vect-early-break_112-pr113750.c: New test. * gcc.dg/vect/vect-early-break_113-pr113750.c: New test. * gcc.dg/vect/vect-early-break_114-pr113750.c: New test. * gcc.dg/vect/vect-early-break_115-pr113750.c: New test. * gcc.dg/vect/vect-early-break_116-pr113750.c: New test.
gcc/rust/ChangeLog: * rust-lang.cc (run_rust_tests): Add test. * rust-system.h: Add <algorithm>. * util/make-rust-unicode.py: Output NFC_Quick_Check table. * util/rust-codepoint.h (struct Codepoint): Add is_supplementary method. * util/rust-unicode-data.h: Generated. * util/rust-unicode.cc (binary_search_sorted_array): Removed. (lookup_cc): Remove namespace. (is_alphabetic): Use std::binary_search (nfc_quick_check): New function. (nfc_normalize): Use nfc_quick_check. (is_nfc_qc_maybe): New function. (is_nfc_qc_no): New function. (rust_nfc_qc_test): New test. * util/rust-unicode.h (is_nfc_qc_no): New function. (is_nfc_qc_maybe): New function. (enum class): New enum class. (nfc_quick_check): New function. (rust_nfc_qc_test): New test. Signed-off-by: Raiki Tamura <tamaron1203@gmail.com>
gcc/rust/ChangeLog: * typecheck/rust-hir-type-check.h (class Lifetime): add interned lifetime class * typecheck/rust-typecheck-context.cc (TypeCheckContext::TypeCheckContext): add resolution tool (TypeCheckContext::intern_lifetime): add method to intern lifetime from tyctx (TypeCheckContext::lookup_lifetime): add method to lookup lifetime from tyctx (TypeCheckContext::intern_and_insert_lifetime): add a helper method Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
gcc/rust/ChangeLog: * typecheck/rust-tyty-region.h: New file. Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
gcc/rust/ChangeLog: * hir/tree/rust-hir-item.h: Add missing getter Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
gcc/rust/ChangeLog: * typecheck/rust-hir-trait-resolve.cc: add regions * typecheck/rust-hir-type-check-base.cc (TypeCheckBase::resolve_literal): add regions, resolve generic lifetimes * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): add regions * typecheck/rust-hir-type-check-implitem.cc (TypeCheckTopLevelExternItem::visit): add regions, resolve lifetimes (TypeCheckImplItem::visit): add regions, resove lifetimes * typecheck/rust-hir-type-check-implitem.h: add default value for result * typecheck/rust-hir-type-check-item.cc (TypeCheckItem::visit): add regions, resove lifetimes (TypeCheckItem::resolve_impl_block_substitutions): add regions, resove lifetimes * typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::visit): add regions, resove lifetimes (TypeCheckExpr::resolve_root_path): add regions, resove lifetimes (TypeCheckExpr::resolve_segments): add regions, resove lifetimes * typecheck/rust-hir-type-check-type.cc (TypeCheckType::visit): add regions, resove lifetimes (TypeCheckType::resolve_root_path): add regions, resove lifetimes (ResolveWhereClauseItem::Resolve): add regions, resove lifetimes (ResolveWhereClauseItem::visit): add regions, resove lifetimes * typecheck/rust-hir-type-check.cc (TypeCheckContext::LifetimeResolver::resolve): add regions, resolve lifetimes (TraitItemReference::get_type_from_fn): add regions, resove lifetimes * typecheck/rust-hir-type-check.h: add regions, resove lifetimes * typecheck/rust-substitution-mapper.cc (SubstMapper::SubstMapper): add regions, resove lifetimes (SubstMapper::Resolve): add regions, resove lifetimes (SubstMapper::InferSubst): add regions, resove lifetimes (SubstMapper::visit): add regions, resove lifetimes * typecheck/rust-substitution-mapper.h: add regions, resove lifetimes * typecheck/rust-typecheck-context.cc (TypeCheckContext::TypeCheckContext): lifetime resolution (TypeCheckContext::regions_from_generic_args): lifetime resolution helper * typecheck/rust-tyty-bounds.cc (TypeBoundPredicate::TypeBoundPredicate): add regions, resove lifetimes (TypeBoundPredicate::operator=): add regions, resove lifetimes (TypeBoundPredicate::apply_generic_arguments): add regions, resove lifetimes (TypeBoundPredicateItem::get_tyty_for_receiver): add regions, resove lifetimes * typecheck/rust-tyty-subst.cc (SubstitutionArgumentMappings::get_regions): add regions, resove lifetimes (SubstitutionArgumentMappings::get_mut_regions): getter (SubstitutionArgumentMappings::error): split error and empty (SubstitutionArgumentMappings::empty): split error and empty (SubstitutionArgumentMappings::find_symbol): helper (SubstitutionRef::get_num_lifetime_params): getter (SubstitutionRef::get_num_type_params): getter (SubstitutionRef::needs_substitution): extend to regions (SubstitutionRef::get_mappings_from_generic_args): helper (SubstitutionRef::infer_substitions): add regions * typecheck/rust-tyty-subst.h (class RegionParamList): region param handler * typecheck/rust-tyty.cc (BaseType::monomorphized_clone): add regions, resove lifetimes (InferType::default_type): add regions, resove lifetimes (FnType::clone): add regions, resove lifetimes (ReferenceType::ReferenceType): add regions (ReferenceType::get_region): getter (ReferenceType::clone): add regions * typecheck/rust-tyty.h: add regions, resove Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-implitem.cc (TypeCheckTopLevelExternItem::visit): Add region constraints. (TypeCheckImplItem::visit): Add region constraints. * typecheck/rust-hir-type-check-implitem.h: Add region constraints. * typecheck/rust-hir-type-check-item.cc (TypeCheckItem::ResolveImplBlockSelf): Add region constraints. (TypeCheckItem::visit): Add region constraints. (TypeCheckItem::resolve_impl_item): Add region constraints. (TypeCheckItem::resolve_impl_block_substitutions): Add region constraints. * typecheck/rust-hir-type-check-item.h: Add region constraints. * typecheck/rust-hir-type-check-type.cc (ResolveWhereClauseItem::Resolve): Add region constraints. (ResolveWhereClauseItem::visit): Add region constraints. * typecheck/rust-hir-type-check-type.h (class ResolveWhereClauseItem): Add region constraints. * typecheck/rust-hir-type-check.cc (TraitItemReference::get_type_from_fn): Add region constraints. * typecheck/rust-tyty-bounds.cc (TypeBoundPredicate::TypeBoundPredicate): Add region constraints. * typecheck/rust-tyty-subst.cc (SubstitutionRef::get_region_constraints): Add region constraints. * typecheck/rust-tyty-subst.h (class BaseType): Add region constraints. (struct RegionConstraints): Add region constraints. * typecheck/rust-tyty.cc (BaseType::monomorphized_clone): Add region constraints. (ADTType::clone): Add region constraints. (FnType::clone): Add region constraints. (ProjectionType::clone): Add region constraints. * typecheck/rust-tyty.h: Add region constraints. Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
gcc/rust/ChangeLog: * typecheck/rust-tyty.cc (BaseType::BaseType): Store orig ref. (BaseType::get_orig_ref): Add getter. * typecheck/rust-tyty.h: Store orig ref. Signed-off-by: Jakub Dupak <dev@jakubdupak.com>
Previously, the default ABI was set to Rust, which is not correct for extern blocks and extern functions. This patch changes the default ABI to C for these cases. gcc/rust/ChangeLog: * hir/rust-ast-lower-base.cc (ASTLoweringBase::lower_qualifiers): Change default ABI to C for extern functions (ASTLoweringBase::lower_extern_block): Likewise Signed-off-by: Nobel Singh <nobel2073@gmail.com>
Fixes Rust-GCC#1483 gcc/testsuite/ChangeLog: * rust/compile/issue-1483.rs: New test.
Fixes Rust-GCC#2772 gcc/testsuite/ChangeLog: * rust/compile/issue-2772-1.rs: New test. * rust/compile/issue-2772-2.rs: New test.
Fixes Rust-GCC#2747 gcc/rust/ChangeLog: * typecheck/rust-tyty-subst.cc (SubstitutionRef::get_mappings_from_generic_args): fix gcc/testsuite/ChangeLog: * rust/compile/issue-2747.rs: New test.
…s seg This patch introduces one regression because generics are getting better understood over time. The code here used to apply generics with the same symbol from previous segments which was a bit of a hack with out limited inference variable support. The regression looks like it will be related to another issue which needs to default integer inference variables much more aggresivly to default integer. Fixes Rust-GCC#2723 gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::resolve_segments): remove hack gcc/testsuite/ChangeLog: * rust/compile/issue-1773.rs: Moved to... * rust/compile/issue-1773.rs.bak: ...here. * rust/compile/issue-2723-1.rs: New test. * rust/compile/issue-2723-2.rs: New test.
As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt
enablement patch this testcase FAILs on ia32, there is nothing vectorized in
there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted.
The following patch instead prunes it.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/pr113693.c: Guard _BitInt(837) use with
__BITINT_MAXWIDTH__ >= 837. Use dg-prune-output instead of
dg-message for dbgcnt message.
This patch depends on the libiberty/vprintf-support.c change. 2024-02-12 Jakub Jelinek <jakub@redhat.com> * gengtype.cc (adjust_field_rtx_def): Use HOST_SIZE_T_PRINT_UNSIGNED and cast to fmt_size_t instead of %lu and cast to unsigned long.
…113674] The C and C++ FEs when parsing attributes already canonicalize them (i.e. if they start with __ and end with __ substrings, we remove those). lookup_attribute already verifies in gcc_assert that the first character of name is not an underscore, and even lookup_scoped_attribute_spec doesn't attempt to canonicalize the namespace it is passed. But for some historic reason it was canonicalizing the name argument, which misbehaves when an attribute starts with ____ and ends with ____. I believe it is just wrong to try to canonicalize lookup_scope_attribute_spec name attribute, it should have been canonicalized already, in other spots where it is called it is already canonicalized before. 2024-02-12 Jakub Jelinek <jakub@redhat.com> PR c++/113674 * attribs.cc (extract_attribute_substring): Remove. (lookup_scoped_attribute_spec): Don't call it. * c-c++-common/Wattributes-3.c: New test.
…ions multiple of limb_prec [PR113849] handle_cast handles the simple way all narrowing large/huge bitint to large/huge bitint conversions and also such widening conversions if we can assume that the most significant limb is processed using constant index and both lhs and rhs have same number of limbs. But, the condition whether we can rely on the most significant limb being processed using constant index is incorrect. For m_upwards_2limb it was correct (m_upwards_2limb then is the number of limbs handled by the loop, so if lhs_type has larger precision than that, it is handled with constant index), similarly if m_var_msb is set (on left shifts), it is never handled with constant idx. But in other cases, like right shifts or non-equality comparisons, or bitquery operations which operate from most significant to least significant limb, all those can handle even the most significant limb in a loop when lhs_type has precision which is a multiple of limb_prec. So, the following patch punts on the optimization in that case and goes for the conditionals in the loop for that case. 2024-02-12 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113849 * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use fast path for widening casts where !m_upwards_2limb and lhs_type has precision which is a multiple of limb_prec. * gcc.dg/torture/bitint-58.c: New test.
Jason, this is the patch you proposed for PR113545. It looks very safe so I'm posting it here so that it's not forgotten. PR c++/113545 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_switch_expr): If the condition doesn't reduce to an INTEGER_CST, consider it non-constant. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-reinterpret3.C: Remove dg-ice.
A call to `basic_string::clear()` in the std::string move assignment operator leads to a constexpr error from an access of inactive union member `_M_local_buf` in the added test (`test_move()`). Changing `__str._M_local_buf` to `__str._M_use_local_data()` in `operator=(basic_string&& __str)` fixes this. PR libstdc++/113294 libstdc++-v3/ChangeLog: * include/bits/basic_string.h (basic_string::operator=): Use _M_use_local_data() instead of _M_local_buf on the moved-from string. * testsuite/21_strings/basic_string/modifiers/constexpr.cc (test_move): New test. Signed-off-by: Paul Keir <paul.keir@uws.ac.uk> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
During tab edits, the pos (position) and bytes_used
Variables were not being set correctly for stream I/O.
Since stream I/O does not have 'real' records, the
format buffer active length must be used instead of
the record length variable.
PR libgfortran/109358
libgfortran/ChangeLog:
* io/transfer.c (formatted_transfer_scalar_write): Adjust
bytes_used and pos variable for stream access.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr109358.f90: New test.
As noted by Joseph, I broke "make gcc.pot" in r14-6057-g12b67d1e13b3cf by adding an overloaded format API with the format string in a different position, leading to this failure: emit_diagnostic_valist used incompatibly as both --keyword=emit_diagnostic_valist:4 --flag=emit_diagnostic_valist:4:gcc-internal-format and --keyword=emit_diagnostic_valist:5 --flag=emit_diagnostic_valist:5:gcc-internal-format Fix by replacing the overloaded function with one with a different name. See also r10-6297-g6c8e584430bc5d for previous fixes for this involving the same function, or r5-6946-g40fecdd62f7d29 and r5-6959-gdb30e21cbff7b9 for older fixes for similar issues. gcc/analyzer/ChangeLog: * pending-diagnostic.cc (diagnostic_emission_context::warn): Update for renaming of emit_diagnostic_valist overload to emit_diagnostic_valist_meta. (diagnostic_emission_context::inform): Likewise. gcc/ChangeLog: * diagnostic-core.h (emit_diagnostic_valist): Rename overload to... (emit_diagnostic_valist_meta): ...this. * diagnostic.cc (emit_diagnostic_valist): Likewise, to... (emit_diagnostic_valist_meta): ...this. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
PR fortran/113883 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_deferred_array): Set length to zero, avoiding extraneous diagnostics. gcc/testsuite/ChangeLog: * gfortran.dg/allocatable_length.f90: New test.
Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ as broke the gengtype on i686-linux before the libiberty fix is certainly unexpected. size_t is there unsigned int, so expected fmt_size_t is unsigned int (or some other 32-bit type). The problem was that I was comparing SIZE_MAX against signed maxima, but SIZE_MAX is unsigned maximum. 2024-02-13 Jakub Jelinek <jakub@redhat.com> * hwint.h (GCC_PRISZ, fmt_size_t): Fix preprocessor conditions, instead of comparing SIZE_MAX against INT_MAX and LONG_MAX compare it against UINT_MAX and ULONG_MAX.
As I wrote earlier, I was seeing FAIL: gcc.dg/torture/bitint-24.c -O0 execution test FAIL: gcc.dg/torture/bitint-24.c -O2 execution test with the ia32 _BitInt enablement patch on i686-linux. I thought floatbitintxf.c was miscompiled with -O2 -march=i686 -mtune=generic, but it turned out to be UB in it. If a signed _BitInt to be converted to binary floating point has (after sign extension from possible partial limb to full limb) one or more most significant limbs equal to all ones and then in the limb below (the most significant non-~(UBILtype)0 limb) has the most significant limb cleared, like for 32-bit limbs 0x81582c05U, 0x0a8b01e4U, 0xc1b8b18fU, 0x2aac2a08U, -1U, -1U then bitint_reduce_prec can't reduce it to that 0x2aac2a08U limb, so msb is all ones and precision is negative (so it reduced precision from 161 to 192 bits down to 160 bits, in theory could go as low as 129 bits but that wouldn't change anything on the following behavior). But still iprec is negative, -160 here. For that case (i.e. where we are dealing with an negative input), the code was using 65 - __builtin_clzll (~msb) to compute how many relevant bits we have from the msb. Unfortunately that invokes UB for msb all ones. The right number of relevant bits in that case is 1 though (like for -2 it is 2 and -4 or -3 3 as already computed) - all we care about from that is that the most significant bit is set (i.e. the number is negative) and the bits below that should be supplied from the limbs below. So, the following patch fixes it by special casing it not to invoke UB. For msb 0 we already have a special case from before (but that is also different because msb 0 implies the whole number is 0 given the way bitint_reduce_prec works - even if we have limbs like ..., 0x80000000U, 0U the reduction can skip the most significant limb and msb then would be the one below it), so if iprec > 0, we already don't call __builtin_clzll on 0. 2024-02-13 Jakub Jelinek <jakub@redhat.com> * soft-fp/bitint.h (FP_FROM_BITINT): If iprec < 0 and msb is all ones, just set n to 1 instead of using __builtin_clzll (~msb).
…ment The following fixes a missing add to the accumulated offset when adjusting an ARRAY_REF op for value-ranges applied to by get_ref_base_and_extent. PR tree-optimization/113898 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Add missing accumulated off adjustment. * gcc.dg/torture/pr113898.c: New testcase.
When __has_feature was introduced for GCC 14, I included the feature cxx_constexpr_string_builtins, since of the relevant string builtins that GCC implements, it seems to support constexpr evaluation of those builtins. However, as the PR shows, GCC doesn't implement the full list of builtins in the clang documentation. After enumerating the builtins, the clang docs [1] say: > Support for constant expression evaluation for the above builtins can > be detected with __has_feature(cxx_constexpr_string_builtins). and a strict reading of this would suggest we can't really support constexpr evaluation of a builtin if we don't implement the builtin in the first place. So the conservatively correct thing to do seems to be to stop advertising the feature altogether to avoid failing to build code which assumes the presence of this feature implies the presence of all the builtins listed in the clang documentation. [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins gcc/cp/ChangeLog: PR c++/113658 * cp-objcp-common.cc (cp_feature_table): Remove entry for cxx_constexpr_string_builtins. gcc/testsuite/ChangeLog: PR c++/113658 * g++.dg/ext/has-feature2.C: New test.
…113734] When doing early break vectorization we should treat the final iteration as possibly being partial. This so that when we calculate the vector loop upper bounds we take into account that final iteration could have done some work. The attached testcase shows that if we don't then cunroll may unroll the loop an if the upper bound is wrong we lose a vector iteration. This is similar to how we adjust the scalar loop bounds for the PEELED case. gcc/ChangeLog: PR tree-optimization/113734 * tree-vect-loop.cc (vect_transform_loop): Treat the final iteration of an early break loop as partial. gcc/testsuite/ChangeLog: PR tree-optimization/113734 * gcc.dg/vect/vect-early-break_117-pr113734.c: New test.
The following adjusts move_early_exit_stmts to track the last seen VUSE instead of getting it from the last store which could be a PHI where gimple_vuse doesn't work. PR tree-optimization/113902 * tree-vect-loop.cc (move_early_exit_stmts): Track last_seen_vuse for VUSE updating. * gcc.dg/vect/pr113902.c: New testcase.
PR tree-optimization/113831 * tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Fix typo in comment.
As it turned out, my patch to complete the libgm2 autoconf macros works
on both Linux/sparc64 and Linux/x86_64, but breaks Solaris bootstrap:
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_gettimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:148:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
148 | return gettimeofday (tv, tz);
| ^~
| |
| void*
In file included from /usr/include/sys/select.h:27,
from /usr/include/sys/types.h:665,
from /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:35:
/usr/include/sys/time.h:444:18: note: initializing argument 1 of 'int gettimeofday(timeval*, void*)'
444 | int gettimeofday(struct timeval *_RESTRICT_KYWD, void *_RESTRICT_KYWD);
| ^
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_settimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:165:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
165 | return settimeofday (tv, tz);
| ^~
| |
| void*
/usr/include/sys/time.h:431:18: note: initializing argument 1 of 'int
settimeofday(timeval*, void*)'
431 | int settimeofday(struct timeval *, void *);
| ^~~~~~~~~~~~~~~~
This happens because on Linux only HAVE_[GS]ETTIMEOFDAY is defined,
while Solaris has both that and HAVE_STRUCT_TIMEZONE, selecting
different implementations.
Fixed by casting tv to struct timeval *.
I thought about changing the signatures instead to take a struct timeval
* instead, but that seemed risky given that there's a
HAVE_STRUCT_TIMEVAL, so would probably break other targets.
Bootstrapped without regressions on i386-pc-solaris2.11,
sparc-sun-solaris2.11, and x86_64-pc-linux-gnu.
2024-02-13 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libgm2:
* libm2iso/wraptime.cc [HAVE_STRUCT_TIMEZONE && HAVE_GETTIMEOFDAY]
(EXPORT(gettimeofday)): Cast tv to struct timeval *.
[HAVE_STRUCT_TIMEZONE && HAVE_SETTIMEOFDAY]
(EXPORT(settimeofday)): Likewise.
The recent enhancement to discover constant array indices by range info used by get_ref_base_and_extent doesn't work when the outermost component reference is to a bitfield because we track the running offset in the reference ops as bytes. The following does as ao_ref_init_from_vn_reference and recovers that manually, tracking the offset for the purpose of discovering the constant array index in bits instead. PR tree-optimization/113895 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Track offset to discover constant array indices in bits, handle COMPONENT_REF to bitfields. * gcc.dg/torture/pr113895-1.c: New testcase.
The SLP permute optimization rewrite fixed this. PR tree-optimization/113896 * g++.dg/torture/pr113896.C: New testcase.
On the heels of r14-8903, this patch adds further complain parameters so that we don't emit "invalid use of incomplete type" from inside a concept. PR c++/112436 gcc/cp/ChangeLog: * except.cc (expand_start_catch_block): Pass tf_warning_or_error to is_admissible_throw_operand_or_catch_parameter. (build_throw): Pass complain to is_admissible_throw_operand_or_catch_parameter. (complete_ptr_ref_or_void_ptr_p): Add a tsubst_flags_t parameter. Use it. Return bool. Call complete_type_or_maybe_complain instead of complete_type_or_else. (is_admissible_throw_operand_or_catch_parameter): Add a tsubst_flags_t parameter. Use it. Guard error calls. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr112436.C: New test.
…UNSPEC_AUIPC. [PR113742] gcc/ChangeLog: PR target/113742 * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr113742.c: New test.
If register_specialization finds a previous declaration and throws the new one away, we shouldn't still add the new one to DECL_TEMPLATE_SPECIALIZATIONS. PR c++/113612 gcc/cp/ChangeLog: * pt.cc (process_partial_specialization): Return early on redeclaration. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ85.C: New test.
gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-implitem.h: Fix typo in field (region_costraints -> region_constraints).
This adds a testcase for issue Rust-GCC#2129. gcc/testsuite/ChangeLog: * rust/execute/torture/matches_macro.rs: New test.
gcc/rust/ChangeLog: * resolve/rust-ast-resolve-item.cc (flatten_glob): Use Import class. (flatten_rebind): Likewise. (flatten_list): Likewise. (flatten): Likewise. (flatten_use_dec_to_paths): Likewise. (flatten_use_dec_to_imports): Likewise. (ResolveItem::visit): Likewise. (Import::add_prefix): New. (rust_flatten_nested_glob): Adjust test. (rust_flatten_glob): Likewise. (rust_flatten_rebind_none): Likewise. (rust_flatten_rebind): Likewise. (rust_flatten_rebind_nested): Likewise. (rust_flatten_list): Likewise. * resolve/rust-ast-resolve-item.h (class Import): New. gcc/testsuite/ChangeLog: * rust/compile/use_2.rs: New test. Signed-off-by: Owen Avery <powerboat9.gamer@gmail.com>
gcc/rust/ChangeLog: * expand/rust-macro-expand.h (struct MacroExpander): Nitpick: fix formatting of emitted error.
To ensure we don't introduce regressions back to issue Rust-GCC#2314 gcc/testsuite/ChangeLog: * rust/compile/rustc_const_stable.rs: New test.
gcc/rust/ChangeLog: * backend/rust-builtins.cc (BuiltinsContext::register_rust_mappings): Add powi and reformat. * backend/rust-builtins.h: Add missing copyright header. gcc/testsuite/ChangeLog: * rust/compile/torture/intrinsics-math.rs: Adjust pow test, add test for powi. Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
gcc/rust/ChangeLog: * backend/rust-compile-pattern.cc (CompilePatternLet::visit): Lookup type of sub-pattern, not tuple pattern itself. gcc/testsuite/ChangeLog: * rust/compile/issue-2847-b.rs: New test. Signed-off-by: Owen Avery <powerboat9.gamer@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull-request aims to help upstreaming commits to the GCC repository by formatting them and checking that they can be cherry-picked/rebased properly.
The last commit upstreamed was:
gccrs: Fix macro parsing for trait items.The list of commits prepared is as follows:
🐙