[upstream] [2024-02-12] Prepare commits #44
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.
Here we crash on this invalid code because we seem to infinitely recurse and end up with __type_pack_element with index that doesn't tree_fits_shwi_p which then crashes on tree_to_shwi. Thanks to Jakub for suggesting a nicer fix than my original one. PR c++/113834 gcc/cp/ChangeLog: * semantics.cc (finish_type_pack_element): Perform range checking before tree_to_shwi. gcc/testsuite/ChangeLog: * g++.dg/ext/type_pack_element4.C: New test.
Re-write address arithmetic in gm2-libs/SArgs.mod:GetArg to avoid (void *) computation. mc treats ADDRESS as (char *) but does not cast user type (PtrToChar) to (char *) when performing address arithmetic. gcc/m2/ChangeLog: PR modula2/113848 * gm2-libs/SArgs.mod (GetArg): Re-write address arithmetic to avoid (void *) computation. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
…nstexpr parameter) Test-cases, with constexpr-reinterpret3.C dg-ice:ing the PR c++/113545 bug. Regarding the request in the comment, A dg-do run when there's an ICE will cause some CI's to signal an error for the run being "UNRESOLVED" (compilation failed to produce executable). Note that dejagnu (1.6.3) itself doesn't consider this an error. gcc/testsuite: PR c++/113545 * g++.dg/cpp1y/constexpr-reinterpret3.C, g++.dg/cpp1y/constexpr-reinterpret4.C: New tests.
I went through suspicios %l in format strings of *printf family functions combined with casts to (long) or (unsigned long) and tried to find out the types of the original expressions that were cast. Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_* macros together with cast to fmt_size_t for those, and then there were quite a few HOST_WIDE_INTs cast to long, used HOST_WIDE_INT_PRINT_* for those without casts. There was one case of a weird unsigned int variable used with %lu and (long) cast too. 2024-02-10 Jakub Jelinek <jakub@redhat.com> gcc/ * ipa-icf.cc (sem_item_optimizer::process_cong_reduction, sem_item_optimizer::dump_cong_classes): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. * tree.cc (print_debug_expr_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. (print_value_expr_statistics, print_type_hash_statistics): Likewise. * dwarf2out.cc (output_macinfo_op): Use HOST_WIDE_INT_PRINT_UNSIGNED instead of "%lu" and casts to unsigned long. * gcov-dump.cc (dump_gcov_file): Use %u instead of %lu and casts to unsigned long. * tree-ssa-dom.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * cfgexpand.cc (dump_stack_var_partition): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. * gengtype.cc (adjust_field_rtx_def): Likewise. * tree-into-ssa.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * postreload-gcse.cc (dump_hash_table): Likewise. * ggc-page.cc (alloc_page): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. (ggc_internal_alloc, ggc_free): Likewise. * genpreds.cc (write_lookup_constraint_1): Likewise. (write_insn_constraint_len): Likewise. * tree-dfa.cc (dump_dfa_stats): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * varasm.cc (output_constant_pool_contents): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long. * var-tracking.cc (dump_var): Likewise. gcc/c-family/ * c-ada-spec.cc (dump_template_types): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. gcc/c/ * c-decl.cc (get_parm_array_spec): Use HOST_WIDE_INT_PRINT_UNSIGNED instead of "%lu" and casts to unsigned long or unsigned long long. gcc/cp/ * tree.cc (debug_binfo): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long. * pt.cc (print_template_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * class.cc (dump_class_hierarchy_1): Use HOST_WIDE_INT_PRINT_UNSIGNED instead of "%lu" and casts to unsigned long. For TYPE_ALIGN, use %u instead of %lu and drop casts to unsigned long. * parser.cc (cp_lexer_peek_nth_token): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. gcc/fortran/ * trans-common.cc (build_common_decl): Use %wu instead of %lu and casts to unsigned long. * resolve.cc (resolve_ordinary_assign): Use %wd instead of %ld and casts to long. * array.cc (gfc_resolve_character_array_constructor): Likewise. * data.cc (create_character_initializer): Likewise. gcc/jit/ * jit-playback.cc (new_bitcast): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long. gcc/lto/ * lto-common.cc (print_lto_report_1): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. Use %d instead of %ld and casts to long for searches and collisions.
In the previous patch I haven't touched the gcc diagnostic routines,
using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
want the strings to be translatable. We already have %w[diox] for
HOST_WIDE_INT arguments, this patch adds t and z modifiers for those.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
gcc/
* pretty-print.cc (pp_integer_with_precision): Handle precision 3 for
size_t and precision 4 for ptrdiff_t. Formatting fix.
(pp_format): Document %{t,z}{d,i,u,o,x}. Implement t and z modifiers.
Formatting fixes.
(test_pp_format): Test t and z modifiers.
* gcc.cc (read_specs): Use %td instead of %ld and casts to long.
gcc/c-family/
* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
z modifiers.
gcc/fortran/
* error.cc (error_print): Handle z and t modifiers on d, i and u.
* check.cc (gfc_check_transfer): Use %zd instead of %ld and casts to
long.
* primary.cc (gfc_convert_to_structure_constructor): Use %td instead
of %ld and casts to long.
…ibute [PR110754] As the following testcases show, the gimple-low outlining of assume magic functions handled volatile automatic vars (including parameters/results) like non-volatile ones except it copied volatile to the new PARM_DECL, which has the undesirable effect that a load from the volatile var is passed to IFN_ASSUME and so there is a side-effect there even when side-effects of the assume attribute shouldn't be evaluated. The following patch fixes that by passing address of the volatile variables/parameters/results instead and doing loads or stores from it or to it where it was originally accessed in the assume attribute expression. 2024-02-10 Jakub Jelinek <jakub@redhat.com> PR middle-end/110754 * gimple-low.cc (assumption_copy_decl): For TREE_THIS_VOLATILE decls create PARM_DECL with pointer to original type, set TREE_READONLY and keep TREE_THIS_VOLATILE, TREE_ADDRESSABLE, DECL_NOT_GIMPLE_REG_P and DECL_BY_REFERENCE cleared. (adjust_assumption_stmt_op): For remapped TREE_THIS_VOLATILE decls wrap PARM_DECL into a simple TREE_THIS_NO_TRAP MEM_REF. (lower_assumption): For TREE_THIS_VOLATILE vars pass ADDR_EXPR of the var as argument. * gcc.dg/attr-assume-6.c: New test. * g++.dg/cpp23/attr-assume12.C: New test.
I've tried last night to enable _BitInt support for i?86-linux, and a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly didn't do what it was supposed to do. Fixed thusly. 2024-02-10 Jakub Jelinek <jakub@redhat.com> * soft-fp/fixddbitint.c (__bid_fixddbitint): Fix up BIL_TYPE_SIZE == 32 shifts. * soft-fp/fixsdbitint.c (__bid_fixsdbitint): Likewise. * soft-fp/fixtdbitint.c (__bid_fixtdbitint): Likewise. * soft-fp/floatbitintdd.c (__bid_floatbitintdd): Likewise. * soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
The ia32 _BitInt support revealed a bug in floatbitint?d.c. As can be even guessed from how the code is written in the loop, the intention was to set inexact to non-zero whenever the remainder after division wasn't zero, but I've ended up just checking whether the 2 least significant limbs of the remainder were non-zero. Now, in the dfp/bitint-4.c test in one case the remainder happens to have least significant 64 bits zero and then the higher limbs are non-zero; with 32-bit limbs that means 2 least significant limbs are zero and so the code acted as if it was exactly divisible. Fixed thusly. 2024-02-10 Jakub Jelinek <jakub@redhat.com> * soft-fp/floatbitintdd.c (__bid_floatbitintdd): Or in all remainder limbs into inexact rather than just first two. * soft-fp/floatbitintsd.c (__bid_floatbitintsd): Likewise. * soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
torture/bitint-37.c test FAILed on i686-linux e.g. on signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575) __builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in the IL, 2 in a loop (which handles the first 8 limbs), then one partial limb (we use 63 bits from that) and finally last_ovf case due to the mixing of signed vs. unsigned. But with 32-bit limbs, we use 5 .UADDC calls in the IL, 2 in a loop (which handles the first 16 limbs), then one full limb above that, one partial (31 bits) and finally last_ovf case, and for the last_ovf case the code computed incorrect idx and so partly did the wrong thing, e.g. overwrote the result from the previous .UADDC. Fixed thusly. 2024-02-10 Jakub Jelinek <jakub@redhat.com> * gimple-lower-bitint.cc (itint_large_huge::lower_addsub_overflow): Fix computation of idx for i == 4 of bitint_prec_huge.
gcc/testsuite/ChangeLog: * gcc.dg/darwin-ld-2.c: Ignore warning that -bind_at_load is deprecated.
Since my r11-532 changes to implement DR2237, for this test:
template<typename T>
struct S {
S<T>();
};
in C++20 we emit the ugly:
q.C:3:8: error: expected unqualified-id before ')' token
3 | S<T>();
which doesn't explain what the problem is. This patch improves that
diagnostic, reduces the error to a pedwarn, and adds a -Wc++20-compat
diagnostic. We now say:
q.C:3:7: warning: template-id not allowed for constructor in C++20 [-Wtemplate-id-cdtor]
3 | S<T>();
q.C:3:7: note: remove the '< >'
This patch also fixes
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202#c8>
where the C++20 diagnostic was missing altogether: The problem was that I checked
for CPP_TEMPLATE_ID too early, at a point at which cp_parser_template_id may not
have been called yet. So let's check for it at the end of the function, after
the tentative parse and rollback.
-Wc++20-compat triggered in libitm/; I sent a patch for that.
DR 2237
PR c++/107126
PR c++/97202
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): In C++20 or with -Wc++20-compat,
turn on -Wtemplate-id-cdtor.
* c.opt (Wtemplate-id-cdtor): New.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_unqualified_id): Downgrade the DR2237 error to
a pedwarn.
(cp_parser_constructor_declarator_p): Likewise.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wtemplate-id-cdtor.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2237.C: Adjust dg-error.
* g++.dg/parse/constructor2.C: Likewise.
* g++.dg/template/error34.C: Likewise.
* g++.old-deja/g++.pt/ctor2.C: Likewise.
* g++.dg/DRs/dr2237-2.C: New test.
* g++.dg/DRs/dr2237-3.C: New test.
* g++.dg/DRs/dr2237-4.C: New test.
* g++.dg/DRs/dr2237-5.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-1.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-2.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-3.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-4.C: New test.
gcc/testsuite/ChangeLog: * gcc.dg/ssp-2.c: Ignore warning that -multiply_defined is obsolete
See PR90698. On Xcode 15, the tests currently lead to a segfault of the clang assembler. gcc/testsuite/ChangeLog: * gcc.target/i386/pr113689-1.c: Skip test on darwin. * gcc.target/i386/pr113689-2.c: Likewise. * gcc.target/i386/pr113689-3.c: Likewise.
ChangeLog: * MAINTAINERS: Add myself to write after approval and DCO. Signed-off-by: Alexander Westbrooks <alexanderw@gcc.gnu.org>
The test case for PR97969 needs updates in order to comply with recent changes in GCC14. Without these changes, failures like this can be seen on arm-none-eabi: .../pr97969.c:6:9: error: type defaults to 'int' in declaration of 'a' [-Wimplicit-int] .../pr97969.c:34:1: error: return type defaults to 'int' [-Wimplicit-int] .../pr97969.c:40:3: error: implicit declaration of function 'ae' [-Wimplicit-function-declaration] .../pr97969.c:42:3: error: implicit declaration of function 'af' [-Wimplicit-function-declaration] .../pr97969.c:43:7: error: implicit declaration of function 'ag' [-Wimplicit-function-declaration] .../pr97969.c:46:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] .../pr97969.c:48:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] .../pr97969.c:50:8: error: implicit declaration of function 'setjmp' [-Wimplicit-function-declaration] .../pr97969.c:51:5: error: implicit declaration of function 'ah' [-Wimplicit-function-declaration] .../pr97969.c:52:5: error: implicit declaration of function 'ai' [-Wimplicit-function-declaration] .../pr97969.c:54:5: error: implicit declaration of function 'aj' [-Wimplicit-function-declaration] Patch has been verified on Linux. gcc/testsuite/ChangeLog: * gcc.target/arm/pr97969.c: Update to comply with GCC14 changes. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2024-02-11 John David Anglin <danglin@gcc.gnu.org> libgomp/ChangeLog: PR libgomp/113843 * configure.tgt (hppa*-*-linux*): Define config_path.
On darwin, symbols are prefixed with underscore, and the order of operands is reversed. gcc/testsuite/ChangeLog: * gcc.target/i386/asm-raw-symbol.c: Adjust asm patterns.
2024-02-11 John David Anglin <danglin@gcc.gnu.org> gcc/testsuite/ChangeLog: * gcc.c-torture/execute/ieee/cdivchkf.c: Use ilogb and __builtin_fmax instead of ilogbf and __builtin_fmaxf.
…ee stores This makes sure to elide degenerate virtual PHIs when moving stores across early exits. PR tree-optimization/113863 * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Record crossed virtual PHIs. * tree-vect-loop.cc (move_early_exit_stmts): Elide crossed virtual PHIs. * gcc.dg/vect/pr113863.c: New testcase.
…FLMAP For devices that see a part for the flash memory in the RAM address space, bit-field NVMCTRL_CTRLB.FLMAP must match the value of symbol __flmap. This is achieved by dragging in startup code from lib<mcu>.a. The mechanism is the same like for libgcc's __do_copy_data and __do_clear_bss. The code is implemented in AVR-LibC Rust-GCC#931 and can be dragged by referencing __do_flmap_init. In addition to setting FLMAP, that code also sets bit FLMAPLOCK provided symbol __flmap_lock has a non-zero value. This protects FLMAP from future changes. When the __do_flmap_init code is not wanted, the symbol can be satisfied by linking with -Wl,--defsym,__do_flmap_init=0 gcc/ PR target/112944 * config/avr/gen-avr-mmcu-specs.cc (print_mcu) [have_flmap]: <*link_rodata_in_ram>: Spec undefs symbol __do_flmap_init when not linked with -mrodata-in-ram.
When build with "-Werror=format-diag", there will be one misspelled
term args as below. This patch would like fix it by taking the term
arguments instead.
../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node*
riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree,
vec<tree_node*, va_gc>*)':
../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error:
misspelled term 'args' in format; use 'arguments' instead
[-Werror=format-diag]
4633 | error_at (loc, "no matching function call to %qE with empty
args", fndecl);
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin):
Replace args to arguments for misspelled term.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: Adjust the test cases.
Signed-off-by: Pan Li <pan2.li@intel.com>
As detailed in PR modula2/113888, the 32-bit libm2pim/target.c doesn't assemble in a Linux/sparc64 multilib build. However, the root cause is that the HAVE_EXP10* macros are never defined. While I was at it, I checked for other cases where the code uses HAVE_* macros that are missing from config.h.in. This patch adds the missing checks, changes the configure checks where the names don't match what's used in the code, or corrects the code to use the right names. So far tested on sparc64-unknown-linux-gnu by building libgm2 (32 and 64-bit) and running the gm2 tests. 2024-02-12 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> libgm2: PR modula2/113888 * configure.ac (GM2_CHECK_LIB): Rename gettimeofday guard to HAVE_GETTIMEOFDAY. (GM_CHECK_LIB): Check for settimeofday. (GM2_CHECK_LIB): Check for exp10, exp10f, exp10l in libm. (AC_CHECK_DECLS): Check for getenv. * configure, config.h.in: Regenerate. * libm2pim/dtoa.cc: Rename <strings.h>, <string.h> guards to HAVE_STRINGS_H, HAVE_STRING_H. * libm2pim/ldtoa.cc: Likewise.
When we use get_ref_base_and_extent during VN and that ends up using global ranges to restrict the range of a ref we have to take care of not using the same expression in the hashtable as for a ref that could not use that global range. The following attempts to ensure this by applying similar logic as get_ref_base_and_extent to copy_reference_ops_from_ref so they behave consistent. PR tree-optimization/113831 PR tree-optimization/108355 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): When we see variable array indices and get_ref_base_and_extent can resolve those to constants fix up the ops to constants as well. (ao_ref_init_from_vn_reference): Use 'off' member for ARRAY_REF and ARRAY_RANGE_REF instead of recomputing it. (valueize_refs_1): Also fixup 'off' of ARRAY_RANGE_REF. * gcc.dg/torture/pr113831.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-104.c: Likewise.
…n-Linux targets [PR113448]
Two libgomp tests XPASS on Solaris (any non-Linux target actually) since
their introduction:
XPASS: libgomp.c/alloc-pinned-1.c execution test
XPASS: libgomp.c/alloc-pinned-2.c execution test
The problem is that the test just prints
OS unsupported
and exits successfully, while the test is XFAILed:
/* { dg-xfail-run-if "Pinning not implemented on this host" { ! *-*-linux-gnu } } */
Fixed by aborting immediately after the message above in the non-Linux
case.
Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.
2024-02-02 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libgomp:
PR testsuite/113448
* testsuite/libgomp.c/alloc-pinned-1.c [!__linux__] (CHECK_SIZE):
Call abort.
* testsuite/libgomp.c/alloc-pinned-2.c [!__linux__] (CHECK_SIZE):
Likewise.
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.
CohenArthur
pushed a commit
that referenced
this pull request
Mar 25, 2024
…-int (PR target/112413)
On m68k the compiler assumes that the PC-relative jump-via-jump-table
instruction and the jump table are adjacent with no padding in between.
When -mlong-jump-table-offsets is combined with -malign-int, a 2-byte
nop may be inserted before the jump table, causing the jump to add the
fetched offset to the wrong PC base and thus jump to the wrong address.
Fixed by referencing the jump table via its label. On the test case
in the PR the object code change is (the moveal at 16 is the nop):
a: 6536 bcss 42 <f+0x42>
c: e588 lsll #2,%d0
e: 203b 0808 movel %pc@(18 <f+0x18>,%d0:l),%d0
- 12: 4efb 0802 jmp %pc@(16 <f+0x16>,%d0:l)
+ 12: 4efb 0804 jmp %pc@(18 <f+0x18>,%d0:l)
16: 284c moveal %a4,%a4
18: 0000 0020 orib #32,%d0
1c: 0000 002c orib #44,%d0
Bootstrapped and tested on m68k-linux-gnu, no regressions.
Note: I don't have commit rights to I would need assistance applying this.
PR target/112413
gcc/
* config/m68k/linux.h (ASM_RETURN_CASE_JUMP): For
TARGET_LONG_JUMP_TABLE_OFFSETS, reference the jump table
via its label.
* config/m68k/m68kelf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/netbsd-elf.h (ASM_RETURN_CASE_JUMP): Likewise.
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:
🐙