Jakub Jelinek [Wed, 7 Feb 2024 09:59:06 +0000 (10:59 +0100)]
range-op: Fix up ABSU_EXPR handling [PR113756]
ABSU_EXPR unary expr is special because it has a signed integer
argument and unsigned integer result (of the same precision).
The following testcase is miscompiled since ABSU_EXPR handling has
been added to range-op because it uses widest_int::from with the
result sign (i.e. UNSIGNED) rather than the operand sign (i.e. SIGNED),
so e.g. for the 32-bit int argument mask ends up 0xffffffc1 or something
similar and even when it has most significant bit in the precision set,
in widest_int (tree-ssa-ccp.cc really should stop using widest_int, but
that is I think stage1 task) it doesn't appear to be negative and so
bit_value_unop ABSU_EXPR doesn't set the resulting mask/value from
oring of the argument and its negation.
Fixed thusly, not doing that for GIMPLE_BINARY_RHS because I don't know
about a binary op that would need something similar.
2024-02-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113756
* range-op.cc (update_known_bitmask): For GIMPLE_UNARY_RHS,
use TYPE_SIGN (lh.type ()) instead of sign for widest_int::from
of lh_bits value and mask.
gcc.dg/debug/dwarf2/inline5.c has been XPASSing on Solaris (both SPARC
and x86, 32 and 64-bit) with the native assembler since 20210429.
According to gcc-testresults postings, the same is true on AIX.
As the following testcases show, the overflow (needs_overflow) and high
handling in wi::mul_internal seem to only work correctly for either
small precisions (less than or equal to 32, that is handled by earlier
simpler code, not the full Knuth's multiplication algorithm) or for
precisions which are multiple of HOST_BITS_PER_WIDE_INT, so it happened
to work fine in most pre-_BitInt era types (and for large bitfields we
probably didn't have good coverage or were lucky and nothing was asking
if there was overflow or not; I think high multiplication is typically
used only when we have optab in corresponding mode).
E.g. on the gcc.dg/bitint-87.c testcase, there were overflow warnings
emitted only the the / 2wb * 3wb _BitInt(128) cases, but not in the
other precisions.
I found 3 issues when prec > HOST_BITS_PER_HALF_WIDE_INT and
(prec % HOST_BITS_PER_WIDE_INT) != 0:
1) the checking for overflow was simply checking the values of the
r array members from half_blocks_needed to 2 * half_blocks_needed - 1,
for UNSIGNED overflow checking if any of them is non-zero, for
SIGNED comparing them if any is different from top where top is computed
from the sign bit of the result (see below); similarly, the highpart
multiplication simply picks the half limbs at r + half_blocks_needed
offset; and furthermore, for SIGNED there is an adjustment if either
operand was negative which also just walks r half-limbs from
half_blocks_needed onwards;
this works great for precisions like 64 or 128, but for precisions like
129, 159, 160 or 161 doesn't, it would need to walk the bits in the
half-limbs starting right above the most significant bit of the base
precision; that can be up to a whole half-limb and all but one bit from
the one below it earlier
2) as the comment says, the multiplication is originally done as unsigned
multiplication, with adjustment of the high bits which subtracts the
other operand once:
if (wi::neg_p (op1))
{
b = 0;
for (i = 0; i < half_blocks_needed; i++)
{
t = (unsigned HOST_WIDE_INT)r[i + half_blocks_needed]
- (unsigned HOST_WIDE_INT)v[i] - b;
r[i + half_blocks_needed] = t & HALF_INT_MASK;
b = t >> (HOST_BITS_PER_WIDE_INT - 1);
}
}
and similarly for the other one. Now, this also only works nicely if
a negative operand has just a single sign bit set in the given precision;
but we were unpacking the operands with wi_unpack (..., SIGNED);, so
say for the negative operand in 129-bit precision, that means the least
significant bit of u[half_blocks_needed - 2] (or v instead of u depending
on which argument it is) is the set sign bit, but then there are 31
further copies of the sign bit in u[half_blocks_needed - 2] and
further 32 copies in u[half_blocks_needed - 1]; the above adjustment
for signed operands doesn't really do the right job in such cases, it
would need to subtract many more times the other operand
3) the computation of top for SIGNED
top = r[(half_blocks_needed) - 1];
top = SIGN_MASK (top << (HOST_BITS_PER_WIDE_INT / 2));
top &= mask;
also uses the most significant bit which fits into prec of the result
only if prec is multiple of HOST_BITS_PER_WIDE_INT, otherwise we need
to look at a different bit and sometimes it can be also a bit in
r[half_blocks_needed - 2]
For 1), while for UNSIGNED overflow it could be fairly easy to check
the bits above prec in r half-limbs for being non-zero, doing all the
shifts also in the SIGNED adjustment code in 2 further locations and finally
for the high handling (unless we want to assert one doesn't do the highpart
multiply for such precisions) would be quite ugly and hard to maintain, so
I instead chose (implemented in the second hunk) to shift the
beyond-precision bits up such that the expectations of the rest of the
code are met, that is the LSB of r[half_blocks_needed] after adjustment
is the bit immediately above the precision, etc. We don't need to care
about the bits it shifts out, because the multiplication will yield at most
2 * prec bits.
For 2), the patch changes the wi_unpack argument from SIGNED to UNSIGNED,
so that we get all zero bits above the precision.
And finally for 3) it does shifts and perhaps picks lower r half-limb so
that it uses the actual MSB of the result within prec.
2024-02-07 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113753
* wide-int.cc (wi::mul_internal): Unpack op1val and op2val with
UNSIGNED rather than SIGNED. If high or needs_overflow and prec is
not a multiple of HOST_BITS_PER_WIDE_INT, shift left bits above prec
so that they start with r[half_blocks_needed] lowest bit. Fix up
computation of top mask for SIGNED.
* gcc.dg/torture/bitint-56.c: New test.
* gcc.dg/bitint-87.c: New test.
Pan Li [Tue, 6 Feb 2024 07:35:02 +0000 (15:35 +0800)]
RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args
There is one corn case when similar as below example:
void test (void)
{
__riscv_vfredosum_tu ();
}
It will meet ICE because of the implement details of overloaded function
in gcc. According to the rvv intrinisc doc, we have no such overloaded
function with empty args. Unfortunately, we register the empty args
function as overloaded for avoiding conflict. Thus, there will be actual
one register function after return NULL_TREE back to the middle-end,
and finally result in ICE when expanding. For example:
1. First we registered void __riscv_vfredmax () as the overloaded function.
2. Then resolve_overloaded_builtin (this func) return NULL_TREE.
3. The functions register in step 1 bypass the args check as empty args.
4. Finally, fall into expand_builtin with empty args and meet ICE.
Here we report error when overloaded function with empty args. For example:
test.c: In function 'foo':
test.c:8:3: error: no matching function call to '__riscv_vfredosum_tu' with empty args
8 | __riscv_vfredosum_tu();
| ^~~~~~~~~~~~~~~~~~~~
Below test are passed for this patch.
* The riscv regression tests.
PR target/113766
gcc/ChangeLog:
* config/riscv/riscv-protos.h (resolve_overloaded_builtin): Adjust
the signature of func.
* config/riscv/riscv-c.cc (riscv_resolve_overloaded_builtin): Ditto.
* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin): Make
overloaded func with empty args error.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: New test.
* gcc.target/riscv/rvv/base/pr113766-2.c: New test.
Jakub Jelinek [Tue, 6 Feb 2024 21:34:55 +0000 (22:34 +0100)]
c++: Disallow this specifier except for parameter declarations [PR113788]
The deducing this patchset added parsing of this specifier to
cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar
this[opt] only appears in the parameter-declaration non-terminal, so
rather than checking in all the callers of cp_parser_decl_specifier_seq
except for cp_parser_parameter_declaration that this specifier didn't
appear I think it is far easier and closer to what the standard says
to only parse this specifier when called from
cp_parser_parameter_declaration.
2024-02-06 Jakub Jelinek <jakub@redhat.com>
PR c++/113788
* parser.cc (CP_PARSER_FLAGS_PARAMETER): New enumerator.
(cp_parser_decl_specifier_seq): Parse RID_THIS only if
CP_PARSER_FLAGS_PARAMETER is set in flags.
(cp_parser_parameter_declaration): Or in CP_PARSER_FLAGS_PARAMETER
when calling cp_parser_decl_specifier_seq.
Andrew Carlotti [Wed, 31 Jan 2024 16:28:12 +0000 (16:28 +0000)]
aarch64: Fix function multiversioning mangling
It would be neater if the middle end for target_clones used a target
hook for version name mangling, so we only do version name mangling
once. However, that would require more intrusive refactoring that will
have to wait till Stage 1.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_mangle_decl_assembler_name):
Move before new caller, and add ".default" suffix.
(get_suffixed_assembler_name): New.
(make_resolver_func): Use get_suffixed_assembler_name.
(aarch64_generate_version_dispatcher_body): Redo name mangling.
Jakub Jelinek [Tue, 6 Feb 2024 14:56:50 +0000 (15:56 +0100)]
aarch64: Fix build against libc++ in c++11 mode [PR113763]
std::pair ctor used in tiles constexpr variable is only constexpr in C++14
and later, it works with libstdc++ because it is marked constexpr there even
in C++11 mode.
The following patch fixes it by using an unnamed local class instead of
std::pair, and additionally changes the first element from unsigned int to
unsigned char because 0xff has to fit into unsigned char on all hosts.
2024-02-06 Jakub Jelinek <jakub@redhat.com>
PR target/113763
* config/aarch64/aarch64.cc (aarch64_output_sme_zero_za): Change tiles
element from std::pair<unsigned int, char> to an unnamed struct.
Adjust uses of tile range variable.
Jakub Jelinek [Tue, 6 Feb 2024 12:00:04 +0000 (13:00 +0100)]
asan: Don't fold some strlens with -fsanitize=address [PR110676]
The UB on the following testcase isn't diagnosed by -fsanitize=address,
because we see that the array has a single element and optimize the
strlen to 0. I think it is fine to assume e.g. for range purposes the
lower bound for the strlen as long as we don't try to optimize
strlen (str)
where we know that it returns [26, 42] to
26 + strlen (str + 26), but for the upper bound we really want to punt
on optimizing that for -fsanitize=address to read all the bytes of the
string and diagnose if we run to object end etc.
2024-02-06 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/110676
* gimple-fold.cc (gimple_fold_builtin_strlen): For -fsanitize=address
reset maxlen to sizetype maximum.
Jakub Jelinek [Tue, 6 Feb 2024 11:58:55 +0000 (12:58 +0100)]
lower-bitint: Encode address space qualifiers in VIEW_CONVERT_EXPRs [PR113736]
As discussed in the PR, e.g. build_fold_addr_expr needs TYPE_ADDR_SPACE
on the outermost reference rather than just on the base, so the
following patch makes sure to propagate the address space from
the accessed var to the MEM_REFs and/or VIEW_CONVERT_EXPRs used to
access those.
2024-02-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113736
* gimple-lower-bitint.cc (bitint_large_huge::limb_access): Use
var's address space for MEM_REF or VIEW_CONVERT_EXPRs.
Jakub Jelinek [Tue, 6 Feb 2024 11:57:53 +0000 (12:57 +0100)]
tree-ssa-math-opts: Fix up convert_{mult,plusminus}_to_widen [PR113759]
On the following testcase we emit invalid stmt:
error: type mismatch in ‘widen_mult_plus_expr’
6 | foo (int c, int b)
| ^~~
unsigned long
int
unsigned int
unsigned long
_31 = WIDEN_MULT_PLUS_EXPR <b_5(D), 2, _30>;
The recent PR113560 r14-8680 changes tweaked convert_mult_to_widen,
but didn't change convert_plusminus_to_widen for the
TREE_TYPE (rhsN) != typeN cases, but looking at this, it was already
before that change quite weird.
Earlier in those functions it determines actual_precision and from_unsignedN
and wants to use that precision and signedness for the operands and
it used build_and_insert_cast for that (which emits a cast stmt, even for
INTEGER_CSTs) and later on for INTEGER_CST arguments fold_converted them
to typeN (which is unclear to me why, because it seems to have assumed
that TREE_TYPE (rhsN) is typeN, for the actual_precision or from_unsignedN
cases it would be wrong except that build_and_insert_cast forced a SSA_NAME
and so it doesn't trigger anymore).
Now, since r14-8680 it is possible that rhsN also has some other type from
typeN and we again want to cast.
The following patch changes this, so that for the differences in
actual_precision and/or from_unsignedN we actually update typeN and then use
it as the type to convert the arguments to if it isn't useless, for
INTEGER_CSTs by just fold_converting, otherwise using build_and_insert_cast.
And uses useless_type_conversion_p test so that we don't convert unless
necessary. Plus by doing that effectively also doing the important part of
the r14-8680 convert_mult_to_widen changes in convert_plusminus_to_widen.
2024-02-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113759
* tree-ssa-math-opts.cc (convert_mult_to_widen): If actual_precision
or from_unsignedN differs from properties of typeN, update typeN
to build_nonstandard_integer_type. If TREE_TYPE (rhsN) is not
uselessly convertible to typeN, convert it using fold_convert or
build_and_insert_cast depending on if rhsN is INTEGER_CST or not.
(convert_plusminus_to_widen): Likewise.
Rainer Orth [Tue, 6 Feb 2024 10:45:45 +0000 (11:45 +0100)]
libssp: Fix gets-chk.c compilation on Solaris
The recent warning patches broke the libssp build on Solaris:
/vol/gcc/src/hg/master/local/libssp/gets-chk.c: In function '__gets_chk':
/vol/gcc/src/hg/master/local/libssp/gets-chk.c:67:12: error: implicit
declaration of function 'gets'; did you mean 'getw'?
[-Wimplicit-function-declaration]
67 | return gets (s);
| ^~~~
| getw
/vol/gcc/src/hg/master/local/libssp/gets-chk.c:67:12: error: returning
'int' from a function with return type 'char *' makes pointer from integer
without a cast [-Wint-conversion]
67 | return gets (s);
| ^~~~~~~~
/vol/gcc/src/hg/master/local/libssp/gets-chk.c:74:12: error: returning
'int' from a function with return type 'char *' makes pointer from integer
without a cast [-Wint-conversion]
74 | return gets (s);
| ^~~~~~~~
The guard around the gets declaration in gets-chk.c is
The target hook aarch64_class_max_nregs returns the incorrect result for 64-bit
structure modes like V31DImode or V41DFmode etc. The calculation of the nregs
is based on the size of AdvSIMD vector register for 64-bit modes which ought to
be UNITS_PER_VREG / 2. This patch fixes the register size.
Rainer Orth [Tue, 6 Feb 2024 09:20:30 +0000 (10:20 +0100)]
libgcc: Export i386 symbols added after GCC_7.0.0 on Solaris [PR113700]
As reported in the PR, all libgcc x86 symbol versions added after
GCC_7.0.0 were only added to i386/libgcc-glibc.ver, missing all of
libgcc-sol2.ver, libgcc-bsd.ver, and libgcc-darwin.ver.
This patch fixes this for Solaris/x86, adding all of them
(GCC_1[234].0.0) as GCC_14.0.0 to not retroactively change history.
Since this isn't the first time this happens, I've added a note to the
end of libgcc-glibc.ver to request notifying other maintainers in case
of additions.
Matteo Italia [Wed, 17 Jan 2024 11:51:44 +0000 (12:51 +0100)]
libgcc: fix SEH C++ rethrow semantics [PR113337]
SEH _Unwind_Resume_or_Rethrow invokes abort directly if
_Unwind_RaiseException doesn't manage to find a handler for the rethrown
exception; this is incorrect, as in this case std::terminate should be
invoked, allowing an application-provided terminate handler to handle
the situation instead of straight crashing the application through
abort.
The bug can be demonstrated with this simple test case:
===
static void custom_terminate_handler() {
fprintf(stderr, "custom_terminate_handler invoked\n");
std::exit(1);
}
On all gcc builds with non-SEH exceptions, this will print
"custom_terminate_handler invoked" both if launched as ./a.out throw or
as ./a.out rethrow, on SEH builds instead if will work as expected only
with ./a.exe throw, but will crash with the "built-in" abort message
with ./a.exe rethrow.
This patch fixes the problem, forwarding back the error code to the
caller (__cxa_rethrow), that calls std::terminate if
_Unwind_Resume_or_Rethrow returns.
The change makes the code path coherent with SEH _Unwind_RaiseException,
and with the generic _Unwind_Resume_or_Rethrow from libgcc/unwind.inc
(used for SjLj and Dw2 exception backend).
libgcc/ChangeLog:
PR libgcc/113337
* unwind-seh.c (_Unwind_Resume_or_Rethrow): forward
_Unwind_RaiseException return code back to caller instead of
calling abort, allowing __cxa_rethrow to invoke std::terminate
in case of uncaught rethrown exception
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
In 17_intro/tag_type_explicit_ctor.cc, the following statement would
fail to match when the DejaGNU testsuite is running in cygwin with a
native toolchain.
// dg-error 53 "explicit" "" { target hosted }
The "target hosted"-check is using cpp to verify if _GLIBCXX_HOSTED is
defined and discards the output by simply redirecting it to /dev/null.
In v3_target_compile, it's overridden to "nul" for MinGW targets, but
the same rule applies when host is cygwin, so replace the condition
with a check for Windows.
The error in the log would look like this for the "target hosted" check:
cc1plus.exe: fatal error: opening output file /dev/null: No such file or directory
The tag_type_explicit_ctor.cc test fails with this on Windows:
.../tag_type_explicit_ctor.cc:53: error: converting to 'std::defer_lock_t' from initializer list would use explicit constructor 'constexpr std::defer_lock_t::defer_lock_t()'
.../tag_type_explicit_ctor.cc:54: error: converting to 'std::try_to_lock_t' from initializer list would use explicit constructor 'constexpr std::try_to_lock_t::try_to_lock_t()'
.../tag_type_explicit_ctor.cc:55: error: converting to 'std::try_to_lock_t' from initializer list would use explicit constructor 'constexpr std::try_to_lock_t::try_to_lock_t()'
.../tag_type_explicit_ctor.cc:67: error: converting to 'std::defer_lock_t' from initializer list would use explicit constructor 'constexpr std::defer_lock_t::defer_lock_t()'
.../tag_type_explicit_ctor.cc:68: error: converting to 'std::try_to_lock_t' from initializer list would use explicit constructor 'constexpr std::try_to_lock_t::try_to_lock_t()'
.../tag_type_explicit_ctor.cc:69: error: converting to 'std::adopt_lock_t' from initializer list would use explicit constructor 'constexpr std::adopt_lock_t::adopt_lock_t()'
Patch has been verified on Windows and Linux.
libstdc++-v3:
* testsuite/lib/libstdc++.exp: Use "nul" for Windows, "/dev/null"
for other environments.
A recent commit introduced a compiler warning in thead.cc:
error: invalid suffix on literal; C++11 requires a space between literal and string macro [-Werror=literal-suffix]
1144 | fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO (addr.reg)],
| ^
This commit addresses this issue and breaks the line such that it won't
exceed 80 characters.
Jason Merrill [Mon, 5 Feb 2024 18:54:22 +0000 (13:54 -0500)]
c++: prvalue of array type [PR111286]
Here we want to build a prvalue array to bind to the T reference, but we
were wrongly trying to strip cv-quals from the array prvalue, which should
be treated the same as a class prvalue.
PR c++/111286
gcc/cp/ChangeLog:
* tree.cc (rvalue): Don't drop cv-quals from an array.
Ian Lance Taylor [Fri, 20 Oct 2023 17:25:04 +0000 (10:25 -0700)]
compiler: add Type::message_name
As we move toward generics, the error messages need to be able
to refer to types in a readable manner. Add that capability,
and use it today in AST dumps.
H.J. Lu [Thu, 1 Feb 2024 16:02:27 +0000 (08:02 -0800)]
x86-64: Find a scratch register for large model profiling
2 scratch registers, %r10 and %r11, are available at function entry for
large model profiling. But %r10 may be used by stack realignment and we
can't use %r10 in this case. Add x86_64_select_profile_regnum to find
a caller-saved register which isn't live or a callee-saved register
which has been saved on stack in the prologue at entry for large model
profiling and sorry if we can't find one.
gcc/
PR target/113689
* config/i386/i386.cc (x86_64_select_profile_regnum): New.
(x86_function_profiler): Call x86_64_select_profile_regnum to
get a scratch register for large model profiling.
Jakub Jelinek [Mon, 5 Feb 2024 17:57:45 +0000 (18:57 +0100)]
contrib: Fill in HOST{CC,CFLAGS,CXX,CXXFLAGS} in test_installed
gcc/Makefile.in since my r0-60234 change fills in HOSTCC and HOSTCFLAGS
in site.exp and since r8-671 also HOSTCXX and HOSTCXXFLAGS.
If those variables aren't set, we get errors like:
/usr/src/gcc/contrib/test_installed --without-g++ --without-gfortran --without-objc struct-layout-1.exp
...
ERROR: tcl error sourcing /usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp.
ERROR: tcl error code TCL LOOKUP VARNAME HOSTCC
ERROR: can't read "HOSTCC": no such variable
while executing
"remote_exec build "$HOSTCC $HOSTCFLAGS $generator_cmd""
(file "/usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp" line 96)
invoked from within
"source /usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp"
invoked from within
"catch "uplevel #0 source $test_file_name" msg"
(similarly in g++ or gfortran) struct-layout-1.exp. One doesn't need to
test specially for just struct-layout-1.exp alone, just not using any arg
will trigger it as well, just later.
The following patch fills it in as cc and c++ with empty flags to compile
those, I believe that is what e.g. make uses by default, so it should be a
reasonable default. We IMHO shouldn't default to GCC_UNDER_TEST because
that might be a cross-compiler etc.
2024-02-05 Jakub Jelinek <jakub@redhat.com>
* test_installed: Fill in HOSTCC, HOSTCXX, HOSTCFLAGS and
HOSTCXXFLAGS.
Jakub Jelinek [Mon, 5 Feb 2024 17:53:59 +0000 (18:53 +0100)]
c: Avoid ICE with _BitInt(N) : 0 bitfield [PR113740]
finish_struct already made sure not to call build_bitint_type for
signed _BitInt(2) : 1;
or
signed _BitInt(2) : 0;
bitfields (but instead build a zero precision integral type,
we remove it later), this patch makes sure we do it also for
unsigned _BitInt(1) : 0;
because of the build_bitint_type assertion that precision is
>= (unsigned ? 1 : 2).
2024-02-05 Jakub Jelinek <jakub@redhat.com>
PR c/113740
* c-decl.cc (finish_struct): Only use build_bitint_type if
bit-field has width larger or equal to minimum _BitInt
precision.
H.J. Lu [Mon, 5 Feb 2024 11:46:50 +0000 (03:46 -0800)]
x86-64: Update gcc.target/i386/apx-ndd.c
Fix the following issues:
1. Replace long with int64_t to support x32.
2. Replace \\(%rdi\\) with \\(%(?:r|e)di\\) for memory operand since x32
uses (%edi).
3. Replace %(?:|r|e)al with %al in negb scan.
Xi Ruoyao [Fri, 2 Feb 2024 19:35:07 +0000 (03:35 +0800)]
MIPS: Fix wrong MSA FP vector negation
We expanded (neg x) to (minus const0 x) for MSA FP vectors, this is
wrong because -0.0 is not 0 - 0.0. This causes some Python tests to
fail when Python is built with MSA enabled.
Use the bnegi.df instructions to simply reverse the sign bit instead.
gcc/ChangeLog:
* config/mips/mips-msa.md (elmsgnbit): New define_mode_attr.
(neg<mode>2): Change the mode iterator from MSA to IMSA because
in FP arithmetic we cannot use (0 - x) for -x.
(neg<mode>2): New define_insn to implement FP vector negation,
using a bnegi instruction to negate the sign bit.
Jakub Jelinek [Mon, 5 Feb 2024 09:57:39 +0000 (10:57 +0100)]
lower-bitint: Remove single label _BitInt switches [PR113737]
The following testcase ICEs, because group_case_labels_stmt optimizes
switch (a.0_7) <default: <L6> [50.00%], case 0: <L7> [50.00%], case 2: <L7> [50.00%]>
where L7 block starts with __builtin_unreachable (); to
switch (a.0_7) <default: <L6> [50.00%]>
and single label GIMPLE_SWITCH is something the switch expansion refuses to
lower:
if (gimple_switch_num_labels (m_switch) == 1
|| range_check_type (index_type) == NULL_TREE)
return false;
(range_check_type never returns NULL for BITINT_TYPE), but the gimple
lowering pass relies on all large/huge _BitInt switches to be lowered
by that pass.
The following patch just removes those after making the single successor
edge EDGE_FALLTHRU. I've done it even if !optimize just in case in case
we'd end up with single case label from earlier passes.
2024-02-05 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113737
* gimple-lower-bitint.cc (gimple_lower_bitint): If GIMPLE_SWITCH
has just a single label, remove it and make single successor edge
EDGE_FALLTHRU.
Jakub Jelinek [Mon, 5 Feb 2024 08:33:26 +0000 (09:33 +0100)]
i386: Clear REG_UNUSED and REG_DEAD notes from the IL at the end of vzeroupper pass [PR113059]
The move of the vzeroupper pass from after reload pass to after
postreload_cse helped only partially, CSE-like passes can still invalidate
those notes (especially REG_UNUSED) if they use some earlier register
holding some value later on in the IL.
So, either we could try to move it one pass further after gcse2 and hope
no later pass invalidates the notes, or the following patch attempts to
restore the REG_DEAD/REG_UNUSED state from GCC 13 and earlier, where
the LRA or reload passes remove all REG_DEAD/REG_UNUSED notes and the notes
reappear only at the start of dse2 pass when it calls
df_note_add_problem ();
df_analyze ();
So, effectively
NEXT_PASS (pass_postreload_cse);
NEXT_PASS (pass_gcse2);
NEXT_PASS (pass_split_after_reload);
NEXT_PASS (pass_ree);
NEXT_PASS (pass_compare_elim_after_reload);
NEXT_PASS (pass_thread_prologue_and_epilogue);
passes operate without those notes in the IL.
While in GCC 14 mode switching computes the notes problem at the start of
vzeroupper, the patch below removes them at the end of the pass again, so
that the above passes continue to operate without them.
2024-02-05 Jakub Jelinek <jakub@redhat.com>
PR target/113059
* config/i386/i386-features.cc (rest_of_handle_insert_vzeroupper):
Remove REG_DEAD/REG_UNUSED notes at the end of the pass before
df_analyze call.
Richard Biener [Thu, 1 Feb 2024 12:54:11 +0000 (13:54 +0100)]
target/113255 - avoid REG_POINTER on a pointer difference
The following avoids re-using a register holding a pointer (and
thus might be REG_POINTER) for the result of a pointer difference
computation. That might confuse heuristics in (broken) RTL alias
analysis which relies on REG_POINTER indicating that we're
dealing with one.
This alone doesn't fix anything.
PR target/113255
* config/i386/i386-expand.cc
(expand_set_or_cpymem_prologue_epilogue_by_misaligned_moves):
Use a new pseudo for the skipped number of bytes.
Jonathan Wakely [Thu, 1 Feb 2024 11:09:29 +0000 (11:09 +0000)]
libstdc++: Replace padding bits with bit-fields in __format::_Spec
This ensures that the unused bits will be zero-initialized reliably, and
so can be used later by assigning them values in formatter
specializations. For example, formatters for std::chrono will need to
use an extra bit for a boolean flag to optimize the conversions between
locale encodings and UTF-8.
Adding the 16-bit _M_reserved2 bit-field results in an increased size
for targets that use 1- or 2-byte alignment for all integral types, e.g.
cris-elf or m68k. Placing that member before the _M_width member
adjusts the layout for all targets, but keeps all the bit-fields
together. We can't make that change once C++20 support is ABI stable and
non-experimental, so do it now before GCC 14 is released. The _M_fill
data member already change from char to char32_t in r14-6991-g37a4c5c23a270c so _Spec is already incompatible with gcc-13
anyway.
libstdc++-v3/ChangeLog:
* include/std/format (__format::_Spec::_M_reserved): Define new
bit-field members to reserve padding bits for future extensions.
Jonathan Wakely [Fri, 2 Feb 2024 12:07:09 +0000 (12:07 +0000)]
libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS symbols
In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
but that wasn't true. Only the symbols from the latter were added to
libstdc++exp.a, the Filesystem TS ones weren't. This seems to be because
libtool won't combine static libs that are going to be installed
separately. Because libstdc++fs.a is still installed, libtool decides it
shouldn't be included in libstdc++exp.a.
The solution is similar to what we already do for libsupc++.a: build two
static libs, libstdc++fs.a and libstdc++fsconvenience.a, where the
former is installed and the latter isn't. If we then tell libtool to
include the latter in libstdc++exp.a it will do as it's told.
libstdc++-v3/ChangeLog:
* src/experimental/Makefile.am: Use libstdc++fsconvenience.a
instead of libstdc++fs.a.
* src/experimental/Makefile.in: Regenerate.
* src/filesystem/Makefile.am: Build libstdc++fsconvenience.a as
well.
* src/filesystem/Makefile.in: Regenerate.
Jonathan Wakely [Fri, 2 Feb 2024 13:20:11 +0000 (13:20 +0000)]
libstdc++: Add copyright and license text to new generated headers
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Add copyright and
license text to the output.
libstdc++-v3/ChangeLog:
* include/bits/text_encoding-data.h: Regenerate.
* include/bits/unicode-data.h: Regenerate.
* scripts/gen_text_encoding_data.py: Add copyright and license
text to the output.
Jeff Law [Sun, 4 Feb 2024 20:01:50 +0000 (13:01 -0700)]
[committed] Reasonably handle SUBREGs in risc-v cost modeling
This patch adjusts the costs so that we treat REG and SUBREG expressions the
same for costing.
This was motivated by bt_skip_func and bt_find_func in xz and results in nearly
a 5% improvement in the dynamic instruction count for input #2 and smaller, but
definitely visible improvements pretty much across the board. Exceptions would
be perlbench input #1 and exchange2 which showed very small regressions.
In the bt_find_func and bt_skip_func cases we have something like this:
Note the two uses of (reg 136). The best way to handle that in combine might be
a 3->2 split. But there's a much better approach if we look at fwprop...
(set (reg:DI 142 [ _1 ])
(plus:DI (zero_extend:DI (subreg/s/u:SI (reg/v:DI 137 [ a ]) 0))
(reg/v:DI 139 [ b ])))
change not profitable (cost 4 -> cost 8)
So that should be the same cost as a regular DImode addition when the ZBA
extension is enabled. But it ends up costing more because the clause to cost
this variant isn't prepared to handle a SUBREG. That results in the RTL above
having too high a cost and fwprop gives up.
One approach would be to replace the REG_P with REG_P || SUBREG_P in the
costing code. I ultimately decided against that and instead check if the
operand in question passes register_operand.
By far the most important case to handle is the DImode PLUS. But for the sake
of consistency, I changed the other instances in riscv_rtx_costs as well. For
those other cases we're talking about improvements in the .000001% range.
While we are into stage4, this just hits cost modeling which we've generally
agreed is still appropriate (though we were mostly talking about vector). So
I'm going to extend that general agreement ever so slightly and include scalar
cost modeling :-)
gcc/
* config/riscv/riscv.cc (riscv_rtx_costs): Handle SUBREG and REG
similarly.
Xi Ruoyao [Fri, 2 Feb 2024 19:16:14 +0000 (03:16 +0800)]
LoongArch: Fix wrong LSX FP vector negation
We expanded (neg x) to (minus const0 x) for LSX FP vectors, this is
wrong because -0.0 is not 0 - 0.0. This causes some Python tests to
fail when Python is built with LSX enabled.
Use the vbitrevi.{d/w} instructions to simply reverse the sign bit
instead. We are already doing this for LASX and now we can unify them
into simd.md.
gcc/ChangeLog:
* config/loongarch/lsx.md (neg<mode:FLSX>2): Remove the
incorrect expand.
* config/loongarch/simd.md (simdfmt_as_i): New define_mode_attr.
(elmsgnbit): Likewise.
(neg<mode:FVEC>2): New define_insn.
* config/loongarch/lasx.md (negv4df2, negv8sf2): Remove as they
are now instantiated in simd.md.
Note that NUM_MACHINE_MODES = MAX_MACHINE_MODE (emitted by genmodes.cc),
thus if __builtin_constant_p (mode) is evaluated true (it happens when
GCC is bootstrapped with LTO+PGO), the assertion will be triggered and
cause an ICE. OTOH if __builtin_constant_p (mode) is evaluated false,
mode_size[mode] is still an out-of-bound array access (the length or the
mode_size array is NUM_MACHINE_MODES).
So we shouldn't call LSX_SUPPORTED_MODE_P or LASX_SUPPORTED_MODE_P with
MAX_MACHINE_MODE in loongarch_symbol_insns. This is very similar to a
MIPS bug PR98491 fixed by me about 3 years ago.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_symbol_insns): Do not
use LSX_SUPPORTED_MODE_P or LASX_SUPPORTED_MODE_P if mode is
MAX_MACHINE_MODE.
This FAIL was introduced from r14-6908. The reason is that when merging
constant vector permutation implementations, the 128-bit matching situation
was not fully considered. In fact, the expansion of 128-bit vectors after
merging only supports value-based 4 elements set shuffle, so this time is a
complete implementation of the entire 128-bit vector constant permutation,
and some structural adjustments have also been made to the code.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_expand_vselect): Adjust.
(loongarch_expand_vselect_vconcat): Ditto.
(loongarch_try_expand_lsx_vshuf_const): New, use vshuf to implement
all 128-bit constant permutation situations.
(loongarch_expand_lsx_shuffle): Adjust and rename function name.
(loongarch_is_imm_set_shuffle): Renamed function name.
(loongarch_expand_vec_perm_even_odd): Function forward declaration.
(loongarch_expand_vec_perm_even_odd_1): Add implement for 128-bit
extract-even and extract-odd permutations.
(loongarch_is_odd_extraction): Delete.
(loongarch_is_even_extraction): Ditto.
(loongarch_expand_vec_perm_const): Adjust.
Jerry DeLisle [Sat, 3 Feb 2024 02:12:33 +0000 (18:12 -0800)]
libgfortran: EN0.0E0 and ES0.0E0 format editing.
F2018 and F2023 standards added zero width exponents. This required
additional special handing in the process of building formatted
floating point strings.
G formatting uses either F or E formatting as documented in
write_float.def comments. This logic changes the format token from FMT_G
to FMT_F or FMT_E. The new formatting requirements interfere with this
process when a FMT_G float string is being built. To avoid this, a new
component called 'pushed' is added to the fnode structure to save this
condition. The 'pushed' condition is then used to bypass portions of
the new ES,E,EN, and D formatting, falling through to the existing
default formatting which is retained.
libgfortran/ChangeLog:
PR libfortran/111022
* io/format.c (get_fnode): Update initialization of fnode.
(parse_format_list): Initialization.
* io/format.h (struct fnode): Added the new 'pushed' component.
* io/write.c (select_buffer): Whitespace.
(write_real): Whitespace.
(write_real_w0): Adjust logic for the d == 0 condition.
* io/write_float.def (determine_precision): Whitespace.
(build_float_string): Calculate width of ..E0 exponents and
adjust logic accordingly.
(build_infnan_string): Whitespace.
(CALCULATE_EXP): Whitespace.
(quadmath_snprintf): Whitespace.
(determine_en_precision): Whitespace.
gcc/testsuite/ChangeLog:
PR libfortran/111022
* gfortran.dg/fmt_error_10.f: Show D+0 exponent.
* gfortran.dg/pr96436_4.f90: Show E+0 exponent.
* gfortran.dg/pr96436_5.f90: Show E+0 exponent.
* gfortran.dg/pr111022.f90: New test.
libatomic: Provide FPU exception defines for __hppa__
The exception defines in <fenv.h> do not match the exception bits
in the FPU status register on hppa-linux and hppa64-hpux11.11. On
linux, they match the trap enable bits. On 64-bit hpux, they match
the exception bits for IA64. The IA64 bits are in a different
order and location than HPPA. HP uses table look ups to reorder
the bits in code to test and raise exceptions.
All the architectures that I looked at just pass the FPU status
register to __atomic_feraiseexcept(). The simplest approach for
hppa is to define FE_INEXACT, etc, to match the status register
and not include <fenv.h>..
2024-02-03 John David Anglin <danglin@gcc.gnu.org>
libatomic/ChangeLog:
PR target/59778
* configure.tgt (hppa*): Set ARCH.
* config/pa/fenv.c: New file.
Jakub Jelinek [Sat, 3 Feb 2024 13:38:27 +0000 (14:38 +0100)]
wide-int: Fix up wi::bswap_large [PR113722]
Since bswap has been converted from a method to a function we miscompile
the following testcase. The problem is the assumption that the passed in
len argument (number of limbs in the xval array) is the upper bound for the
bswap result, which is true only if precision is <= 64. If precision is
larger than that, e.g. 128 as in the testcase, if the argument has only
one limb (i.e. 0 to ~(unsigned HOST_WIDE_INT) 0), the result can still
need 2 limbs for that precision, or generally BLOCKS_NEEDED (precision)
limbs, it all depends on how many least significant limbs of the operand
are zero. bswap_large as implemented only cleared len limbs of result,
then swapped the bytes (invoking UB when oring something in all the limbs
above it) and finally passed len to canonize, saying that more limbs
aren't needed.
The following patch fixes it by renaming len to xlen (so that it is clear
it is X's length), using it solely for safe_uhwi argument when we attempt
to read from X, and using new len = BLOCKS_NEEDED (precision) instead in
the other two spots (i.e. when clearing the val array, turned it also
into memset, and in canonize argument). wi::bswap asserts it isn't invoked
on widest_int, so we are always invoked on wide_int or similar and those
have preallocated result sized for the corresponding precision (i.e.
BLOCKS_NEEDED (precision)).
2024-02-03 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113722
* wide-int.cc (wi::bswap_large): Rename third argument from
len to xlen and adjust use in safe_uhwi. Add len variable, set
it to BLOCKS_NEEDED (precision) and use it for clearing of val
and as canonize argument. Clear val using memset instead of
a loop.
Jakub Jelinek [Sat, 3 Feb 2024 13:37:19 +0000 (14:37 +0100)]
ggc-common: Fix save PCH assertion
We are getting a gnuradio PCH ICE
/usr/include/pybind11/stl.h:447:1: internal compiler error: in gt_pch_save, at ggc-common.cc:693
0x1304e7d gt_pch_save(_IO_FILE*)
../../gcc/ggc-common.cc:693
0x12a45fb c_common_write_pch()
../../gcc/c-family/c-pch.cc:175
0x18ad711 c_parse_final_cleanups()
../../gcc/cp/decl2.cc:5062
0x213988b c_common_parse_file()
../../gcc/c-family/c-opts.cc:1319
(unfortunately it isn't reproduceable always, but often needs
up to 100 attempts, isn't reproduceable in a cross etc.).
The bug is in the assertion I've added in gt_pch_save when adding
relocation support for the PCH files in case they happen not to be
mmapped at the selected address.
addr is a relocated address which points to a location in the PCH
blob (starting at mmi.preferred_base, with mmi.size bytes) which contains
a pointer that needs to be relocated. So the assertion is meant to
verify the address is within the PCH blob, obviously it needs to be
equal or above mmi.preferred_base, but I got the other comparison wrong
and when one is very unlucky and the last sizeof (void *) bytes of the
blob happen to be a pointer which needs to be relocated, such as on the
s390x host addr 0x8008a04ff8, mmi.preferred_base 0x8000000000 and
mmi.size 0x8a05000, addr + sizeof (void *) is equal to mmi.preferred_base +
mmi.size and that is still fine, both addresses are end of something.
2024-02-03 Jakub Jelinek <jakub@redhat.com>
* ggc-common.cc (gt_pch_save): Allow addr to be equal to
mmi.preferred_base + mmi.size - sizeof (void *).
- Import latest fixes from dmd v2.107.0-beta.1.
- Hex strings can now be cast to integer arrays.
- Add support for Interpolated Expression Sequences.
D runtime changes:
- Import latest fixes from druntime v2.107.0-beta.1.
- New core.interpolation module to provide run-time support for D
interpolated expression sequence literals.
Phobos changes:
- Import latest fixes from phobos v2.107.0-beta.1.
- `std.range.primitives.isBidirectionalRange', and
`std.range.primitives.isRandomAccessRange' now take an optional
element type.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd e770945277.
* Make-lang.in (D_FRONTEND_OBJS): Add d/basicmangle.o, d/enumsem.o,
d/funcsem.o, d/templatesem.o.
* d-builtins.cc (build_frontend_type): Update for new front-end
interface.
* d-codegen.cc (declaration_type): Likewise.
(parameter_type): Likewise.
* d-incpath.cc (add_globalpaths): Likewise.
(add_filepaths): Likewise.
(add_import_paths): Likewise.
* d-lang.cc (d_init_options): Likewise.
(d_handle_option): Likewise.
(d_parse_file): Likewise.
* decl.cc (DeclVisitor::finish_vtable): Likewise.
(DeclVisitor::visit (FuncDeclaration *)): Likewise.
(get_symbol_decl): Likewise.
* expr.cc (ExprVisitor::visit (StringExp *)): Likewise.
Implement support for 8-byte hexadecimal strings.
* typeinfo.cc (create_tinfo_types): Update internal TypeInfo
representation.
(TypeInfoVisitor::visit (TypeInfoConstDeclaration *)): Update for new
front-end interface.
(TypeInfoVisitor::visit (TypeInfoInvariantDeclaration *)): Likewise.
(TypeInfoVisitor::visit (TypeInfoSharedDeclaration *)): Likewise.
(TypeInfoVisitor::visit (TypeInfoWildDeclaration *)): Likewise.
(TypeInfoVisitor::visit (TypeInfoClassDeclaration *)): Move data for
TypeInfo_Class.nameSig to the end of the object.
(create_typeinfo): Update for new front-end interface.
Xi Ruoyao [Thu, 1 Feb 2024 21:37:38 +0000 (05:37 +0800)]
LoongArch: Fix an ODR violation
When bootstrapping GCC 14 with --with-build-config=bootstrap-lto, an ODR
violation is detected:
../../gcc/config/loongarch/loongarch-opts.cc:57: warning:
'abi_minimal_isa' violates the C++ One Definition Rule [-Wodr]
57 | abi_minimal_isa[N_ABI_BASE_TYPES][N_ABI_EXT_TYPES];
../../gcc/config/loongarch/loongarch-def.cc:186: note:
'abi_minimal_isa' was previously declared here
186 | abi_minimal_isa = array<array<loongarch_isa, N_ABI_EXT_TYPES>,
../../gcc/config/loongarch/loongarch-def.cc:186: note:
code may be misoptimized unless '-fno-strict-aliasing' is used
Fix it by adding a proper declaration of abi_minimal_isa into
loongarch-def.h and remove the ODR-violating local declaration in
loongarch-opts.cc.
Patrick Palka [Sat, 3 Feb 2024 00:07:08 +0000 (19:07 -0500)]
c++: requires-exprs and partial constraint subst [PR110006]
In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.
These PRs however illustrate that we still sometimes do need to
partially substitute into a requires-expression, in particular when it
appears in associated constraints that we're directly substituting for
sake of declaration matching or dguide constraint rewriting. In these
cases we're being called from tsubst_constraint during which
processing_constraint_expression_p is true, so this patch checks this
predicate to control whether we defer substitution or partially
substitute.
In turn, we now need to propagate semantic tsubst flags through
tsubst_requires_expr rather than just using tf_none, notably for sake of
dguide constraint rewriting which sets tf_dguide.
PR c++/110006
PR c++/112769
gcc/cp/ChangeLog:
* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise. Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) <case REQUIRES_EXPR>: Accomodate
non-diagnostic tsubst flags.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
Gaius Mulley [Sat, 3 Feb 2024 00:03:39 +0000 (00:03 +0000)]
PR modula2/113730 Unexpected handling of mixed-precision integer arithmetic
This patch fixes a bug which occurs when an expression is created with
a ZType and an integer or cardinal. The resulting subexpression is
incorrecly given a ZType which allows compatibility with another
integer/cardinal type. The solution was to fix the subexpression
type. In turn this required a minor change to SArgs.mod.
gcc/m2/ChangeLog:
PR modula2/113730
* gm2-compiler/M2Base.mod (IsUserType): New procedure function.
(MixTypes): Use IsUserType instead of IsType before calling MixTypes.
* gm2-compiler/M2GenGCC.mod (GetTypeMode): Remove and import from
SymbolTable.
(CodeBinaryCheck): Replace call to MixTypes with MixTypesBinary.
(CodeBinary): Replace call to MixTypes with MixTypesBinary.
(CodeIfLess): Replace MixTypes with ComparisonMixTypes.
(CodeIfGre): Replace MixTypes with ComparisonMixTypes.
(CodeIfLessEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfGreEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfNotEqu): Replace MixTypes with ComparisonMixTypes.
(ComparisonMixTypes): New procedure function.
* gm2-compiler/M2Quads.mod (BuildEndFor): Replace GenQuadO
with GenQuadOtok and pass tokenpos for the operands to the AddOp
and XIndrOp.
(CheckRangeIncDec): Check etype against NulSym and dtype for a
pointer and set etype to Address.
(BuildAddAdrFunction): New variable opa. Convert operand to an
address and save result in opa. Replace GenQuad with GenQuadOtok.
(BuildSubAdrFunction): New variable opa. Convert operand to an
address and save result in opa. Replace GenQuad with GenQuadOtok.
(BuildDiffAdrFunction): New variable opa. Convert operand to an
address and save result in opa. Replace GenQuad with GenQuadOtok.
(calculateMultipicand): Replace GenQuadO with GenQuadOtok.
(ConvertToAddress): New procedure function.
(BuildDynamicArray): Convert index to address before adding to
the base.
* gm2-compiler/SymbolTable.def (GetTypeMode): New procedure function.
* gm2-compiler/SymbolTable.mod (GetTypeMode): New procedure
function implemented (moved from M2GenGCC.mod).
* gm2-libs/SArgs.mod (GetArg): Replace cast to PtrToChar with ADDRESS.
gcc/testsuite/ChangeLog:
PR modula2/113730
* gm2/extensions/fail/arith1.mod: New test.
* gm2/extensions/fail/arith2.mod: New test.
* gm2/extensions/fail/arith3.mod: New test.
* gm2/extensions/fail/arith4.mod: New test.
* gm2/extensions/fail/arithpromote.mod: New test.
* gm2/extensions/fail/extensions-fail.exp: New test.
* gm2/linking/fail/badimp.def: New test.
* gm2/linking/fail/badimp.mod: New test.
* gm2/linking/fail/linking-fail.exp: New test.
* gm2/linking/fail/testbadimp.mod: New test.
Tamar Christina [Fri, 2 Feb 2024 23:52:27 +0000 (23:52 +0000)]
middle-end: check memory accesses in the destination block [PR113588].
When analyzing loads for early break it was always the intention that for the
exit where things get moved to we only check the loads that can be reached from
the condition.
However the main loop checks all loads and we skip the destination BB. As such
we never actually check the loads reachable from the COND in the last BB unless
this BB was also the exit chosen by the vectorizer.
This leads us to incorrectly vectorize the loop in the PR and in doing so access
out of bounds.
gcc/ChangeLog:
PR tree-optimization/113588
PR tree-optimization/113467
* tree-vect-data-refs.cc
(vect_analyze_data_ref_dependence): Choose correct dest and fix checks.
(vect_analyze_early_break_dependences): Update comments.
gcc/testsuite/ChangeLog:
PR tree-optimization/113588
PR tree-optimization/113467
* gcc.dg/vect/vect-early-break_108-pr113588.c: New test.
* gcc.dg/vect/vect-early-break_109-pr113588.c: New test.
Andrew Pinski [Tue, 23 Jan 2024 00:27:49 +0000 (16:27 -0800)]
Fix some of vect-avg-*.c testcases
The vect-avg-*.c testcases are trying to make sure
the AVG internal function are used and not
doing promotion to `vector unsigned short`
but when V4QI is implemented, `vector(2) unsigned short`
shows up in the detail dump file and causes the failure.
To fix this checking the optimized dump instead of the vect dump
for `vector unsigned short` to make sure the vectorizer does not
do the promotion.
Ian Lance Taylor [Fri, 20 Oct 2023 17:11:48 +0000 (10:11 -0700)]
compiler: export the type "any" as a builtin
Otherwise we can't tell the difference between builtin type "any" and
a locally defined type "any".
This will require updates to the gccgo export data parsers in the main
Go repo and the x/tools repo. These updates are https://go.dev/cl/537195
and https://go.dev/cl/537215.
Jakub Jelinek [Fri, 2 Feb 2024 21:14:33 +0000 (22:14 +0100)]
libgcc: Fix up _BitInt division [PR113604]
The following testcase ends up with SIGFPE in __divmodbitint4.
The problem is a thinko in my attempt to implement Knuth's algorithm.
The algorithm does (where b is 65536, i.e. one larger than what
fits in their unsigned short word):
// Compute estimate qhat of q[j].
qhat = (un[j+n]*b + un[j+n-1])/vn[n-1];
rhat = (un[j+n]*b + un[j+n-1]) - qhat*vn[n-1];
again:
if (qhat >= b || qhat*vn[n-2] > b*rhat + un[j+n-2])
{ qhat = qhat - 1;
rhat = rhat + vn[n-1];
if (rhat < b) goto again;
}
The problem is that it uses a double-word / word -> double-word
division (and modulo), while all we have is udiv_qrnnd unless
we'd want to do further library calls, and udiv_qrnnd is a
double-word / word -> word division and modulo.
Now, as the algorithm description says, it can produce at most
word bits + 1 bit quotient. And I believe that actually the
highest qhat the original algorithm can produce is
(1 << word_bits) + 1. The algorithm performs earlier canonicalization
where both the divisor and dividend are shifted left such that divisor
has msb set. If it has msb set already before, no shifting occurs but
we start with added 0 limb, so in the first uv1:uv0 double-word uv1
is 0 and so we can't get too high qhat, if shifting occurs, the first
limb of dividend is shifted right by UWtype bits - shift count into
a new limb, so again in the first iteration in the uv1:uv0 double-word
uv1 doesn't have msb set while vv1 does and qhat has to fit into word.
In the following iterations, previous iteration should guarantee that
the previous quotient digit is correct. Even if the divisor was the
maximal possible vv1:all_ones_in_all_lower_limbs, if the old uv0:lower_limbs
would be larger or equal to the divisor, the previous quotient digit
would increase and another divisor would be subtracted, which I think
implies that in the next iteration in uv1:uv0 double-word uv1 <= vv1,
but uv0 could be up to all ones, e.g. in case of all lower limbs
of divisor being all ones and at least one dividend limb below uv0
being not all ones. So, we can e.g. for 64-bit UWtype see
uv1:uv0 / vv1 0x8000000000000000UL:0xffffffffffffffffUL / 0x8000000000000000UL
or 0xffffffffffffffffUL:0xffffffffffffffffUL / 0xffffffffffffffffUL
In all these cases (when uv1 == vv1 && uv0 >= uv1), qhat is
0x10000000000000001UL, i.e. 2 more than fits into UWtype result,
if uv1 == vv1 && uv0 < uv1 it would be 0x10000000000000000UL, i.e.
1 more than fits into UWtype result.
Because we only have udiv_qrnnd which can't deal with those too large
cases (SIGFPEs or otherwise invokes undefined behavior on those), I've
tried to handle the uv1 >= vv1 case separately, but for one thing
I thought it would be at most 1 larger than what fits, and for two
have actually subtracted vv1:vv1 from uv1:uv0 instead of subtracting
0:vv1 from uv1:uv0.
For the uv1 < vv1 case, the implementation already performs roughly
what the algorithm does.
Now, let's see what happens with the two possible extra cases in
the original algorithm.
If uv1 == vv1 && uv0 < uv1, qhat above would be b, so we take
if (qhat >= b, decrement qhat by 1 (it becomes b - 1), add
vn[n-1] aka vv1 to rhat and goto again if rhat < b (but because
qhat already fits we can goto to the again label in the uv1 < vv1
code). rhat in this case is uv0 and rhat + vv1 can but doesn't
have to overflow, say for uv0 42UL and vv1 0x8000000000000000UL
it will not (and so we should goto again), while for uv0
0x8000000000000000UL and vv1 0x8000000000000001UL it will (and
we shouldn't goto again).
If uv1 == vv1 && uv0 >= uv1, qhat above would be b + 1, so we
take if (qhat >= b, decrement qhat by 1 (it becomes b), add
vn[n-1] aka vv1 to rhat. But because vv1 has msb set and
rhat in this case is uv0 - vv1, the rhat + vv1 addition
certainly doesn't overflow, because (uv0 - vv1) + vv1 is uv0,
so in the algorithm we goto again, again take if (qhat >= b and
decrement qhat so it finally becomes b - 1, and add vn[n-1]
aka vv1 to rhat again. But this time I believe it must always
overflow, simply because we added (uv0 - vv1) + vv1 + vv1 and
vv1 has msb set, so already vv1 + vv1 must overflow. And
because it overflowed, it will not goto again.
So, I believe the following patch implements this correctly, by
subtracting vv1 from uv1:uv0 double-word once, then comparing
again if uv1 >= vv1. If that is true, subtract vv1 from uv1:uv0
again and add 2 * vv1 to rhat, no __builtin_add_overflow is needed
as we know it always overflowed and so won't goto again.
If after the first subtraction uv1 < vv1, use __builtin_add_overflow
when adding vv1 to rhat, because it can but doesn't have to overflow.
I've added an extra testcase which tests the behavior of all the changed
cases, so it has a case where uv1:uv0 / vv1 is 1:1, where it is
1:0 and rhat + vv1 overflows and where it is 1:0 and rhat + vv1 does not
overflow, and includes tests also from Zdenek's other failing tests.
2024-02-02 Jakub Jelinek <jakub@redhat.com>
PR libgcc/113604
* libgcc2.c (__divmodbitint4): If uv1 >= vv1, subtract
vv1 from uv1:uv0 once or twice as needed, rather than
subtracting vv1:vv1.
* gcc.dg/torture/bitint-53.c: New test.
* gcc.dg/torture/bitint-55.c: New test.
This change implements __builtin_get_fpsr() and __builtin_set_fpsr(x)
to get and set the floating-point status register. They are used to
implement pa_atomic_assign_expand_fenv().
2024-02-02 John David Anglin <danglin@gcc.gnu.org>
Such situation can only happen on auto-vectorization, never happen on intrinsic codes.
Since the reduction is passed VLMAX AVL, it should be more natural to pass VLMAX to the scalar move which initial the value of the reduction.
Iain Sandoe [Mon, 29 Jan 2024 10:09:25 +0000 (10:09 +0000)]
testsuite, Darwin: Allow for undefined symbols in shared test.
Darwin's linker defaults to error on undefined (which makes it look as
if we do not support shared, leading to tests being marked incorrectly
as unsupported).
This fixes the issue by allowing the symbols used in the target
supports test to be undefined.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_shared):
Allow the external symbols referenced in the test to be undefined.
Iain Sandoe [Fri, 26 Jan 2024 15:23:19 +0000 (15:23 +0000)]
testsuite, ubsan: Add libstdc++ deps where required.
We use the ubsan tests from both C, C++, D and Fortran.
thee sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver, and the target might
require a path to the libstdc++ (e.g. for handing -static-xxxx or
for embedded runpaths), we need to add a suitable option (or we get
fails at execution time because of the missing paths).
Conversely, we do not want to add multiple instances of these
paths (since that leads to failures on tools that report warnings
for duplicate runpaths).
This patch modifies the _init function to allow a sigle parameter
that determines whether the *asan_init should add a path for
libstdc++ (yes for C driver, no for C++ driver).
gcc/testsuite/ChangeLog:
* g++.dg/ubsan/ubsan.exp:Add a parameter to init to say that
we expect the C++ driver to provide paths for libstdc++.
* gcc.dg/ubsan/ubsan.exp: Add a parameter to init to say that
we need a path added for libstdc++.
* gdc.dg/ubsan/ubsan.exp: Likewise.
* gfortran.dg/ubsan/ubsan.exp: Likewise.
* lib/ubsan-dg.exp: Handle a single parameter to init that
requests addition of a path to libstdc++ to link flags.
Iain Sandoe [Fri, 26 Jan 2024 15:22:44 +0000 (15:22 +0000)]
testsuite, asan, hwsan: Add libstdc++ deps where required.
We use the shared asan/hwasan rom both C,C++,D and Fortran.
The sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver, and the target might
require a path to the libstdc++ (e.g. for handing -static-xxxx or
for embedded runpaths), we need to add a suitable option (or we get
fails at execution time because of the missing paths).
Conversely, we do not want to add multiple instances of these
paths (since that leads to failures on tools that report warnings
for duplicate runpaths).
This patch modifies the _init function to allow a single parameter
that determines whether the *asan_init should add a path for
libstdc++ (yes for C driver, no for C++ driver).
gcc/testsuite/ChangeLog:
* g++.dg/asan/asan.exp: Add a parameter to init to say that
we expect the C++ driver to provide paths for libstdc++.
* g++.dg/hwasan/hwasan.exp: Likewise
* gcc.dg/asan/asan.exp: Add a parameter to init to say that
we need a path added for libstdc++.
* gcc.dg/hwasan/hwasan.exp: Likewise.
* gdc.dg/asan/asan.exp: Likewise.
* gfortran.dg/asan/asan.exp: Likewise.
* lib/asan-dg.exp: Handle a single parameter to init that
requests addition of a path to libstdc++ to link flags.
* lib/hwasan-dg.exp: Likewise.
Jonathan Wakely [Fri, 2 Feb 2024 10:03:12 +0000 (10:03 +0000)]
libstdc++: Make std::function deduction guide support explicit object functions [PR113335]
This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.
libstdc++-v3/ChangeLog:
PR libstdc++/113335
* include/bits/std_function.h (__function_guide_helper): Add
partial specialization for explicit object member functions, as
per LWG 3617.
* testsuite/20_util/function/cons/deduction_c++23.cc: Check
explicit object member functions.
* testsuite/30_threads/packaged_task/cons/deduction_c++23.cc:
Likewise.
Jakub Jelinek [Fri, 2 Feb 2024 10:46:34 +0000 (11:46 +0100)]
libgcc: Export XF, TF, HF and BFmode specific _BitInt symbols from libgcc_s.so.1 [PR113700]
Rainer pointed out that __PFX__ and __FIXPTPFX__ prefix replacement is done
solely for libgcc-std.ver.in and not for the *.ver files in config.
I've used the __PFX__ prefix even in config/i386/libgcc-glibc.ver because it
was used for similar symbols in libgcc-std.ver.in, and that results in those
symbols being STB_LOCAL in libgcc_s.so.1. Tests still work because gcc by
default uses -static-libgcc when linking (unlike g++ etc.), but would
have failed when using -shared-libgcc (but I see nothing in the testsuite
actually testing with -shared-libgcc, so am not adding tests).
With the patch, libgcc_s.so.1 now exports
__fixtfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__fixxfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitintbf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitinthf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitinttf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitintxf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
on x86_64-linux which it wasn't before.
2024-02-02 Jakub Jelinek <jakub@redhat.com>
PR target/113700
* config/i386/libgcc-glibc.ver (GCC_14.0.0): Remove __PFX prefixes
from symbol names.
Jakub Jelinek [Fri, 2 Feb 2024 10:28:31 +0000 (11:28 +0100)]
lower-bitint: Handle casts from large/huge _BitInt to pointer/reference types [PR113692]
I thought one needs to cast first to pointer-sized integer before casting to
pointer, but apparently that is not the case.
So the following patch arranges for the large/huge _BitInt to
pointer/reference conversions to use the same code as for conversions
of them to small integral types.
2024-02-02 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113692
* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Handle casts
from large/huge BITINT_TYPEs to POINTER_TYPE/REFERENCE_TYPE as
final_cast_p.
Jakub Jelinek [Fri, 2 Feb 2024 10:27:37 +0000 (11:27 +0100)]
lower-bitint: Handle uninitialized large/huge SSA_NAMEs as inline asm inputs [PR113699]
Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME
arguments, var_to_partition will not work for those, but unlike calls
where we just create a new uninitialized SSA_NAME here we need to change
the inline asm input to be an uninitialized VAR_DECL.
Jonathan Wakely [Thu, 1 Feb 2024 10:08:05 +0000 (10:08 +0000)]
libstdc++: Implement some missing functions for net::ip::network_v6
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string specialization.
* testsuite/experimental/net/internet/network/v6/cons.cc: New
test.
Jonathan Wakely [Wed, 31 Jan 2024 10:41:49 +0000 (10:41 +0000)]
libstdc++: Avoid reusing moved-from iterators in PSTL tests [PR90276]
The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second time that results in making new
copies of moved-from iterators. For libstdc++ debug mode iterators, the
moved-from state is singular, which means copying them will abort at
runtime.
The fix is to make copies of iterator arguments instead of forwarding
them.
The callers of reverse_invoker::operator() also forward the iterators
multiple times, but that's OK because reverse_invoker accepts them by
forwarding reference but then breaks the chain of forwarding and copies
them as lvalues.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/util/pstl/test_utils.h (reverse_invoker): Do not use
perfect forwarding for iterator arguments.
This change broke bootstrap on aarch64-linux.
The problem can be seen even on the reduced testcase.
The IL on the unreduced testcase before widening_mul has:
# val_583 = PHI <val_26(13), val_164(40)>
...
pretmp_266 = MEM[(const struct wide_int_storage *)&D.160657].len;
_264 = pretmp_266 & 65535;
...
_176 = (sizetype) val_583;
_439 = (sizetype) _264;
_284 = _439 * 8;
_115 = _176 + _284;
where 583/266/264 have unsigned int type and 176/439/284/115 have sizetype.
widening_mul first turns that into:
# val_583 = PHI <val_26(13), val_164(40)>
...
pretmp_266 = MEM[(const struct wide_int_storage *)&D.160657].len;
_264 = pretmp_266 & 65535;
...
_176 = (sizetype) val_583;
_439 = (sizetype) _264;
_284 = _264 w* 8;
_115 = _176 + _284;
and then is_widening_mult_rhs_p is called, with type sizetype (64-bit),
rhs _264, hprec 32 and prec 64. Now tree_nonzero_bits (rhs) is
65535, so bits is 64-bit wide_int 65535, stmt is BIT_AND_EXPR,
but we ICE on the
wi::to_wide (gimple_assign_rhs2 (stmt)) == wi::mask (hprec, false, prec)
comparison because wi::to_wide on gimple_assign_rhs2 (stmt) - unsigned int
65535 gives 32-bit wide_int 65535, while wi::mask (hprec, false, prec)
gives 64-bit wide_int 0xffffffff and comparison between different precision
wide_ints is forbidden.
The following patch fixes it the same way how bits is computed earlier,
by calling wide_int::from on the wi::to_wide (gimple_assign_rhs2 (stmt)),
so we compare 64-bit 65535 with 64-bit 0xffffffff.
2024-02-02 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113705
* tree-ssa-math-opts.cc (is_widening_mult_rhs_p): Use wide_int_from
around wi::to_wide in order to compare value in prec precision.
The problem is that /bin/as doesn't fully support cfi directives, so the
.eh_frame section is specified explicitly, which includes ".long 0".
The regular expression above includes ".*", which does multiline
matches. AFAICS those aren't needed here.
This patch changes the RE not to use multiline patches.
Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.
Jonathan Wakely [Thu, 1 Feb 2024 21:40:33 +0000 (21:40 +0000)]
libstdc++: Allow explicit conversion of string views with different traits
This was changed by LWG 3857.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
* testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc:
Explicit conversion between different specializations should be
allowed.
* testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc:
Likewise.
Jonathan Wakely [Thu, 1 Feb 2024 21:15:20 +0000 (21:15 +0000)]
libstdc++: Remove noexcept from std::generator::promise_type::yield_value
This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.
libstdc++-v3/ChangeLog:
* include/std/generator (promise_type::yield_value): Remove
noexcept from fourth overload, as per LWG 3894.
git://gcc.gnu.org / gcc.git / log