Jakub Jelinek [Wed, 6 Sep 2023 15:52:24 +0000 (17:52 +0200)]
Additional _BitInt test coverage [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:50:49 +0000 (17:50 +0200)]
Handle BITINT_TYPE in build_{,minus_}one_cst [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:49:44 +0000 (17:49 +0200)]
_BitInt profile fixes [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:47:49 +0000 (17:47 +0200)]
Add further _BitInt <-> floating point tests [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:42:37 +0000 (17:42 +0200)]
libgcc _BitInt helper documentation [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:39:15 +0000 (17:39 +0200)]
C _BitInt incremental fixes [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:37:53 +0000 (17:37 +0200)]
testsuite part 2 for _BitInt support [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:36:41 +0000 (17:36 +0200)]
testsuite part 1 for _BitInt support [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:34:49 +0000 (17:34 +0200)]
C _BitInt support [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:33:05 +0000 (17:33 +0200)]
libgcc _BitInt support [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:31:23 +0000 (17:31 +0200)]
libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:30:07 +0000 (17:30 +0200)]
ubsan: _BitInt -fsanitize=undefined support [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:27:41 +0000 (17:27 +0200)]
_BitInt lowering support [PR102989]
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.
Jakub Jelinek [Wed, 6 Sep 2023 15:25:49 +0000 (17:25 +0200)]
Middle-end _BitInt support [PR102989]
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.
RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit
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.
David Malcolm [Wed, 6 Sep 2023 13:32:01 +0000 (09:32 -0400)]
analyzer: implement kf_strncpy [PR105899]
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>
xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX
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;
}
;; 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.
riscv: xtheadbb: Fix xtheadbb-li-rotr test for rv32
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.
RISC-V: Keep vlmax vector operators in simple form until split1 pass
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.
RISC-V: Part-3: Output .variant_cc directive for vector function
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].
RISC-V: Part-2: Save/Restore vector registers which need to be preversed
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.
RISC-V: Part-1: Select suitable vector registers for vector type args and 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.
* 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.
Jakub Jelinek [Wed, 6 Sep 2023 06:51:00 +0000 (08:51 +0200)]
c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X
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.
* 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.
Jason Merrill [Tue, 5 Sep 2023 21:36:28 +0000 (17:36 -0400)]
c++: [[no_unique_address]] and cv-qualified type
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.
Tsukasa OI [Sun, 3 Sep 2023 12:39:47 +0000 (12:39 +0000)]
RISC-V: Fix Zicond ICE on large constants
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:
riscv: Synthesize all 11-bit-rotate constants with rori
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.
Jeff Law [Tue, 5 Sep 2023 21:39:16 +0000 (15:39 -0600)]
RISC-V: Expose bswapsi for TARGET_64BIT
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.
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.
Marek Polacek [Fri, 1 Sep 2023 21:26:01 +0000 (17:26 -0400)]
c++: improve verify_constant diagnostic [PR91483]
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.
Edwin Lu [Tue, 5 Sep 2023 17:09:40 +0000 (10:09 -0700)]
RISC-V: Add Types to Un-Typed Risc-v Instructions
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>
riscv: xtheadbb: Enable constant synthesis with th.srri
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.
Jakub Jelinek [Tue, 5 Sep 2023 15:31:12 +0000 (17:31 +0200)]
c++: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]
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).
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.
Jakub Jelinek [Tue, 5 Sep 2023 15:26:59 +0000 (17:26 +0200)]
c++: Diagnose [basic.scope.block]/2 violations even in compound-stmt of 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.
Fixes: 1d5bc3285e8a ("[committed][RISC-V] Fix 20010221-1.c with zicond")
This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since in
failing case, pattern semantics were not matching with asm czero.nez
We start with the following src code snippet:
if (a == 0)
return 0;
else
return x;
}
which is equivalent to: "x = (a != 0) ? x : a" where x is NOT 0.
^^^^^^^^^^^^^^^^
and matches define_insn "*czero.nez.<GPR:mode><X:mode>.opt2"
| (insn 41 20 38 3 (set (reg/v:DI 136 [ x ])
| (if_then_else:DI (ne (reg/v:DI 134 [ a ])
| (const_int 0 [0]))
| (reg/v:DI 136 [ x ])
| (reg/v:DI 134 [ a ]))) {*czero.nez.didi.opt2}
The corresponding asm pattern generates
czero.nez x, x, a ; %0, %2, %1
which implies
"x = (a != 0) ? 0 : a"
clearly not what the pattern wants to do.
Essentially "(a != 0) ? x : a" cannot be expressed with CZERO.nez if X
is not guaranteed to be 0.
However this can be fixed with a small tweak
"x = (a != 0) ? x : a"
is same as
"x = (a == 0) ? a : x"
and since middle operand is 0 when a == 0, it is equivalent to
"x = (a == 0) ? 0 : x"
which can be expressed with CZERO.eqz
before fix after fix
----------------- -----------------
li a5,1 li a5,1
ld a4,8(sp) ld a4,8(sp)
czero.nez a0,a4,a5 czero.eqz a0,a4,a5
The issue only happens at -O1 as at higher optimization levels, the
whole conditional move gets optimized away.
This fixes 4 testsuite failues in a zicond build:
FAIL: gcc.c-torture/execute/pr60003.c -O1 execution test
FAIL: gcc.dg/setjmp-3.c execution test
FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 execution test
FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 -fpic execution test
Patrick Palka [Tue, 5 Sep 2023 14:20:51 +0000 (10:20 -0400)]
c++: more dummy non_constant_p arg avoidance
As a follow-up to Marek's r14-3088-ga263152643bbec, this patch makes
us avoid passing an effectively dummy non_constant_p argument in two
more spots in the parser so that we further avoid unnecessary
constantness checks from cp_parser_constant_expression.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_parenthesized_expression_list_elt): Pass
nullptr as non_constant_p to cp_parser_braced_list if our
non_constant_p is null.
(cp_parser_initializer_list): Likewise to
cp_parser_initializer_clause. Avoid inspecting
clause_non_constant_p if it's uninitialized.
Patrick Palka [Tue, 5 Sep 2023 14:17:44 +0000 (10:17 -0400)]
c++: use conversion_obstack_sentinel throughout
This replaces direct calls to conversion_obstack_alloc(0) and obstack_free
with the recently added conversion_obstack_sentinel. In passing, I
noticed build_user_type_conversion and build_operator_new_call don't
free their conversion_obstack allocations, so this patch also uses this
SFINAE helper in those two entry points.
gcc/cp/ChangeLog:
* call.cc (build_user_type_conversion): Free allocated
conversions.
(build_converted_constant_expr_internal): Use
conversion_obstack_sentinel instead.
(perform_dguide_overload_resolution): Likewise.
(build_new_function_call): Likewise.
(build_operator_new_call): Free allocated conversions.
(build_op_call): Use conversion_obstack_sentinel instead.
(build_conditional_expr): Use conversion_obstack_sentinel
instead, and hoist it out to the outermost scope.
(build_new_op): Use conversion_obstack_sentinel instead
and set it up before the first goto. Remove second unneeded goto.
(build_op_subscript): Use conversion_obstack_sentinel instead.
(ref_conv_binds_to_temporary): Likewise.
(build_new_method_call): Likewise.
(can_convert_arg): Likewise.
(can_convert_arg_bad): Likewise.
(perform_implicit_conversion_flags): Likewise.
(perform_direct_initialization_if_possible): Likewise.
(initialize_reference): Likewise.
Kito Cheng [Wed, 30 Aug 2023 07:10:44 +0000 (15:10 +0800)]
RISC-V: Emit .note.GNU-stack for non-linux target as well
We only emit that on linux target before, that not problem before,
however Qemu has fix a bug to make qemu user mode honor PT_GNU_STACK[1],
that will cause problem when we test baremetal with qemu.
So the straightforward is enable that as well for non-linux toolchian,
the price is that will increase few bytes for each binary.
Pan Li [Tue, 5 Sep 2023 10:28:03 +0000 (18:28 +0800)]
RISC-V: Support FP SGNJ autovec for VLS mode
This patch would like to allow the VLS mode autovec for the
floating-point binary operation MAX/MIN.
Given below code example:
void test(float * restrict out, float * restrict in1, float * restrict in2)
{
for (int i = 0; i < 128; i++)
out[i] = __builtin_copysignf (in1[i], in2[i]);
}
Before this patch:
test:
csrr a4,vlenb
slli a4,a4,1
li a5,128
bleu a5,a4,.L2
mv a5,a4
.L2:
vsetvli zero,a5,e32,m8,ta,ma
vle32.v v8,0(a1)
vle32.v v16,0(a2)
vsetvli a4,zero,e32,m8,ta,ma
vfsgnj.vv v8,v8,v16
vsetvli zero,a5,e32,m8,ta,ma
vse32.v v8,0(a0)
ret
After this patch:
test:
li a5,128
vsetvli zero,a5,e32,m1,ta,ma
vle32.v v1,0(a1)
vle32.v v2,0(a2)
vfsgnj.vv v1,v1,v2
vse32.v v1,0(a0)
ret
Signed-off-by: Pan Li <pan2.li@intel.com>
gcc/ChangeLog:
* config/riscv/autovec-vls.md (copysign<mode>3): New pattern.
* config/riscv/vector.md: Extend iterator for VLS.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/def.h: New macro.
* gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/floating-point-sgnj-2.c: New test.
Piotr Trojanek [Wed, 23 Aug 2023 14:02:21 +0000 (16:02 +0200)]
ada: Add guard before querying the type for its interfaces
Fix crash on illegal code, when routine Iface_Present_In_Ancestor is
called on the predefined String type and attempts to examine the list of
interfaces.
gcc/ada/
* sem_type.adb (Iface_Present_In_Ancestor): Only look at the list of
interfaces for types that allow it. The guard is a high-level equivalent
of the entity kinds listed in the preconditon of the Interfaces query.
Before this patch, warnings handled by `Sem_Warn.Check_References` were
erroneously emitted in some cases. Here is an example of a program that,
when compiled with the `-gnatwu` switch, triggered the bug:
procedure Main is
package T is
A : Integer;
end T;
begin
T.A := 7;
end Main;
The following message was emitted:
main.adb:3:07: warning: variable "A" is never read and never assigned [-gnatwu]
This patch mitigates the issue by restricting the cases in which
`Sem_Warn.Check_References` is called for package specifications.
Note that the recursive calls in `Sem_Warn.Check_References` can be used
to convince oneself that this patch does not remove legitimate warnings
for non-library-level package specifications.
gcc/ada/
* sem_ch7.adb (Analyze_Package_Declaration): Restrict calls to
`Sem_Warn.Check_References` and adjust comment accordingly.
Eric Botcazou [Mon, 21 Aug 2023 16:23:46 +0000 (18:23 +0200)]
ada: Fix assertion failure on very peculiar enumeration type
The compiler currently does not support the combination of a representation
clause on an enumeration type with a size clause whose value is greater than
the size of the largest machine scalar supported by the target.
Given that such a type would have little practical value, this change causes
the compiler to give a proper error message instead of aborting.
gcc/ada/
* freeze.adb (Freeze_Enumeration_Type): Give an error on a type with
both representation clause and too large size.
Javier Miranda [Sat, 19 Aug 2023 16:50:42 +0000 (16:50 +0000)]
ada: Crash on creation of extra formals on type extension
The compiler blows up processing an overriding dispatching function
of a derived tagged type that returns a private tagged type that
has an access type discriminant.
gcc/ada/
* accessibility.ads (Needs_Result_Accessibility_Extra_Formal): New
subprogram.
* accessibility.adb (Needs_Result_Accessibility_Level_Param): New
subprogram.
(Needs_Result_Accessibility_Extra_Formal): New subprogram,
temporarily keep the previous behavior of the frontend.
* sem_ch6.adb (Create_Extra_Formals): Replace occurrences of
function Needs_Result_Accessibility_Level_Param by calls to
function Needs_Result_Accessibility_Extra_Formal.
(Extra_Formals_OK): Ditto.
ada: Pass -msmp when linking for ppc-vx6 --RTS=rtp-smp
gprbuild and gnatmake won't pass --RTS=rtp-smp to the compiler driver
for linking. The flag was not used during linking: the .spec files
named as linker options were all we passed for the linker to get the
-L flags for lib_smp and lib.
There was a problem, though: although /lib_smp/ and /lib/ were to be
searched in this order, and the specs files did that correctly, the
compiler would search /lib/ first regardless, because
STARTFILE_PREFIX_SPEC said so, and specs files cannot override that.
With this patch, we make sure the rtp-smp runtime causes -msmp to be
added to the command line passed to the compiler driver for linking,
and a corresponding patch for the ppc-vxworks configuration makes the
GCC compiler driver use this flag to select /lib_smp/ rather than
/lib/.
gcc/ada/
* libgnat/system-vxworks-ppc-rtp-smp.ads: Add -msmp to
Linker_Options pragma.
Javier Miranda [Tue, 15 Aug 2023 12:57:10 +0000 (12:57 +0000)]
ada: Crash on function returning empty Ada 2022 aggregate
The compiler crashes processing a function that returns an empty
aggregate when its returned type is a record type which defined
its container aggregate aspects.
gcc/ada/
* exp_aggr.adb (Expand_Container_Aggregate): Report warning on
infinite recursion if an empty container aggregate appears in the
return statement of its Empty function. Fix typo in comment.
* sem_aggr.adb (Resolve_Aggregate): Resolve Ada 2022 empty
aggregate that initializes a record type that has defined its
container aggregate aspects.
(Resolve_Iterated_Association): Protect access to attribute Etype.
* sem_ch13.adb (Resolve_Aspect_Aggregate): Fix typo in comment.
Steve Baird [Thu, 10 Aug 2023 23:21:34 +0000 (16:21 -0700)]
ada: Compiler hangs on invalid postcondition
In some cases involving an illegal reference to F'Result in
the postcondition for a function not named F, the compiler would
hang instead of correctly diagnosing the error.
gcc/ada/
* sem_attr.adb (Denote_Same_Function): Handle the case where
Has_Homonym (Pref_Id) returns True but Homonym (Pref_Id) returns
an empty result.
Steve Baird [Thu, 10 Aug 2023 22:39:01 +0000 (15:39 -0700)]
ada: Spurious warning about negative modular literal
If -gnatw.m is enabled, the compiler generates a warning if a unary
minus operator of a modular type is applied to an integer literal.
This warning was being incorrectly generated in some cases where no integer
literal is present in the source code.
gcc/ada/
* sem_res.adb (Resolve_Unary_Op): In deciding whether to emit a
warning about a modular type's unary minus operator being applied
to an integer literal, ignore integer literals for which
Comes_From_Source is False.
QNX does not support setting the thread affinity via a POSIX API.
This implementation uses QNX's native Thread_Ctl API to set the
thread affinity for Ada tasks.
Daniel King [Tue, 1 Aug 2023 13:39:39 +0000 (14:39 +0100)]
ada: Preserve capability validity in address arithmetic
On CHERI targets where System.Address is a capability, arithmetic on
addresses should avoid converting to integers and instead use the
operations defined in System.Storage_Elements to perform the arithmetic
directly on the System.Address object. This preserves the capability's
validity throughout the calculation, ensuring that the resulting capability
can be dereferenced.
Eric Botcazou [Sat, 5 Aug 2023 12:43:41 +0000 (14:43 +0200)]
ada: Fix internal error on instantiation with private component type
First, this fixes an internal error on the instantiation of a nested generic
package taking an array type whose component type is a private type declared
in the parent package as formal type parameter. In the body of the instance,
the full view of the private type is visible and must be restored by means
of the Check_Generic_Actuals mechanism.
Second, this fixes the same internal error in the case where the component
type itself is an array type whose component type is a private type declared
in the parent package, i.e. when the formal type parameter is an array of
array type, by naturally extending the Has_Secondary_Private_View mechanism
to the array of array case.
gcc/ada/
* sem_ch12.adb (Component_Type_For_Private_View): New function.
(Check_Generic_Actuals): For an actual type parameter, also check
its component type if it is an array type.
(Check_Private_View): Use Component_Type_For_Private_View in the
case of an array type.
(Instantiate_Type): Likewise.
(Save_Global_References.Set_Global_Type): Likewise.
Sheri Bernstein [Thu, 3 Aug 2023 12:38:53 +0000 (12:38 +0000)]
ada: Remove GNATcheck violations
Use pragma Annotate to exempt GNATcheck violations that are related
to proof code. Specifically, exempt rules "Metrics_LSLOC" and
"Metrics_Cyclomatic_Complexity" whose limits are exceeded due to
proof code, and exempt rule "Discriminated_Records" for a variant record
that is only used in proof code.
gcc/ada/
* libgnat/s-aridou.adb: Add pragma to exempt Metrics_LSLOC.
(Double_Divide): Add pragma to exempt
Metrics_Cyclomatic_Complexity.
(Scaled_Divide): Likewise.
* libgnat/s-vauspe.ads (Uns_Option): Add pragma to exempt
Discriminated_Records.
Sheri Bernstein [Tue, 1 Aug 2023 16:36:14 +0000 (16:36 +0000)]
ada: Handle GNATcheck violations
For the GNATcheck rule "Improper_Returns", either use pragma Annotate
to exempt the violation with the rationale "early returns for performance",
or refactor the code by replacing multiple returns by a single return
statement with a conditional expression; this is more readable and
maintainable, and also conformant with a Highly Recommended design principle
of ISO 26262-6. For the GNATcheck rule "Discriminated_Records", use pragma
Annotate to exempt the violation with the rationale "only variant records
are disallowed".
As the generated code with -Oz consumes less size, there is nothing
wrong in the code generation. Instead, let's not run the xtheadcondmov
tests with -Oz.
Yang Yujie [Mon, 28 Aug 2023 02:20:12 +0000 (10:20 +0800)]
LoongArch: add new configure option --with-strict-align-lib
LoongArch processors may not support memory accesses without natural
alignments. Building libraries with -mstrict-align may help with
toolchain binary compatiblity and performance on these implementations
(e.g. Loongson 2K1000LA).
No significant performance degredation is observed on current mainstream
LoongArch processors when the option is enabled.
gcc/ChangeLog:
* config.gcc: use -mstrict-align for building libraries
if --with-strict-align-lib is given.
* doc/install.texi: likewise.
These are exported according to the LoongArch Toolchain Conventions[1]
as a replacement of the obsolete "_LOONGARCH_{ARCH,TUNE}" macros,
which are expanded to strings representing the actual architecture
and microarchitecture of the target.
[1] currently relased at https://github.com/loongson/LoongArch-Documentation
/blob/main/docs/LoongArch-toolchain-conventions-EN.adoc
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc: Export macros
"__loongarch_{arch,tune}" in the preprocessor.
The configure script and the GCC driver are updated so that
it is easier to customize and control GCC builds for targeting
different LoongArch implementations.
* Make --with-abi obsolete, since it might cause different default ABI
under the same target triplet, which is undesirable. The default ABI
is now purely decided by the target triplet.
* Support options for LoongArch SIMD extensions:
new configure options --with-simd={none,lsx,lasx};
new compiler option -msimd={none,lsx,lasx};
new driver options -m[no]-l[a]sx.
* Enforce the priority of configuration paths (for <parm>={fpu,tune,simd}):
-m<parm> > -march-implied > --with-<parm> > --with-arch-implied.
* Allow the user to control the compiler options used when building
GCC libraries for each multilib variant via --with-multilib-list
and --with-multilib-default. This could become more useful when
we have 32-bit support later.
Example 1: the following configure option
--with-multilib-list=lp64d/la464/mno-strict-align/msimd=lsx,lp64s/mfpu=32
| | | |
-mabi=ABI -march=ARCH a list of other options
(mandatory) (optional) (optional)
builds two sets of libraries:
1. lp64d/base ABI (built with "-march=la464 -mno-strict-align -msimd=lsx")
2. lp64s/base ABI (built with "-march=abi-default -mfpu=32")
Example 2: the following 3 configure options
--with-arch=loongarch64
--with-multilib-list=lp64d,lp64f,lp64s/la464
--with-multilib-default=fixed/mno-strict-align/mfpu=64
| | |
-march=ARCH a list of other options
(optional) (optional)
is equivalent to (in terms of building libraries):
Note:
1. the GCC driver and compiler proper does not support
"-march=fixed". "fixed" that appear here acts as a placeholder for
"use whatever ARCH in --with-arch=ARCH" (or the default value
of --with-arch=ARCH if --with-arch is not explicitly configured).
2. if the ARCH part is omitted, "-march=abi-default"
is used for building all library variants, which
practically means enabling the minimal ISA features
that can support the given ABI.
ChangeLog:
* config-ml.in: Do not build the multilib library variant
that is duplicate with the toplevel one.
gcc/ChangeLog:
* config.gcc: Make --with-abi= obsolete, decide the default ABI
with target triplet. Allow specifying multilib library build
options with --with-multilib-list and --with-multilib-default.
* config/loongarch/t-linux: Likewise.
* config/loongarch/genopts/loongarch-strings: Likewise.
* config/loongarch/loongarch-str.h: Likewise.
* doc/install.texi: Likewise.
* config/loongarch/genopts/loongarch.opt.in: Introduce
-m[no-]l[a]sx options. Only process -m*-float and
-m[no-]l[a]sx in the GCC driver.
* config/loongarch/loongarch.opt: Likewise.
* config/loongarch/la464.md: Likewise.
* config/loongarch/loongarch-c.cc: Likewise.
* config/loongarch/loongarch-cpu.cc: Likewise.
* config/loongarch/loongarch-cpu.h: Likewise.
* config/loongarch/loongarch-def.c: Likewise.
* config/loongarch/loongarch-def.h: Likewise.
* config/loongarch/loongarch-driver.cc: Likewise.
* config/loongarch/loongarch-driver.h: Likewise.
* config/loongarch/loongarch-opts.cc: Likewise.
* config/loongarch/loongarch-opts.h: Likewise.
* config/loongarch/loongarch.cc: Likewise.
* doc/invoke.texi: Likewise.
Generate vmovsh instead of vpblendw for specific vec_merge.
On SPR, vmovsh can be execute on 3 ports, vpblendw can only be
executed on 2 ports.
On znver4, vpblendw can be executed on 4 ports, if vmovsh is similar
as vmovss, then it can also be executed on 4 ports.
So there's no difference for znver? but vmovsh is more optimized on
SPR.
gcc/ChangeLog:
* config/i386/sse.md: (V8BFH_128): Renamed to ..
(VHFBF_128): .. this.
(V16BFH_256): Renamed to ..
(VHFBF_256): .. this.
(avx512f_mov<mode>): Extend to V_128.
(vcvtnee<bf16_ph>2ps_<mode>): Changed to VHFBF_128.
(vcvtneo<bf16_ph>2ps_<mode>): Ditto.
(vcvtnee<bf16_ph>2ps_<mode>): Changed to VHFBF_256.
(vcvtneo<bf16_ph>2ps_<mode>): Ditto.
* config/i386/i386-expand.cc (expand_vec_perm_blend):
Canonicalize vec_merge.
testsuite: Remove unwanted 'dg-do run' from gcc.dg/vect tests
Tests under gcc.dg/vect use check_vect_support_and_set_flags to set
compilation flags as appropriate for the target, but they also set
dg-do-what-default to 'run' or 'compile', depending on the actual
target hardware (or simulator) capabilities.
For instance on arm, we use options to enable Neon, but set
dg-do-what-default to 'run' only if we cam actually execute Neon
instructions.
Therefore, we would always try to link and execute tests containing
'dg-do run', although dg-do-what-default says otherwise, leading to
uninteresting failures.
Therefore, this patch removes all such unconditionnal 'dg-do run',
thus avoid link errors for instance if GCC has been configured with
multilibs disabled and some --with-{float|cpu|hard} option
incompatible with what check_vect_support_and_set_flags selects.
For exmaple, GCC configured with:
--disable-multilib --with-mode=thumb --with-cpu=cortex-m7 --with-float=hard
and check_vect_support_and_set_flags uses
-mfpu=neon -mfloat-abi=softfp -march=armv7-a
(thus incompatible float-abi options)
Tested on native aarch64-linux-gnu (no change) and several arm-eabi
cases where the FAIL/UNRESOLVED disappear (and we keep only the
'compilation' tests).
projects / thirdparty / gcc.git / log
