This is needed to avoid errors outside the immediate context when
evaluating is_default_constructible_v<vector<T, A>> when A is not
default constructible.
To avoid diagnostic regressions for 23_containers/vector/48101_neg.cc we
need to make the std::allocator<cv T> partial specializations default
constructible, which they probably should have been anyway.
libstdc++-v3/ChangeLog:
PR libstdc++/113841
* include/bits/allocator.h (allocator<cv T>): Add default
constructor to partial specializations for cv-qualified types.
* include/bits/stl_vector.h (_Vector_impl::_Vector_impl()):
Constrain so that it's only present if the allocator is default
constructible.
* include/bits/stl_bvector.h (_Bvector_impl::_Bvector_impl()):
Likewise.
* testsuite/23_containers/vector/cons/113841.cc: New test.
Jonathan Wakely [Mon, 18 Mar 2024 13:09:52 +0000 (13:09 +0000)]
libstdc++: Use feature test macros in <bits/stl_construct.h>
The preprocessor checks for __cplusplus in <bits/stl_construct.h> should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.
For the latter, we want to check the compiler macro not the library's
__cpp_lib_constexpr_dynamic_alloc, because the latter is not defined for
freestanding but std::construct_at needs to be.
libstdc++-v3/ChangeLog:
* include/bits/stl_construct.h (destroy_at, construct_at): Guard
with feature test macros instead of just __cplusplus.
Jonathan Wakely [Tue, 19 Mar 2024 14:02:06 +0000 (14:02 +0000)]
libstdc++: Replace std::result_of with __invoke_result_t [PR114394]
Replace std::result_of with std::invoke_result, as specified in the
standard since C++17, to avoid deprecated warnings for std::result_of.
We don't have __invoke_result_t in C++11 mode, so add it as an alias
template for __invoke_result<>::type (which is what std::result_of uses
as its base class, so there's no change in functionality).
This fixes warnings given by Clang 18.
libstdc++-v3/ChangeLog:
PR libstdc++/114394
* include/std/functional (bind): Use __invoke_result_t instead
of result_of::type.
* include/std/type_traits (__invoke_result_t): New alias
template.
* testsuite/20_util/bind/ref_neg.cc: Adjust prune pattern.
openmp: Change to using a hashtab to lookup offload target addresses for indirect function calls
A splay-tree was previously used to lookup equivalent target addresses
for a given host address on offload targets. However, as splay-trees can
modify their structure on lookup, they are not suitable for concurrent
access from separate teams/threads without some form of locking. This
patch changes the lookup data structure to a hashtab instead, which does
not have these issues.
The call to build_indirect_map to initialize the data structure is now
called from just the first thread of the first team to avoid redundant
calls to this function.
Andrew Stubbs [Wed, 6 Mar 2024 15:54:46 +0000 (15:54 +0000)]
amdgcn: Adjust GFX10/GFX11 cache coherency
The RDNA devices have different cache architectures to the CDNA devices, and
the differences go deeper than just the assembler mnemonics.
I believe this patch is correct according to the documentation in the LLVM
AMDGPU user guide (the ISA manual is less instructive), but I hadn't observed
any real problems before (or after).
gcc/ChangeLog:
* config/gcn/gcn.md (*memory_barrier): Split into RDNA and !RDNA.
(atomic_load<mode>): Adjust RDNA cache settings.
(atomic_store<mode>): Likewise.
(atomic_exchange<mode>): Likewise.
Andrew Stubbs [Thu, 22 Feb 2024 11:41:19 +0000 (11:41 +0000)]
amdgcn: Prefer V32 on RDNA devices
We run these devices in wavefrontsize64 for compatibility, but they actually
only have 32-lane vectors, natively. If the upper part of a V64 is masked
off (as it is in V32) then RDNA devices will skip execution of the upper part
for most operations, so this adjustment shouldn't leave too much performance on
the table. One exception is memory instructions, so full wavefrontsize32
support would be better.
The advantage is that we avoid the missing V64 operations (such as permute and
vec_extract).
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_vectorize_preferred_simd_mode): Prefer V32 on
RDNA devices.
David Malcolm [Fri, 22 Mar 2024 14:57:25 +0000 (10:57 -0400)]
analyzer: look through casts in taint sanitization [PR112974,PR112975]
PR analyzer/112974 and PR analyzer/112975 record false positives
from the analyzer's taint detection where sanitization of the form
if (VALUE CMP VALUE-OF-WIDER-TYPE)
happens, but wasn't being "noticed" by the taint checker, due to the
test being:
(WIDER_TYPE)VALUE CMP VALUE-OF-WIDER-TYPE
at the gimple level, and thus taint_state_machine recording
sanitization of (WIDER_TYPE)VALUE, but not of VALUE.
Fix by stripping casts in taint_state_machine::on_condition so that
the state machine records sanitization of the underlying value.
gcc/analyzer/ChangeLog:
PR analyzer/112974
PR analyzer/112975
* sm-taint.cc (taint_state_machine::on_condition): Strip away
casts before considering LHS and RHS, to increase the chance of
detecting places where sanitization of a value may have happened.
gcc/testsuite/ChangeLog:
PR analyzer/112974
PR analyzer/112975
* gcc.dg/plugin/plugin.exp (plugin_test_list): Add
taint-pr112974.c and taint-pr112975.c to analyzer_kernel_plugin.c.
* gcc.dg/plugin/taint-pr112974.c: New test.
* gcc.dg/plugin/taint-pr112975.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Andrew Stubbs [Fri, 15 Mar 2024 14:26:15 +0000 (14:26 +0000)]
amdgcn: Add gfx1103 target
Add support for the gfx1103 RDNA3 APU integrated graphics devices. The ROCm
documentation warns that these may not be supported, but it seems to work
at least partially.
Marek Polacek [Thu, 22 Feb 2024 23:49:08 +0000 (18:49 -0500)]
c++: direct-init of an array of class type [PR59465]
...from another array in a mem-initializer should not be accepted.
We already reject
struct string {} a[1];
string x[1](a);
but
struct pair {
string s[1];
pair() : s(a) {}
};
is wrongly accepted.
It started to be accepted with r0-110915-ga034826198b771:
<https://gcc.gnu.org/pipermail/gcc-patches/2011-August/320236.html>
which was supposed to be a cleanup, not a deliberate change to start
accepting the code. The build_vec_init_expr code was added in r165976:
<https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297582.html>.
It appears that we do the magic copy array when we have a defaulted
constructor and we generate code for its mem-initializer which
initializes an array. I also see that we go that path for compound
literals. So when initializing an array member, we can limit building
up a VEC_INIT_EXPR to those special cases.
PR c++/59465
gcc/cp/ChangeLog:
* init.cc (can_init_array_with_p): New.
(perform_member_init): Check it.
gcc/testsuite/ChangeLog:
* g++.dg/init/array62.C: New test.
* g++.dg/init/array63.C: New test.
* g++.dg/init/array64.C: New test.
Andrew Stubbs [Fri, 15 Mar 2024 14:21:15 +0000 (14:21 +0000)]
vect: more oversized bitmask fixups
These patches fix up a failure in testcase vect/tsvc/vect-tsvc-s278.c when
configured to use V32 instead of V64 (I plan to do this for RDNA devices).
The problem was that a "not" operation on the mask inadvertently enabled
inactive lanes 31-63 and corrupted the output. The fix is to adjust the mask
when calling internal functions (in this case COND_MINUS), when doing masked
loads and stores, and when doing conditional jumps (some cases were already
handled).
gcc/ChangeLog:
* dojump.cc (do_compare_rtx_and_jump): Clear excess bits in vector
bitmasks.
(do_compare_and_jump): Remove now-redundant similar code.
* internal-fn.cc (expand_fn_using_insn): Clear excess bits in vector
bitmasks.
(add_mask_and_len_args): Likewise.
Thomas Neumann [Mon, 11 Mar 2024 13:35:20 +0000 (14:35 +0100)]
handle unwind tables that are embedded within unwinding code [PR111731]
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup structure. That data structure
assumes that is consists of non-overlappping intervals. This
becomes a problem if the unwinding table is embedded within the
code itself, as now the intervals do overlap.
To fix this problem we now keep the unwind tables in a separate
b-tree, which prevents the overlap.
libgcc/ChangeLog:
PR libgcc/111731
* unwind-dw2-fde.c: Split unwind ranges if they contain the
unwind table.
Mikael Morin [Thu, 21 Mar 2024 16:27:54 +0000 (17:27 +0100)]
fortran: Ignore use statements on error [PR107426]
This fixes an access to freed memory on the testcase from the PR.
The problem comes from an invalid subroutine statement in an interface,
which is ignored and causes the following statements forming the procedure
body to be rejected. One of them use-associates the intrinsic ISO_C_BINDING
module, which imports new symbols in a namespace that is freed at the time
the statement is rejected. However, this creates dangling pointers as
ISO_C_BINDING is special and its import creates a reference to the imported
C_PTR symbol in the return type of the global intrinsic symbol for C_LOC
(see the function create_intrinsic_function).
This change saves and restores the list of use statements, so that rejected
use statements are removed before they have a chance to be applied to the
current namespace and create dangling pointers.
PR fortran/107426
gcc/fortran/ChangeLog:
* gfortran.h (gfc_save_module_list, gfc_restore_old_module_list):
New declarations.
* module.cc (old_module_list_tail): New global variable.
(gfc_save_module_list, gfc_restore_old_module_list): New functions.
(gfc_use_modules): Set module_list and old_module_list_tail.
* parse.cc (next_statement): Save module_list before doing any work.
(reject_statement): Restore module_list to its saved value.
Mikael Morin [Fri, 22 Mar 2024 11:32:34 +0000 (12:32 +0100)]
fortran: Fix specification expression error with dummy procedures [PR111781]
This fixes a spurious invalid variable in specification expression error.
The error was caused on the testcase from the PR by two different bugs.
First, the call to is_parent_of_current_ns was unable to recognize
correct host association and returned false. Second, an ad-hoc
condition coming next was using a global variable previously improperly
restored to false (instead of restoring it to its initial value). The
latter happened on the testcase because one dummy argument was a procedure,
and checking that argument what causing a check of all its arguments with
the (improper) reset of the flag at the end, and that preceded the check of
the next argument.
For the first bug, the wrong result of is_parent_of_current_ns is fixed by
correcting the namespaces that function deals with, both the one passed
as argument and the current one tracked in the gfc_current_ns global. Two
new functions are introduced to select the right namespace.
Regarding the second bug, the problematic condition is removed, together
with the formal_arg_flag associated with it. Indeed, that condition was
(wrongly) allowing local variables to be used in array bounds of dummy
arguments.
PR fortran/111781
gcc/fortran/ChangeLog:
* symbol.cc (gfc_get_procedure_ns, gfc_get_spec_ns): New functions.
* gfortran.h (gfc_get_procedure_ns, gfc_get_spec ns): Declare them.
(gfc_is_formal_arg): Remove.
* expr.cc (check_restricted): Remove special case allowing local
variable in dummy argument bound expressions. Use gfc_get_spec_ns
to get the right namespace.
* resolve.cc (gfc_is_formal_arg, formal_arg_flag): Remove.
(gfc_resolve_formal_arglist): Set gfc_current_ns. Quit loop and
restore gfc_current_ns instead of early returning.
(resolve_symbol): Factor common array spec resolution code to...
(resolve_symbol_array_spec): ... this new function. Additionnally
set and restore gfc_current_ns.
gcc/testsuite/ChangeLog:
* gfortran.dg/spec_expr_8.f90: New test.
* gfortran.dg/spec_expr_9.f90: New test.
Pan Li [Fri, 22 Mar 2024 06:43:47 +0000 (14:43 +0800)]
RISC-V: Introduce gcc attribute riscv_rvv_vector_bits for RVV
This patch would like to introduce one new gcc attribute for RVV.
This attribute is used to define fixed-length variants of one
existing sizeless RVV types.
This attribute is valid if and only if the mrvv-vector-bits=zvl, the only
one args should be the integer constant and its' value is terminated
by the LMUL and the vector register bits in zvl*b. For example:
The above type define is valid when -march=rv64gc_zve64d_zvl64b
(aka 2(m2) * 64 = 128 for vin32m2_t), and will report error when
-march=rv64gcv_zvl128b similar to below.
"error: invalid RVV vector size '128', expected size is '256' based on
LMUL of type and '-mrvv-vector-bits=zvl'"
Meanwhile, a pre-define macro __riscv_v_fixed_vlen is introduced to
represent the fixed vlen in a RVV vector register.
For the vint*m*_t below operations are allowed.
* The sizeof.
* The global variable(s).
* The element of union and struct.
* The cast to other equalities.
* CMP: >, <, ==, !=, <=, >=
* ALU: +, -, *, /, %, &, |, ^, >>, <<, ~, -
The CMP will return vint*m*_t the same as aarch64 sve. For example:
typedef vint32m1_t fixed_vint32m1_t __attribute__((riscv_rvv_vector_bits(128)));
fixed_vint32m1_t less_than (fixed_vint32m1_t a, fixed_vint32m1_t b)
{
return a < b;
}
For the vfloat*m*_t below operations are allowed.
* The sizeof.
* The global variable(s).
* The element of union and struct.
* The cast to other equalities.
* CMP: >, <, ==, !=, <=, >=
* ALU: +, -, *, /, -
The CMP will return vfloat*m*_t the same as aarch64 sve. For example:
typedef vfloat32m1_t fixed_vfloat32m1_t __attribute__((riscv_rvv_vector_bits(128)));
fixed_vfloat32m1_t less_than (fixed_vfloat32m1_t a, fixed_vfloat32m1_t b)
{
return a < b;
}
For the vbool*_t types only below operations are allowed except
the CMP and ALU. The CMP and ALU operations on vbool*_t is not
well defined currently.
* The sizeof.
* The global variable(s).
* The element of union and struct.
* The cast to other equalities.
For the vint*x*m*_t tuple types are not suppored in this patch which is
compatible with clang.
This patch passed the below testsuites.
* The riscv fully regression tests.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Add pre-define
macro __riscv_v_fixed_vlen when zvl.
* config/riscv/riscv.cc (riscv_handle_rvv_vector_bits_attribute):
New static func to take care of the RVV types decorated by
the attributes.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-1.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-10.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-11.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-12.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-13.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-14.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-15.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-16.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-17.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-18.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-2.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-3.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-4.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-5.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-6.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-7.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-8.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits-9.c: New test.
* gcc.target/riscv/rvv/base/riscv_rvv_vector_bits.h: New test.
Jakub Jelinek [Fri, 22 Mar 2024 09:20:11 +0000 (10:20 +0100)]
testsuite: Fix up depobj-3.c test on i686-linux [PR112724]
While I've posted a patch to handle EXCESS_PRECISION_EXPR in C/C++
pretty printing, still we'd need to handle
(a + (float)5)
and
(float)(((long double)a) + (long double)5)
and possibly
(float)(((double)a) + (double)5)
too for s390?, so the following patch just uses -fexcess-precision=fast,
so that the expression is always the same.
2024-03-22 Jakub Jelinek <jakub@redhat.com>
PR c++/112724
* c-c++-common/gomp/depobj-3.c: Add -fexcess-precision=fast as
dg-additional-options.
Andrew Pinski [Thu, 21 Mar 2024 23:29:20 +0000 (16:29 -0700)]
Another ICE after conflicting types of redeclaration [PR109619]
This another one of these ICE after error issues with the
gimplifier and a fallout from r12-3278-g823685221de986af.
This case happens when we are trying to fold memcpy/memmove.
There is already code to try to catch ERROR_MARKs as arguments
to the builtins so just need to change them to use error_operand_p
which checks the type of the expression to see if it was an error mark
also.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR c/109619
* builtins.cc (fold_builtin_1): Use error_operand_p
instead of checking against ERROR_MARK.
(fold_builtin_2): Likewise.
(fold_builtin_3): Likewise.
gcc/testsuite/ChangeLog:
PR c/109619
* gcc.dg/redecl-26.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Rainer Orth [Fri, 22 Mar 2024 09:07:05 +0000 (10:07 +0100)]
testsuite: vect: Remove dg-final in gcc.dg/vect/bb-slp-32.c [PR96147]
gcc.dg/vect/bb-slp-32.c currently XPASSes on 32 and 64-bit Solaris/SPARC:
XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects scan-tree-dump slp2
"vectorization is not profitable"
XPASS: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2 "vectorization is not
profitable"
Richard suggested to remove the dg-final, so this is what the patch does.
Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
Rainer Orth [Fri, 22 Mar 2024 08:55:03 +0000 (09:55 +0100)]
testsuite: i386: Skip gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. with Solaris as [PR114150]
Two avx512cd tests FAIL to assemble with the Solaris/x86 assembler:
FAIL: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c compilation failed
to produce executable
FAIL: gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c compilation failed
to produce executable
Excess errors:
Assembler: avx512cd-vpbroadcastmb2q-2.c
"/var/tmp//ccs_9lod.s", line 42 : Invalid instruction argument
Near line: " vpbroadcastmb2q %k0, %zmm0"
Assembler: avx512cd-vpbroadcastmw2d-2.c
"/var/tmp//ccevT6Rd.s", line 35 : Invalid instruction argument
Near line: " vpbroadcastmw2d %k0, %zmm0"
This seems to be an as bug, but given that this rarely if ever gets any
fixes these days, this test just skips the affected tests.
Adjuststing check_effective_target_avx512cd instead doesn't seem
sensible since it would disable quite a number of working tests.
Tested on i386-pc-solaris2.11 (as and gas) and x86_64-pc-linux-gnu.
On x86 and avr some address spaces allow 0 pointers (on avr actually
even generic as, but libsanitizer isn't ported to it and
I'm not convinced we should completely kill -fsanitize=null in that
case).
The following patch makes sure those aren't diagnosed for -fsanitize=null,
though they are still sanitized for -fsanitize=alignment.
2024-03-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/111736
* ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
SANITIZE_NULL instrumentation for non-generic address spaces
for which targetm.addr_space.zero_address_valid (as) is true.
Jakub Jelinek [Fri, 22 Mar 2024 08:22:04 +0000 (09:22 +0100)]
bitint: Some bitint store fixes [PR114405]
The following patch fixes some bugs in the handling of stores to large/huge
_BitInt bitfields.
In the first 2 hunks we are processing the most significant limb of the
actual type (not necessarily limb in the storage), and so we know it is
either partial or full limb, so [1, limb_prec] bits rather than
[0, limb_prec - 1] bits as the code actually assumed. So, those 2
spots are fixed by making sure if tprec is a multiple of limb_prec we
actually use limb_prec bits rather than 0. Otherwise, it e.g. happily
could create and use 0 precision INTEGER_TYPE even when it actually
should have processed 64 bits, or for non-zero bo_bit could handle just
say 1 bit rather than 64 bits plus 1 bit in the last hunk spot.
In the last hunk we are dealing with the extra bits in the last storage
limb, and the code was e.g. happily creating 65 bit precision INTEGER_TYPE,
even when we really should use 1 bit precision in that case. Also, it
used a wrong offset in that case.
The large testcase covers all these cases.
2024-03-22 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114405
* gimple-lower-bitint.cc (bitint_large_huge::lower_mergeable_stmt):
Set rprec to limb_prec rather than 0 if tprec is divisible by
limb_prec. In the last bf_cur handling, set rprec to (tprec + bo_bit)
% limb_prec rather than tprec % limb_prec and use just rprec instead
of rprec + bo_bit. For build_bit_field_ref offset, divide
(tprec + bo_bit) by limb_prec rather than just tprec.
RISC-V: Don't add fractional LMUL types to V_VLS for XTheadVector
The expansion of `memset` (via expand_builtin_memset_args())
uses clear_by_pieces() and store_by_pieces() to avoid calls
to the C runtime. To check if a type can be used for that purpose
the function by_pieces_mode_supported_p() tests if a `mov` and
a `vec_duplicate` INSN can be expaned by the backend.
The `vec_duplicate` expansion takes arguments of type `V_VLS`.
The `mov` expansions take arguments of type `V`, `VB`, `VT`,
`VLS_AVL_IMM`, and `VLS_AVL_REG`. Some of these types (in fact
not types but type iterators) include fractional LMUL types.
E.g. `V_VLS` includes `V`, which includes `VI`, which includes
`RVVMF2QI`.
This results in an attempt to use fractional LMUL-types for
the `memset` expansion resulting in an ICE for XTheadVector,
because that extension cannot handle fractional LMULs.
This patch addresses this issue by splitting the definition
of the `VI` mode itereator into `VI_NOFRAC` (without fractional
LMUL types) and `VI_FRAC` (only fractional LMUL types).
Further, it defines `V_VLS` such, that `VI_FRAC` types are only
included if XTheadVector is not enabled.
The effect is demonstrated by a new test case that shows
that the by-pieces framework now emits `sb` instructions
instead of triggering an ICE.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
PR target/114194
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Split VI into VI_FRAC and VI_NOFRAC.
Only include VI_NOFRAC in V_VLS without TARGET_XTHEADVECTOR.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/pr114194.c: New test.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Jeff Law [Fri, 22 Mar 2024 02:41:59 +0000 (20:41 -0600)]
[committed] Fix RISC-V missing stack tie
As some of you know, Raphael has been working on stack-clash support for the
RISC-V port. A little while ago Florian reached out to us with an issue where
glibc was failing its smoke test due to referencing an unallocated stack slot.
Without diving into the code in detail I (incorrectly) concluded it was a
problem with the fallback of using Ada's stack-check paths due to not having
stack-clash support.
Once enough stack-clash bits were ready I had Raphael review the code generated
for Florian's test and we concluded the the original case from Florian was just
wrong irrespective of stack clash/stack check. While Raphael's stack-clash
work will indirectly fix Florian's case, it really should also work without
stack-clash.
In particular this code was called out by valgrind:
While I haven't reproduced Florian's code exactly, I was able to get reasonably
close and verify my suspicion that everything was fine before sched2 and
incorrect after sched2. It was also obvious at that point what had gone wrong
-- we were missing a stack tie after the final stack pointer adjustment.
This patch adds the missing stack tie.
While not technically a regression, I shudder at the thought of chasing one of
these issues down again in the wild. Been there, done that.
Regression tested on rv64gc. Verified the scheduler no longer mucked up
realpath by hand. Pushing to the trunk.
gcc/
* config/riscv/riscv.cc (riscv_expand_prologue): Add missing stack
tie for scalable and final stack adjustment if needed.
The scope of the target attribute should not extend the function body.
Aka, test_3 cannot have the 'v' extension, as well as the test_4
cannot have both the 'v' and 'zfh' extension.
Unfortunately, for now the test_4 is able to leverage the 'v' and
the 'zfh' extension which is incorrect. This patch would like to
fix the sticking attribute by introduce the commandline subset_list.
When parse_arch, we always clone from the cmdline_subset_list instead
of the current_subset_list.
Meanwhile, we correct the print information about arch like below.
The riscv_declare_function_name hook is always after the hook
riscv_process_target_attr. Thus, we introduce one hash_map to record
the 1:1 mapping from fndel to its' subset_list in advance. And later
the riscv_declare_function_name is able to get the right information
about the arch.
Below test are passed for this patch
* The riscv fully regression test.
PR target/114352
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (struct riscv_func_target_info):
New struct for func decl and target name.
(struct riscv_func_target_hasher): New hasher for hash table mapping
from the fn_decl to fn_target_name.
(riscv_func_decl_hash): New func to compute the hash for fn_decl.
(riscv_func_target_hasher::hash): New func to impl hash interface.
(riscv_func_target_hasher::equal): New func to impl equal interface.
(riscv_cmdline_subset_list): New static var for cmdline subset list.
(riscv_func_target_table_lazy_init): New func to lazy init the func
target hash table.
(riscv_func_target_get): New func to get target name from hash table.
(riscv_func_target_put): New func to put target name into hash table.
(riscv_func_target_remove_and_destory): New func to remove target
info from the hash table and destory it.
(riscv_parse_arch_string): Set the static var cmdline_subset_list.
* config/riscv/riscv-subset.h (riscv_cmdline_subset_list): New static
var for cmdline subset list.
(riscv_func_target_get): New func decl.
(riscv_func_target_put): Ditto.
(riscv_func_target_remove_and_destory): Ditto.
* config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch):
Take cmdline_subset_list instead of current_subset_list when clone.
(riscv_process_target_attr): Record the func target info to hash table.
(riscv_option_valid_attribute_p): Add new arg tree fndel.
* config/riscv/riscv.cc (riscv_declare_function_name): Consume the
func target info and print the arch message.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr114352-3.c: New test.
There are two reasons for this ICE.
1. The implied extension(s) of v are not well handled and the
TARGET_MIN_VLEN is 0 which is not reinitialized. Then the
size / TARGET_MIN_VLEN will have DivideByZero.
2. The machine modes of the vector types will be vary after
the v extension is introduced.
This patch passed below testsuite:
1. The riscv fully regression test.
PR target/114352
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::parse):
Replace implied, combine and check to func finalize.
(riscv_subset_list::finalize): New func impl to take care of
implied, combine ext and related checks.
* config/riscv/riscv-subset.h: Add func decl for finalize.
* config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch):
Finalize the ext before return succeed.
* config/riscv/riscv.cc (riscv_set_current_function): Reinit the
machine mode before when set cur function.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr114352-1.c: New test.
* gcc.target/riscv/rvv/base/pr114352-2.c: New test.
Gaius Mulley [Fri, 22 Mar 2024 01:47:31 +0000 (01:47 +0000)]
PR modula2/114422 Attempting to declare a set of unknown type causes ICE
This patch corrects an error message directive which did not
escape the { character. The patch also contains test cases
to stress set declaration errors.
gcc/analyzer/ChangeLog:
PR analyzer/113619
* region-model.cc (region_model::eval_condition): Fix
cast-handling from r14-3632-ge7b267444045c5 so that if those give
an unknown result, we continue trying the constraint manager.
gcc/testsuite/ChangeLog:
PR analyzer/113619
* c-c++-common/analyzer/taint-divisor-pr113619.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Gaius Mulley [Thu, 21 Mar 2024 19:38:03 +0000 (19:38 +0000)]
PR modula2/113836 gm2 does not dump gimple or quadruples to file
This patch provides the localized modula2 changes to gcc/m2
which facilitate the dumping of gimple and quadruples to file.
PR modula2/113836 will be full complete after a subsequent patch
adding changes to lang.opt and documentation. The lang.opt
patch requires all language bootstrap regression testing whereas
this patch is isolated to gcc/m2 and only the m2 language.
gcc/m2/ChangeLog:
PR modula2/113836
* Make-lang.in (GM2_C_OBJS): Add m2/gm2-gcc/m2pp.o.
(m2/m2pp.o): Remove rule.
(GM2-COMP-BOOT-DEFS): Add M2LangDump.def.
(GM2-COMP-BOOT-MODS): Add M2LangDump.mod.
(GM2-GCC-DEFS): Add M2LangDump.def.
(GM2-GCC-MODS): Add M2LangDump.mod.
* gm2-compiler/M2CaseList.mod (WriteCase): Rewrite.
* gm2-compiler/M2Code.mod (DoModuleDeclare): Call
DumpFilteredResolver depending upon DumpLangDecl.
(DoCodeBlock): Call CreateDumpGimple depending upon
DumpLangGimple.
(Code): Replace DisplayQuadList blocks with DumpQuadruples.
(DisplayQuadsInScope): Remove.
(DisplayQuadNumbers): Remove.
(CodeBlock): Rewrite.
* gm2-compiler/M2GCCDeclare.def (IncludeDumpSymbol): New procedure.
(DumpFilteredResolver): New procedure.
(DumpFilteredDefinitive): New procedure.
* gm2-compiler/M2GCCDeclare.mod (IncludeDumpSymbol): New procedure.
(DumpFilteredResolver): New procedure.
(DumpFilteredDefinitive): New procedure.
(doInclude): Rewrite to use GetDumpFile.
(WatchIncludeList): Remove fixed debugging value.
(doExclude): Rewrite to use GetDumpFile.
(DeclareTypesConstantsProceduresInRange): Remove fixed debugging
values.
(PreAddModGcc): Rename parameter t as tree.
(IncludeGetNth): Rewrite to use GetDumpFile.
(IncludeType): Ditto.
(IncludeSubscript): Ditto.
(PrintLocalSymbol): Ditto.
(PrintLocalSymbols): Ditto.
(IncludeGetVarient): Ditto.
(PrintDeclared): Ditto.
(PrintAlignment): Ditto.
(PrintDecl): Ditto.
(PrintScope): Ditto.
(PrintProcedure): Ditto.
(PrintSym): Ditto.
(PrintSymbol): Ditto.
(PrintTerse): Ditto.
* gm2-compiler/M2Options.def (GetDumpLangDeclFilename): New
procedure function.
(SetDumpLangDeclFilename): New procedure.
(GetDumpLangQuadFilename): New procedure function.
(SetDumpLangQuadFilename): New procedure.
(GetDumpLangGimpleFilename): New procedure function.
(SetDumpLangGimpleFilename): New procedure.
(SetM2DumpFilter): New procedure.
(GetM2DumpFilter): New procedure function.
(GetDumpLangGimple): New procedure function.
* gm2-compiler/M2Options.mod (GetDumpLangDeclFilename): New
procedure function.
(SetDumpLangDeclFilename): New procedure.
(GetDumpLangQuadFilename): New procedure function.
(SetDumpLangQuadFilename): New procedure.
(GetDumpLangGimpleFilename): New procedure function.
(SetDumpLangGimpleFilename): New procedure.
(SetM2DumpFilter): New procedure.
(GetM2DumpFilter): New procedure function.
(GetDumpLangGimple): New procedure function.
* gm2-compiler/M2Quads.def (DumpQuadruples): New procedure.
* gm2-compiler/M2Quads.mod (DumpUntil): New procedure.
(GetCtorInit): New procedure function.
(GetCtorFini): New procedure function.
(DumpQuadrupleFilter): New procedure function.
(DumpQuadrupleAll): New procedure.
(DisplayQuadList): Remove procedure.
(DumpQuadruples): New procedure.
(DisplayQuadRange): Rewrite.
(DisplayQuad): Ditto.
(DisplayProcedureAttributes): Ditto.
(WriteOperator): Ditto.
(WriteMode): Ditto.
* gm2-compiler/M2Scope.mod (ForeachScopeBlockDo2): Replace
DisplayQuadruples with TraceQuadruples.
(ForeachScopeBlockDo3): Replace DisplayQuadruples with
TraceQuadruples.
* gm2-compiler/SymbolConversion.def (Gcc2Mod): New procedure function.
* gm2-compiler/SymbolConversion.mod: New procedure function.
* gm2-gcc/m2misc.cc (m2misc_DebugTree): New function.
(m2misc_DebugTreeChain): New function.
* gm2-gcc/m2options.h (M2Options_GetDumpLangDeclFilename): New
prototype.
(M2Options_SetDumpLangDeclFilename): New prototype.
(M2Options_GetDumpLangQuadFilename): New prototype.
(M2Options_SetDumpLangQuadFilename): New prototype.
(M2Options_GetDumpLangGimpleFilename): New prototype.
(M2Options_SetDumpLangGimpleFilename): New prototype.
(M2Options_GetDumpLangGimple): New prototype.
(M2Options_SetM2DumpFilter): New prototype.
(M2Options_GetM2DumpFilter): New prototype.
* m2pp.cc: Move to...
* gm2-gcc/m2pp.cc: ...here.
* m2pp.h: Move to...
* gm2-gcc/m2pp.h: ...here.
* gm2-gcc/m2statement.cc (m2statement_BuildEndFunctionCode): Call
m2pp_dump_gimple.
* gm2-lang.cc (ENABLE_QUAD_DUMP_ALL): New define.
(gm2_langhook_init_options): Add switch cases for proposed new
command line options.
* gm2-libs/DynamicStrings.def (ReverseIndex): New procedure
function.
* gm2-libs/DynamicStrings.mod: New procedure function.
* gm2-compiler/M2LangDump.def: New file.
* gm2-compiler/M2LangDump.mod: New file.
* gm2-gcc/m2langdump.h: New file.
* gm2-gcc/m2pp.def: New file.
Gaius Mulley [Thu, 21 Mar 2024 18:30:23 +0000 (18:30 +0000)]
PR modula2/114418 missing import of TSIZE from system causes ICE
This patch detects whether the symbol func is NulSym before generating
an error and if so just uses the token location and fixed string to
generate an error message.
gcc/m2/ChangeLog:
PR modula2/114418
* gm2-compiler/PCSymBuild.mod (PushConstFunctionType): Check
func against NulSym and issue an error.
gcc/testsuite/ChangeLog:
PR modula2/114418
* gm2/pim/fail/missingtsize.mod: New test.
* gm2/pim/fail/missingtsize2.mod: New test.
Harald Anlauf [Wed, 20 Mar 2024 19:59:24 +0000 (20:59 +0100)]
Fortran: improve array component description in runtime error message [PR30802]
Runtime error messages for array bounds violation shall use the following
scheme for a coherent, abridged description of arrays or array components
of derived types:
(1) If x is an ordinary array variable, use "x"
(2) if z is a DT scalar and x an array component at level 1, use "z%x"
(3) if z is a DT scalar and x an array component at level > 1, or
if z is a DT array and x an array (at any level), use "z...%x"
Use a new helper function abridged_ref_name for construction of that name.
gcc/fortran/ChangeLog:
PR fortran/30802
* trans-array.cc (abridged_ref_name): New helper function.
(trans_array_bound_check): Use it.
(array_bound_check_elemental): Likewise.
(gfc_conv_array_ref): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/30802
* gfortran.dg/bounds_check_17.f90: Adjust pattern.
* gfortran.dg/bounds_check_fail_8.f90: New test.
where we since r11-291 fail to emit the code for the explicit
instantiation. That's because cp_walk_subtrees/TYPENAME_TYPE now
walks TYPE_CONTEXT ('conditional' here) as well, and in a template
finds the B==VAL template argument. VAL is constexpr, which implies const,
which in the global scope implies static. constrain_visibility_for_template
then makes "struct conditional<(B == VAL), int, float>" non-TREE_PUBLIC.
Then symtab_node::needed_p checks TREE_PUBLIC, sees it's 0, and we don't
emit any code.
I thought the fix would be some ODR-esque check to not consider
constexpr variables/fns that are used just for their value. But
it turned out to be tricky. For instance, we can't skip
determine_visibility in a template; we can't even skip it for value-dep
expressions. For example, no-linkage-expr1.C has
using P = struct {}*;
template <int N>
void f(int(*)[((P)0, N)]) {}
where ((P)0, N) is value-dep, but N is not relevant here: we have to
ferret out the anonymous type. When instantiating, it's already gone.
This patch uses decl_constant_var_p. This is to implement (an
approximation) [basic.def.odr]#14.5.1 and [basic.def.odr]#5.2.
PR c++/110323
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r) <case VAR_DECL>: Do nothing for
decl_constant_var_p VAR_DECLs.
gcc/testsuite/ChangeLog:
* g++.dg/template/explicit-instantiation6.C: New test.
* g++.dg/template/explicit-instantiation7.C: New test.
Jakub Jelinek [Thu, 21 Mar 2024 12:07:50 +0000 (13:07 +0100)]
libgcc: Fix up bitint division [PR114397]
The Knuth's division algorithm relies on the number of dividend limbs
to be greater ore equal to number of divisor limbs, which is why
I've added a special case for un < vn at the start of __divmodbitint4.
Unfortunately, my assumption that it then implies abs(v) > abs(u) and
so quotient must be 0 and remainder same as dividend is incorrect.
This is because this check is done before negation of the operands.
While bitint_reduce_prec reduces precision from clearly useless limbs,
the problematic case is when the dividend is unsigned or non-negative
and divisor is negative. We can have limbs (from MS to LS):
dividend: 0 M ?...
divisor: -1 -N ?...
where M has most significant bit set and M >= N (if M == N then it
also the following limbs matter) and the most significant limbs can
be even partial. In this case, the quotient should be -1 rather than
0. bitint_reduce_prec will reduce the precision of the dividend so
that M is the most significant limb, but can't reduce precision of the
divisor to more than having the -1 as most significant limb, because
-N doesn't have the most significant bit set.
The following patch fixes it by detecting this problematic case in the
un < vn handling, and instead of assuming q is 0 and r is u will
decrease vn by 1 because it knows the later code will negate the divisor
and it can be then expressed after negation in one fewer limbs.
2024-03-21 Jakub Jelinek <jakub@redhat.com>
PR libgcc/114397
* libgcc2.c (__divmodbitint4): Don't assume un < vn always means
abs(v) > abs(u), check for a special case of un + 1 == vn where
u is non-negative and v negative and after v's negation vn could
be reduced by 1.
Richard Biener [Tue, 19 Mar 2024 13:50:06 +0000 (14:50 +0100)]
tree-optimization/113727 - bogus SRA with BIT_FIELD_REF
When SRA analyzes BIT_FIELD_REFs it handles writes and not byte
aligned reads differently from byte aligned reads. Instead of
trying to create replacements for the loaded portion the former
cases try to replace the base object while keeping the wrapping
BIT_FIELD_REFs. This breaks when we have both kinds operating
on the same base object if there's no appearant overlap conflict
as the conflict that then nevertheless exists isn't handled with.
The fix is to enforce what I think is part of the design handling
the former case - that only the full base object gets replaced
and no further sub-objects are created within as otherwise
keeping the wrapping BIT_FIELD_REF cannot work. The patch
enforces this within analyze_access_subtree.
PR tree-optimization/113727
* tree-sra.cc (analyze_access_subtree): Do not allow
replacements in subtrees when grp_partial_lhs.
David Malcolm [Wed, 20 Mar 2024 22:33:11 +0000 (18:33 -0400)]
analyzer: fix -Wanalyzer-deref-before-check false positive seen in loop header macro [PR109251]
gcc/analyzer/ChangeLog:
PR analyzer/109251
* sm-malloc.cc (deref_before_check::emit): Reject cases where the
check is in a loop header within a macro expansion.
(deref_before_check::loop_header_p): New.
gcc/testsuite/ChangeLog:
PR analyzer/109251
* c-c++-common/analyzer/deref-before-check-pr109251-1.c: New test.
* c-c++-common/analyzer/deref-before-check-pr109251-2.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
bpf: Corrected index computation when present with unnamed struct fields
Any unnamed non-struct-or-union field is not a member of the
BTF_KIND_STRUCT.
For that reason, CO-RE access strings indexes should take that in
consideration. This patch adds a condition to the incrementer that
computes the index for the field access.
gcc/ChangeLog:
* config/bpf/core-builtins.cc (bpf_core_get_index): Check if
field contains a DECL_NAME.
gcc/testsuite/ChangeLog:
* gcc.target/bpf/core-builtin-fieldinfo-offset-1.c: Add
testcase for unnamed fields.
bpf: Fix access string default for CO-RE type based relocations
Although part of all CO-RE relocation data, type based relocations do
not require an access string.
Initial implementation defined it as an empty string.
On the other hand, libbpf when parsing the CO-RE relocations verifies
that those strings would contain "0", otherwise reports an error.
This patch makes GCC compliant with libbpf expectations.
gcc/Changelog:
* config/bpf/btfext-out.cc (cpf_core_reloc_add): Correct for new code.
Add assert to validate the string is set.
* config/bpf/core-builtins.cc (cr_final): Make string struct
field as const.
(process_enum_value): Correct for field type change.
(process_type): Set access string to "0".
This patch corrects bugs within the CO-RE builtin field expression
related builtins.
The following bugs were identified and corrected based on the expected
results of bpf-next selftests testsuite.
It addresses the following problems:
- Expressions with pointer dereferencing now point to the BTF structure
type, instead of the structure pointer type.
- Pointer addition to structure root is now identified and constructed
in CO-RE relocations as if it is an array access. For example,
"&(s+2)->b" generates "2:1" as an access string where "2" is
refering to the access for "s+2".
gcc/ChangeLog:
* config/bpf/core-builtins.cc (core_field_info): Add
support for POINTER_PLUS_EXPR in the root of the field expression.
(bpf_core_get_index): Likewise.
(pack_field_expr): Make the BTF type to point to the structure
related node, instead of its pointer type.
(make_core_safe_access_index): Correct to new code.
gcc/testsuite/ChangeLog:
* gcc.target/bpf/core-attr-5.c: Correct.
* gcc.target/bpf/core-attr-6.c: Likewise.
* gcc.target/bpf/core-attr-struct-as-array.c: Add test case for
pointer arithmetics as array access use case.
Jakub Jelinek [Wed, 20 Mar 2024 16:00:51 +0000 (17:00 +0100)]
visium: Fix up visium_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, visium seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/visium/visium.cc (visium_setup_incoming_varargs): Only skip
TARGET_FUNCTION_ARG_ADVANCE for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 16:00:08 +0000 (17:00 +0100)]
nios2: Fix up nios2_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, nios2 seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip
nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:56 +0000 (16:59 +0100)]
nds32: Fix up nds32_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, nds32 seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/nds32/nds32.cc (nds32_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:43 +0000 (16:59 +0100)]
m32r: Fix up m32r_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, m32r seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/m32r/m32r.cc (m32r_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:32 +0000 (16:59 +0100)]
ft32: Fix up ft32_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, ft32 seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/ft32/ft32.cc (ft32_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:21 +0000 (16:59 +0100)]
epiphany: Fix up epiphany_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, epiphany seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs): Only
skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:08 +0000 (16:59 +0100)]
csky: Fix up csky_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, csky seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/csky/csky.cc (csky_setup_incoming_varargs): Only skip
csky_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 10:46:07 +0000 (11:46 +0100)]
Use integer_{zero,one}_node some more
When looking at the analyzer MEM_REF invalid second arg issue, I've noticed
tons of build_int_cst (integer_type_node, {0,1}) or build_zero_cst
(integer_type_node) cases.
That just wastes compile time (albeit not very much).
The following patch fixes what my sed script found.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
gcc/analyzer/
* constraint-manager.cc (test_range, test_constraint_conditions,
test_constant_comparisons, test_constraint_impl, test_purging,
test_bits): Use integer_zero_node instead of
build_zero_cst (integer_type_node) or
build_int_cst (integer_type_node, 0) and integer_one_node instead of
build_int_cst (integer_type_node, 1).
* region-model.cc (region_model::get_store_value,
append_interesting_constants, test_array_1,
test_get_representative_tree, test_unique_constants, test_assignment,
test_stack_frames, test_constraint_merging, test_widening_constraints,
test_iteration_1, test_array_2): Likewise.
gcc/cp/
* coroutines.cc (expand_one_await_expression): Use
integer_zero_node instead of build_int_cst (integer_type_node, 0)
and integer_one_node instead of build_int_cst (integer_type_node, 1).
gcc/fortran/
* trans-array.cc (structure_alloc_comps): Use integer_zero_node
instead of build_zero_cst (integer_type_node) or
build_int_cst (integer_type_node, 0) and integer_one_node instead of
build_int_cst (integer_type_node, 1).
* trans-expr.cc (conv_scalar_char_value): Likewise.
* trans-stmt.cc (gfc_trans_form_team, gfc_trans_change_team,
gfc_trans_sync_team, gfc_trans_sync): Likewise.
* trans-decl.cc (create_main_function): Likewise.
* trans-intrinsic.cc (trans_this_image, conv_intrinsic_move_alloc):
Likewise.
* trans.cc (gfc_allocate_using_caf_lib, gfc_deallocate_with_status):
Likewise.
gcc/objc/
* objc-next-runtime-abi-02.cc (build_v2_class_ro_t_initializer): Use
integer_zero_node instead of build_int_cst (integer_type_node, 0).
Jakub Jelinek [Wed, 20 Mar 2024 09:55:07 +0000 (10:55 +0100)]
bitint: Fix handling of conditional bitfield loads [PR114365]
For the m_var_msb (aka left shift) case of large/huge _BitInt bitfield loads
handle_load adds a PHI node, but I forgot to actually update the temporary
the code later on uses, so the PHI result was unused and the code
incorrectly used something that wasn't valid SSA form.
In particular, we emitted
if (_29 != 2)
goto <bb 4>; [80.00%]
else
goto <bb 5>; [20.00%]
Jakub Jelinek [Wed, 20 Mar 2024 09:34:51 +0000 (10:34 +0100)]
system.h: rename vec_step to workaround powerpc/clang bug [PR114369]
On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote:
> Gerald Pfeifer <gerald@pfeifer.com> writes:
> > I have seen an increasing number of reports of GCC failing to
> > build with clang on powerpc (on FreeBSD, though that's probably
> > immaterial).
> >
> > Turns out that clang has vec_step as a reserved word on powerpc
> > with AltiVec.
> >
> > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c.
> >
> >
> > The best approach I can see is to rename vec_step. Before I prepare
> > a patch: what alternate name/spelling would you prefer?
>
> Would it work to #define vec_step to vec_step_ or something on affected
> hosts, say in system.h?
>
> I'd prefer that to renmaing since "vec_step" does seem the most natural
> name for the variable. The equivalent scalar variable is "step" and
> other vector values in the surrounding code also use the "vec_" prefix.
So like this?
If/when clang finally fixes https://github.com/llvm/llvm-project/issues/85579
on their side, we can then limit it to clang versions which still have the
bug.
I've git grepped for vec_set and appart from altivec.h it is just used in
tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs,
rs6000-vecdefines.h (but that header is only included from altivec.h and
vec_step is then redefined to the function-like macro) and in rs6000-overload.def
but that file is processed with a generator, not included in C/C++ sources.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/114369
* system.h (vec_step): Define to vec_step_ when compiling
with clang on PowerPC.
Richard Biener [Tue, 19 Mar 2024 14:25:16 +0000 (15:25 +0100)]
middle-end/113396 - int128 array index and value-ranges
The following fixes bogus truncation of a value-range for an int128
array index when computing the maximum extent for a variable array
reference. Instead of possibly slowing things down by using
widest_int the following makes sure the range bounds fit within
the constraints offset_int were designed for.
PR middle-end/113396
* tree-dfa.cc (get_ref_base_and_extent): Use index range
bounds only if they fit within the address-range constraints
of offset_int.
Lewis Hyatt [Wed, 8 Nov 2023 21:13:14 +0000 (16:13 -0500)]
diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]
When a diagnostic pragma changes the classification of a given diagnostic,
the global options flags (such as warn_narrowing, etc.) may get changed too.
Specifically, if a warning was not enabled initially and was later enabled
by a pragma, then the corresponding global flag will change from false to
true when the pragma is processed. That change is permanent and is not
undone by a subsequent `#pragma GCC diagnostic pop'; the warning flag needs
to remain enabled since a diagnostic could be generated later on for a
source location prior to the pop.
So in order to support popping to the initial classification, given that the
global options flags no longer reflect that state, the diagnostic_context
object itself remembers the way things were before it changed anything. The
current implementation works fine for diagnostics that are always errors or
always warnings, but it doesn't do the right thing for diagnostics that
could be either, such as -Wnarrowing. The classification of that diagnostic
(or any permerror diagnostic) depends on the state of -fpermissive; for the
particular case of -Wnarrowing it also matters whether a compile-time or
run-time narrowing is being diagnosed.
The problem is that the current implementation insists on recording whether
an enabled diagnostic should be a DK_WARNING or a DK_ERROR, and then, after
popping to the initial state, it overrides it always to that type only. Fix
that up by adding a new internal diagnostic type DK_ANY. This just indicates
that the diagnostic is enabled without mandating exactly what type of
diagnostic it should be. Then the diagnostic can be emitted with whatever
type the frontend asks for.
Incidentally, while making this change, I noticed that classify_diagnostic()
spends some time computing a return value (the old classification kind) that
is not used anywhere. The computed value seems to have some problems, mainly
that it does not take into account `#pragma GCC diagnostic pop' at all, and
so the returned value doesn't seem like it could make sense in many
contexts. Given it would also not be desirable to leak the new internal-only
DK_ANY type to outside callers, I think it would make sense in a subsequent
cleanup patch to remove the return value altogether.
gcc/ChangeLog:
PR c++/111918
* diagnostic-core.h (enum diagnostic_t): Add DK_ANY special flag.
* diagnostic.cc (diagnostic_option_classifier::classify_diagnostic):
Make use of DK_ANY to indicate a diagnostic was initially enabled.
(diagnostic_context::diagnostic_enabled): Do not change the type of
a diagnostic if the saved classification is type DK_ANY.
gcc/testsuite/ChangeLog:
PR c++/111918
* g++.dg/cpp0x/Wnarrowing21a.C: New test.
* g++.dg/cpp0x/Wnarrowing21b.C: New test.
* g++.dg/cpp0x/Wnarrowing21c.C: New test.
* g++.dg/cpp0x/Wnarrowing21d.C: New test.
Martin Jambor [Tue, 19 Mar 2024 21:33:27 +0000 (22:33 +0100)]
ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)
Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, it turns out that it does not work for lambdas and that it
has been severely broken since GCC 10 when the base class has virtual
functions.
Lambdas don't work because the code cannot work with structures
representing member function pointers because they are passed by
reference instead by value and the code was not ready for that.
The presence of virtual methods broke thinks because at some point C++
FE got clever and stopped emitting the check for virtual methods when
the base class does not have any and that in turn made our existing
testcases not test the necessary pattern matching code. The pattern
matcher had a small bug which did not matter before r10-917-g3b47da42de621c but did afterwards.
This patch changes the pattern matcher to match both of these cases.
gcc/ChangeLog:
2024-03-06 Martin Jambor <mjambor@suse.cz>
PR ipa/108802
PR ipa/114254
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case looking
at COMPONENT_REFs directly from a PARM_DECL, also recognize loads from
a pointer parameter.
(ipa_analyze_indirect_call_uses): Also recognize loads from a pointer
parameter, also recognize the case when pfn pointer is loaded in its
own BB.
Marek Polacek [Tue, 19 Mar 2024 21:15:38 +0000 (17:15 -0400)]
testsuite: fix target for linkage-1.C
This test fails in C++11 due to:
linkage-1.C:3:8: error: 'f' function uses 'auto' type specifier without trailing return type
3 | inline auto f() {
| ^~~~
linkage-1.C:3:8: note: deduced return type only available with '-std=c++14' or '-std=gnu++14'
LRA removed insn setting equivalence to memory whose output was
reloaded. This resulted in writing an uninitiated value to the memory
which triggered assert in LRA code checking the final generated code.
This patch fixes the problem. Comment in the patch contains more
details about the problem and its solution.
gcc/ChangeLog:
PR target/99829
* lra-constraints.cc (lra_constraints): Prevent removing insn
with reverse equivalence to memory if the memory was reloaded.
Jakub Jelinek [Tue, 19 Mar 2024 20:06:13 +0000 (16:06 -0400)]
analyzer: fix ICE due to corrupt MEM_REFs [PR113505]
gcc/analyzer/ChangeLog
PR analyzer/113505
* region-model.cc (get_tree_for_byte_offset,
region_model::get_representative_path_var_1,
test_mem_ref, test_POINTER_PLUS_EXPR_then_MEM_REF): Use
char __attribute__((may_alias)) * as type of MEM_REF second argument.
gcc/testsuite/ChangeLog
PR analyzer/113505
* gcc.dg/analyzer/pr113505.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Tue, 19 Mar 2024 17:57:35 +0000 (13:57 -0400)]
diagnostics: fix corrupt json/SARIF on stderr [PR114348]
Various values of -fdiagnostics-format= request machine-readable output
on stderr, using JSON, but in various places we use fnotice to write
free-form text to stderr, such as "compilation terminated", leading to
corrupt JSON.
Fix by having fnotice skip the output for such cases.
gcc/ChangeLog:
PR middle-end/114348
* diagnostic-format-json.cc
(json_stderr_output_format::machine_readable_stderr_p): New.
(json_file_output_format::machine_readable_stderr_p): New.
* diagnostic-format-sarif.cc
(sarif_stream_output_format::machine_readable_stderr_p): New.
(sarif_file_output_format::machine_readable_stderr_p): New.
* diagnostic.cc (diagnostic_context::action_after_output): Move
"fnotice" to before "finish" call, so that we still have the
diagnostic_context.
(fnotice): Bail out if the user requested one of the
machine-readable diagnostic output formats on stderr.
* diagnostic.h
(diagnostic_output_format::machine_readable_stderr_p): New pure
virtual function.
(diagnostic_text_output_format::machine_readable_stderr_p): New.
(diagnostic_context::get_output_format): New accessor.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Edwin Lu [Tue, 12 Mar 2024 21:31:40 +0000 (14:31 -0700)]
RISC-V: Update test expectancies with recent scheduler change
Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.
Edwin Lu [Mon, 18 Mar 2024 18:43:41 +0000 (11:43 -0700)]
RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail
PR target/114175
* config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL
Jonathan Wakely [Mon, 18 Mar 2024 13:22:17 +0000 (13:22 +0000)]
libstdc++: Fix infinite loop in std::binomial_distribution [PR114359]
The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't multiplying
integers.
libstdc++-v3/ChangeLog:
PR libstdc++/114359
* include/bits/random.tcc (binomial_distribution::param_type):
Ensure arithmetic is done as type double.
* testsuite/26_numerics/random/binomial_distribution/114359.cc: New test.
Jonathan Wakely [Thu, 29 Feb 2024 17:13:49 +0000 (17:13 +0000)]
libstdc++: Suppress deprecation messages from <tbb/task.h> [PR101228]
libstdc++-v3/ChangeLog:
PR libstdc++/101228
* include/pstl/parallel_backend_tbb.h (TBB_SUPPRESS_DEPRECATED_MESSAGES):
Define before including <tbb/task.h> then undef afterwards.
Jonathan Wakely [Fri, 1 Mar 2024 11:20:51 +0000 (11:20 +0000)]
libstdc++: Regenerate <bits/version.h> in maintainer mode
This is a generated header but regenerating it requires the manual step
of running 'make -C include update-version' in the libstdc++ build dir.
Make it regenerate automatically when --enable-maintainer-mode is used.
Jonathan Wakely [Tue, 19 Mar 2024 12:58:27 +0000 (12:58 +0000)]
libstdc++: Update docs on build process and generated files
There are several more sub-directories below 'src' now, with lots more
conveience libraries. Document them all as of GCC 14.
Also document how to regenerate the generated headers under include/bits
and how to update the tzdata.zi file.
libstdc++-v3/ChangeLog:
* doc/xml/manual/build_hacking.xml: Document generated files.
Update list of convenience libraries and sub-directories under
the src directory.
* doc/html/*: Regenerate.
Jonathan Wakely [Tue, 19 Mar 2024 12:43:29 +0000 (12:43 +0000)]
libstdc++: Fix Python scripts to output the correct filename
These scripts both print "generated by $file, do not edit" header but
one of them prints the wrong filename. Use the built-in __file__
attribute to ensure it's correct.
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Fix header of generated
file to name the correct script.
libstdc++-v3/ChangeLog:
* include/bits/text_encoding-data.h: Regenerate.
* include/bits/unicode-data.h: Regenerate.
* scripts/gen_text_encoding_data.py: Fix header of generated
file to name the correct script.
Jonathan Wakely [Mon, 18 Mar 2024 13:00:17 +0000 (13:00 +0000)]
libstdc++: Begin lifetime of storage in std::vector<bool> [PR114367]
This doesn't cause a problem with GCC, but Clang correctly diagnoses a
bug in the code. The objects in the allocated storage need to begin
their lifetime before we start using them.
This change uses the allocator's construct function instead of using
std::construct_at directly, in order to support fancy pointers.
libstdc++-v3/ChangeLog:
PR libstdc++/114367
* include/bits/stl_bvector.h (_M_allocate): Use allocator's
construct function to begin lifetime of words.
David Malcolm [Tue, 19 Mar 2024 13:06:45 +0000 (09:06 -0400)]
analyzer: fixes to __atomic_{exchange,load,store} [PR114286]
In r14-1497-gef768035ae8090 I added some support to the analyzer for
__atomic_ builtins (enough to fix false positives I was seeing in
my integration tests).
Unfortunately I messed up the implementation of
__atomic_{exchange,load,store}, leading to ICEs seen in
PR analyzer/114286.
Fixed thusly, fixing the ICEs. Given that we're in stage 4, the patch
doesn't add support for any of the various __atomic_compare_exchange
builtins, so that these continue to fall back to the analyzer's
"anything could happen" handling of unknown functions.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
gcc/analyzer/ChangeLog:
PR analyzer/114286
* kf.cc (class kf_atomic_exchange): Reimplement based on signature
seen in gimple, rather than user-facing signature.
(class kf_atomic_load): Likewise.
(class kf_atomic_store): New.
(register_atomic_builtins): Register kf_atomic_store.
gcc/testsuite/ChangeLog:
PR analyzer/114286
* c-c++-common/analyzer/atomic-builtins-pr114286.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Iain Sandoe [Mon, 18 Mar 2024 10:06:44 +0000 (10:06 +0000)]
testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].
The intent of the test is to show that we find a framework that
is installed in /System/Library/Frameworks when the user has added
a '-F' option. The trick is to choose some header that is present
for all the Darwin versions we support and that does not contain any
content we cannot parse. We had been using the Kernel framework for
this, but recent SDK versions have revealed that this is not suitable.
Replacing with a use of IOKit.
PR target/114049
gcc/testsuite/ChangeLog:
* gcc.dg/framework-1.c: Use an IOKit header instead of a
Kernel one.
Iain Sandoe [Mon, 18 Mar 2024 09:57:33 +0000 (09:57 +0000)]
libstdc++: Sync the atomic_link_flags implementation with GCC.
For Darwin, in order to allow uninstalled testing, we need to provide
a '-B' option pointing to each path containing an uninstalled library
that we are using (these get appended to the embedded runpaths).
This updates the version of the atomic_link_flags proc in the libstdc++
testsuite to do the same as the one in the GCC testsuite.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (atomic_link_flags): Emit a -B
option for the path to the uninstalled libatomic.
Iain Sandoe [Tue, 19 Mar 2024 10:40:50 +0000 (10:40 +0000)]
libstdc++, Darwin: Do not use dev/null as the file for executables.
Darwin has a separate debug linker, which is invoked when the command
line contains source files and debug is enabled.
Using /dev/null as the executable name does not, therefore, work when
debug is enabled, since the debug linker does not accept /dev/null as
a valid executable name.
The leads to incorrectly UNSUPPORTED testcases because of the unintended
error result from the test compilation.
The solution here is to use a temporary file that is deleted at the
end of the test (which is the mechanism used elsewhere)
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp (v3_target_compile): Instead of
/dev/null, use a temporary file for test executables on Darwin.
Richard Biener [Tue, 19 Mar 2024 11:24:08 +0000 (12:24 +0100)]
tree-optimization/114151 - revert PR114074 fix
The following reverts the chrec_fold_multiply fix and only keeps
handling of constant overflow which keeps the original testcase
fixed. A better solution might involve ranger improvements or
tracking of assumptions during SCEV analysis similar to what niter
analysis does.
PR tree-optimization/114151
PR tree-optimization/114269
PR tree-optimization/114322
PR tree-optimization/114074
* tree-chrec.cc (chrec_fold_multiply): Restrict the use of
unsigned arithmetic when actual overflow on constant operands
is observed.
Jakub Jelinek [Tue, 19 Mar 2024 08:49:59 +0000 (09:49 +0100)]
arc: Fix up arc_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, arc seems to be affected too.
2024-03-19 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/arc/arc.cc (arc_setup_incoming_varargs): Only skip
arc_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Xi Ruoyao [Mon, 18 Mar 2024 09:18:34 +0000 (17:18 +0800)]
LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument. This is causing gcc.dg/c23-stdarg-6.c and
gcc.dg/c23-stdarg-8.c to fail.
Fix the issue by checking if arg.type is NULL, as r14-9503 explains.
gcc/ChangeLog:
PR target/114175
* config/loongarch/loongarch.cc
(loongarch_setup_incoming_varargs): Only skip
loongarch_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.
Christophe Lyon [Fri, 15 Mar 2024 19:55:43 +0000 (19:55 +0000)]
arm: [MVE intrinsics] Fix support for loads [PR target/114323]
The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account. Fixing this gives vld1 the "pure"
attribute instead, and solves the problem.
Like in the r14-9503 change on x86-64, I think Alpha also needs to
function_arg_advance after the hidden return pointer argument if
any.
At least, the following patch changes the assembly of s1-s6 functions
on the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647956.html
c23-stdarg-9.c testcase, and eyeballing the assembly for int f8 (...)
the ... args are passed in 16..21 registers and then on the stack,
while for struct S s8 (...) have hidden return pointer passed in 16
register and ... args in 17..21 registers and then on the stack, and
seems without this patch the incoming varargs setup does the wrong thing
(but I can't test on alpha easily).
Many targets seem to be unaffected, e.g. aarch64, arm, s390*, so I'm not
trying to change all targets together because such a change clearly isn't
needed e.g. for targets which use special register for the hidden return
pointer.
2024-03-19 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/alpha/alpha.cc (alpha_setup_incoming_varargs): Only skip
function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
projects / thirdparty / gcc.git / log
