2024-05-13 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/113363
* trans-array.cc (gfc_array_init_size): Use the expr3 dtype so
that the correct element size is used.
* trans-expr.cc (gfc_conv_procedure_call): Remove restriction
that ss and ss->loop be present for the finalization of class
array function results.
(trans_class_assignment): Use free and malloc, rather than
realloc, for character expressions assigned to unlimited poly
entities.
* trans-stmt.cc (gfc_trans_allocate): Build a correct rhs for
the assignment of an unlimited polymorphic 'source'.
gcc/testsuite/
PR fortran/113363
* gfortran.dg/pr113363.f90: New test.
(cherry picked from commit 2d0eeb529d400e61197a09c56011be976dd81ef0)
2024-06-20 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/59104
* dependency.cc (dependency_fcn, gfc_function_dependency): New
functions to detect dependency in array bounds and character
lengths on old style function results.
* dependency.h : Add prototype for gfc_function_dependency.
* error.cc (error_print): Remove trailing space.
* gfortran.h : Remove dummy_order and add fn_result_spec.
* symbol.cc : Remove declaration of next_dummy_order..
(gfc_set_sym_referenced): remove setting of symbol dummy order.
* trans-array.cc (gfc_trans_auto_array_allocation): Detect
non-dummy symbols with function dependencies and put the
allocation at the end of the initialization code.
* trans-decl.cc : Include dependency.h.
(decl_order): New function that determines uses the location
field of the symbol 'declared_at' to determine the order of two
declarations.
(gfc_defer_symbol_init): Call gfc_function_dependency to put
dependent symbols in the right part of the tlink chain. Use
the location field of the symbol declared_at to determine the
order of declarations.
(gfc_trans_auto_character_variable): Put character length
initialization of dependent symbols at the end of the chain.
* trans.cc (gfc_add_init_cleanup): Add boolean argument with
default false that determines whther an expression is placed at
the back or the front of the initialization chain.
* trans.h : Update the prototype for gfc_add_init_cleanup.
gcc/testsuite/
PR fortran/59104
* gfortran.dg/dependent_decls_2.f90: New test.
(cherry picked from commit ccaa39a268bef2a1d8880022696ff2dcaa6af941)
There are various non-IBM CPUs with altivec, so we cannot use that
flag to determine which .machine cpu to use, so ignore it.
Emit an additional ".machine altivec" if Altivec is enabled so
that the assembler doesn't require an explicit -maltivec option
to assemble any Altivec instructions for those targets where
the ".machine cpu" is insufficient to enable Altivec. For example,
-mcpu=G5 emits a ".machine power4".
2024-07-18 René Rebe <rene@exactcode.de>
Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/97367
* config/rs6000/rs6000.cc (rs6000_machine_from_flags): Do not consider
OPTION_MASK_ALTIVEC.
(emit_asm_machine): For Altivec compiles, emit a ".machine altivec".
gcc/testsuite/
PR target/97367
* gcc.target/powerpc/pr97367.c: New test.
Signed-off-by: René Rebe <rene@exactcode.de>
(cherry picked from commit 6962835bca3e6bef0f6ceae84a7814138b08b8a5)
gcc/fortran/ChangeLog:
PR fortran/103115
* trans-array.cc (gfc_trans_array_constructor_value): If the first
element of an array constructor is deferred-length character and
therefore does not have an element size known at compile time, do
not try to collect subsequent constant elements into a constructor
for optimization.
gcc/testsuite/ChangeLog:
PR fortran/103115
* gfortran.dg/string_array_constructor_4.f90: New test.
(cherry picked from commit c93be1606ecf8e0f65b96b67aa023fb456ceb3a3)
As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
stddef.h header causes the NULL macro in C++ to be re-defined to an
integral constant (__null). This makes the workaround in d59a576b8
("Redefine NULL to nullptr") ineffective, as other headers that are
typically included after system.h (such as obstack.h) do include
stddef.h too.
This can be seen by running the sample below through `clang++ -E`
#include <stddef.h>
#define NULL nullptr
#include <stddef.h>
NULL
The relevant libc++ change is here:
2950283ddd
Filed as FB14261859 to Apple and added a comment about it on LLVM PR
86843.
This fixes the cases in --enable-languages=c,c++,objc,obj-c++,rust build
where NULL being an integral constant instead of a null pointer literal
(therefore no longer implicitly converting to a pointer when used as a
template function's argument) caused issues.
gcc/value-pointer-equiv.cc:65:43: error: no viable conversion from `pair<typename __unwrap_ref_decay<long>::type, typename __unwrap_ref_decay<long>::type>' to 'const pair<tree, tree>'
65 | const std::pair <tree, tree> m_marker = std::make_pair (NULL, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
As noted in the previous commit though, the proper solution would be to
phase out the usages of NULL in GCC's C++ source code.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::saved_diagnostic):
Change NULL to nullptr.
(struct null_assignment_sm_context): Likewise.
* infinite-loop.cc: Likewise.
* infinite-recursion.cc: Likewise.
* varargs.cc (va_list_state_machine::on_leak): Likewise.
gcc/rust/ChangeLog:
* metadata/rust-imports.cc (Import::try_package_in_directory):
Change NULL to nullptr.
gcc/ChangeLog:
* value-pointer-equiv.cc: Change NULL to nullptr.
Signed-off-by: Daniel Bertalan <dani@danielbertalan.dev>
(cherry picked from commit 08776bef53835ff6318ecfeade8f6c6896ffd81f)
vwadd.wx and vwsub.wx have the same problem vfwadd.wf had. This patch
splits the insn pattern in the same way vfwadd.wf was split.
It also adds two patterns to recognize extended scalars. In practice
those do not provide a lot of improvement over what we already have but
in some instances we can get rid of redundant extensions.
gcc/ChangeLog:
* config/riscv/vector.md: Split vwadd.wx/vwsub.wx pattern and
add extended_scalar patterns.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115068.c: Add vwadd.wx/vwsub.wx
tests.
* gcc.target/riscv/rvv/base/pr115068-run.c: Include pr115068.c.
* gcc.target/riscv/rvv/base/vwaddsub-1.c: New test.
(cherry picked from commit 9781885a624f3e29634d95c14cd10940cefb1a5a)
This patch splits the vfw...wf pattern so we do not emit e.g. vfwadd.wf
v0,v8,fa5,v0.t anymore.
gcc/ChangeLog:
PR target/115068
* config/riscv/vector.md: Split vfw<insn>.wf pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115068-run.c: New test.
* gcc.target/riscv/rvv/base/pr115068.c: New test.
(cherry picked from commit a2fd0812a54cf51520f15e900df4cfb5874b75ed)
--discard-locals (-X) instructs the linker to remove local .L* symbols,
which occur a lot due to label differences for linker relaxation. The
arm port has a similar need and passes -X to ld.
In contrast, the RISC-V port does not pass -X to ld and rely on the
default --discard-locals in GNU ld's riscv port. The arm way is more
conventional (compiler driver instead of the linker customizes the
default linker behavior) and works with lld.
gcc/ChangeLog:
* config/riscv/elf.h (LINK_SPEC): Add -X.
* config/riscv/freebsd.h (LINK_SPEC): Add -X.
* config/riscv/linux.h (LINK_SPEC): Add -X.
(cherry picked from commit 50c218e3ffe57860591a987ecf44fcc0abb31f2c)
The extension parsing table entries for a range of Zic* extensions
does not match the mask definition in riscv.opt.
This results in broken TARGET_ZIC* macros, because the values of
riscv_zi_subext and riscv_zicmo_subext are set wrong.
This patch fixes this by moving Zic64b into riscv_zicmo_subext
and all other affected Zic* extensions to riscv_zi_subext.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Move ziccamoa, ziccif,
zicclsm, and ziccrse into riscv_zi_subext.
* config/riscv/riscv.opt: Define MASK_ZIC64B for
riscv_ziccmo_subext.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
(cherry picked from commit 285300eb928b171236e895f28c960ad02dcb0d67)
For the vfw vx format RVV intrinsic, the scalar type _Float16 also
requires the zvfh extension. Unfortunately, we only check the
vector tree type and miss the scalar _Float16 type checking. For
example:
vfloat32mf2_t test_vfwsub_wf_f32mf2(vfloat32mf2_t vs2, _Float16 rs1, size_t vl)
{
return __riscv_vfwsub_wf_f32mf2(vs2, rs1, vl);
}
It should report some error message like zvfh extension is required
instead of ICE for unreg insn.
This patch would like to make up such kind of validation for _Float16
in the RVV intrinsic API. It will report some error like below when
there is no zvfh enabled.
error: built-in function '__riscv_vfwsub_wf_f32mf2(vs2, rs1, vl)'
requires the zvfhmin or zvfh ISA extension
Passed the rv64gcv fully regression tests, included c/c++/fortran.
PR target/114988
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc
(validate_instance_type_required_extensions): New func impl to
validate the intrinisc func type ops.
(expand_builtin): Validate instance type before expand.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr114988-1.c: New test.
* gcc.target/riscv/rvv/base/pr114988-2.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
(cherry picked from commit 41b3cf262e61aee9d26380f1c820e0eaae740f50)
We have vec_extract pattern which takes ZVFHMIN as the mode
iterator of the V mode. Aka VF_ZVFHMIN iterator. But it will
expand to pred_extract_first pattern which takes the ZVFH as the mode
iterator of the V mode. AKa VF. The mismatch will result in one ICE
similar as below:
insn 30 29 31 2 (set (reg:HF 156 [ _2 ])
(unspec:HF [
(vec_select:HF (reg:RVVMF2HF 134 [ _1 ])
(parallel [
(const_int 0 [0])
]))
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)) "compress_run-2.c":22:3 -1
(nil))
during RTL pass: vregs
compress_run-2.c:25:1: internal compiler error: in extract_insn, at
recog.cc:2812
0xb3bc47 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:108
0xb3bc69 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:116
0xb3a545 extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2812
0x1010e9e instantiate_virtual_regs_in_insn
../../../gcc/gcc/function.cc:1612
0x1010e9e instantiate_virtual_regs
../../../gcc/gcc/function.cc:1995
0x1010e9e execute
../../../gcc/gcc/function.cc:2042
The below test suites are passed for this patch.
1. The rv64gcv fully regression test.
2. The rv64gcv build with glibc.
There may be other similar issue(s) for the mismatch, we will take care
of them by test cases one by one.
PR target/115456
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Leverage V_ZVFH instead of V
which contains the VF_ZVFHMIN for alignment.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115456-2.c: New test.
* gcc.target/riscv/rvv/base/pr115456-3.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
(cherry picked from commit c2c61d8902dbda017b1647252d17bce141493433)
We have vec_extract pattern which takes ZVFHMIN as the mode
iterator of the VLS mode. Aka V_VLS. But it will expand to
pred_extract_first pattern which takes the ZVFH as the mode
iterator of the VLS mode. AKa V_VLSF. The mismatch will
result in one ICE similar as below:
error: unrecognizable insn:
27 | }
| ^
(insn 19 18 20 2 (set (reg:HF 150 [ _13 ])
(unspec:HF [
(vec_select:HF (reg:V4HF 134 [ _1 ])
(parallel [
(const_int 0 [0])
]))
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)) "compress_run-2.c":24:5 -1
(nil))
during RTL pass: vregs
compress_run-2.c:27:1: internal compiler error: in extract_insn, at
recog.cc:2812
0x1a627ef _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
../../../gcc/gcc/rtl-error.cc:108
0x1a62834 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:116
0x1a0f356 extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2812
0x159ee61 instantiate_virtual_regs_in_insn
../../../gcc/gcc/function.cc:1612
0x15a04aa instantiate_virtual_regs
../../../gcc/gcc/function.cc:1995
0x15a058e execute
../../../gcc/gcc/function.cc:2042
This patch would like to fix this issue by align the mode
iterator restriction to ZVFH.
The below test suites are passed for this patch.
1. The rv64gcv fully regression test.
2. The rv64gcv build with glibc.
PR target/115456
gcc/ChangeLog:
* config/riscv/autovec.md: Take ZVFH mode iterator instead of
the ZVFHMIN for the alignment.
* config/riscv/vector-iterators.md: Add 2 new iterator
V_VLS_ZVFH and VLS_ZVFH.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr115456-1.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
(cherry picked from commit 3dac1049c1211e6d06c2536b86445a6334c3866d)
Presently, the code fragment:
int x[5];
void
d(int a, int b, int c) {
for (int i = 0; i < 5; i++)
x[i] = (a != b) ? c : a;
}
causes an ICE when compiled with -O2 -march=rv32i_zicond:
test.c: In function 'd':
test.c: error: unrecognizable insn:
11 | }
| ^
(insn 8 5 9 2 (set (reg:SI 139 [ iftmp.0_2 ])
(if_then_else:SI (ne:SI (reg/v:SI 136 [ a ])
(reg/v:SI 137 [ b ]))
(reg/v:SI 136 [ a ])
(reg/v:SI 138 [ c ]))) -1
(nil))
during RTL pass: vregs
This happens because, as part of one of the optimizations in
riscv_expand_conditional_move(), an if_then_else is generated with both
comparands being register operands, resulting in an unmatchable insn since
Zicond patterns require constant 0 as the second comparand. Fix this by adding
a extra check before performing this optimization.
The code snippet mentioned above is also included in this patch as a new Zicond
testcase.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_conditional_move): Add a
CONST0_RTX check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zicond-ice-5.c: New test.
(cherry picked from commit eb647daa87b466d0a71246fad302cd81bfce9be5)
This patch changes the tail policy for vmv.s.x from ta to tu.
By default the bug does not show up with qemu because qemu's
current vmv.s.x implementation always uses the tail-undisturbed
policy. With a local qemu version that overwrites the tail
with ones when the tail-agnostic policy is specified, the bug
shows.
gcc/ChangeLog:
* config/riscv/autovec.md: Add TU policy.
* config/riscv/riscv-protos.h (enum insn_type): Define
SCALAR_MOVE_MERGED_OP_TU.
gcc/testsuite/ChangeLog:
PR target/115725
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-1.c: Adjust
test expectation.
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-4.c: Ditto.
(cherry picked from commit acc3b703c05debc6276451f9daae5d0ffc797eac)
Call handle_implied_ext repeatly until there's no
new subset added into the subset list.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::riscv_subset_list):
init m_subset_num to 0.
(riscv_subset_list::add): increase m_subset_num once a subset added.
(riscv_subset_list::finalize): call handle_implied_ext repeatly
until no change in m_subset_num.
* config/riscv/riscv-subset.h: add m_subset_num member.
Signed-off-by: Fei Gao <gaofei@eswincomputing.com>
(cherry picked from commit 682731d11f9c02b24358d1af1e2bf6fca0221ee7)
Here we ICE with -fsanitize=address on
std::initializer_list x = { 1, 2, 3 };
since r14-8681, which removed .ASAN_MARK calls on TREE_STATIC variables.
That means that lower_try_finally now instead of
try
{
.ASAN_MARK (UNPOISON, &C.0, 12);
x = {};
x._M_len = 3;
x._M_array = &C.0;
}
finally
{
.ASAN_MARK (POISON, &C.0, 12);
}
gets:
try
{
x = {};
x._M_len = 3;
x._M_array = &C.0;
}
finally
{
}
and we ICE on the empty finally in lower_try_finally_onedest while
getting get_eh_else.
PR c++/115865
gcc/ChangeLog:
* tree-eh.cc (get_eh_else): Check that the result of
gimple_seq_first_stmt is non-null.
gcc/testsuite/ChangeLog:
* g++.dg/asan/initlist2.C: New test.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
(cherry picked from commit 1e60a6abfece40c7bf55d6ca0a439078d3f5159a)
A reference to a COMDAT function may be resolved to another definition
outside the current translation unit, so it's not eligible for `-fipa-ra`.
In `decl_binds_to_current_def_p()` there is already a check for weak
symbols. This commit checks for COMDAT functions that are not implemented
as weak symbols, for example, on *-*-mingw32.
gcc/ChangeLog:
PR rtl-optimization/115049
* varasm.cc (decl_binds_to_current_def_p): Add a check for COMDAT
declarations too, like weak ones.
(cherry picked from commit 5080840d8fbf25a321dd27543a1462d393d338bc)
Here we started to ICE with r13-25: in check_trait_type, for "X[]" we
return true here:
if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
return true; // Array of unknown bound. Don't care about completeness.
and then end up crashing in record_has_unique_obj_representations:
4836 if (cur != wi::to_offset (sz))
because sz is null.
https://eel.is/c++draft/type.traits#tab:meta.unary.prop-row-47-column-3-sentence-1
says that the preconditions for __has_unique_object_representations are:
"T shall be a complete type, cv void, or an array of unknown bound" and
that "For an array type T, the same result as
has_unique_object_representations_v<remove_all_extents_t<T>>" so T[]
should be treated as T. So we should use kind==2 for the trait.
PR c++/115476
gcc/cp/ChangeLog:
* semantics.cc (finish_trait_expr)
<case CPTK_HAS_UNIQUE_OBJ_REPRESENTATIONS>: Move below to call
check_trait_type with kind==2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/has-unique-obj-representations4.C: New test.
(cherry picked from commit fc382a373e6824bb998007d1dcb0805b0cf4b8e8)
This patch addresses PR target/115351, which is a code quality regression
on x86 when passing floating point complex numbers. The ABI considers
these arguments to have TImode, requiring interunit moves to place the
FP values (which are actually passed in SSE registers) into the upper
and lower parts of a TImode pseudo, and then similar moves back again
before they can be used.
The cause of the regression is that changes in how TImode initialization
is represented in RTL now prevents the RTL optimizers from eliminating
these redundant moves. The specific cause is that the *concatditi3
pattern, (zext(hi)<<64)|zext(lo), has an inappropriately high (default)
rtx_cost, preventing fwprop1 from propagating it. This pattern just
sets the hipart and lopart of a double-word register, typically two
instructions (less if reload can allocate things appropriately) but
the current ix86_rtx_costs actually returns INSN_COSTS(13), i.e. 52.
propagating insn 5 into insn 6, replacing:
(set (reg:TI 110)
(ior:TI (and:TI (reg:TI 110)
(const_wide_int 0x0ffffffffffffffff))
(ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ]) 0))
(const_int 64 [0x40]))))
successfully matched this instruction to *concatditi3_3:
(set (reg:TI 110)
(ior:TI (ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ]) 0))
(const_int 64 [0x40]))
(zero_extend:TI (subreg:DI (reg:DF 111 [ zD.2796 ]) 0))))
change not profitable (cost 50 -> cost 52)
This issue is resolved by having ix86_rtx_costs return more reasonable
values for these (place-holder) patterns.
2024-06-07 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/115351
* config/i386/i386.cc (ix86_rtx_costs): Provide estimates for
the *concatditi3 and *insvti_highpart patterns, about two insns.
gcc/testsuite/ChangeLog
PR target/115351
* g++.target/i386/pr115351.C: New test case.
(cherry picked from commit fb3e4c549d16d5050e10114439ad77149f33c597)
TARGET_MEM_REF can be used to offset constant base into a memory object (to
produce lea instruction). This confuses points_to_local_or_readonly_memory_p
which treats the constant address as a base of the access.
Bootstrapped/regtsted x86_64-linux, comitted.
Honza
gcc/ChangeLog:
PR ipa/113787
* ipa-fnsummary.cc (points_to_local_or_readonly_memory_p): Do not
look into TARGET_MEM_REFS with constant opreand 0.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/pr113787.c: New test.
(cherry picked from commit 96d53252aefcbc2fe419c4c3b4bcd3fc03d4d187)
This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
caused by load merging of (ptr[0]<<8)+ptr[1] when -ftrapv has been
specified. When the operator is | or ^ this is safe, but for addition
of signed integer types, a trap may be generated/required, so merging this
idiom into a single non-trapping instruction is inappropriate, confusing
the compiler by transforming a basic block with an exception edge into one
without.
This revision implements Richard Biener's feedback to add an early check
for stmt_can_throw_internal (cfun, stmt) to prevent transforming in the
presence of any statement that could trap, not just overflow on addition.
The one other tweak included in this patch is to mark the local function
find_bswap_or_nop_load as static ensuring that it isn't called from outside
this file, and guaranteeing that it is dominated by stmt_can_throw_internal
checking.
2024-06-24 Roger Sayle <roger@nextmovesoftware.com>
Richard Biener <rguenther@suse.de>
gcc/ChangeLog
PR tree-optimization/113673
* gimple-ssa-store-merging.cc (find_bswap_or_nop_load): Make static.
(find_bswap_or_nop_1): Avoid transformations (load merging) when
stmt_can_throw_internal indicates that a statement can trap.
gcc/testsuite/ChangeLog
PR tree-optimization/113673
* g++.dg/pr113673.C: New test case.
(cherry picked from commit d8b05aef77443e1d3d8f3f5d2c56ac49a503fee3)
As reported on gcc-regression, this test FAILs on aarch64, but my
r15-2090 change didn't change anything on the generated assembly,
just added the forgotten dg-do run directive to the test, so the
test has been failing forever, just we didn't know it.
I can actually reproduce it on x86_64 with -funsigned-char too,
s2.b.a has int type and -1 is stored to it, so we should compare
it against -1 rather than (char) -1; the latter is appropriate for
testing char fields into which we've stored -1.
2024-07-18 Jakub Jelinek <jakub@redhat.com>
* c-c++-common/torture/builtin-clear-padding-3.c (main): Compare
s2.b.a against -1 rather than (char) -1.
(cherry picked from commit 958ee138748fae4371e453eb9b357f576abbe83e)
While lazy loading, instantiation of pendings can sometimes recursively
perform name lookup and begin further lazy loading. When using the
'-ftime-report' functionality this causes ICEs as we could start an
already-running timer for the importing.
This patch fixes the issue by using the 'timevar_cond*' API instead to
support such recursive calls.
PR c++/115165
gcc/cp/ChangeLog:
* module.cc (lazy_load_binding): Use 'timevar_cond*' APIs.
(lazy_load_pendings): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/timevar-1_a.H: New test.
* g++.dg/modules/timevar-1_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
maybe_new_partial_specialization wasn't propagating TYPE_CONTEXT when
creating a new class type corresponding to a constrained partial spec,
which do_friend relies on via template_class_depth to distinguish a
template friend from a non-template friend, and so in the below testcase
we were incorrectly instantiating the non-template operator+ as if it
were a template leading to an ICE.
PR c++/111890
gcc/cp/ChangeLog:
* pt.cc (maybe_new_partial_specialization): Propagate TYPE_CONTEXT
to the newly created partial specialization.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-partial-spec15.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 247335823f420eb1dd56f4bf32ac78d441f5ccc2)
Here we're prematurely stripping the dependent alias template-id A<T> to
its defining-type-id T when used as a template argument, which in turn
causes us to essentially ignore A's vector_size attribute in the outer
template-id.
This has always been a problem for class template-ids it seems, and after
r14-2170 variable template-ids are affected as well.
This patch marks alias templates that have a dependent attribute as
complex (as with e.g. constrained alias templates) so that we don't look
through them prematurely.
PR c++/115897
gcc/cp/ChangeLog:
* pt.cc (complex_alias_template_p): Return true for an alias
template with attributes.
(get_underlying_template): Don't look through an alias template
with attributes.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-77.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 7954bb4fcb6fa80f6bb840133314885011821188)
Here we notice the 'this' conversion for the call f<void>() is bad, so
we correctly defer deduction for the template candidate, but we end up
never adding it to 'bad_cands' since missing_conversion_p for it returns
false (its only argument is 'this' which has already been determined to
be bad). This is not a huge deal, but it causes us to longer accept the
call with -fpermissive in release builds, and a tree check ICE in checking
builds.
So if we have a non-strictly viable template candidate that has not been
instantiated, then we need to add it to 'bad_cands' even if no argument
conversion is missing.
PR c++/106760
gcc/cp/ChangeLog:
* call.cc (add_candidates): Relax test for adding a candidate
to 'bad_cands' to also accept an uninstantiated template candidate
that has no missing conversions.
gcc/testsuite/ChangeLog:
* g++.dg/ext/conv3.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 50073ffae0a9b8feb9b36fdafdebd9885f6d7dc8)
Add missing "cannot_copy" attribute to instructions that have to
stay in 1-1 correspondence with another insn.
PR target/115526
gcc/ChangeLog:
* config/alpha/alpha.md (movdi_er_high_g): Add cannot_copy attribute.
(movdi_er_tlsgd): Ditto.
(movdi_er_tlsldm): Ditto.
(call_value_osf_<tls>): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/pr115526.c: New test.
(cherry picked from commit 0841fd4c42ab053be951b7418233f0478282d020)
The following testcase ICEs on x86_64-linux, because we try to
gsi_insert_on_edge_immediate a statement on an edge which already has
statements queued with gsi_insert_on_edge, and the deferral has been
intentional so that we don't need to deal with cfg changes in between.
The following patch uses the delayed insertion as well.
2024-07-17 Jakub Jelinek <jakub@redhat.com>
PR middle-end/115887
* gimple-lower-bitint.cc (gimple_lower_bitint): Use gsi_insert_on_edge
instead of gsi_insert_on_edge_immediate and set edge_insertions to
true.
* gcc.dg/bitint-108.c: New test.
(cherry picked from commit 5104fe4c7808a66ed3041a8da8e4720585cc8a1f)
The builtin-clear-padding-6.c testcase fails as clear_padding_type
doesn't correctly recompute the buf->size and buf->off members after
expanding clearing of an array using a runtime loop.
buf->size should be in that case the offset after which it should continue
with next members or padding before them modulo UNITS_PER_WORD and
buf->off that offset minus buf->size. That is what the code was doing,
but with off being the start of the loop cleared array, not its end.
So, the last hunk in gimple-fold.cc fixes that.
When adding the testcase, I've noticed that the
c-c++-common/torture/builtin-clear-padding-* tests, although clearly
written as runtime tests to test the builtins at runtime, didn't have
{ dg-do run } directive and were just compile tests because of that.
When adding that to the tests, builtin-clear-padding-1.c was already
failing without that clear_padding_type hunk too, but
builtin-clear-padding-5.c was still failing even after the change.
That is due to a bug in clear_padding_flush which the patch fixes as
well - when clear_padding_flush is called with full=true (that happens
at the end of the whole __builtin_clear_padding or on those array
padding clears done by a runtime loop), it wants to flush all the pending
padding clearings rather than just some. If it is at the end of the whole
object, it decreases wordsize when needed to make sure the code never writes
including RMW cycles to something outside of the object:
if ((unsigned HOST_WIDE_INT) (buf->off + i + wordsize)
> (unsigned HOST_WIDE_INT) buf->sz)
{
gcc_assert (wordsize > 1);
wordsize /= 2;
i -= wordsize;
continue;
}
but if it is full==true flush in the middle, this doesn't happen, but we
still process just the buffer bytes before the current end. If that end
is not on a wordsize boundary, e.g. on the builtin-clear-padding-5.c test
the last chunk is 2 bytes, '\0', '\xff', i is 16 and end is 18,
nonzero_last might be equal to the end - i, i.e. 2 here, but still all_ones
might be true, so in some spots we just didn't emit any clearing in that
last chunk.
2024-07-17 Jakub Jelinek <jakub@redhat.com>
PR middle-end/115527
* gimple-fold.cc (clear_padding_flush): Introduce endsize
variable and use it instead of wordsize when comparing it against
nonzero_last.
(clear_padding_type): Increment off by sz.
* c-c++-common/torture/builtin-clear-padding-1.c: Add dg-do run
directive.
* c-c++-common/torture/builtin-clear-padding-2.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-3.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-4.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-5.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-6.c: New test.
(cherry picked from commit 8b5919bae11754f4b65a17e63663d3143f9615ac)
C++26 is making in P2747R2 paper placement new constexpr.
While working on a patch for that, I've noticed we ICE starting with
GCC 14 on the following testcase.
The problem is that e.g. for the void * to sometype * casts checks,
we really assume the casts have their operand constant evaluated
as prvalue, but on the testcase the cast itself is evaluated with
vc_discard and that means op can end up e.g. a VAR_DECL which the
later code doesn't like and asserts on.
If the result type is void, we don't really need the cast operand
for anything, so can use vc_discard for the recursive call,
VIEW_CONVERT_EXPR can appear on the lhs, so we need to honor the
lval but otherwise the patch uses vc_prvalue.
I'd like to get this patch in before the rest of P2747R2 implementation,
so that it can be backported to 14.2 later on.
2024-07-02 Jakub Jelinek <jakub@redhat.com>
Jason Merrill <jason@redhat.com>
PR c++/115754
* constexpr.cc (cxx_eval_constant_expression) <case CONVERT_EXPR>:
For conversions to void, pass vc_discard to the recursive call
and otherwise for tcode other than VIEW_CONVERT_EXPR pass vc_prvalue.
* g++.dg/cpp26/pr115754.C: New test.
(cherry picked from commit 1250540a98e0a1dfa4d7834672d88d8543ea70b1)
Currently we discard the cond-op mask when the loop is fully masked
which causes wrong code in
gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
when compiled with
-O3 -march=cascadelake --param vect-partial-vector-usage=2.
This patch ANDs both masks.
gcc/ChangeLog:
PR tree-optimization/115382
* tree-vect-loop.cc (vectorize_fold_left_reduction): Use
prepare_vec_mask.
* tree-vect-stmts.cc (check_load_store_for_partial_vectors):
Remove static of prepare_vec_mask.
* tree-vectorizer.h (prepare_vec_mask): Export.
(cherry picked from commit 2b438a0d2aa80f051a09b245a58f643540d4004b)
The following adjusts mask recording which didn't take into account
that we can merge call arguments from two vectors like
_50 = {vect_d_1.253_41, vect_d_1.254_43};
_51 = VIEW_CONVERT_EXPR<unsigned char>(mask__19.257_49);
_52 = (unsigned int) _51;
_53 = _Z3bazd.simdclone.7 (_50, _52);
_54 = BIT_FIELD_REF <_53, 256, 0>;
_55 = BIT_FIELD_REF <_53, 256, 256>;
The testcase g++.dg/vect/pr68762-2.cc exercises this on x86_64 with
partial vector usage enabled and AVX512 support.
PR tree-optimization/115868
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Correctly
compute the number of mask copies required for vect_record_loop_mask.
(cherry picked from commit abf3964711f05b6858d9775c3595ec2b45483e14)
When importing modules, when a binding vector for a name runs out of
slots it gets reallocated with a larger size, and existing bindings are
copied across. However, the flags to indicate whether deduping needs to
occur did not: this causes ICEs, as it allows a duplicate binding to be
added which then violates assumptions later on.
PR c++/99242
gcc/cp/ChangeLog:
* name-lookup.cc (append_imported_binding_slot): Propagate dups
flags.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr99242_a.H: New test.
* g++.dg/modules/pr99242_b.H: New test.
* g++.dg/modules/pr99242_c.H: New test.
* g++.dg/modules/pr99242_d.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
(cherry picked from commit 1aa0f1627857c3e2d90982bdb07ca78ca10b26f3)
When emitting the compensation to the vectorized main loop for
a vector reduction value to be re-used in the vectorized epilogue
we fail to place it in the correct block when the main loop is
known to be entered (no loop_vinfo->main_loop_edge) but the
epilogue is not (a loop_vinfo->skip_this_loop_edge). The code
currently disregards this situation.
With the recent znver4 cost fix I couldn't trigger this situation
with the testcase but I adjusted it so it could eventually trigger
on other targets.
PR tree-optimization/115841
* tree-vect-loop.cc (vect_transform_cycle_phi): Correctly
place the partial vector reduction for the accumulator
re-use when the main loop cannot be skipped but the
epilogue can.
* gcc.dg/vect/pr115841.c: New testcase.
(cherry picked from commit 016c947b02e79a5c0c0c2d4ad5cb71aa04db3efd)
When AVX512 uses a fully masked loop and peeling we fail to create the
correct initial loop mask when the mask is composed of multiple
components in some cases. The following fixes this by properly applying
the bias for the component to the shift amount.
PR tree-optimization/115843
* tree-vect-loop-manip.cc
(vect_set_loop_condition_partial_vectors_avx512): Properly
bias the shift of the initial mask for alignment peeling.
* gcc.dg/vect/pr115843.c: New testcase.
(cherry picked from commit a177be05f6952c3f7e62186d2e138d96c475b81a)
The following restricts copying of points-to info from defs that
might be in regions invoking UB and are never executed.
PR tree-optimization/115701
* tree-ssanames.cc (maybe_duplicate_ssa_info_at_copy):
Only copy info from within the same BB.
* gcc.dg/torture/pr115701.c: New testcase.
(cherry picked from commit b77f17c5feec9614568bf2dee7f7d811465ee4a5)
The following factors out the code that preserves SSA info of the LHS
of a SSA copy LHS = RHS when LHS is about to be eliminated to RHS.
PR tree-optimization/115701
* tree-ssanames.h (maybe_duplicate_ssa_info_at_copy): Declare.
* tree-ssanames.cc (maybe_duplicate_ssa_info_at_copy): New
function, split out from ...
* tree-ssa-copy.cc (fini_copy_prop): ... here.
* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt): ...
and here.
(cherry picked from commit b5c64b413fd5bc03a1a8ef86d005892071e42cbe)
When only a loop mask is to be supplied for the inbranch arg to a
simd function we fail to handle integer mode masks correctly. We
need to guess the number of elements represented by it. This assumes
that excess arguments are all for masks, I wasn't able to create
a simdclone with more than one integer mode mask argument.
The gcc.dg/vect/vect-simd-clone-20.c exercises this with -mavx512vl
PR tree-optimization/115867
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Properly
guess the number of mask elements for integer mode masks.
(cherry picked from commit 4f4478f0f31263997bfdc4159f90e58dd79b38f9)
Currently unaligned YMM and ZMM load and store costs are cheaper than
aligned which causes the vectorizer to purposely mis-align accesses
by adding an alignment prologue. It looks like the unaligned costs
were simply copied from the bogus znver4 costs. The following makes
the unaligned costs equal to the aligned costs like in the fixed znver4
version.
* config/i386/x86-tune-costs.h (znver5_cost): Update unaligned
load and store cost from the aligned costs.
(cherry picked from commit 896393791ee34ffc176c87d232dfee735db3aaab)
Currently unaligned YMM and ZMM load and store costs are cheaper than
aligned which causes the vectorizer to purposely mis-align accesses
by adding an alignment prologue. It looks like the unaligned costs
were simply left untouched from znver3 where they equate the aligned
costs when tweaking aligned costs for znver4. The following makes
the unaligned costs equal to the aligned costs.
This avoids the miscompile seen in PR115843 but it's of course not
a real fix for the issue uncovered there. But it makes it qualify
as a regression fix.
PR tree-optimization/115843
* config/i386/x86-tune-costs.h (znver4_cost): Update unaligned
load and store cost from the aligned costs.
(cherry picked from commit 1e3aa9c9278db69d4bdb661a750a7268789188d6)
Before issuing loads or stores for a block move, adjust the MEM
alignments if analysis of the addresses enabled the inference of
stricter alignment. This ensures that the MEMs are sufficiently
aligned for the corresponding insns, which avoids trouble in case of
e.g. substitutions into SUBREGs.
for gcc/ChangeLog
PR target/115459
* config/alpha/alpha.cc (alpha_expand_block_move): Adjust
MEMs to match inferred alignment.
(cherry picked from commit ccfe7151803956d178947d0afda0bd66ce097275)
The set of enabled extensions can be extended via target arch function
attributes by listing each extension with a '+' prefix and a comma as
list separator. E.g.:
__attribute__((target("arch=+zba,+zbb"))) void foo();
The programmer intends to ensure that one or more extensions
are enabled when building the code. This is independent of the arch
string that is passed at build time via the -march= option.
Therefore, it is reasonable to allow enabling extensions via target arch
attributes, which have already been enabled via the -march= string.
The subset list code already supports such duplication for implied
extensions. This patch adds an interface so the subset list
parser can be switched into a mode where duplication is allowed.
This commit fixes the following regressed test cases:
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-39.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-42.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-43.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-44.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-45.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-46.c
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::add):
Allow adding enabled extension if m_allow_adding_dup is set.
* config/riscv/riscv-subset.h: Add m_allow_adding_dup and setter.
* config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch):
Allow adding enabled extensions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr115554.c: Change expected fail to expected pass.
* gcc.target/riscv/target-attr-16.c: New test.
(cherry picked from commit 61c21a719e205f70bd046c6a0275d1a3fd6341a4)
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
The target-arch attribute handling in RISC-V is only a few months old,
but already saw a rewrite (9941f0295a), which addressed an important
issue. This rewrite introduced a hash table in the backend, which is
used to keep track of target-arch attributes of all functions.
The index of this hash table is the pointer to the function declaration
object (fndecl). However, objects like these don't have the lifetime
that is assumed here, which resulted in observing two fndecl objects
with the same address for different objects (triggering the assertion
in riscv_func_target_put() -- see also PR115562).
This patch removes the hash table approach in favor of storing target
specific options using the DECL_FUNCTION_SPECIFIC_TARGET() macro, which
is also used by other backends and is specifically designed for this
purpose (https://gcc.gnu.org/onlinedocs/gccint/Function-Properties.html).
To have an accessible field in the target options, we need to
adjust riscv.opt and introduce the field riscv_arch_string
(for the already existing option '-march=').
Using this macro allows to remove much code from riscv-common.cc, which
controls access to the objects 'func_target_table' and 'current_subset_list'.
One thing to mention is, that we had two subset lists:
current_subset_list and cmdline_subset_list, with the latter being
introduced recently for target attribute handling.
This patch reduces them back to one (cmdline_subset_list) which
contains the list of extensions that have been enabled by the command
line arguments.
Note that the patch keeps the existing behavior of rejecting
duplications of extensions when added via the '+' operator in a function
target attribute. E.g. "-march=rv64gc_zbb" and "arch=+zbb" will trigger
an error (see pr115554.c). However, at the same time this patch breaks
the acceptance of adding implied extensions, which causes the following
six regressions (with the error "extension 'EXT' appear more than one time"):
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-39.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-42.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-43.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-44.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-45.c
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-46.c
New tests were added to document the behavior and to ensure it won't
regress. This patch did not show any regressions for rv32/rv64
and fixes the ICEs from PR115554 and PR115562.
PR target/115554
PR target/115562
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (struct riscv_func_target_info):
Remove.
(struct riscv_func_target_hasher): Likewise.
(riscv_func_decl_hash): Likewise.
(riscv_func_target_hasher::hash): Likewise.
(riscv_func_target_hasher::equal): Likewise.
(riscv_current_subset_list): Likewise.
(riscv_cmdline_subset_list): Remove obsolete space.
(riscv_func_target_table_lazy_init): Remove.
(riscv_func_target_get): Likewise.
(riscv_func_target_put): Likewise.
(riscv_func_target_remove_and_destory): Likewise.
(riscv_arch_str): Generate from cmdline_subset_list.
(riscv_set_arch_by_subset_list): Don't set current_subset_list.
(riscv_parse_arch_string): Remove current_subset_list.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins):
Get subset list via riscv_cmdline_subset_list().
* config/riscv/riscv-subset.h (riscv_current_subset_list):
Remove prototype.
(riscv_func_target_get): Likewise.
(riscv_func_target_put): Likewise.
(riscv_func_target_remove_and_destory): Likewise.
* config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch):
Build base arch string from existing target options, if any.
(riscv_target_attr_parser::update_settings): Store new arch
string in target options.
(riscv_process_one_target_attr): Whitespace fix.
(riscv_process_target_attr): Drop opts argument.
(riscv_option_valid_attribute_p): Properly save, change and restore
target options.
* config/riscv/riscv.cc (get_arch_str): New function.
(riscv_declare_function_name): Get arch string for option-arch
directive from function's target options.
* config/riscv/riscv.opt: Add riscv_arch_string variable to
march option.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/target-attr-01.c: Add test for option-arch directive.
* gcc.target/riscv/target-attr-02.c: Likewise.
* gcc.target/riscv/target-attr-03.c: Likewise.
* gcc.target/riscv/target-attr-04.c: Likewise.
* gcc.target/riscv/target-attr-05.c: Fix formatting.
* gcc.target/riscv/target-attr-06.c: Likewise.
* gcc.target/riscv/target-attr-07.c: Likewise.
* gcc.target/riscv/pr115554.c: New test.
* gcc.target/riscv/pr115562.c: New test.
* gcc.target/riscv/target-attr-08.c: New test.
* gcc.target/riscv/target-attr-09.c: New test.
* gcc.target/riscv/target-attr-10.c: New test.
* gcc.target/riscv/target-attr-11.c: New test.
* gcc.target/riscv/target-attr-12.c: New test.
* gcc.target/riscv/target-attr-13.c: New test.
* gcc.target/riscv/target-attr-14.c: New test.
* gcc.target/riscv/target-attr-15.c: New test.
(cherry picked from commit aa8e2de78cae4dca7f9b0efe0685f3382f9ecb9a)
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Function target attributes have to be separated by semi-colons.
Let's fix the comment and variable naming to better explain what
the code does.
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc (riscv_process_target_attr):
Fix comments and variable names.
(cherry picked from commit 5ef0b7d2048a7142174ee3e8e021fc1a9c3e3334)
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
