aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-09-06-fgo-dump-spec: support _BitIntIan Lance Taylor2-0/+30
gcc/ PR go/111310 * godump.cc (go_format_type): Handle BITINT_TYPE. gcc/testsuite/ PR go/111310 * gcc.misc-tests/godump-1.c: Add _BitInt test cases.
2023-09-06libstdc++: Disable <stacktrace> support by default for freestandingJonathan Wakely2-2/+2
libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Disable by default for freestanding. * configure: Regenerate.
2023-09-06cmd/go: permit $AR to include optionsIan Lance Taylor2-7/+3
Handle the AR environment variable, used by gccgo, the same way we handle the CC environment variable. This ports https://go.dev/cl/526275 to the gofrontend repo. This is needed for gccgo testing because the top-level GCC Makefile now passes a --plugin option to ar if it supports one. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/526295
2023-09-06Additional _BitInt test coverage [PR102989]Jakub Jelinek8-1/+132
On Tue, Sep 05, 2023 at 10:40:26PM +0000, Joseph Myers wrote: > Additional tests I think should be added (for things I expect should > already work): > > * Tests for BITINT_MAXWIDTH in <limits.h>. Test that it's defined for > C2x, but not defined for C11/C17 (the latter independent of whether the > target has _BitInt support). Test the value as well: _BitInt > (BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt > (BITINT_MAXWIDTH + 1) should not be OK. Also test that BITINT_MAXWIDTH >= > ULLONG_MAX. > > * Test _BitInt (N) where N is a constexpr variable or enum constant (I > expect these should work - the required call to convert_lvalue_to_rvalue > for constexpr to work is present - but I don't see such tests in the > testsuite). > > * Test that -funsigned-bitfields does not affect the signedness of _BitInt > (N) bit-fields (the standard wording isn't entirely clear, but that's > what's implemented in the patches). > > * Test the errors for _Sat used with _BitInt (though such a test might not > actually run at present because no target supports both features). The following patch does that plus for most of the new changes in the C _BitInt support patch requested in patch review it also does testsuite coverage. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 * gcc.dg/bitint-2.c (foo): Add tests for constexpr var or enumerator arguments of _BitInt. * gcc.dg/bitint-31.c: Remove forgotten 0 &&. * gcc.dg/bitint-32.c: New test. * gcc.dg/bitint-33.c: New test. * gcc.dg/bitint-34.c: New test. * gcc.dg/bitint-35.c: New test. * gcc.dg/bitint-36.c: New test. * gcc.dg/fixed-point/bitint-1.c: New test.
2023-09-06Handle BITINT_TYPE in build_{,minus_}one_cst [PR102989]Jakub Jelinek1-2/+2
Recent match.pd changes trigger ICE in build_minus_one_cst, apparently I forgot to handle BITINT_TYPE in these (while I've handled it in build_zero_cst). 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 * tree.cc (build_one_cst, build_minus_one_cst): Handle BITINT_TYPE like INTEGER_TYPE.
2023-09-06_BitInt profile fixes [PR102989]Jakub Jelinek1-2/+4
On Thu, Aug 24, 2023 at 03:14:32PM +0200, Jan Hubicka via Gcc-patches wrote: > this patch extends verifier to check that all probabilities and counts are > initialized if profile is supposed to be present. This is a bit complicated > by the posibility that we inline !flag_guess_branch_probability function > into function with profile defined and in this case we need to stop > verification. For this reason I added flag to cfg structure tracking this. This patch broke a couple of _BitInt tests (in the admittedly still uncommitted series - still waiting for review of the C FE bits). Here is a minimal patch to make it work again, though I'm not sure if in the if_then_else and if_then_if_then_else cases I shouldn't scale count of the other bbs as well. if_then method creates if (COND) new_bb1; in a middle of some pre-existing bb (with PROB that COND is true), if_then_else if (COND) new_bb1; else new_bb2; and if_then_if_then_else if (COND1) { if (COND2) new_bb2; else new_bb1; } with PROB1 and PROB2 probabilities that COND1 and COND2 are true. The lowering happens shortly after IPA. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 * gimple-lower-bitint.cc (bitint_large_huge::if_then_else, bitint_large_huge::if_then_if_then_else): Use make_single_succ_edge rather than make_edge, initialize bb->count.
2023-09-06Add further _BitInt <-> floating point tests [PR102989]Jakub Jelinek11-74/+2098
Here are just the testsuite additions from libgcc _BitInt patch review. On Fri, Sep 01, 2023 at 09:48:22PM +0000, Joseph Myers wrote: > 1. Test overflowing conversions to integers (including from inf or NaN) > raise FE_INVALID. (Note: it's not specified in the standard whether > inexact conversions to integers raise FE_INEXACT or not, so testing that > seems less important.) This is in gcc.dg/bitint-28.c (FE_INVALID) and gcc.dg/bitint-29.c (FE_INEXACT) for binary and dfp/bitint-8.c new tests. > 2. Test conversions from integers to floating point raise FE_INEXACT when > inexact, together with FE_OVERFLOW when overflowing (while exact > conversions don't raise exceptions). This is in gcc.dg/bitint-30.c new test. > 3. Test conversions from integers to floating point respect the rounding > mode. This is in gcc.dg/bitint-31.c new test. > 4. Test converting floating-point values in the range (-1.0, 0.0] to both > unsigned and signed _BitInt; I didn't see such tests for binary floating > types, only for decimal types, and the decimal tests didn't include tests > of negative zero itself as the value converted to _BitInt. This is done as incremental changes to existing tests. > 5. Test conversions of noncanonical BID zero to integers (these tests > would be specific to BID). See below for a bug in this area. This is done in dfp/bitint-7.c test. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 * gcc.dg/torture/bitint-21.c (main): Add tests for -1 for signed only, -1 + epsilon, another (-1, 0) range value and -0. * gcc.dg/torture/bitint-22.c (main): Likewise. * gcc.dg/bitint-28.c: New test. * gcc.dg/bitint-29.c: New test. * gcc.dg/bitint-30.c: New test. * gcc.dg/bitint-31.c: New test. * gcc.dg/dfp/bitint-1.c (main): Add tests for -1 for signed only, -1 + epsilon and -0. * gcc.dg/dfp/bitint-2.c (main): Likewise. * gcc.dg/dfp/bitint-3.c (main): Likewise. * gcc.dg/dfp/bitint-7.c: New test. * gcc.dg/dfp/bitint-8.c: New test.
2023-09-06libgcc _BitInt helper documentation [PR102989]Jakub Jelinek3-0/+111
On Mon, Aug 21, 2023 at 05:32:04PM +0000, Joseph Myers wrote: > I think the libgcc functions (i.e. those exported by libgcc, to which > references are generated by the compiler) need documenting in libgcc.texi. > Internal functions or macros in the libgcc patch need appropriate comments > specifying their semantics; especially FP_TO_BITINT and FP_FROM_BITINT > which have a lot of arguments and no comments saying what the semantics of > the macros and their arguments are supposed to me. Here is an incremental patch which does that. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/ * doc/libgcc.texi (Bit-precise integer arithmetic functions): Document general rules for _BitInt support library functions and document __mulbitint3 and __divmodbitint4. (Conversion functions): Document __fix{s,d,x,t}fbitint, __floatbitint{s,d,x,t,h,b}f, __bid_fix{s,d,t}dbitint and __bid_floatbitint{s,d,t}d. libgcc/ * libgcc2.c (bitint_negate): Add function comment. * soft-fp/bitint.h (bitint_negate): Add function comment. (FP_TO_BITINT, FP_FROM_BITINT): Add comment explaining the macros.
2023-09-06C _BitInt incremental fixes [PR102989]Jakub Jelinek17-3/+227
On Wed, Aug 09, 2023 at 09:17:57PM +0000, Joseph Myers wrote: > > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > > mention how those should be passed/returned; in a limited way they are > > supported internally because the internal functions into which > > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > > hack to return 2 values without using references/pointers > > What happens when the usual arithmetic conversions are applied to > operands, one of which is a complex integer type and the other of which is > a wider _BitInt type? I don't see anything in the code to disallow this > case (which would produce an expression with a _Complex _BitInt type), or > any testcases for it. I've added a sorry for that case (+ return the narrower COMPLEX_TYPE). Also added testcase to verify we don't create VECTOR_TYPEs of BITINT_TYPE even if they have mode precision and suitable size (others were rejected already before). > Other testcases I think should be present (along with any corresponding > changes needed to the code itself): > > * Verifying that the new integer constant suffix is rejected for C++. Done. > * Verifying appropriate pedwarn-if-pedantic for the new constant suffix > for versions of C before C2x (and probably for use of _BitInt type > specifiers before C2x as well) - along with the expected -Wc11-c2x-compat > handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. Done. Here is an incremental patch which does that. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/c/ * c-decl.cc (finish_declspecs): Emit pedwarn_c11 on _BitInt. * c-typeck.cc (c_common_type): Emit sorry for common type between _Complex integer and larger _BitInt and return the _Complex integer. gcc/c-family/ * c-attribs.cc (type_valid_for_vector_size): Reject vector types with BITINT_TYPE elements even if they have mode precision and suitable size. gcc/testsuite/ * gcc.dg/bitint-19.c: New test. * gcc.dg/bitint-20.c: New test. * gcc.dg/bitint-21.c: New test. * gcc.dg/bitint-22.c: New test. * gcc.dg/bitint-23.c: New test. * gcc.dg/bitint-24.c: New test. * gcc.dg/bitint-25.c: New test. * gcc.dg/bitint-26.c: New test. * gcc.dg/bitint-27.c: New test. * g++.dg/ext/bitint1.C: New test. * g++.dg/ext/bitint2.C: New test. * g++.dg/ext/bitint3.C: New test. * g++.dg/ext/bitint4.C: New test. libcpp/ * expr.cc (cpp_classify_number): Diagnose wb literal suffixes for -pedantic* before C2X or -Wc11-c2x-compat.
2023-09-06testsuite part 2 for _BitInt support [PR102989]Jakub Jelinek34-0/+5283
This is second part of the testcase additions in order to fit into mailing lists limits. Most of these tests are for the floating point conversions, atomics, __builtin_*_overflow and -fsanitize=undefined. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/testsuite/ * gcc.dg/torture/bitint-20.c: New test. * gcc.dg/torture/bitint-21.c: New test. * gcc.dg/torture/bitint-22.c: New test. * gcc.dg/torture/bitint-23.c: New test. * gcc.dg/torture/bitint-24.c: New test. * gcc.dg/torture/bitint-25.c: New test. * gcc.dg/torture/bitint-26.c: New test. * gcc.dg/torture/bitint-27.c: New test. * gcc.dg/torture/bitint-28.c: New test. * gcc.dg/torture/bitint-29.c: New test. * gcc.dg/torture/bitint-30.c: New test. * gcc.dg/torture/bitint-31.c: New test. * gcc.dg/torture/bitint-32.c: New test. * gcc.dg/torture/bitint-33.c: New test. * gcc.dg/torture/bitint-34.c: New test. * gcc.dg/torture/bitint-35.c: New test. * gcc.dg/torture/bitint-36.c: New test. * gcc.dg/torture/bitint-37.c: New test. * gcc.dg/torture/bitint-38.c: New test. * gcc.dg/torture/bitint-39.c: New test. * gcc.dg/torture/bitint-40.c: New test. * gcc.dg/torture/bitint-41.c: New test. * gcc.dg/torture/bitint-42.c: New test. * gcc.dg/atomic/stdatomic-bitint-1.c: New test. * gcc.dg/atomic/stdatomic-bitint-2.c: New test. * gcc.dg/dfp/bitint-1.c: New test. * gcc.dg/dfp/bitint-2.c: New test. * gcc.dg/dfp/bitint-3.c: New test. * gcc.dg/dfp/bitint-4.c: New test. * gcc.dg/dfp/bitint-5.c: New test. * gcc.dg/dfp/bitint-6.c: New test. * gcc.dg/ubsan/bitint-1.c: New test. * gcc.dg/ubsan/bitint-2.c: New test. * gcc.dg/ubsan/bitint-3.c: New test.
2023-09-06testsuite part 1 for _BitInt support [PR102989]Jakub Jelinek38-0/+4621
This patch adds first part of the testsuite support. When creating the testcases, I've been using https://defuse.ca/big-number-calculator.htm tool, a randombitint tool I wrote (posted as a reply to the first series) plus LLVM trunk on godbolt and the WIP GCC support checking if both compilers agree on stuff (and in case of differences tried constant evaluation etc.). The whole testsuite has been also tested with make -j32 -k check-gcc GCC_TEST_RUN_EXPENSIVE=1 \ RUNTESTFLAGS='GCC_TEST_RUN_EXPENSIVE=1 --target_board=unix\{-m32,-m64\} ubsan.exp=bitint*.c dg.exp=bitint* dg-torture.exp=bitint*' to verify it in all modes, normally I'm limitting the torture tests to just -O0 and -O2 because they are quite large and expensive. Generally it is needed to test different _BitInt precisions because they are lowered differently (the small vs. medium vs. large vs. huge, precision of multiples of limb precision or some other etc.). 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/testsuite/ * lib/target-supports.exp (check_effective_target_bitint, check_effective_target_bitint128, check_effective_target_bitint575): New effective targets. * gcc.dg/bitint-1.c: New test. * gcc.dg/bitint-2.c: New test. * gcc.dg/bitint-3.c: New test. * gcc.dg/bitint-4.c: New test. * gcc.dg/bitint-5.c: New test. * gcc.dg/bitint-6.c: New test. * gcc.dg/bitint-7.c: New test. * gcc.dg/bitint-8.c: New test. * gcc.dg/bitint-9.c: New test. * gcc.dg/bitint-10.c: New test. * gcc.dg/bitint-11.c: New test. * gcc.dg/bitint-12.c: New test. * gcc.dg/bitint-13.c: New test. * gcc.dg/bitint-14.c: New test. * gcc.dg/bitint-15.c: New test. * gcc.dg/bitint-16.c: New test. * gcc.dg/bitint-17.c: New test. * gcc.dg/bitint-18.c: New test. * gcc.dg/torture/bitint-1.c: New test. * gcc.dg/torture/bitint-2.c: New test. * gcc.dg/torture/bitint-3.c: New test. * gcc.dg/torture/bitint-4.c: New test. * gcc.dg/torture/bitint-5.c: New test. * gcc.dg/torture/bitint-6.c: New test. * gcc.dg/torture/bitint-7.c: New test. * gcc.dg/torture/bitint-8.c: New test. * gcc.dg/torture/bitint-9.c: New test. * gcc.dg/torture/bitint-10.c: New test. * gcc.dg/torture/bitint-11.c: New test. * gcc.dg/torture/bitint-12.c: New test. * gcc.dg/torture/bitint-13.c: New test. * gcc.dg/torture/bitint-14.c: New test. * gcc.dg/torture/bitint-15.c: New test. * gcc.dg/torture/bitint-16.c: New test. * gcc.dg/torture/bitint-17.c: New test. * gcc.dg/torture/bitint-18.c: New test. * gcc.dg/torture/bitint-19.c: New test.
2023-09-06C _BitInt support [PR102989]Jakub Jelinek16-143/+844
This patch adds the C FE support, c-family support, small libcpp change so that 123wb and 42uwb suffixes are handled plus glimits.h change to define BITINT_MAXWIDTH macro. The previous patches really do nothing without this, which enables all the support. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/ * glimits.h (BITINT_MAXWIDTH): Define if __BITINT_MAXWIDTH__ is predefined. gcc/c-family/ * c-common.cc (c_common_reswords): Add _BitInt as keyword. (unsafe_conversion_p): Handle BITINT_TYPE like INTEGER_TYPE. (c_common_signed_or_unsigned_type): Handle BITINT_TYPE. (c_common_truthvalue_conversion, c_common_get_alias_set, check_builtin_function_arguments): Handle BITINT_TYPE like INTEGER_TYPE. (sync_resolve_size): Add ORIG_FORMAT argument. If FETCH && !ORIG_FORMAT, type is BITINT_TYPE, return -1 if size isn't one of 1, 2, 4, 8 or 16 or if it is 16 but TImode is not supported. (atomic_bitint_fetch_using_cas_loop): New function. (resolve_overloaded_builtin): Adjust sync_resolve_size caller. If -1 is returned, use atomic_bitint_fetch_using_cas_loop to lower it. Formatting fix. (keyword_begins_type_specifier): Handle RID_BITINT. * c-common.h (enum rid): Add RID_BITINT enumerator. * c-cppbuiltin.cc (c_cpp_builtins): For C call targetm.c.bitint_type_info and predefine __BITINT_MAXWIDTH__ and for -fbuilding-libgcc also __LIBGCC_BITINT_LIMB_WIDTH__ and __LIBGCC_BITINT_ORDER__ macros if _BitInt is supported. * c-lex.cc (interpret_integer): Handle CPP_N_BITINT. * c-pretty-print.cc (c_pretty_printer::simple_type_specifier, c_pretty_printer::direct_abstract_declarator, c_pretty_printer::direct_declarator, c_pretty_printer::declarator): Handle BITINT_TYPE. (pp_c_integer_constant): Handle printing of large precision wide_ints which would buffer overflow digit_buffer. * c-warn.cc (conversion_warning, warnings_for_convert_and_check, warnings_for_convert_and_check): Handle BITINT_TYPE like INTEGER_TYPE. gcc/c/ * c-convert.cc (c_convert): Handle BITINT_TYPE like INTEGER_TYPE. * c-decl.cc (check_bitfield_type_and_width): Allow BITINT_TYPE bit-fields. (finish_struct): Prefer to use BITINT_TYPE for BITINT_TYPE bit-fields if possible. (declspecs_add_type): Formatting fixes. Handle cts_bitint. Adjust for added union in *specs. Handle RID_BITINT. (finish_declspecs): Handle cts_bitint. Adjust for added union in *specs. * c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs, c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle RID_BITINT. (c_parser_omp_clause_schedule): Handle BITINT_TYPE like INTEGER_TYPE. * c-tree.h (enum c_typespec_keyword): Mention _BitInt in comment. Add cts_bitint enumerator. (struct c_declspecs): Move int_n_idx and floatn_nx_idx into a union and add bitint_prec there as well. * c-typeck.cc (c_common_type, comptypes_internal): Handle BITINT_TYPE. (perform_integral_promotions): Promote BITINT_TYPE bit-fields to their declared type. (build_array_ref, build_unary_op, build_conditional_expr, build_c_cast, convert_for_assignment, digest_init, build_binary_op): Handle BITINT_TYPE. * c-fold.cc (c_fully_fold_internal): Handle BITINT_TYPE like INTEGER_TYPE. * c-aux-info.cc (gen_type): Handle BITINT_TYPE. libcpp/ * expr.cc (interpret_int_suffix): Handle wb and WB suffixes. * include/cpplib.h (CPP_N_BITINT): Define.
2023-09-06libgcc _BitInt support [PR102989]Jakub Jelinek33-13/+3339
This patch adds the library helpers for multiplication, division + modulo and casts from and to floating point (both binary and decimal). As described in the intro, the first step is try to reduce further the passed in precision by skipping over most significant limbs with just zeros or sign bit copies. For multiplication and division I've implemented a simple algorithm, using something smarter like Karatsuba or Toom N-Way might be faster for very large _BitInts (which we don't support right now anyway), but could mean more code in libgcc, which maybe isn't what people are willing to accept. For the to/from floating point conversions the patch uses soft-fp, because it already has tons of handy macros which can be used for that. In theory it could be implemented using {,unsigned} long long or {,unsigned} __int128 to/from floating point conversions with some frexp before/after, but at that point we already need to force it into integer registers and analyze it anyway. Plus, for 32-bit arches there is no __int128 that could be used for XF/TF mode stuff. I know that soft-fp is owned by glibc and I think the op-common.h change should be propagated there, but the bitint stuff is really GCC specific and IMHO doesn't belong into the glibc copy. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 libgcc/ * config/aarch64/t-softfp (softfp_extras): Use += rather than :=. * config/i386/64/t-softfp (softfp_extras): Likewise. * config/i386/libgcc-glibc.ver (GCC_14.0.0): Export _BitInt support routines. * config/i386/t-softfp (softfp_extras): Add fixxfbitint and bf, hf and xf mode floatbitint. (CFLAGS-floatbitintbf.c, CFLAGS-floatbitinthf.c): Add -msse2. * config/riscv/t-softfp32 (softfp_extras): Use += rather than :=. * config/rs6000/t-e500v1-fp (softfp_extras): Likewise. * config/rs6000/t-e500v2-fp (softfp_extras): Likewise. * config/t-softfp (softfp_floatbitint_funcs): New. (softfp_bid_list): New. (softfp_func_list): Add sf and df mode from and to _BitInt libcalls. (softfp_bid_file_list): New. (LIB2ADD_ST): Add $(softfp_bid_file_list). * config/t-softfp-sfdftf (softfp_extras): Add fixtfbitint and floatbitinttf. * config/t-softfp-tf (softfp_extras): Likewise. * libgcc2.c (bitint_reduce_prec): New inline function. (BITINT_INC, BITINT_END): Define. (bitint_mul_1, bitint_addmul_1): New helper functions. (__mulbitint3): New function. (bitint_negate, bitint_submul_1): New helper functions. (__divmodbitint4): New function. * libgcc2.h (LIBGCC2_UNITS_PER_WORD): When building _BitInt support libcalls, redefine depending on __LIBGCC_BITINT_LIMB_WIDTH__. (__mulbitint3, __divmodbitint4): Declare. * libgcc-std.ver.in (GCC_14.0.0): Export _BitInt support routines. * Makefile.in (lib2funcs): Add _mulbitint3. (LIB2_DIVMOD_FUNCS): Add _divmodbitint4. * soft-fp/bitint.h: New file. * soft-fp/fixdfbitint.c: New file. * soft-fp/fixsfbitint.c: New file. * soft-fp/fixtfbitint.c: New file. * soft-fp/fixxfbitint.c: New file. * soft-fp/floatbitintbf.c: New file. * soft-fp/floatbitintdf.c: New file. * soft-fp/floatbitinthf.c: New file. * soft-fp/floatbitintsf.c: New file. * soft-fp/floatbitinttf.c: New file. * soft-fp/floatbitintxf.c: New file. * soft-fp/op-common.h (_FP_FROM_INT): Add support for rsize up to 4 * _FP_W_TYPE_SIZE rather than just 2 * _FP_W_TYPE_SIZE. * soft-fp/bitintpow10.c: New file. * soft-fp/fixsdbitint.c: New file. * soft-fp/fixddbitint.c: New file. * soft-fp/fixtdbitint.c: New file. * soft-fp/floatbitintsd.c: New file. * soft-fp/floatbitintdd.c: New file. * soft-fp/floatbitinttd.c: New file.
2023-09-06libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989]Jakub Jelinek1-0/+4947
The following patch adds a header with generated helper tables to support computation of powers of 10 from 10^0 to 10^6111 inclusive into a sufficiently large array of _BitInt limbs. This is split from the rest of the libgcc _BitInt support because it is quite large and together it would run into gcc-patches mail length limits. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 libgcc/ * soft-fp/bitintpow10.h: New file.
2023-09-06ubsan: _BitInt -fsanitize=undefined support [PR102989]Jakub Jelinek4-15/+119
The following patch introduces some -fsanitize=undefined support for _BitInt, but some of the diagnostics is limited by lack of proper support in the library. I've filed https://github.com/llvm/llvm-project/issues/64100 to request proper support, for now some of the diagnostics might have less or more confusing or inaccurate wording but UB should still be diagnosed when it happens. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 gcc/ * internal-fn.cc (expand_ubsan_result_store): Add LHS, MODE and DO_ERROR arguments. For non-mode precision BITINT_TYPE results check if all padding bits up to mode precision are zeros or sign bit copies and if not, jump to DO_ERROR. (expand_addsub_overflow, expand_neg_overflow, expand_mul_overflow): Adjust expand_ubsan_result_store callers. * ubsan.cc: Include target.h and langhooks.h. (ubsan_encode_value): Pass BITINT_TYPE values which fit into pointer size converted to pointer sized integer, pass BITINT_TYPE values which fit into TImode (if supported) or DImode as those integer types or otherwise for now punt (pass 0). (ubsan_type_descriptor): Handle BITINT_TYPE. For pstyle of UBSAN_PRINT_FORCE_INT use TK_Integer (0x0000) mode with a TImode/DImode precision rather than TK_Unknown used otherwise for large/huge BITINT_TYPEs. (instrument_si_overflow): Instrument BITINT_TYPE operations even when they don't have mode precision. * ubsan.h (enum ubsan_print_style): New enumerator. gcc/c-family/ * c-ubsan.cc (ubsan_instrument_shift): Use UBSAN_PRINT_FORCE_INT for type0 type descriptor.
2023-09-06i386: Enable _BitInt on x86-64 [PR102989]Jakub Jelinek1-1/+31
The following patch enables _BitInt support on x86-64, the only target which has _BitInt specified in psABI. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 * config/i386/i386.cc (classify_argument): Handle BITINT_TYPE. (ix86_bitint_type_info): New function. (TARGET_C_BITINT_TYPE_INFO): Redefine.
2023-09-06_BitInt lowering support [PR102989]Jakub Jelinek8-6/+6270
The following patch adds a new bitintlower lowering pass which lowers most operations on medium _BitInt into operations on corresponding integer types, large _BitInt into straight line code operating on 2 or more limbs and finally huge _BitInt into a loop plus optional straight line code. As the only supported architecture is little-endian, the lowering only supports little-endian for now, because it would be impossible to test it all for big-endian. Rest is written with any endian support in mind, but of course only little-endian has been actually tested. I hope it is ok to add big-endian support to the lowering pass incrementally later when first big-endian target shows with the backend support. There are 2 possibilities of adding such support, one would be minimal one, just tweak limb_access function and perhaps one or two other spots and transform there the indexes from little endian (index 0 is least significant) to big endian for just the memory access. Advantage is I think maintainance costs, disadvantage is that the loops will still iterate from 0 to some number of limbs and we'd rely on IVOPTs or something similar changing it later if needed. Or we could make those indexes endian related everywhere, though I'm afraid that would be several hundreds of changes. For switches indexed by large/huge _BitInt the patch invokes what the switch lowering pass does (but only on those specific switches, not all of them); the switch lowering breaks the switches into clusters and none of the clusters can have a range which doesn't fit into 64-bit UWHI, everything else will be turned into a tree of comparisons. For clusters normally emitted as smaller switches, because we already have a guarantee that the low .. high range is at most 64 bits, the patch forces subtraction of the low and turns it into a 64-bit switch. This is done before the actual pass starts. Similarly, we cancel lowering of certain constructs like ABS_EXPR, ABSU_EXPR, MIN_EXPR, MAX_EXPR and COND_EXPR and turn those back to simpler comparisons etc., so that fewer operations need to be lowered later. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 * Makefile.in (OBJS): Add gimple-lower-bitint.o. * passes.def: Add pass_lower_bitint after pass_lower_complex and pass_lower_bitint_O0 after pass_lower_complex_O0. * tree-pass.h (PROP_gimple_lbitint): Define. (make_pass_lower_bitint_O0, make_pass_lower_bitint): Declare. * gimple-lower-bitint.h: New file. * tree-ssa-live.h (struct _var_map): Add bitint member. (init_var_map): Adjust declaration. (region_contains_p): Handle map->bitint like map->outofssa_p. * tree-ssa-live.cc (init_var_map): Add BITINT argument, initialize map->bitint and set map->outofssa_p to false if it is non-NULL. * tree-ssa-coalesce.cc: Include gimple-lower-bitint.h. (build_ssa_conflict_graph): Call build_bitint_stmt_ssa_conflicts if map->bitint. (create_coalesce_list_for_region): For map->bitint ignore SSA_NAMEs not in that bitmap, and allow res without default def. (compute_optimized_partition_bases): In map->bitint mode try hard to coalesce any SSA_NAMEs with the same size. (coalesce_bitint): New function. (coalesce_ssa_name): In map->bitint mode, or map->bitmap into used_in_copies and call coalesce_bitint. * gimple-lower-bitint.cc: New file.
2023-09-06Middle-end _BitInt support [PR102989]Jakub Jelinek30-63/+877
The following patch introduces the middle-end part of the _BitInt support, a new BITINT_TYPE, handling it where needed, except the lowering pass and sanitizer support. 2023-09-06 Jakub Jelinek <jakub@redhat.com> PR c/102989 * tree.def (BITINT_TYPE): New type. * tree.h (TREE_CHECK6, TREE_NOT_CHECK6): Define. (NUMERICAL_TYPE_CHECK, INTEGRAL_TYPE_P): Include BITINT_TYPE. (BITINT_TYPE_P): Define. (CONSTRUCTOR_BITFIELD_P): Return true even for BLKmode bit-fields if they have BITINT_TYPE type. (tree_check6, tree_not_check6): New inline functions. (any_integral_type_check): Include BITINT_TYPE. (build_bitint_type): Declare. * tree.cc (tree_code_size, wide_int_to_tree_1, cache_integer_cst, build_zero_cst, type_hash_canon_hash, type_cache_hasher::equal, type_hash_canon): Handle BITINT_TYPE. (bitint_type_cache): New variable. (build_bitint_type): New function. (signed_or_unsigned_type_for, verify_type_variant, verify_type): Handle BITINT_TYPE. (tree_cc_finalize): Free bitint_type_cache. * builtins.cc (type_to_class): Handle BITINT_TYPE. (fold_builtin_unordered_cmp): Handle BITINT_TYPE like INTEGER_TYPE. * cfgexpand.cc (expand_debug_expr): Punt on BLKmode BITINT_TYPE INTEGER_CSTs. * convert.cc (convert_to_pointer_1, convert_to_real_1, convert_to_complex_1): Handle BITINT_TYPE like INTEGER_TYPE. (convert_to_integer_1): Likewise. For BITINT_TYPE don't check GET_MODE_PRECISION (TYPE_MODE (type)). * doc/generic.texi (BITINT_TYPE): Document. * doc/tm.texi.in (TARGET_C_BITINT_TYPE_INFO): New. * doc/tm.texi: Regenerated. * dwarf2out.cc (base_type_die, is_base_type, modified_type_die, gen_type_die_with_usage): Handle BITINT_TYPE. (rtl_for_decl_init): Punt on BLKmode BITINT_TYPE INTEGER_CSTs or handle those which fit into shwi. * expr.cc (expand_expr_real_1): Define EXTEND_BITINT macro, reduce to bitfield precision reads from BITINT_TYPE vars, parameters or memory locations. Expand large/huge BITINT_TYPE INTEGER_CSTs into memory. * fold-const.cc (fold_convert_loc, make_range_step): Handle BITINT_TYPE. (extract_muldiv_1): For BITINT_TYPE use TYPE_PRECISION rather than GET_MODE_SIZE (SCALAR_INT_TYPE_MODE). (native_encode_int, native_interpret_int, native_interpret_expr): Handle BITINT_TYPE. * gimple-expr.cc (useless_type_conversion_p): Make BITINT_TYPE to some other integral type or vice versa conversions non-useless. * gimple-fold.cc (gimple_fold_builtin_memset): Punt for BITINT_TYPE. (clear_padding_unit): Mention in comment that _BitInt types don't need to fit either. (clear_padding_bitint_needs_padding_p): New function. (clear_padding_type_may_have_padding_p): Handle BITINT_TYPE. (clear_padding_type): Likewise. * internal-fn.cc (expand_mul_overflow): For unsigned non-mode precision operands force pos_neg? to 1. (expand_MULBITINT, expand_DIVMODBITINT, expand_FLOATTOBITINT, expand_BITINTTOFLOAT): New functions. * internal-fn.def (MULBITINT, DIVMODBITINT, FLOATTOBITINT, BITINTTOFLOAT): New internal functions. * internal-fn.h (expand_MULBITINT, expand_DIVMODBITINT, expand_FLOATTOBITINT, expand_BITINTTOFLOAT): Declare. * match.pd (non-equality compare simplifications from fold_binary): Punt if TYPE_MODE (arg1_type) is BLKmode. * pretty-print.h (pp_wide_int): Handle printing of large precision wide_ints which would buffer overflow digit_buffer. * stor-layout.cc (finish_bitfield_representative): For bit-fields with BITINT_TYPE, prefer representatives with precisions in multiple of limb precision. (layout_type): Handle BITINT_TYPE. Handle COMPLEX_TYPE with BLKmode element type and assert it is BITINT_TYPE. * target.def (bitint_type_info): New C target hook. * target.h (struct bitint_info): New type. * targhooks.cc (default_bitint_type_info): New function. * targhooks.h (default_bitint_type_info): Declare. * tree-pretty-print.cc (dump_generic_node): Handle BITINT_TYPE. Handle printing large wide_ints which would buffer overflow digit_buffer. * tree-ssa-sccvn.cc: Include target.h. (eliminate_dom_walker::eliminate_stmt): Punt for large/huge BITINT_TYPE. * tree-switch-conversion.cc (jump_table_cluster::emit): For more than 64-bit BITINT_TYPE subtract low bound from expression and cast to 64-bit integer type both the controlling expression and case labels. * typeclass.h (enum type_class): Add bitint_type_class enumerator. * varasm.cc (output_constant): Handle BITINT_TYPE INTEGER_CSTs. * vr-values.cc (check_for_binary_op_overflow): Use widest2_int rather than widest_int. (simplify_using_ranges::simplify_internal_call_using_ranges): Use unsigned_type_for rather than build_nonstandard_integer_type.
2023-09-06RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296]Juzhe-Zhong2-0/+23
This patch fix incorrect mode tieable between DI and V2SI which cause ICE in RA. gcc/ChangeLog: PR target/111296 * config/riscv/riscv.cc (riscv_modes_tieable_p): Fix incorrect mode tieable for RVV modes. gcc/testsuite/ChangeLog: PR target/111296 * g++.target/riscv/rvv/base/pr111296.C: New test.
2023-09-06RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]Juzhe-Zhong2-2/+37
Fix bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 gcc/ChangeLog: PR target/111295 * config/riscv/riscv-vsetvl.cc (insert_vsetvl): Bug fix. gcc/testsuite/ChangeLog: PR target/111295 * gcc.target/riscv/rvv/autovec/pr111295.c: New test.
2023-09-06RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bitJuzhe-Zhong17-20/+20
Previously, I add TARGET_64BIT condtion to block VLS modes with size = 64bit in RV32 system E.g. V8QI Since I realized such modes may cause inferior codegen for some situations in RV32 system. However, this is really quite ugly and it cause ICE for some cases in RV32: FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (internal compiler error: in require, at machmode.h:313) 3937FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (test for excess errors) For inferior codegen in RV32 system, we should try another reasonable approach to fix it. Remove those TARGET_64BIT and fix ICE. gcc/ChangeLog: * config/riscv/riscv-vector-switch.def (VLS_ENTRY): Remove TARGET_64BIT gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/partial/slp-9.c: Adapt test. * gcc.target/riscv/rvv/autovec/zve32f_zvl1024b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32f_zvl128b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32f_zvl2048b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32f_zvl256b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32f_zvl4096b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32f_zvl512b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32x_zvl1024b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32x_zvl128b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32x_zvl2048b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32x_zvl256b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32x_zvl4096b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve32x_zvl512b-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve64d-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve64f-1.c: Ditto. * gcc.target/riscv/rvv/autovec/zve64x-1.c: Ditto.
2023-09-06analyzer: implement kf_strstr [PR105899]David Malcolm2-0/+150
gcc/analyzer/ChangeLog: PR analyzer/105899 * kf.cc (class kf_strstr): New. (kf_strstr::impl_call_post): New. (register_known_functions): Register it. gcc/testsuite/ChangeLog: PR analyzer/105899 * c-c++-common/analyzer/strstr-1.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-09-06analyzer: implement kf_strncpy [PR105899]David Malcolm6-8/+398
gcc/analyzer/ChangeLog: PR analyzer/105899 * kf.cc (class kf_strncpy): New. (kf_strncpy::impl_call_post): New. (register_known_functions): Register it. * region-model.cc (region_model::read_bytes): Handle unknown number of bytes. gcc/testsuite/ChangeLog: PR analyzer/105899 * c-c++-common/analyzer/null-terminated-strings-2.c: New test. * c-c++-common/analyzer/overlapping-buffers.c: Update dg-bogus directives to avoid clashing with note from <string.h> that might happen to have the same line number. Add strpncpy test coverage. * c-c++-common/analyzer/strncpy-1.c: New test. * gcc.dg/analyzer/null-terminated-strings-1.c (test_filled_nonzero): New. (void test_filled_zero): New. (test_filled_symbolic): New. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-09-06analyzer: add ctxt to fill_region/zero_fill_regionDavid Malcolm4-13/+22
I noticed that region_model's fill_region/zero_fill_region member functions weren't checking that the write to the region was valid. Fixed thusly. gcc/analyzer/ChangeLog: * kf.cc (kf_calloc::impl_call_pre): Pass ctxt to zero_fill_region. (kf_memset::impl_call_pre): Move responsibility for calling check_region_for_write to fill_region. * region-model.cc (region_model::on_assignment): Pass ctxt to zero_fill_region. (region_model::fill_region): Add "ctxt" param, using it to call check_region_for_write. (region_model::zero_fill_region): Likewise. * region-model.h (region_model::fill_region): Add "ctxt" param. (region_model::zero_fill_region): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/plugin/analyzer_cpython_plugin.c: Pass ctxt to zero_fill_region. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-09-06RISC-V: Fix incorrect folder for VRGATHERI16 test casePan Li1-0/+0
Put the test file to the incorrect folder, this patch would like to fix it. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/intrisinc-vrgatherei16.c: Moved to... * gcc.target/riscv/rvv/base/intrisinc-vrgatherei16.c: ...here. Signed-off-by: Pan Li <pan2.li@intel.com>
2023-09-06xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAXTakayuki 'January June' Suwa2-40/+37
This patch optimizes the boolean evaluation for equality to 0 in SImode using the MINU (Minimum Value Unsigned) machine instruction available when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x, 1) and (x == 0) to (MINU(x, 1) ^ 1). /* example */ int test0(int x) { return x == 0; } int test1(int x) { return x != 0; } ;; before test0: mov.n a10, a2 movi.n a9, 1 movi.n a2, 0 moveqz a2, a9, a10 ret.n test1: mov.n a10, a2 movi.n a9, 1 movi.n a2, 0 movnez a2, a9, a10 ret.n ;; after (prereq. TARGET_MINMAX) test0: movi.n a9, 1 minu a2, a2, a9 xor a2, a2, a9 ret.n test1: movi.n a9, 1 minu a2, a2, a9 ret.n gcc/ChangeLog: * config/xtensa/xtensa.cc (xtensa_expand_scc): Add code for particular constants (only 0 and INT_MIN for now) for EQ/NE boolean evaluation in SImode. * config/xtensa/xtensa.md (*eqne_INT_MIN): Remove because its implementation has been integrated into the above.
2023-09-06riscv: xtheadbb: Fix xtheadbb-li-rotr test for rv32Christoph Müllner1-1/+1
The test was introduced recently and tests a RV64-only feature. However, when testing an RV32 compiler, the test gets executed as well and fails with "cc1: error: ABI requires '-march=rv32'". This patch fixes this by adding '-mabi=lp64' (like it is done for other RV64-only tests as well). Retested with RV32 and RV64 to ensure this won't pop up again. Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> gcc/testsuite/ChangeLog: * gcc.target/riscv/xtheadbb-li-rotr.c: Don't run for RV32.
2023-09-06RISC-V: Keep vlmax vector operators in simple form until split1 passLehua Ding5-136/+276
This patch keep vlmax vector pattern in simple before split1 pass which will allow more optimization (e.g. combine) before split1 pass. This patch changes the vlmax pattern in autovec.md to define_insn_and_split as much as possible and clean up some combine patterns that are no longer needed. This patch also fixed PR111232 bug which was caused by a combined failed. PR target/111232 gcc/ChangeLog: * config/riscv/autovec-opt.md (@pred_single_widen_mul<any_extend:su><mode>): Delete. (*pred_widen_mulsu<mode>): Delete. (*pred_single_widen_mul<mode>): Delete. (*dual_widen_<any_widen_binop:optab><any_extend:su><mode>): Add new combine patterns. (*single_widen_sub<any_extend:su><mode>): Ditto. (*single_widen_add<any_extend:su><mode>): Ditto. (*single_widen_mult<any_extend:su><mode>): Ditto. (*dual_widen_mulsu<mode>): Ditto. (*dual_widen_mulus<mode>): Ditto. (*dual_widen_<optab><mode>): Ditto. (*single_widen_add<mode>): Ditto. (*single_widen_sub<mode>): Ditto. (*single_widen_mult<mode>): Ditto. * config/riscv/autovec.md (<optab><mode>3): Change define_expand to define_insn_and_split. (<optab><mode>2): Ditto. (abs<mode>2): Ditto. (smul<mode>3_highpart): Ditto. (umul<mode>3_highpart): Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/widen/widen-4.c: Add more testcases. * gcc.target/riscv/rvv/autovec/widen/widen-complicate-4.c: Ditto. * gcc.target/riscv/rvv/autovec/pr111232.c: New test.
2023-09-06RISC-V: Part-3: Output .variant_cc directive for vector functionLehua Ding4-0/+105
Functions which follow vector calling convention variant need be annotated by .variant_cc directive according the RISC-V Assembly Programmer's Manual[1] and RISC-V ELF Specification[2]. [1] https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#pseudo-ops [2] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#dynamic-linking gcc/ChangeLog: * config/riscv/riscv-protos.h (riscv_declare_function_name): Add protos. (riscv_asm_output_alias): Ditto. (riscv_asm_output_external): Ditto. * config/riscv/riscv.cc (riscv_asm_output_variant_cc): Output .variant_cc directive for vector function. (riscv_declare_function_name): Ditto. (riscv_asm_output_alias): Ditto. (riscv_asm_output_external): Ditto. * config/riscv/riscv.h (ASM_DECLARE_FUNCTION_NAME): Implement ASM_DECLARE_FUNCTION_NAME. (ASM_OUTPUT_DEF_FROM_DECLS): Implement ASM_OUTPUT_DEF_FROM_DECLS. (ASM_OUTPUT_EXTERNAL): Implement ASM_OUTPUT_EXTERNAL. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/abi-call-variant_cc.c: New test.
2023-09-06RISC-V: Part-2: Save/Restore vector registers which need to be preversedLehua Ding12-32/+994
Because functions which follow vector calling convention variant has callee-saved vector reigsters but functions which follow standard calling convention don't have. We need to distinguish which function callee is so that we can tell GCC exactly which vector registers callee will clobber. So I encode the callee's calling convention information into the calls rtx pattern like AArch64. The old operand 2 and 3 of call pattern which copy from MIPS target are useless and removed according to my analysis. gcc/ChangeLog: * config/riscv/riscv-sr.cc (riscv_remove_unneeded_save_restore_calls): Pass riscv_cc. * config/riscv/riscv.cc (struct riscv_frame_info): Add new fileds. (riscv_frame_info::reset): Reset new fileds. (riscv_call_tls_get_addr): Pass riscv_cc. (riscv_function_arg): Return riscv_cc for call patterm. (get_riscv_cc): New function return riscv_cc from rtl call_insn. (riscv_insn_callee_abi): Implement TARGET_INSN_CALLEE_ABI. (riscv_save_reg_p): Add vector callee-saved check. (riscv_stack_align): Add vector save area comment. (riscv_compute_frame_info): Ditto. (riscv_restore_reg): Update for type change. (riscv_for_each_saved_v_reg): New function save vector registers. (riscv_first_stack_step): Handle funciton with vector callee-saved registers. (riscv_expand_prologue): Ditto. (riscv_expand_epilogue): Ditto. (riscv_output_mi_thunk): Pass riscv_cc. (TARGET_INSN_CALLEE_ABI): Implement TARGET_INSN_CALLEE_ABI. * config/riscv/riscv.h (get_riscv_cc): Export get_riscv_cc function. * config/riscv/riscv.md: Add CALLEE_CC operand for call pattern. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-1.c: New test. * gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-2.c: New test. * gcc.target/riscv/rvv/base/abi-callee-saved-1-save-restore.c: New test. * gcc.target/riscv/rvv/base/abi-callee-saved-1-zcmp.c: New test. * gcc.target/riscv/rvv/base/abi-callee-saved-1.c: New test. * gcc.target/riscv/rvv/base/abi-callee-saved-2-save-restore.c: New test. * gcc.target/riscv/rvv/base/abi-callee-saved-2-zcmp.c: New test. * gcc.target/riscv/rvv/base/abi-callee-saved-2.c: New test.
2023-09-06RISC-V: Part-1: Select suitable vector registers for vector type args and ↵Lehua Ding16-17/+1610
returns I post the vector register calling convention rules from in the proposal[1] directly here: v0 is used to pass the first vector mask argument to a function, and to return vector mask result from a function. v8-v23 are used to pass vector data arguments, vector tuple arguments and the rest vector mask arguments to a function, and to return vector data and vector tuple results from a function. Each vector data type and vector tuple type has an LMUL attribute that indicates a vector register group. The value of LMUL indicates the number of vector registers in the vector register group and requires the first vector register number in the vector register group must be a multiple of it. For example, the LMUL of `vint64m8_t` is 8, so v8-v15 vector register group can be allocated to this type, but v9-v16 can not because the v9 register number is not a multiple of 8. If LMUL is less than 1, it is treated as 1. If it is a vector mask type, its LMUL is 1. Each vector tuple type also has an NFIELDS attribute that indicates how many vector register groups the type contains. Thus a vector tuple type needs to take up LMUL×NFIELDS registers. The rules for passing vector arguments are as follows: 1. For the first vector mask argument, use v0 to pass it. The argument has now been allocated. 2. For vector data arguments or rest vector mask arguments, starting from the v8 register, if a vector register group between v8-v23 that has not been allocated can be found and the first register number is a multiple of LMUL, then allocate this vector register group to the argument and mark these registers as allocated. Otherwise, pass it by reference. The argument has now been allocated. 3. For vector tuple arguments, starting from the v8 register, if NFIELDS consecutive vector register groups between v8-v23 that have not been allocated can be found and the first register number is a multiple of LMUL, then allocate these vector register groups to the argument and mark these registers as allocated. Otherwise, pass it by reference. The argument has now been allocated. NOTE: It should be stressed that the search for the appropriate vector register groups starts at v8 each time and does not start at the next register after the registers are allocated for the previous vector argument. Therefore, it is possible that the vector register number allocated to a vector argument can be less than the vector register number allocated to previous vector arguments. For example, for the function `void foo (vint32m1_t a, vint32m2_t b, vint32m1_t c)`, according to the rules of allocation, v8 will be allocated to `a`, v10-v11 will be allocated to `b` and v9 will be allocated to `c`. This approach allows more vector registers to be allocated to arguments in some cases. Vector values are returned in the same manner as the first named argument of the same type would be passed. [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/389 gcc/ChangeLog: * config/riscv/riscv-protos.h (builtin_type_p): New function for checking vector type. * config/riscv/riscv-vector-builtins.cc (builtin_type_p): Ditto. * config/riscv/riscv.cc (struct riscv_arg_info): New fields. (riscv_init_cumulative_args): Setup variant_cc field. (riscv_vector_type_p): New function for checking vector type. (riscv_hard_regno_nregs): Hoist declare. (riscv_get_vector_arg): Subroutine of riscv_get_arg_info. (riscv_get_arg_info): Support vector cc. (riscv_function_arg_advance): Update cum. (riscv_pass_by_reference): Handle vector args. (riscv_v_abi): New function return vector abi. (riscv_return_value_is_vector_type_p): New function for check vector arguments. (riscv_arguments_is_vector_type_p): New function for check vector returns. (riscv_fntype_abi): Implement TARGET_FNTYPE_ABI. (TARGET_FNTYPE_ABI): Implement TARGET_FNTYPE_ABI. * config/riscv/riscv.h (GCC_RISCV_H): Define macros for vector abi. (MAX_ARGS_IN_VECTOR_REGISTERS): Ditto. (MAX_ARGS_IN_MASK_REGISTERS): Ditto. (V_ARG_FIRST): Ditto. (V_ARG_LAST): Ditto. (enum riscv_cc): Define all RISCV_CC variants. * config/riscv/riscv.opt: Add --param=riscv-vector-abi. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/abi-call-args-1-run.c: New test. * gcc.target/riscv/rvv/base/abi-call-args-1.c: New test. * gcc.target/riscv/rvv/base/abi-call-args-2-run.c: New test. * gcc.target/riscv/rvv/base/abi-call-args-2.c: New test. * gcc.target/riscv/rvv/base/abi-call-args-3-run.c: New test. * gcc.target/riscv/rvv/base/abi-call-args-3.c: New test. * gcc.target/riscv/rvv/base/abi-call-args-4-run.c: New test. * gcc.target/riscv/rvv/base/abi-call-args-4.c: New test. * gcc.target/riscv/rvv/base/abi-call-error-1.c: New test. * gcc.target/riscv/rvv/base/abi-call-return-run.c: New test. * gcc.target/riscv/rvv/base/abi-call-return.c: New test.
2023-09-06c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2XJakub Jelinek18-7/+218
Now that _Float{16,32,64,128,32x,64x,128x} and {f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard, I think it is undesirable to pedwarn about these for -std=c2x, so this patch uses pedwarn_c11 instead. In c-family/, we don't have that function and am not sure it would be very clean to define dummy pedwarn_c11 in the C++ FE, so the patch just does what pedwarn_c11 does using pedwarn/warning. 2023-09-06 Jakub Jelinek <jakub@redhat.com> gcc/c-family/ * c-lex.cc (interpret_float): For C diagnostics on FN and FNx suffixes append " before C2X" to diagnostics text and follow behavior of pedwarn_c11. gcc/c/ * c-decl.cc (declspecs_add_type): Use pedwarn_c11 rather than pedwarn for _FloatN{,x} diagnostics and append " before C2X" to the diagnostic text. gcc/testsuite/ * gcc.dg/c11-floatn-1.c: New test. * gcc.dg/c11-floatn-2.c: New test. * gcc.dg/c11-floatn-3.c: New test. * gcc.dg/c11-floatn-4.c: New test. * gcc.dg/c11-floatn-5.c: New test. * gcc.dg/c11-floatn-6.c: New test. * gcc.dg/c11-floatn-7.c: New test. * gcc.dg/c11-floatn-8.c: New test. * gcc.dg/c2x-floatn-1.c: New test. * gcc.dg/c2x-floatn-2.c: New test. * gcc.dg/c2x-floatn-3.c: New test. * gcc.dg/c2x-floatn-4.c: New test. * gcc.dg/c2x-floatn-5.c: New test. * gcc.dg/c2x-floatn-6.c: New test. * gcc.dg/c2x-floatn-7.c: New test. * gcc.dg/c2x-floatn-8.c: New test.
2023-09-06RISC-V: Add conditional sqrt autovec patternLehua Ding6-2/+131
This patch adds a combined pattern for combining vfsqrt.v and vcond_mask. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_<optab><mode>): Add sqrt + vcond_mask combine pattern. * config/riscv/autovec.md (<optab><mode>2): Change define_expand to define_insn_and_split. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-1.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-2.c: New test.
2023-09-05c++: [[no_unique_address]] and cv-qualified typeJason Merrill4-2/+88
We were checking for overlap using same_type_p and therefore allocating two Empty subobjects at the same offset because one was cv-qualified. This gives the warning at the location of the class name rather than the member declaration, but this should be a rare enough issue that it doesn't seem worth trying to be more precise. gcc/ChangeLog: * common.opt: Update -fabi-version=19. gcc/cp/ChangeLog: * class.cc (check_subobject_offset): Check same_type_ignoring_top_level_qualifiers_p. gcc/testsuite/ChangeLog: * g++.dg/abi/no_unique_address8.C: New test. * g++.dg/abi/no_unique_address8a.C: New test.
2023-09-06RISC-V: typo: add closing paren to a commentTsukasa OI1-1/+1
gcc/ChangeLog: * config/riscv/zicond.md: Add closing parent to a comment.
2023-09-06RISC-V: Fix Zicond ICE on large constantsTsukasa OI2-6/+26
Large constant cons and/or alt will trigger ICEs building GCC target libraries (libgomp and libatomic) when the 'Zicond' extension is enabled. For instance, zicond-ice-2.c (new test case in this commit) will cause an ICE when SOME_NUMBER is 0x1000 or larger. While opposite numbers corresponding cons/alt (two temp2 variables) are checked, cons/alt themselves are not checked and causing 2 ICEs building GCC target libraries as of this writing: 1. gcc/libatomic/config/posix/lock.c 2. gcc/libgomp/fortran.c Coercing a large value into a register will fix the issue. It also coerce a large cons into a register on "imm, imm" case (the author could not reproduce but possible to cause an ICE). gcc/ChangeLog: * config/riscv/riscv.cc (riscv_expand_conditional_move): Force large constant cons/alt into a register. gcc/testsuite/ChangeLog: * gcc.target/riscv/zicond-ice-2.c: New test. This is based on an ICE at libat_lock_n func on gcc/libatomic/config/posix/lock.c but heavily minimized.
2023-09-06Daily bump.GCC Administrator5-1/+187
2023-09-05riscv: Synthesize all 11-bit-rotate constants with roriChristoph Müllner3-12/+118
Some constants can be built up using LI+RORI instructions. The current implementation requires one of the upper 32-bits to be a zero bit, which is not neccesary. Let's drop this requirement in order to be able to synthesize a constant like 0xffffffff00ffffffL. The tests for LI+RORI are made more strict to detect regression in the calculation of the LI constant and the rotation amount. Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> gcc/ChangeLog: * config/riscv/riscv.cc (riscv_build_integer_1): Don't require one zero bit in the upper 32 bits for LI+RORI synthesis. gcc/testsuite/ChangeLog: * gcc.target/riscv/xtheadbb-li-rotr.c: New tests. * gcc.target/riscv/zbb-li-rotr.c: Likewise.
2023-09-05RISC-V: Expose bswapsi for TARGET_64BITJeff Law1-1/+10
Various bswapsi tests are failing for rv64. More importantly, we're generating crappy code. Let's take the first test from bswapsi-1.c as an example. > typedef unsigned int uint32_t; > > #define __const_swab32(x) ((uint32_t)( \ > (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) | \ > (((uint32_t)(x) & (uint32_t)0x0000ff00UL) << 8) | \ > (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >> 8) | \ > (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24))) > > /* This byte swap implementation is used by the Linux kernel and the > GNU C library. */ > > uint32_t > swap32_a (uint32_t in) > { > return __const_swab32 (in); > } > > > We generate this for rv64gc_zba_zbb_zbs: > srliw a1,a0,24 > slliw a5,a0,24 > slliw a3,a0,8 > li a2,16711680 > li a4,65536 > or a5,a5,a1 > and a3,a3,a2 > addi a4,a4,-256 > srliw a0,a0,8 > or a5,a5,a3 > and a0,a0,a4 > or a0,a5,a0 > retUrgh! After this patch we generate: > rev8 a0,a0 > srai a0,a0,32 > ret Clearly better. The stated rationale behind not exposing bswapsi2 for TARGET_64BIT is that the RTL expanders already know how to widen a bswap, which is definitely true. But it's the case that failure to expose a bswapsi will cause the 32bit bswap optimizations in gimple store merging to not trigger. Thus we get crappy code. To fix this we expose bswapsi on TARGET_64BIT. gimple-store-merging then detects the 32bit bswap idioms and generates suitable __builtin calls. The expander will "FAIL" expansion for TARGET_64BIT which forces the generic expander code to synthesize the operation (we could synthesize in here, but that'd result in duplicate code). Tested on rv64gc_zba_zbb_zbs, fixes all the bswapsi failures in the testsuite without any regressions. gcc/ * config/riscv/bitmanip.md (bswapsi2): Expose for TARGET_64BIT.
2023-09-05MATCH: Add `(x | c) & ~(y | c)` and `x & ~(y | x)` patterns [PR98710]Andrew Pinski3-1/+48
Adding some more simple bit_and/bit_ior patterns. How often these show up, I have no idea. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/98710 * match.pd (`(x | c) & ~(y | c)`, `(x & c) | ~(y & c)`): New pattern. (`x & ~(y | x)`, `x | ~(y & x)`): New patterns. gcc/testsuite/ChangeLog: PR tree-optimization/98710 * gcc.dg/tree-ssa/andor-7.c: New test. * gcc.dg/tree-ssa/andor-8.c: New test.
2023-09-05MATCH: Add pattern for `(x | y) & (x & z)`Andrew Pinski3-1/+38
Like the pattern already there for `(x | y) & x`, this adds a simple pattern to optimize `(x | y) & (x & z)` to just `x & z`. OK? Bootstrapped and tested on x86-64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/103536 * match.pd (`(x | y) & (x & z)`, `(x & y) | (x | z)`): New patterns. gcc/testsuite/ChangeLog: PR tree-optimization/103536 * gcc.dg/tree-ssa/andor-6.c: New test. * gcc.dg/tree-ssa/andor-bool-1.c: New test.
2023-09-05MATCH: `(nop_convert)-(convert)a` into -(convert)a if we are converting from ↵Andrew Pinski3-0/+46
something smaller This allows removal of one conversion and in the case of booleans, might be able to remove the negate and the other conversion later on. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/107137 gcc/ChangeLog: * match.pd (`(nop_convert)-(convert)a`): New pattern. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/neg-cast-2.c: New test. * gcc.dg/tree-ssa/neg-cast-3.c: New test.
2023-09-05MATCH: Add `~MAX(~X, Y)` pattern: [PR96694]Andrew Pinski2-1/+37
This adds `~MAX(~X, Y)` and `~MIN(~X, Y)` patterns that are like the `~(~a & b)` and `~(~a | b)` patterns and allows to reduce the number of ~ by 1. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/96694 gcc/ChangeLog: * match.pd (`~MAX(~X, Y)`, `~MIN(~X, Y)`): New patterns. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/minmax-24.c: New test.
2023-09-05MATCH: Transform `(1 >> X) !=/== 0` into `X ==/!= 0`Andrew Pinski4-2/+109
We currently have a pattern for handling `(C >> X) & D == 0` but if C is 1 and D is 1, the `& 1` might have been removed. gcc/ChangeLog: PR tree-optimization/105832 * match.pd (`(1 >> X) != 0`): New pattern gcc/testsuite/ChangeLog: PR tree-optimization/105832 * gcc.dg/tree-ssa/pr105832-1.c: New test. * gcc.dg/tree-ssa/pr105832-2.c: New test. * gcc.dg/tree-ssa/pr105832-3.c: New test.
2023-09-05c++: improve verify_constant diagnostic [PR91483]Marek Polacek2-1/+95
When verify_constant complains, it's pretty terse. Consider void test () { constexpr int i = 42; constexpr const int *p = &i; } where it says "'& i' is not a constant expression". OK, but why? With this patch, we say: b.C:5:28: error: '& i' is not a constant expression 5 | constexpr const int *p = &i; | ^~ b.C:5:28: note: pointer to 'i' is not a constant expression b.C:4:17: note: address of non-static constexpr variable 'i' may differ on each invocation of the enclosing function; add 'static' to give it a constant address 4 | constexpr int i = 42; | ^ | static which brings g++ on par with clang++. PR c++/91483 gcc/cp/ChangeLog: * constexpr.cc (verify_constant_explain_r): New. (verify_constant): Call it. gcc/testsuite/ChangeLog: * g++.dg/diagnostic/constexpr3.C: New test.
2023-09-05RISC-V: Add Types to Un-Typed Risc-v InstructionsEdwin Lu1-30/+82
Updates risc-v instructions to ensure that no instruction is left without a type attribute. Added new types "trap" and "cbo" (for cache related instructions) Tested for regressions using rv32/64 multilib with newlib/linux and rv32/64 gcv for linux. gcc/Changelog: * config/riscv/riscv.md: Update/Add types Reviewed-by: Jeff Law <jlaw@ventanamicro.com> Signed-off-by: Edwin Lu <ewlu@rivosinc.com>
2023-09-05RISC-V: Add Types to Un-Typed Pic InstructionsEdwin Lu1-10/+20
Updates pic instructions to ensure that no instruction is left without a type attribute. Tested for regressions using rv32/64 multilib with newlib/linux. gcc/Changelog: * config/riscv/pic.md: Update types Reviewed-by: Jeff Law <jlaw@ventanamicro.com> Signed-off-by: Edwin Lu <ewlu@rivosinc.com>
2023-09-05riscv: xtheadbb: Enable constant synthesis with th.srriChristoph Müllner2-1/+35
Some constants can be built up using rotate-right instructions. The code that enables this can be found in riscv_build_integer_1(). However, this functionality is only available for Zbb, which includes the rori instruction. This patch enables this also for XTheadBb, which includes the th.srri instruction. Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> gcc/ChangeLog: * config/riscv/riscv.cc (riscv_build_integer_1): Enable constant synthesis with rotate-right for XTheadBb. gcc/testsuite/ChangeLog: * gcc.target/riscv/xtheadbb-li-rotr.c: New test.
2023-09-05c++: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]Jakub Jelinek4-19/+394
C++17 had in [basic.block.scope]/2 "A parameter name shall not be redeclared in the outermost block of the function definition nor in the outermost block of any handler associated with a function-try-block." and in [basic.block.scope]/4 similar rule for selection/iteration statements. My reading of that is that it applied even for block local externs in all those spots, while they declare something at namespace scope, the redeclaration happens in that outermost block etc. and introduces names into that. Those wordings seemed to have been moved somewhere else in C++20, but what's worse, they were moved back and completely rewritten in P1787R6: Declarations and where to find them which has been applied as a DR (but admittedly, we don't claim yet to implement that). The current wording at https://eel.is/c++draft/basic.scope#block-2 and https://eel.is/c++draft/basic.scope#scope-2.10 seem to imply at least to me that it doesn't apply to extern block local decls because their target scope is the namespace scope and [basic.scope.block]/2 says "and whose target scope is the block scope"... Now, it is unclear if that is actually the intent or not. There seems to be quite large implementation divergence on this as well. Unpatched g++ e.g. on the redeclaration-5.C testcase diagnoses just lines 55,58,67,70 (i.e. where the previous declaration is in for's condition). clang++ trunk diagnoses just lines 8 and 27, i.e. redeclaration in the function body vs. parameter both in normal fn and lambda (but not e.g. function-try-block and others, including ctors, but it diagnoses those for non-extern decls). ICC 19 diagnoses lines 8,32,38,41,45,52,55,58,61,64,67,70,76. And MSCV trunk diagnoses 8,27,32,38,41,45,48,52,55,58,67,70,76,87,100,137 although the last 4 are just warnings. g++ with the patch diagnoses 8,15,27,32,38,41,45,48,52,55,58,61,64,67,70,76,87,100,121,137 as the dg-error directives test. Jason said: > Yes, I suspect that should be > > If a declaration that is not a name-independent declaration and <del>whose > target scope is</del><ins>that binds a name in</ins> the block scope S of a > > which seems to also be needed to prohibit the already-diagnosed > > void f(int i) { union { int i; }; } > void g(int i) { enum { i }; } The following patch diagnoses DECL_EXTERNAL in check_local_shadow like !DECL_EXTERNAL, except that 1) it uses pedwarn instead of errors for those cases 2) it doesn't diagnose shadowing of namespace scope identifiers by block local externs, as they could be not actually shadowing but just redeclaring the same objects 2023-09-05 Jakub Jelinek <jakub@redhat.com> PR c++/52953 * name-lookup.cc (check_local_shadow): Don't punt early for DECL_EXTERNAL decls, instead just disable the shadowing of namespace decls check for those and emit a pedwarn rather than error_at or permerror for those. Formatting fix. * g++.dg/diagnostic/redeclaration-4.C: New test. * g++.dg/diagnostic/redeclaration-5.C: New test. * g++.dg/warn/Wshadow-19.C: New test.
2023-09-05c++: Diagnose [basic.scope.block]/2 violations even in compound-stmt of ↵Jakub Jelinek8-20/+250
function-try-block [PR52953] As the following testcase shows, while check_local_shadow diagnoses most of the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's name is redeclared inside of the compound-stmt of a function-try-block. There is in that case an extra scope (sk_try with parent artificial sk_block with for FUNCTION_NEEDS_BODY_BLOCK another sk_block and only then sk_function_param). The in_function_try_handler case doesn't work correctly void foo (int x) try { } catch (int) { try { } catch (int x) { } try { } catch (int) { int x; } } (which is valid) is rejected, because || (TREE_CODE (old) == PARM_DECL && (current_binding_level->kind == sk_catch || current_binding_level->level_chain->kind == sk_catch) && in_function_try_handler)) is true but nothing verified that for the first case current_binding_level->level_chain->kind == sk_function_params (with perhaps artificial scopes in between and in the latter case with one extra level in between). The patch also changes behavior where for catch handlers of function-try-block the diagnostics will have the shadows function parameter wording as pedwarn rather than the old redeclaration permerror. 2023-09-05 Jakub Jelinek <jakub@redhat.com> PR c++/52953 * name-lookup.h (struct cp_binding_level): Add artificial bit-field. Formatting fixes. * name-lookup.cc (check_local_shadow): Skip artificial bindings when checking if parameter scope is parent scope. Don't special case FUNCTION_NEEDS_BODY_BLOCK. Diagnose the in_function_try_handler cases in the b->kind == sk_function_parms test and verify no non-artificial intervening scopes. Add missing auto_diagnostic_group. * decl.cc (begin_function_body): Set current_binding_level->artificial. * semantics.cc (begin_function_try_block): Likewise. * g++.dg/diagnostic/redeclaration-1.C: Expect different diagnostic wording. * g++.dg/diagnostic/redeclaration-3.C: New test. * g++.dg/parse/pr31952-1.C: Expect different diagnostic wording. * g++.dg/parse/pr31952-3.C: Likewise.
generated by cgit v1.1 at 2025-02-06 12:32:17 +0000