>> 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.
Co-authored-by: Thorsten Otto <admin@tho-otto.de>
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.
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.
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:
bar: movq %xmm2, %rdx
movq %xmm3, %rax
movq %xmm0, %rsi
xchgq %rdx, %rax
movq %rsi, %rcx
movq %rax, %rsi
movq %rdx, %rax
shrq $32, %rcx
shrq $32, %rax
movd %ecx, %xmm4
movd %eax, %xmm0
comiss %xmm4, %xmm0
jb .L6
movd %esi, %xmm0
xorl %eax, %eax
comiss %xmm0, %xmm1
setnb %al
ret
.L6: xorl %eax, %eax
ret
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.
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.
gcc/fortran/ChangeLog:
PR fortran/113377
* trans-expr.cc (gfc_conv_procedure_call): Fix handling of optional
scalar arguments of intrinsic type with the VALUE attribute.
gcc/testsuite/ChangeLog:
PR fortran/113377
* gfortran.dg/optional_absent_9.f90: New test.
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.
gcc/testsuite:
* gcc.dg/pr113492.c: New test.
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.
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.
These arise because 32-bit ELF targets were changed from
callee copies to caller copies.
2024-01-20 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* gcc.dg/ipa/iinline-4.c: Remove dg-final xfail for
32-bit hppa*-*-*.
* gcc.dg/ipa/inline-5.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-7.c: Likewise.
* gcc.dg/tree-ssa/vector-4.c: Likewise.
2024-01-20 John David Anglin <danglin@gcc.gnu.org>
libgomp/ChangeLog:
* testsuite/libgomp.fortran/alloc-comp-3.f90: Increase
timeout by 2 on hppa*-*-*.
hppa*-*-hpux* lacks necessary math functions.
2024-01-20 John David Anglin <danglin@gcc.gnu.org>
libgomp/ChangeLog:
* testsuite/libgomp.c/simd-math-1.c: Don't run on
hppa*-*-hpux*.
2024-01-20 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/slsr-13.c: xfail scan-tree-dump-times
checks on hppa*64*-*-*.
LRA is required for asm goto.
2024-01-20 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr110422.c: Require target lra.
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|.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wdangling-reference17.C: New test.
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>
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.
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.
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.
* gcc.dg/bitint-76.c: New test.
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.
* gcc.dg/torture/bitint-51.c: New test.
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.
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.
gcc/jit/ChangeLog:
* jit-recording.h (is_numeric_vector, vector_type::new_int): New
functions.
* libgccjit.cc (gcc_jit_context_new_unary_op,
gcc_jit_context_new_binary_op): add checks for
is_numeric_vector.
gcc/testsuite/ChangeLog:
* jit.dg/test-reflection.c: Add check to make sure
gcc_jit_type_is_integral returns 0 on a vector type.
get_template_info was crashing because it assumed that any decl with
DECL_LANG_SPECIFIC could use DECL_TEMPLATE_INFO. It's more complicated than
that.
PR c++/113498
gcc/cp/ChangeLog:
* pt.cc (decl_template_info): New fn.
(get_template_info): Use it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-using4.C: New test.
My change in r14-8181-g665a3ff1539ce2 was incomplete as there's a second
place using CTAD with the _Utf32_view alias template. This fixes it.
libstdc++-v3/ChangeLog:
* include/std/format (_Spec::_M_parse_fill_and_align): Do not
use CTAD for _Utf32_view.
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.
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.
PR c++/112632
PR c++/112594
PR c++/111357
PR c++/104594
PR c++/67898
gcc/cp/ChangeLog:
* cp-tree.h (IMPLICIT_CONV_EXPR_FORCED): New.
* pt.cc (expand_integer_pack): Remove 111357 workaround.
(maybe_convert_nontype_argument): Add force parm.
(convert_template_argument): Handle alias template args
specially.
(tsubst_expr): Don't ignore IMPLICIT_CONV_EXPR_NONTYPE_ARG.
* error.cc (dump_expr) [CASE_CONVERT]: Handle null optype.
gcc/testsuite/ChangeLog:
* 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.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
2024-01-19 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr47917.c: Limit dg-xfail-run-if for
hpux11.[012]* to -O0.
Pthreads on hpux needs _HPUX_SOURCE define for id_t and spu_t types.
2024-01-19 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* gcc.dg/pthread-init-2.c: Change dg-options for hpux
to define _HPUX_SOURCE.
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.
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 ?
PR target/113495
gcc/ChangeLog:
* config/riscv/riscv-protos.h (RVV_VLMAX): Change to regno_reg_rtx[X0_REGNUM].
(RVV_VUNDEF): Ditto.
* config/riscv/riscv-vsetvl.cc: Add timevar.
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.
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.
PR tree-optimization/113494
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Handle endless loop on exit. Handle re-allocated PHI.
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.
libsanitizer/ChangeLog:
* sanitizer_common/Makefile.am (DEFS): Add @AS_SYM_ASSIGN_DEFS@.
* sanitizer_common/Makefile.in: Regenerate.
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.
* gcc.dg/bitint-75.c: New test.
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.
* gcc.dg/bitint-74.c: New test.
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.
* gcc.dg/bitint-73.c: New test.
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.
