Thus, unless gfx803 is explicitly enabled, the following testcases will
fail to link as libgomp is not available for Fiji. Hence, this commit
xfails those testcases.
libgomp/ChangeLog:
* testsuite/libgomp.c/declare-variant-4-fiji.c: Xfail as fiji
support is no longer enabled by default.
* testsuite/libgomp.c/declare-variant-4-gfx803.c: Likewise.
The root cause is register_operand and reg_or_subregno are consistent so we reach the assertion fail.
We shouldn't worry about subreg:...VL_REGNUM since it's impossible that we can have such situation,
that is, we only have (set (reg) (reg:VL_REGNUM)) which generate "csrr vl" ASM for first fault load instructions (vleff).
So, using REG_P and REGNO must be totally solid and robostic.
Since we don't allow VL_RENUM involved into register allocation and we don't have such constraint, we always use this
following pattern to generate "csrr vl" ASM:
With debugging enabled, '*.mkoffload.dbg.o' files are generated. The e_flags
header of all *.o files must be the same - otherwise, the linker complains.
Since r14-4734-g56ed1055b2f40ac162ae8d382280ac07a33f789f the -march= default
is now gfx900. If compiling without any -march= flag, the default value is
used by the compiler but not passed to mkoffload. Hence, mkoffload.cc's uses
its own default for march - unfortunately, it still had gfx803/fiji as default,
leading to the linker error: 'incompatible mach'. Solution: Update the
default to gfx900.
While debugging it, I saw that /tmp/cc*.mkoffload.dbg.o kept accumulating;
there were a couple of issues with the handling:
* dbgobj was always added to files_to_cleanup
* If copy_early_debug_info returned true, dbgobj was added again
-> pointless and in theory a race if the same file was added in the
faction of a second.
* If copy_early_debug_info returned false,
- In exactly one case, it already deleted the file it self
(same potential race as above)
- The pointer dbgobj was freed - such that files_to_cleanup contained
a dangling pointer - probably the reason that stale files remained.
Solution: Only if copy_early_debug_info returns true, dbgobj is added to
files_to_cleanup. If it returns false, the file is unlinked before freeing
the pointer.
When compiling, GCC warned about several fatal_error messages as having
no %<...%> or %qs quotes. This patch now silences several of those warnings
by using those quotes.
gcc/ChangeLog:
PR other/111966
* config/gcn/mkoffload.cc (elf_arch): Change default to gfx900
to match the compiler default.
(simple_object_copy_lto_debug_sections): Never unlink the outfile
on error as the caller does so.
(maybe_unlink, compile_native): Use %<...%> and %qs in fatal_error.
(main): Likewise. Fix 'mkoffload.dbg.o' cleanup.
Richard Biener [Fri, 19 Jan 2024 12:55:09 +0000 (13:55 +0100)]
tree-optimization/113373 - add missing LC PHIs for live operations
The following makes reduction epilogue code generation happy by properly
adding LC PHIs to the exit blocks for multiple exit vectorized loops.
Some refactoring might make the flow easier to follow but I've refrained
from doing that with this patch.
I've kept some fixes in reduction epilogue generation from the earlier
attempt fixing this PR.
PR tree-optimization/113373
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Create LC PHIs in the exit blocks where necessary.
* tree-vect-loop.cc (vectorizable_live_operation): Do not try
to handle missing LC PHIs.
(find_connected_edge): Remove.
(vect_create_epilog_for_reduction): Cleanup use of auto_vec.
* gcc.dg/vect/vect-early-break_104-pr113373.c: New testcase.
Juzhe-Zhong [Mon, 22 Jan 2024 02:49:05 +0000 (10:49 +0800)]
RISC-V: Fix vfirst/vmsbf/vmsif/vmsof ratio attributes
vfirst/vmsbf/vmsif/vmsof instructions are supposed to demand ratio instead of demanding sew_lmul.
But my previous typo makes VSETVL PASS miss honor the risc-v v spec.
Consider this following simple case:
int foo4 (void * in, void * out)
{
vint32m1_t v = __riscv_vle32_v_i32m1 (in, 4);
v = __riscv_vadd_vv_i32m1 (v, v, 4);
vbool32_t mask = __riscv_vreinterpret_v_i32m1_b32(v);
mask = __riscv_vmsof_m_b32(mask, 4);
return __riscv_vfirst_m_b32(mask, 4);
}
xuli [Mon, 22 Jan 2024 06:41:49 +0000 (06:41 +0000)]
RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]
v2:
Avoid internal ICE for the case below.
vint8mf8_t test_vle8_v_i8mf8_m(vbool64_t vm, const int32_t *rs1, size_t vl) {
return __riscv_vle8(vm, rs1, vl);
}
v1:
Change the hash value of overloaded intrinsic from considering
all parameter types to:
1. Encoding vector data type
2. In order to distinguish vle8_v_i8mf8_m(vbool64_t vm, const int8_t *rs1, size_t vl)
and vle8_v_u8mf8_m(vbool64_t vm, const uint8_t *rs1, size_t vl), encode the pointer type
3. In order to distinguish vfadd_vv_f32mf2_rm(vfloat32mf2_t vs2, vfloat32mf2_t vs1, size_t vl)
and vfadd_vv_f32mf2(vfloat32mf2_t vs2, vfloat32mf2_t vs1, size_t vl), encode the number of
parameters. The same goes for the vxrm intrinsics.
Jeff Law [Mon, 22 Jan 2024 02:12:21 +0000 (19:12 -0700)]
[committed] Adjust expectations for pr59533-1.c
The change for pr111267 twiddled code generation for sh/pr59533-1.c
We end up eliminating two comparisons, but require two shll instructions to do
so. And in a couple places we're using an addc sequence rather than a subc
sequence. This patch adjusts the expected codegen for the test as all those
are either a wash or a
The fwprop change does cause some code regressions on the same test. I'll file
a distinct but for that issue.
Re: [PATCH] Avoid ICE with m68k-elf -malign-int and libcalls
>> emit_library_call_value_1 calls emit_push_insn with NULL_TREE
>> for TYPE. Sometimes emit_push_insn needs to assign a temp with
>> that TYPE, which causes a segfault.
>>
>> Fixed by computing the TYPE from MODE when needed.
>>
>> Original patch by Thorsten Otto.
>>
[ ... ]
> This really needs to happen in the two call paths which pass in
> NULL_TREE for the type. Note how the type is used to determine padding
> earlier in emit_push_insn. That would also make the code more
> consistent with the comment before emit_push_insn which implies that
> both MODE and TYPE are valid.
>
>
> Additionally you should bootstrap and regression test this patch on at
> least one target.
Updated as requested, and bootstrapped and tested on
{x86_64,aarch64,m68k}-linux-gnu without regressions.
gcc/
PR target/82420
PR target/111279
* calls.cc (emit_library_call_value_1): Pass valid TYPE
to emit_push_insn.
* expr.cc (emit_push_insn): Likewise.
gcc/testsuite/
PR target/82420
* gcc.target/m68k/pr82420.c: New test.
Jeff Law [Sun, 21 Jan 2024 22:41:38 +0000 (15:41 -0700)]
[committed] [NFC] Fix riscv_init_cumulative_args for unused arguments
The signature was still using ATTRIBUTE_UNUSED and actually marked one
of the used arguments with ATTRIBUTE_UNUSED.
This patch drops the decorations and instead remove the name of arguments
which are actually unused which is the preferred way to handle this now
when we can.
Bootstrapped. I didn't have test results on the platform where I
bootstrapped, so no results to compare against. Given its NFC, I
think we're OK without the regression results.
gcc/
* config/riscv/riscv.cc (riscv_init_cumulative_args): Update and
fix bugs in signature.
Jonathan Wakely [Sun, 21 Jan 2024 18:16:14 +0000 (18:16 +0000)]
libstdc++: Fix std::format for floating-point chrono::time_point [PR113500]
Currently trying to use std::format with certain specializations of
std::chrono::time_point is ill-formed, due to one member function of the
__formatter_chrono type which tries to write a time_point to an ostream.
For sys_time<floating-point> or sys_time with a period greater than days
there is no operator<< that can be used.
That operator<< is only needed when using an empty chrono-specs in the
format string, like "{}", but the ill-formed expression gives an error
even if not actually used. This means it's not possible to format some
other specializations of chrono::time_point, even when using a non-empty
chrono-specs.
This fixes it by avoiding using 'os << t' for all chrono::time_point
specializations, and instead using std::format("{:L%F %T}", t). So that
we continue to reject std::format("{}", sys_time{1.0s}) a check for
empty chrono-specs is added to the formatter<sys_time<D>, C>
specialization.
While testing this I noticed that the output for %S with a
floating-point duration was incorrect, as the subseconds part was being
appended to the seconds without a decimal point, and without the correct
number of leading zeros.
libstdc++-v3/ChangeLog:
PR libstdc++/113500
* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix
printing of subseconds with floating-point rep.
(__formatter_chrono::_M_format_to_ostream): Do not write
time_point specializations directly to the ostream.
(formatter<chrono::sys_time<D>, C>::parse): Do not allow an
empty chrono-spec if the type fails to meet the constraints for
writing to an ostream with operator<<.
* testsuite/std/time/clock/file/io.cc: Check formatting
non-integral times with empty chrono-specs.
* testsuite/std/time/clock/gps/io.cc: Likewise.
* testsuite/std/time/clock/utc/io.cc: Likewise.
* testsuite/std/time/hh_mm_ss/io.cc: Likewise.
Jonathan Wakely [Sun, 21 Jan 2024 18:11:16 +0000 (18:11 +0000)]
libstdc++: Fix std::chrono::file_clock conversions for low-precision times
THe std::chrono::file_clock conversions were not using common_type and
so failed to compile when converting anything that should have increased
precision after arithmetic with a std::chrono::seconds value.
libstdc++-v3/ChangeLog:
* include/bits/chrono.h (__file_clock::from_sys)
(__file_clock::to_sys, __file_clock::_S_from_sys)
(__file_clock::_S_to_sys): Use common_type for return type.
* testsuite/std/time/clock/file/members.cc: Check round trip
conversion for time with lower precision that seconds.
This patch resolves PR rtl-optimization/111267 by improving RTL-level
forward propagation. This x86_64 code quality regression was caused
(exposed) by my changes to improve how x86's (TImode) argument passing
is represented at the RTL-level (reducing the use of SUBREGs to catch
more optimization opportunities in combine). The pitfall is that the
more complex RTL representations expose a limitation in RTL's fwprop
pass.
At the heart of fwprop, in try_fwprop_subst_pattern, the logic can
be summarized as three steps. Step 1 is a heuristic that rejects the
propagation attempt if the expression is too complex, step 2 calls
the backend's recog to see if the propagated/simplified instruction
is recognizable/valid, and step 3 then calls set_src_cost to compare
the rtx costs of the replacement vs. the original, and accepts the
transformation if the final cost is the same of better.
The logic error (or missed optimization opportunity) is that the
step 1 heuristic that attempts to predict (second guess) the
process is flawed. Ultimately the decision on whether to fwprop
or not should depend solely on actual improvement, as measured
by RTX costs. Hence the prototype fix in the bugzilla PR removes
the heuristic of calling prop.profitable_p entirely, relying
entirely on the cost comparison in step 3.
Unfortunately, things are a tiny bit more complicated. The cost
comparison in fwprop uses the older set_src_cost API and not the
newer (preffered) insn_cost API as currently used in combine.
This means that the cost improvement comparisons are only done
for single_set instructions (more complex PARALLELs etc. aren't
supported). Hence we can only rely on skipping step 1 for that
subset of instructions actually evaluated by step 3.
The other subtlety is that to avoid potential infinite loops
in fwprop we should only reply purely on rtx costs when the
transformation is obviously an improvement. If the replacement
has the same cost as the original, we can use the prop.profitable_p
test to preserve the current behavior.
Finally, to answer Richard Biener's remaining question about this
approach: yes, there is an asymmetry between how patterns are
handled and how REG_EQUAL notes are handled. For example, at
the moment propagation into notes doesn't use rtx costs at all,
and ultimately when fwprop is updated to use insn_cost, this
(and recog) obviously isn't applicable to notes. There's no reason
the logic need be identical between patterns and notes, and during
stage4 we only need update propagation into patterns to fix this
P1 regression (notes and use of cost_insn can be done for GCC 15).
For Jakub's reduced testcase:
struct S { float a, b, c, d; };
int bar (struct S x, struct S y) {
return x.b <= y.d && x.c >= y.a;
}
On x86_64-pc-linux-gnu with -O2 gcc currently generates:
with this simple patch to fwprop, we now generate:
bar: shufps $85, %xmm0, %xmm0
shufps $85, %xmm3, %xmm3
comiss %xmm0, %xmm3
jb .L6
xorl %eax, %eax
comiss %xmm2, %xmm1
setnb %al
ret
.L6: xorl %eax, %eax
ret
2024-01-21 Roger Sayle <roger@nextmovesoftware.com>
Richard Biener <rguenther@suse.de>
gcc/ChangeLog
PR rtl-optimization/111267
* fwprop.cc (fwprop_propagation::profitabe_p): Rename
profitable_p method to likely_profitable_p.
(try_fwprop_subst_node): Update call to likely_profitable_p.
Only bail-out early when !prop.likely_profitable_p for instructions
that are not single sets. When comparing costs, bail-out if the
cost is unchanged and !prop.likely_profitable_p.
gcc/testsuite/ChangeLog
PR rtl-optimization/111267
* gcc.target/i386/pr111267.c: New test case.
Sandra Loosemore [Sun, 21 Jan 2024 20:42:59 +0000 (20:42 +0000)]
Make the manual clearer about what options -Wunused enables [PR90464]
gcc/ChangeLog
PR c++/90464
* doc/invoke.texi (Warning Options): Document that -Wunused-parameter
isn't enabled by -Wunused unless -Wextra is provided, and that
-Wunused does enable -Wunused-const-variable=1 for C. Clarify that
-Wunused doesn't enable -Wunused-* options documented as behaving
otherwise, and list them explicitly.
Martin Uecker [Sat, 20 Jan 2024 18:03:57 +0000 (19:03 +0100)]
C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
This patch fixes a bug when forming a composite type from structs that
contain an unsigned bitfield declared with int while using -funsigned-bitfields.
In such structs the unsigned integer type was not compatible to the
regular unsigned integer type used elsewhere in the C FE.
PR c/113492
gcc/c:
* c-decl.cc (grokdeclarator): Use c_common_unsigned_type instead of
unsigned_type_for to create the unsigned type for bitfields declared
with int when using -funsigned-bitfields.
Jonathan Wakely [Sat, 20 Jan 2024 00:44:12 +0000 (00:44 +0000)]
libstdc++: Fix std::format floating-point alternate forms [PR113512]
The logic for handling '#' forms was ... not good. The count of
significant figures just counted digits, instead of ignoring leading
zeros. And when moving the result from the stack buffer to a dynamic
string the exponent could get lost in some cases.
libstdc++-v3/ChangeLog:
PR libstdc++/113512
* include/std/format (__formatter_fp::format): Fix logic for
alternate forms.
* testsuite/std/format/functions/format.cc: Check buggy cases of
alternate forms with g presentation type.
Sandra Loosemore [Sun, 21 Jan 2024 02:36:19 +0000 (02:36 +0000)]
Clean up examples for -Wdangling-pointer [PR109708]
gcc/ChangeLog
PR c/109708
* doc/invoke.texi (Warning Options): Fix broken example and
clean up/reorganize the others. Also describe what the short-form
options mean.
Marek Polacek [Fri, 19 Jan 2024 20:27:51 +0000 (15:27 -0500)]
libstdc++: suppress -Wdangling-reference with operator| [PR111410]
It seems to me that we should exclude std::ranges::views::__adaptor::operator|
from the -Wdangling-reference warning. It's commonly used when handling
ranges.
PR c++/111410
libstdc++-v3/ChangeLog:
* include/std/ranges: Add #pragma to disable -Wdangling-reference with
std::ranges::views::__adaptor::operator|.
Andrew Pinski [Sat, 20 Jan 2024 19:39:11 +0000 (11:39 -0800)]
ipa: Add testcase for already fixed case [PR110705]
This testcase was fixed with r13-1695-gb0f02eeb906b63 which
added an Ada testcase for the issue but adding a C testcase
is a good idea and that is what this does.
Committed after making sure it passes on x86_64-linux-gnu.
PR ipa/110705
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr110705-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Mikael Morin [Fri, 19 Jan 2024 17:47:36 +0000 (18:47 +0100)]
fortran: Restore current interface info on error [PR111291]
This change is a followup to the fix for PR48776 (namely r14-3572-gd58150452976c4ca65ddc811fac78ef956fa96b0 AKA
fortran: Restore interface to its previous state on error [PR48776]),
which cleaned up new changes from interfaces upon error.
Unfortunately, there is one case in that fix that is mishandled, visible
on unexpected_interface.f90 with valgrind or an asan-instrumented gfortran.
when an interface statement is found while parsing an interface body (which
is invalid), the current interface is replaced by the one from the new
statement, and as parsing continues, new procedures are added
to the new interface, which has been rejected and freed, instead of the
original one.
This change restores the current interface pointer to its previous value
on each rejected statement.
PR fortran/48776
PR fortran/111291
gcc/fortran/ChangeLog:
* parse.cc: Restore current interface to its previous value on error.
Sandra Loosemore [Sat, 20 Jan 2024 14:30:17 +0000 (14:30 +0000)]
Correct documentation for -Warray-parameter [PR102998]
gcc/ChangeLog
PR c/102998
* doc/invoke.texi (Option Summary): Add -Warray-parameter.
(Warning Options): Correct/edit discussion of -Warray-parameter
to make the first example less confusing, and fill in missing info.
Jakub Jelinek [Sat, 20 Jan 2024 11:36:32 +0000 (12:36 +0100)]
lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
The following patch ICEs because fre3 leaves around unfolded
_1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
statement and in handle_cast I was expecting just SSA_NAMEs for the
large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
we can handle in that case exactly the same, as the handle_operand recursion
handles those.
Of course, maybe we should also try to fold_stmt such cases somewhere in
bitint lowering preparation.
2024-01-20 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113462
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
Handle rhs1 INTEGER_CST like SSA_NAME.
Jakub Jelinek [Sat, 20 Jan 2024 11:35:38 +0000 (12:35 +0100)]
tree-switch-conversion: Bugfixes for _BitInt [PR113491]
The following patch fixes various issues with large/huge _BitInt used as switch
expressions.
In particular:
1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than
sizetype precision, varasm uses wi::to_offset on those and too large
indexes ICE; we've already checked earlier that the cluster is at most
sizetype bits and arrays can't be larger than that anyway
2) some spots were using SCALAR_INT_TYPE_MODE or
lang_hooks.types.type_for_mode on TYPE_MODE to determine types to use,
that obviously doesn't work for the large/huge BITINT_TYPE
3) like the recent change in the C FE, this patch makes sure we don't create
ARRAY_REFs with indexes with precision above sizetype precision, because
bitint lowering isn't prepared for that and because the indexes can't be
larger than sizetype anyway; the subtraction of the cluster minimum from
the index obviously needs to be done in unsigned __int128 or large/huge
BITINT_TYPE, but then we cast to sizetype if the precision is larger than
sizetype
2024-01-20 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113491
* tree-switch-conversion.cc (switch_conversion::build_constructors):
If elt.index has precision higher than sizetype, fold_convert it to
sizetype.
(switch_conversion::array_value_type): Return type if type is
BITINT_TYPE with precision above MAX_FIXED_MODE_SIZE or with BLKmode.
(switch_conversion::build_arrays): Use unsigned_type_for rather than
lang_hooks.types.type_for_mode if utype is BITINT_TYPE with precision
above MAX_FIXED_MODE_SIZE or with BLKmode. If utype has precision
higher than sizetype, use sizetype as tidx type and fold_convert the
subtraction to sizetype.
[PATCH] Avoid ICE on m68k -fzero-call-used-regs -fpic [PR110934]
PR110934 is a problem on m68k where -fzero-call-used-regs -fpic ICEs
when clearing an FP register.
The generic code generates an XFmode move of zero to that register,
which becomes an XFmode load from initialized data, which due to -fpic
uses a non-constant address, which the backend rejects. The
zero-call-used-regs pass runs very late, after register allocation and
frame layout, and at that point we can't allow new uses of the PIC
register or new pseudos.
To clear an FP register on m68k it's enough to do the move in SFmode,
but the generic code can't be told to do that, so this patch updates
m68k to use its own TARGET_ZERO_CALL_USED_REGS.
Bootstrapped and regression tested on m68k-linux-gnu.
Ok for master? (I don't have commit rights.)
gcc/
PR target/110934
* config/m68k/m68k.cc (m68k_zero_call_used_regs): New function.
(TARGET_ZERO_CALL_USED_REGS): Define.
gcc/testsuite/
PR target/110934
* gcc.target/m68k/pr110934.c: New test.
[PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]
When generating RMW logical operations on m68k, the backend
recognizes single-bit operations and rewrites them as bit
instructions on operands adjusted to address the intended byte.
When offsetting the addresses the backend keeps the modes as
SImode, even though the actual access will be in QImode.
The uclinux target defines M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
which adds a check that the adjusted operand is within the bounds
of the original object. Since the address has been offset it is
not, and the compiler ICEs.
The bug is that the modes of the adjusted operands should have been
narrowed to QImode, which is that this patch does. Nearby code
which narrows to HImode gets that right.
Bootstrapped and regression tested on m68k-linux-gnu.
Ok for master? (Note: I don't have commit rights.)
gcc/
PR target/108640
* config/m68k/m68k.cc (output_andsi3): Use QImode for
address adjusted for 1-byte RMW access.
(output_iorsi3): Likewise.
(output_xorsi3): Likewise.
gcc/testsuite/
PR target/108640
* gcc.target/m68k/pr108640.c: New test.
Harald Anlauf [Fri, 19 Jan 2024 20:20:44 +0000 (21:20 +0100)]
Fortran: fix wrong array bounds check [PR113471]
gcc/fortran/ChangeLog:
PR fortran/113471
* trans-array.cc (array_bound_check_elemental): Array bounds check
shall apply here to elemental dimensions of an array section only.
gcc/testsuite/ChangeLog:
PR fortran/113471
* gfortran.dg/bounds_check_24.f90: New test.
Jonathan Wakely [Fri, 19 Jan 2024 12:28:30 +0000 (12:28 +0000)]
libstdc++: Fix P2255R2 dangling checks for std::tuple in C++17 [PR108822]
I accidentally used && in a fold-expression instead of || which meant
that in C++17 the tuple(UElements&&...) constructor only failed its
debug assertion if all tuple elements were dangling references. Some
missing tests (noted as "TODO") meant this wasn't tested.
This fixes the fold expression and adds the missing tests.
libstdc++-v3/ChangeLog:
PR libstdc++/108822
* include/std/tuple (__glibcxx_no_dangling_refs) [C++17]: Fix
wrong fold-operator.
* testsuite/20_util/tuple/dangling_ref.cc: Check tuples with one
element and three elements. Check allocator-extended
constructors.
Jason Merrill [Wed, 17 Jan 2024 22:29:33 +0000 (17:29 -0500)]
c++: alias template argument conversion [PR112632]
We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into them in a way that we don't for other templates. And fixing
that specific problem is a lot simpler than adding IMPLICIT_CONV_EXPR around
all dependent template arguments the way I gave up on for 111357.
The other part of the fix was changing tsubst_expr to actually call
convert_nontype_argument instead of assuming it will eventually happen.
I waffled about stripping the forced conversion when !force_conv
vs. skipping them in iterative_hash_template_arg and
template_args_equal (like we already do for some other conversions) and
decided to go with the former, but that isn't a strong preference if it
turns out to be somehow problematic.
* g++.dg/cpp0x/alias-decl-nontype1.C: New test.
* g++.dg/cpp2a/concepts-narrowing1.C: New test.
* g++.dg/cpp2a/nontype-class63.C: New test.
* g++.dg/cpp2a/nontype-class63a.C: New test.
This patch removes unused parameters and local variables from
M2GenGCC.mod. It required ForeachScopeBlockDo2 to be implemented and
exported affecting any module indirectly calling ConvertQuadsToTree.
gcc/m2/ChangeLog:
* gm2-compiler/M2BasicBlock.mod (InitBasicBlocks): Rename
ForeachScopeBlockDo to ForeachScopeBlockDo3.
* gm2-compiler/M2Code.mod: Import ForeachScopeBlockDo2.
(OptimizeScopeBlock): Call ForeachScopeBlockDo3 for
procedures with three parameters and ForeachScopeBlockDo2
for two parameters.
(CodeBlock): Ditto.
* gm2-compiler/M2GCCDeclare.mod (DeclareTypesConstantsProcedures):
Rename ForeachScopeBlockDo to ForeachScopeBlockDo3.
* gm2-compiler/M2GenGCC.def (ConvertQuadsToTree): Remove Scope
parameter.
* gm2-compiler/M2GenGCC.mod (ConvertQuadsToTree): Remove Scope
parameter.
(MaybeDebugBuiltinMemcpy): Remove parameter tok.
(MaybeDebugBuiltinMemset): Remove.
(MakeCopyUse): Remove tokenno from call to
MaybeDebugBuiltinMemcpy.
(PerformFoldBecomes): Remove desloc and exprloc.
(checkArrayElements): Remove location. Remove virtpos
as a parameter to MaybeDebugBuiltinMemcpy.
(NoWalkProcedure): Add attribute unused.
(CheckElementSetTypes): Remove parameter p.
Remove CurrentQuadToken in call to MaybeDebugBuiltinMemcpy.
Remove NoWalkProcedure from call to CheckElementSetTypes.
Remove tokenno from call to MaybeDebugBuiltinMemcpy.
* gm2-compiler/M2Optimize.mod (RemoveProcedures): Replace
two parameter indirect procedure iterator with
ForeachScopeBlockDo2.
* gm2-compiler/M2SSA.mod: Remove ForeachScopeBlockDo.
* gm2-compiler/M2Scope.def (ForeachScopeBlockDo2): New
declaration.
(ForeachScopeBlockDo): Rename ...
(ForeachScopeBlockDo3): ... to this.
(ScopeProcedure2): New declaration.
* gm2-compiler/M2Scope.mod (ForeachScopeBlockDo2): New
procedure.
(ForeachScopeBlockDo): Rename ...
(ForeachScopeBlockDo3): ... to this.
Kito Cheng [Mon, 8 Jan 2024 13:26:52 +0000 (21:26 +0800)]
RISC-V: Documnet the list of supported extensions
Try to list all supported extensions: name, version and few description
for each extension.
v2 changes:
- Fix several typo.
- Add expantion info for vector crypto extensions.
- Drop zvl8192b, zvl16384b, zvl32768b and zvl65536b.
- Aadd zicntr and zihpm
gcc/ChangeLog:
* doc/invoke.texi (RISC-V Options): Add list of supported
extensions.
Juzhe-Zhong [Fri, 19 Jan 2024 08:34:25 +0000 (16:34 +0800)]
RISC-V: Fix RVV_VLMAX
This patch fixes memory hog found in SPEC2017 wrf benchmark which caused by
RVV_VLMAX since RVV_VLMAX generate brand new rtx by gen_rtx_REG (Pmode, X0_REGNUM)
every time we call RVV_VLMAX, that is, we are always generating garbage and redundant
(reg:DI 0 zero) rtx.
After this patch fix, the memory hog is gone.
Time variable usr sys wall GGC
machine dep reorg : 1.99 ( 9%) 0.35 ( 56%) 2.33 ( 10%) 939M ( 80%) [Before this patch]
machine dep reorg : 1.71 ( 6%) 0.16 ( 27%) 3.77 ( 6%) 659k ( 0%) [After this patch]
Time variable usr sys wall GGC
machine dep reorg : 75.93 ( 18%) 14.23 ( 88%) 90.15 ( 21%) 33383M ( 95%) [Before this patch]
machine dep reorg : 56.00 ( 14%) 7.92 ( 77%) 63.93 ( 15%) 4361k ( 0%) [After this patch]
Test is running. Ok for trunk if I passed the test with no regresion ?
Richard Biener [Fri, 19 Jan 2024 08:50:43 +0000 (09:50 +0100)]
debug/113488 - DW_AT_abstract_origin to self
The new sanity check avoiding creating of DIE refs to self triggers
on the PRs testcase when using -g1 and -ffat-lto-objects as while
early DWARF with -g1 doesn't contain any DIEs for LABEL_DECLs later
cloning will still mark DECLs as in if they would via
dwarf2out_abstract_function calling set_block_origin_self.
Instead of messing with the delicate setup of dwarf2out at this stage
the following simply rectifies things after the fact during LTO
streaming when the decl indicates there's an early DIE but there
isn't fixup that indication.
PR debug/113488
* lto-streamer-in.cc (lto_read_tree_1): When there isn't
an early DIE but there should be, do not pretend there is.
Richard Biener [Fri, 19 Jan 2024 08:23:48 +0000 (09:23 +0100)]
tree-optimization/113494 - Fix two observed regressions with r14-8206
The following handles the situation where we lack a loop-closed
PHI for a virtual operand because a loop exit goes to a code
region not having any virtual use (an endless loop). It also
handles the situation of edge redirection re-allocating a PHI node
in the destination block so we have to re-lookup that before
populating the new PHI argument.
Daniel Cederman [Tue, 16 Jan 2024 13:57:15 +0000 (14:57 +0100)]
libsanitizer: Replace memcpy with internal version in sanitizer_common
When GCC is configured with --enable-target-optspace the compiler generates
a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
when compiling for SPARC V8. Add HAVE_AS_SYM_ASSIGN to replace it with a
call to __sanitizer_internal_memcpy.
Jakub Jelinek [Fri, 19 Jan 2024 09:01:43 +0000 (10:01 +0100)]
lower-bitint: Don't use m_loads for loads used in GIMPLE_ASM [PR113464]
Like for GIMPLE_PHIs or calls, even for GIMPLE_ASMs we want
a corresponding VAR_DECL assigned for lhs SSA_NAMEs of loads
from memory, as even GIMPLE_ASM relies on those VAR_DECLs to exist.
2024-01-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113464
* gimple-lower-bitint.cc (gimple_lower_bitint): Don't try to
optimize loads into GIMPLE_ASM stmts.
Jakub Jelinek [Fri, 19 Jan 2024 09:00:51 +0000 (10:00 +0100)]
gimple-ssa-warn-restrict: Only use type range from NOP_EXPR for non-narrowing conversions [PR113463]
builtin_memref::extend_offset_range when it sees a NOP_EXPR from
INTEGRAL_TYPE (to INTEGRAL_TYPE of sizetype/ptrdifftype precision
given the callers) uses wi::to_offset on TYPE_{MIN,MAX}_VALUE
of the rhs1 type. This ICEs with large BITINT_TYPEs - to_offset
is only supported for precisions up to the offset_int precision
- but it even doesn't make any sense to do such thing for narrowing
conversions, their range means the whole sizetype/ptrdifftype range
and so the normal handling done later on (largest sized supported object)
is the way to go in that case.
So, the following patch just restrict this to non-narrowing conversions.
2024-01-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113463
* gimple-ssa-warn-restrict.cc (builtin_memref::extend_offset_range):
Only look through NOP_EXPRs if rhs1 doesn't have wider type than
lhs.
Jakub Jelinek [Fri, 19 Jan 2024 09:00:16 +0000 (10:00 +0100)]
sccvn: Don't use SCALAR_INT_TYPE_MODE on BLKmode BITINT_TYPEs [PR113459]
sccvn uses GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (type)) for INTEGER_TYPEs,
most likely because that is what native_{interpret,encode}_int used.
This obviously doesn't work for larger BITINT_TYPEs which have BLKmode
and the above ICEs on those. native_{interpret,encode}_int checks whether
the BITINT_TYPE is medium/large/huge (i.e. an array of 2+ ABI limbs)
and uses TYPE_SIZE_UNIT for that case, otherwise SCALAR_INT_TYPE_MODE like
for the INTEGER_TYPE case.
The following patch instead just uses SCALAR_INT_TYPE_MODE for non-BLKmode
TYPE_MODE and TYPE_SIZE_UNIT otherwise.
2024-01-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113459
* tree-ssa-sccvn.cc (vn_walk_cb_data::push_partial_def): Use
TREE_INT_CST_LOW of TYPE_SIZE_UNIT rather than GET_MODE_SIZE
of SCALAR_INT_TYPE_MODE if type has BLKmode.
(vn_reference_lookup_3): Likewise. Formatting fix.
Jakub Jelinek [Fri, 19 Jan 2024 08:31:42 +0000 (09:31 +0100)]
expansion: Fix ICEs with BLKmode VIEW_CONVERT_EXPR around non-BLKmode VAR_DECLs
On aarch64 the backend decides to use non-BLKmode for some arrays
like unsigned long[4] - OImode in that case, but the corresponding
BITINT_TYPEs have BLKmode (like structures containing that many limb
elements).
This later causes ICEs durring expansion when expanding VIEW_CONVERT_EXPR
from non-BLKmode VAR_DECL to BLKmode BITINT_TYPE.
The following fix contains two parts, the discover_nonconstant_array_refs_r
is make sure we force such variables into memory and the expand_expr_real_1
change makes sure we don't try to extract a bitfield or something similar
which doesn't really work for BLKmode - as op0 is a MEM, all we need is
the op0 = adjust_address (op0, mode, 0); at the end to change the MEM's mode
to BLKmode.
2024-01-19 Jakub Jelinek <jakub@redhat.com>
Richard Biener <rguenther@suse.de>
* cfgexpand.cc (discover_nonconstant_array_refs_r): Force non-BLKmode
VAR_DECLs referenced in BLKmode VIEW_CONVERT_EXPRs into memory.
* expr.cc (expand_expr_real_1) <case VIEW_CONVERT_EXPR>: Do nothing
but adjust_address also for BLKmode mode and MEM op0.
Palmer Dabbelt [Wed, 9 Nov 2022 03:00:36 +0000 (19:00 -0800)]
RISC-V: Add the Zihpm and Zicntr extensions
These extensions were recently frozen [1]. As per Andrew's post [2]
we're meant to ignore these in software, this just adds them to the list
of allowed extensions and otherwise ignores them. I added these under
SPEC_CLASS_NONE even though the PDF lists them as 20190614 because it
seems pointless to add another spec class just to accept two extensions
we then ignore.
Kito Cheng [Fri, 5 Jan 2024 14:08:34 +0000 (22:08 +0800)]
RISC-V: Relax the -march string for accept any order
-march was require canonical order before, however it's not easy for
most user when we have so many extension, so this patch is relax the
constraint, -march accept the ISA string in any order, it only has few
requirement:
1. Must start with rv[32|64][e|i|g].
2. Multi-letter and single letter extension must be separated by
at least one underscore(`_`).
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_single_std_ext): New parameter.
(riscv_subset_list::parse_single_multiletter_ext): Ditto.
(riscv_subset_list::parse_single_ext): Ditto.
(riscv_subset_list::parse): Relax the order for the input of ISA
string.
* config/riscv/riscv-subset.h
(riscv_subset_list::parse_single_std_ext): New parameter.
(riscv_subset_list::parse_single_multiletter_ext): Ditto.
(riscv_subset_list::parse_single_ext): Ditto.
Kito Cheng [Fri, 5 Jan 2024 13:33:35 +0000 (21:33 +0800)]
RISC-V: Extract part parsing base ISA logic into a standalone function [NFC]
Minor refactor, preparation for further change.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_base_ext): New.
(riscv_subset_list::parse): Extract part of logic into
riscv_subset_list::parse_base_ext.
* config/riscv/riscv-subset.h (riscv_subset_list::parse_base_ext):
New.
liuhongt [Fri, 19 Jan 2024 01:22:39 +0000 (09:22 +0800)]
Fix testcase failure on many platforms which don't support vect_int_max.
After r14-7124-g6686e16fda4190, the testcase can be optimized to
MAX_EXPR if the backends support that. So I adjust the testcase to
scan for MAX_EXPR, but it failed many platforms which don't support
that.
As pinski mentioned, target vect_no_int_min_max is only available
under vect directory, so for simplicity, I adjust the testcase to scan
either MAX_EXPR or original VEC_COND_EXPR.
gcc/testsuite/ChangeLog:
PR testsuite/113437
* gcc.dg/tree-ssa/pr95906.c: Scan either MAX_EXPR or
VEC_COND_EXPR.
Sandra Loosemore [Fri, 19 Jan 2024 02:06:55 +0000 (02:06 +0000)]
More precise documentation for cleanup attribute [PR110029]
gcc/ChangeLog
PR c/110029
* doc/extend.texi (Common Variable Attributes): Explain what
happens when multiple variables with cleanups are in the same scope.
Sandra Loosemore [Thu, 18 Jan 2024 23:19:39 +0000 (23:19 +0000)]
Improve documentation of noinline and noipa attributes [PR108470]
gcc/ChangeLog
PR ipa/108470
* doc/extend.texi (Common Function Attributes): Document that
noinline also disables some interprocedural optimizations and
improve flow to the part about using inline asm instead to
disable calls from being optimized away completely. Remove the
sentence that says noipa is mainly for internal compiler testing.
Sandra Loosemore [Thu, 18 Jan 2024 18:28:22 +0000 (18:28 +0000)]
Restore documentation for const/volatile functions [PR107942]
In r5-7698-g8648c55f3b703a I accidentally removed the documentation of
GCC's special interpretation of const/volatile qualifiers on functions
from the function attributes section, thinking this was just a
bit-rotten leftover from old versions of GCC. PR107942 points out
that this functionality is still present even though the docs are now gone.
I decided this material didn't really belong in the function
attributes discussion, but a new subsection in the general list of GCC
extensions to the C language. And I agree with the comment in the
issue that we shouldn't really recommend this usage any more.
gcc/ChangeLog
PR c/107942
* doc/extend.texi (C Extensions): Add new section to menu.
(Function Attributes): Move dangling index entries to....
(Const and Volatile Functions): New section.
David Malcolm [Thu, 18 Jan 2024 17:11:57 +0000 (12:11 -0500)]
analyzer: fix ICE on strlen ((char *)&VECTOR_CST) [PR111361]
gcc/analyzer/ChangeLog:
PR analyzer/111361
* region-model.cc (svalue_byte_range_has_null_terminator_1): The
initial byte of an all-zeroes SVAL is a zero byte. Remove
gcc_unreachable from SK_CONSTANT for constants that aren't
STRING_CST or INTEGER_CST.
gcc/testsuite/ChangeLog:
PR analyzer/111361
* c-c++-common/analyzer/strlen-pr111361.c: New test.
* c-c++-common/analyzer/strncpy-1.c (test_zero_fill): Remove fixed
xfail.
* c-c++-common/analyzer/strncpy-pr111361.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 18 Jan 2024 17:11:57 +0000 (12:11 -0500)]
analyzer: fix offsets in has_null_terminator [PR112811]
PR analyzer/112811 reports an ICE attempting to determine whether a
string is null-terminated.
The root cause is confusion in the code about whether byte offsets are
relative to the start of the base region, or relative to the bound
fragment within the the region.
This patch rewrites the code to enforce a clearer separation between
the kinds of offset, fixing the ICE, and adds logging to help track
down future issues in this area of the code.
gcc/analyzer/ChangeLog:
PR analyzer/112811
* region-model.cc (fragment::dump_to_pp): New.
(fragment::has_null_terminator): Convert to...
(svalue_byte_range_has_null_terminator_1): ...this new function,
updating to use a byte_range relative to the start of the svalue.
(svalue_byte_range_has_null_terminator): New.
(fragment::string_cst_has_null_terminator): Convert to...
(string_cst_has_null_terminator): ...this, updating to use a
byte_range relative to the start of the svalue.
(iterable_cluster::dump_to_pp): New.
(region_model::scan_for_null_terminator): Add logging, moving body
to...
(region_model::scan_for_null_terminator_1): ...this new function,
adding more logging, and updating to use
svalue_byte_range_has_null_terminator.
* region-model.h (region_model::scan_for_null_terminator_1): New
decl.
gcc/testsuite/ChangeLog:
PR analyzer/112811
* c-c++-common/analyzer/strlen-pr112811.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 18 Jan 2024 17:11:57 +0000 (12:11 -0500)]
Fix ICE in -fdiagnostics-generate-patch [PR112684]
gcc/ChangeLog:
PR middle-end/112684
* toplev.cc (toplev::main): Don't ICE in
-fdiagnostics-generate-patch when exiting after options,
since no edit context will have been created.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Patrick Palka [Thu, 18 Jan 2024 15:36:07 +0000 (10:36 -0500)]
libstdc++/debug: Fix constexpr _Safe_iterator in C++20 mode [PR109536]
Some _Safe_iterator member functions define a variable of non-literal
type __gnu_cxx::__scoped_lock, which automatically disqualifies them from
being constexpr in C++20 mode even if that code path is never constant
evaluated. This restriction was lifted by P2242R3 for C++23, but we
need to work around it in C++20 mode. To that end this patch defines
a pair of macros that encapsulate the lambda-based workaround mentioned
in that paper and uses it to make these functions valid C++20 constexpr
functions. The augmented std::vector test element_access/constexpr.cc
now successfully compiles in C++20 mode with -D_GLIBCXX_DEBUG (and it
should test all member functions modified by this patch).
PR libstdc++/109536
libstdc++-v3/ChangeLog:
* include/debug/safe_base.h (_Safe_sequence_base::_M_swap):
Remove _GLIBCXX20_CONSTEXPR from non-inline member function.
* include/debug/safe_iterator.h
(_GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_BEGIN): Define.
(_GLIBCXX20_CONSTEXPR_NON_LITERAL_SCOPE_END): Define.
(_Safe_iterator::operator=): Use them around the code path that
defines a variable of type __gnu_cxx::__scoped_lock.
(_Safe_iterator::operator++): Likewise.
(_Safe_iterator::operator--): Likewise.
(_Safe_iterator::operator+=): Likewise.
(_Safe_iterator::operator-=): Likewise.
* testsuite/23_containers/vector/element_access/constexpr.cc
(test_iterators): Test more iterator operations.
* testsuite/23_containers/vector/bool/element_access/constexpr.cc
(test_iterators): Likewise.
* testsuite/std/ranges/adaptors/all.cc (test08) [_GLIBCXX_DEBUG]:
Remove.
Iain Sandoe [Thu, 18 Jan 2024 09:56:42 +0000 (09:56 +0000)]
Darwin, configure: Handle a missing substitution.
The configure substitution for enable_darwin_at_rpath has been
omitted, which leads to a failure to set ENABLE_DARWIN_AT_RPATH in
the testsuite site.exp (which leads to failure to add -B options
in some cases, breaking uninstalled testing there).
Since we already have substitutions for ENABLE_DARWIN_AT_RPATH_TRUE
we can use that instead, which is what this patch does.
gcc/ChangeLog:
* Makefile.in: Emit ENABLE_DARWIN_AT_RPATH into site.exp
when ENABLE_DARWIN_AT_RPATH_TRUE is not '#'.
Jun Sha (Joshua) [Fri, 12 Jan 2024 08:44:20 +0000 (16:44 +0800)]
RISC-V: Rewrite some instructions using ASM targethook
There are some xtheadvector instructions that differ from RVV1.0
apart from simply adding "th." prefix. For example, RVV1.0
load/store instructions will have SEW while xtheadvector not;
RVV1.0 will have "o" for indexed-ordered store instructions while
xtheadvecotr not; xtheadvector and RVV1.0 have different
vnsrl/vnsra/vfncvt suffix (vv/vx/vi vs wv/wx/wi).
To address this issue without duplicating patterns, we use ASM
targethook to rewrite the whole string of the instructions. We
identify different instructions from the corresponding attribute.
gcc/ChangeLog:
* config/riscv/thead.cc
(th_asm_output_opcode): Rewrite some instructions.
Co-authored-by: Jin Ma <jinma@linux.alibaba.com> Co-authored-by: Xianmiao Qu <cooper.qu@linux.alibaba.com> Co-authored-by: Christoph Müllner <christoph.muellner@vrull.eu>
Jun Sha (Joshua) [Fri, 12 Jan 2024 03:23:21 +0000 (11:23 +0800)]
RISC-V: Fix register overlap issue for some xtheadvector instructions
For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions
and floating-point compare instructions, an illegal instruction
exception will be raised if the destination vector register overlaps
a source vector register group.
To handle this issue, we add an attribute "spec_restriction" to disable
some alternatives for xtheadvector.
gcc/ChangeLog:
* config/riscv/riscv.md (none,thv,rvv): New attribute.
(no,yes): Add an attribute to disable alternative
for xtheadvector or RVV1.0.
* config/riscv/vector.md:
Disable alternatives that destination register overlaps
source register group for xtheadvector.
Co-authored-by: Jin Ma <jinma@linux.alibaba.com> Co-authored-by: Xianmiao Qu <cooper.qu@linux.alibaba.com> Co-authored-by: Christoph Müllner <christoph.muellner@vrull.eu>
Jun Sha (Joshua) [Fri, 12 Jan 2024 03:22:41 +0000 (11:22 +0800)]
RISC-V: Add support for xtheadvector-specific intrinsics.
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(class th_extract): Define new builtin bases.
(BASE): Define new builtin bases.
* config/riscv/riscv-vector-builtins-bases.h:
Define new builtin class.
* config/riscv/riscv-vector-builtins-shapes.cc
(struct th_loadstore_width_def): Define new builtin shapes.
(struct th_indexed_loadstore_width_def):
Define new builtin shapes.
(struct th_extract_def): Define new builtin shapes.
(SHAPE): Define new builtin shapes.
* config/riscv/riscv-vector-builtins-shapes.h:
Define new builtin shapes.
* config/riscv/riscv-vector-builtins.cc (DEF_RVV_FUNCTION):
Redefine DEF_RVV_FUNCTION for XTheadVector special intrinsics.
* config/riscv/riscv-vector-builtins.h
(enum required_ext): Add new XTheadVector member.
(struct function_group_info): Likewise.
* config/riscv/t-riscv:
Add thead-vector-builtins-functions.def
* config/riscv/thead-vector.md
(@pred_mov_width<vlmem_op_attr><mode>): Add new patterns.
(*pred_mov_width<vlmem_op_attr><mode>): Likewise.
(@pred_store_width<vlmem_op_attr><mode>): Likewise.
(@pred_strided_load_width<vlmem_op_attr><mode>): Likewise.
(@pred_strided_store_width<vlmem_op_attr><mode>): Likewise.
(@pred_indexed_load_width<vlmem_op_attr><mode>): Likewise.
(@pred_th_extract<mode>): Likewise.
(*pred_th_extract<mode>): Likewise.
* config/riscv/thead-vector-builtins-functions.def: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlbu-vsb.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlh-vsh.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlhu-vsh.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlw-vsw.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlwu-vsw.c: New test.
Co-authored-by: Jin Ma <jinma@linux.alibaba.com> Co-authored-by: Xianmiao Qu <cooper.qu@linux.alibaba.com> Co-authored-by: Christoph Müllner <christoph.muellner@vrull.eu>
Jun Sha (Joshua) [Fri, 12 Jan 2024 03:22:10 +0000 (11:22 +0800)]
RISC-V: Handle differences between XTheadvector and Vector
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share same patterns as RVV1.0 instructions, we will
use ASM targethook to rewrite the whole string of the instructions in
the following patches.
For some vector patterns that cannot be avoided, we use
"!TARGET_XTHEADVECTOR" to disable them in vector.md in order
not to generate instructions that xtheadvector does not support,
like vmv1r.
gcc/ChangeLog:
* config.gcc: Add files for XTheadVector intrinsics.
* config/riscv/autovec.md: Guard XTheadVector.
* config/riscv/predicates.md: Disable immediate vl
for XTheadVector.
* config/riscv/riscv-c.cc (riscv_pragma_intrinsic):
Add pragma for XTheadVector.
* config/riscv/riscv-string.cc (riscv_expand_block_move):
Guard XTheadVector.
* config/riscv/riscv-v.cc (vls_mode_valid_p):
Avoid autovec.
* config/riscv/riscv-vector-builtins-bases.cc:
Do not normalize vsetvl instructions for XTheadVector.
* config/riscv/riscv-vector-builtins-shapes.cc (check_type):
New check type function.
(build_one): Adjust for XTheadVector.
* config/riscv/riscv-vector-switch.def (ENTRY):
Disable fractional mode for the XTheadVector extension.
(TUPLE_ENTRY): Likewise.
* config/riscv/riscv.cc (riscv_v_adjust_bytesize):
Guard XTheadVector.
(riscv_preferred_simd_mode): Likewsie.
(riscv_autovectorize_vector_modes): Likewise.
(riscv_vector_mode_supported_any_target_p): Likewise.
(TARGET_VECTOR_MODE_SUPPORTED_ANY_TARGET_P): Likewise.
* config/riscv/thead.cc (th_asm_output_opcode):
Rewrite vsetvl instructions.
* config/riscv/vector.md:
Include thead-vector.md and change fractional LMUL
into 1 for vbool.
* config/riscv/riscv_th_vector.h: New file.
* config/riscv/thead-vector.md: New file.
Co-authored-by: Jin Ma <jinma@linux.alibaba.com> Co-authored-by: Xianmiao Qu <cooper.qu@linux.alibaba.com> Co-authored-by: Christoph Müllner <christoph.muellner@vrull.eu>
Jun Sha (Joshua) [Fri, 12 Jan 2024 08:34:21 +0000 (16:34 +0800)]
RISC-V: Adds the prefix "th." for the instructions of XTheadVector.
This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. We only check the
prefix is 'v', so that no extra attribute is needed.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_asm_output_opcode):
Add new function to add assembler insn code prefix/suffix.
(th_asm_output_opcode):
Add Thead function to add assembler insn code prefix/suffix.
* config/riscv/riscv.cc (riscv_asm_output_opcode):
Implement function to add assembler insn code prefix/suffix.
* config/riscv/riscv.h (ASM_OUTPUT_OPCODE):
Add new function to add assembler insn code prefix/suffix.
* config/riscv/thead.cc (th_asm_output_opcode):
Implement Thead function to add assembler insn code
prefix/suffix.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/prefix.c: New test.
Co-authored-by: Jin Ma <jinma@linux.alibaba.com> Co-authored-by: Xianmiao Qu <cooper.qu@linux.alibaba.com> Co-authored-by: Christoph Müllner <christoph.muellner@vrull.eu>
Jun Sha (Joshua) [Fri, 12 Jan 2024 03:20:29 +0000 (11:20 +0800)]
RISC-V: Introduce XTheadVector as a subset of V1.0.0
This patch is to introduce basic XTheadVector support
(march string parsing and a test for __riscv_xtheadvector)
according to https://github.com/T-head-Semi/thead-extension-spec/
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse): Add new vendor extension.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins):
Add test marco.
* config/riscv/riscv.opt: Add new mask.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-__riscv_th_v_intrinsic.c: New test.
* gcc.target/riscv/rvv/xtheadvector.c: New test.
Co-authored-by: Jin Ma <jinma@linux.alibaba.com> Co-authored-by: Xianmiao Qu <cooper.qu@linux.alibaba.com> Co-authored-by: Christoph Müllner <christoph.muellner@vrull.eu>
Iain Sandoe [Mon, 8 Jan 2024 17:00:18 +0000 (17:00 +0000)]
Darwin: Suppress adding embedded rpaths for earlier OS versions.
When we have @rpath support by virtue of the OS version we're hosting on
we still need to omit those rpath entries when targeting < 10.5 (or the
linker will complain). To do this we (maybe ab-)use a property of the
spec function expansion that a non-null return value can be used as the
true input to a second spec (whereas, unfortunately, we cannot pass specs
to the version function at present).
gcc/ChangeLog:
* config/darwin.h (DARWIN_RPATH_SPEC): Arrange for the %P spec
to be conditional on macosx-version-min.
Iain Sandoe [Mon, 8 Jan 2024 16:17:04 +0000 (16:17 +0000)]
Darwin: Fix a typo in Objective-C meta-data.
We have a typo in the metadata for assigning NSStrings to a specific
section for the V1 (32b) ABI. When that is fixed we should never see
the case where the section needs to be deduced from the properties of
the DECLs.
gcc/ChangeLog:
* config/darwin.cc (darwin_objc1_section): Use the correct
meta-data version for constant strings.
(machopic_select_section): Assert if we fail to handle CFString
sections as Obejctive-C meta-data or drectly.
Marek Polacek [Thu, 18 Jan 2024 00:16:32 +0000 (19:16 -0500)]
c++: ICE when xobj is not the first parm [PR113389]
In grokdeclarator/cdk_function the comment says that the find_xobj_parm
lambda clears TREE_PURPOSE so that we can correctly detect an xobj that
is not the first parameter. That's all good, but we should also clear
the TREE_PURPOSE once we've given the error, otherwise we crash later in
check_default_argument because the 'this' TREE_PURPOSE lacks a type.
PR c++/113389
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator) <case cdk_function>: Set TREE_PURPOSE to
NULL_TREE when emitting an error.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-diagnostics10.C: New test.
Iain Sandoe [Tue, 16 Jan 2024 08:45:26 +0000 (08:45 +0000)]
lto, Darwin: Fix offload section names.
Currently, these section names have wrong syntax for Mach-O.
Although they were added some time ago; recently added tests are
now emitting them leading to new fails on Darwin.
This adds a Mach-O variant for each.
gcc/ChangeLog:
* lto-section-names.h (OFFLOAD_SECTION_NAME_PREFIX,
OFFLOAD_VAR_TABLE_SECTION_NAME, OFFLOAD_FUNC_TABLE_SECTION_NAME,
OFFLOAD_IND_FUNC_TABLE_SECTION_NAME): Provide Mach-O syntax
versions when the object format is Mach-O.
projects / thirdparty / gcc.git / log
