Andi Kleen [Wed, 24 Jan 2024 07:54:56 +0000 (23:54 -0800)]
Add tests for C/C++ musttail attributes
Some adopted from the existing C musttail plugin tests.
Also extends the ability to query the sibcall capabilities of the
target.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp:
(check_effective_target_struct_tail_call): New function.
* c-c++-common/musttail1.c: New test.
* c-c++-common/musttail12.c: New test.
* c-c++-common/musttail13.c: New test.
* c-c++-common/musttail2.c: New test.
* c-c++-common/musttail3.c: New test.
* c-c++-common/musttail4.c: New test.
* c-c++-common/musttail5.c: New test.
* c-c++-common/musttail7.c: New test.
* c-c++-common/musttail8.c: New test.
* g++.dg/musttail10.C: New test.
* g++.dg/musttail11.C: New test.
* g++.dg/musttail6.C: New test.
* g++.dg/musttail9.C: New test.
Andi Kleen [Wed, 24 Jan 2024 07:44:48 +0000 (23:44 -0800)]
C++: Support clang compatible [[musttail]] (PR83324)
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
optimizations not scaling. With musttail the interpreter can be instead
written as a sequence of smaller functions that call each other. To
avoid unbounded stack growth this requires forcing a sibling call, which
this attribute does. It guarantees an error if the call cannot be tail
called which allows the programmer to fix it instead of risking a stack
overflow. Unlike computed goto it is also type-safe.
It turns out that David Malcolm had already implemented middle/backend
support for a musttail attribute back in 2016, but it wasn't exposed
to any frontend other than a special plugin.
This patch adds a [[gnu::musttail]] attribute for C++ that can be added
to return statements. The return statement must be a direct call
(it does not follow dependencies), which is similar to what clang
implements. It then uses the existing must tail infrastructure.
For compatibility it also detects clang::musttail
Passes bootstrap and full test
gcc/c-family/ChangeLog:
* c-attribs.cc (set_musttail_on_return): New function.
* c-common.h (set_musttail_on_return): Declare new function.
Patrick Palka [Tue, 23 Jul 2024 17:16:14 +0000 (13:16 -0400)]
c++: normalizing ttp constraints [PR115656]
Here we normalize the constraint same_as<T, bool> for the first
time during ttp coercion of B / UU, specifically constraint subsumption
checking. During this normalization the set of in-scope template
parameters i.e. current_template_parms is empty, which we rely on
during normalization of the ttp constraints since we pass in_decl=NULL_TREE
to norm_info. And this tricks the satisfaction cache into thinking that
the satisfaction value of same_as<T, bool> is independent of its template
parameters, and we incorrectly conflate the satisfaction value with
T = bool vs T = long and accept the specialization A<long, B>.
Since is_compatible_template_arg rewrites the ttp's constraints to
be in terms of the argument template's parameters, and since it's
the only caller of weakly_subsumes, the latter funcion can instead
pass in_decl=tmpl to avoid relying on current_template_parms. This
patch implements this, and in turns renames weakly_subsumes to
ttp_subsumes to reflect that this predicate is now hardcoded for this
one caller.
PR c++/115656
gcc/cp/ChangeLog:
* constraint.cc (weakly_subsumes): Pass in_decl=tmpl to
get_normalized_constraints_from_info. Rename to ...
(ttp_subsumes): ... this.
* cp-tree.h (weakly_subsumes): Rename to ...
(ttp_subsumes): ... this.
* pt.cc (is_compatible_template_arg): Adjust after renaming.
Patrick Palka [Tue, 23 Jul 2024 15:37:31 +0000 (11:37 -0400)]
c++: missing SFINAE during alias CTAD [PR115296]
During the alias CTAD transformation, if substitution failed for some
guide we should just silently discard the guide. We currently do
discard the guide, but not silently, as in the below testcase which
we diagnose forming a too-large array type when transforming the
user-defined deduction guides.
This patch fixes this by using complain=tf_none instead of
tf_warning_or_error throughout alias_ctad_tweaks.
PR c++/115296
gcc/cp/ChangeLog:
* pt.cc (alias_ctad_tweaks): Use complain=tf_none instead of
tf_warning_or_error.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias23.C: New test.
Gaius Mulley [Tue, 23 Jul 2024 14:54:16 +0000 (15:54 +0100)]
PR modula2/116048 ICE when encountering wrong kind of qualident
Following on from PR-115957 further ICEs can be generated by using the
wrong kind of qualident symbol. For example using a variable instead of
a type or using a type instead of a const. This fix tracks the expected
qualident kind state when parsing const, type and variable declarations.
If the error is unrecoverable then a detailed message explaining the
context of the qualident (and why the seen qualident is wrong) is
generated.
gcc/m2/ChangeLog:
PR modula2/116048
* Make-lang.in (GM2-COMP-BOOT-DEFS): Add M2StateCheck.def.
(GM2-COMP-BOOT-MODS): Add M2StateCheck.mod.
(GM2-COMP-DEFS): Add M2StateCheck.def.
(GM2-COMP-MODS): Add M2StateCheck.mod.
* gm2-compiler/M2Quads.mod (StartBuildWith): Generate
unrecoverable error is the qualident type is NulSym.
Replace MetaError1 with MetaErrorT1 and position the error
to the qualident.
* gm2-compiler/P3Build.bnf (M2StateCheck): Import procedures.
(seenError): New variable.
(WasNoError): Remove variable.
(BlockState): New variable.
(ErrorString): Rewrite using seenError.
(CompilationUnit): Ditto.
(QualidentCheck): New rule.
(ConstantDeclaration): Bookend with InclConst and ExclConst.
(Constructor): Add InclConstructor, ExclConstructor and call
CheckQualident.
(ConstActualParameters): Call PushState, PopState, InclConstFunc
and CheckQualident.
(TypeDeclaration): Bookend with InclType and ExclType.
(SimpleType): Call QualidentCheck.
(CaseTag): Ditto.
(OptReturnType): Ditto.
(VariableDeclaration): Bookend with InclVar and ExclVar.
(Designator): Call QualidentCheck.
(Formal;Type): Ditto.
* gm2-compiler/PCBuild.bnf (M2StateCheck): Import procedures.
(ConstantDeclaration): Rewrite using InclConst and ExclConst.
(Constructor): Bookend with InclConstructor and ExclConstructor.
Call CheckQualident.
(ConstructorOrConstActualParameters): Rewrite and cal
l CheckQualident.
(ConstActualParameters): Bookend with PushState PopState.
Call InclConstFunc and CheckQualident.
* gm2-gcc/init.cc (_M2_M2StateCheck_init): New declaration.
(_M2_P3Build_init): New declaration.
(init_PerCompilationInit): Call _M2_M2StateCheck_init and
_M2_P3Build_init.
* gm2-compiler/M2StateCheck.def: New file.
* gm2-compiler/M2StateCheck.mod: New file.
gcc/testsuite/ChangeLog:
PR modula2/116048
* gm2/errors/fail/errors-fail.exp: Remove -Wstudents
and add -Wuninit-variable-checking=all.
Replace gm2_init_pim with gm2_init_iso.
* gm2/errors/fail/testfio.mod: Modify test code to
provoke an error in the first basic block.
* gm2/errors/fail/testparam.mod: Ditto.
* gm2/errors/fail/array1.mod: Ditto.
* gm2/errors/fail/badtype.mod: New test.
* gm2/errors/fail/badvar.mod: New test.
install.texi (gcn): Suggest newer commit for Newlib
Newlib 4.4.0 lacks two commits: 7dd4eb1db (2024-03-25) to fix device console
output for GFX10/GFX11 and ed50a50b9 (2024-04-04) to make the added lock.h
compilable with C++. This commit mentiones now also the second commit.
gcc/ChangeLog:
* doc/install.texi (amdgcn-x-amdhsa): Suggest newer git version
for newlib.
report message for operator %a on unaddressible operand
Hi,
For PR96866, when printing asm code for modifier "%a", an addressable
operand is required. While the constraint "X" allow any kind of
operand even which is hard to get the address directly. e.g. extern
symbol whose address is in TOC.
An error message would be reported to indicate the invalid asm operand.
Compare with previous version, test case is updated with -mno-pcrel.
Bootstrap®test pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff(Jiufu Guo)
PR target/96866
gcc/ChangeLog:
* config/rs6000/rs6000.cc (print_operand_address): Emit message for
unsupported operand.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr96866-1.c: New test.
* gcc.target/powerpc/pr96866-2.c: New test.
Richard Biener [Tue, 23 Jul 2024 08:29:58 +0000 (10:29 +0200)]
tree-optimization/116002 - PTA solving slow with degenerate graph
When the constraint graph consists of N nodes with only complex
constraints and no copy edges we have to be lucky to arrive at
a constraint solving order that requires the optimal number of
iterations. What happens in the testcase is that we bottle-neck
on computing the visitation order but propagate changes only
very slowly. Luckily the testcase complex constraints are
all copy-with-offset and those do provide a way to order
visitation. The following adds this which reduces the iteration
count to one.
PR tree-optimization/116002
* tree-ssa-structalias.cc (topo_visit): Also consider
SCALAR = SCALAR complex constraints as edges.
avrlibc has an incomplete unistd.h that doesn't have isatty.
So building libstdc++ fails when compiling c++23/print.cc.
As a workaround I added a check for AVR.
libstdc++-v3/ChangeLog:
PR libstdc++/115482
* src/c++23/print.cc (__open_terminal) [__AVR__]: Do not use
isatty.
Jakub Jelinek [Tue, 23 Jul 2024 08:50:29 +0000 (10:50 +0200)]
ssa: Fix up maybe_rewrite_mem_ref_base complex type handling [PR116034]
The folding into REALPART_EXPR is correct, used only when the mem_offset
is zero, but for IMAGPART_EXPR it didn't check the exact offset value (just
that it is not 0).
The following patch fixes that by using IMAGPART_EXPR only if the offset
is right and using BITFIELD_REF or whatever else otherwise.
2024-07-23 Jakub Jelinek <jakub@redhat.com>
Andrew Pinski <quic_apinski@quicinc.com>
PR tree-optimization/116034
* tree-ssa.cc (maybe_rewrite_mem_ref_base): Only use IMAGPART_EXPR
if MEM_REF offset is equal to element type size.
Jakub Jelinek [Tue, 23 Jul 2024 08:39:08 +0000 (10:39 +0200)]
c++: Remove CHECK_CONSTR
On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote:
> FWIW this tree code seems to be a vestige of the initial Concepts TS
> implementation and is effectively unused, we can remove it outright.
Richard Biener [Fri, 19 Jul 2024 14:23:51 +0000 (16:23 +0200)]
[v2] rtl-optimization/116002 - cselib hash is bad
The following addresses the bad hash function of cselib which uses
integer plus for merging. This causes a huge number of collisions
for the testcase in the PR and thus very large compile-time.
The following rewrites it to use inchash, eliding duplicate mixing
of RTX code and mode in some cases and more consistently avoiding
a return value of zero as well as treating zero as fatal. An
important part is to preserve mixing of hashes of commutative
operators as commutative.
For cselib_hash_plus_const_int this removes the apparent attempt
of making sure to hash the same as a PLUS as cselib_hash_rtx makes
sure to dispatch to cselib_hash_plus_const_int consistently.
This reduces compile-time for the testcase in the PR from unknown
to 22s and for a reduced testcase from 73s to 9s. There's another
pending patchset to improve the speed of inchash mixing, but it's
not in the profile for this testcase (PTA pops up now).
The generated code is equal. I've also compared cc1 builds
with and without the patch and they are now commparing equal
after retaining commutative hashing for commutative operators.
PR rtl-optimization/116002
* cselib.cc (cselib_hash_rtx): Use inchash to get proper mixing.
Consistently avoid a zero return value when hashing successfully.
Consistently treat a zero hash value from recursing as fatal.
Use hashval_t where appropriate.
(cselib_hash_plus_const_int): Likewise.
(new_cselib_val): Use hashval_t.
(cselib_lookup_1): Likewise.
> The solution proposed here is to have the x86 backend/recog prevent
> early RTL passes composing instructions (that set likely_spilled hard
> registers) that they (combine) can't simplify, until after reload.
> We allow sets from pseudo registers, immediate constants and memory
> accesses, but anything more complicated is performed via a temporary
> pseudo. Not only does this simplify things for the register allocator,
> but any remaining register-to-register moves are easily cleaned up
> by the late optimization passes after reload, such as peephole2 and
> cprop_hardreg.
The restriction is mainly for rtl optimization passes before pass_combine.
There're many splitters generating MOV insn with SUBREG and would have
same problem.
Instead of changing those splitters one by one, the patch relaxes
ix86_hard_mov_ok to allow mov subreg to hard register after
split1. ix86_pre_reload_split () is used to replace
!reload_completed && ira_in_progress.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_hardreg_mov_ok): Relax mov subreg
to hard register after split1.
Kewen Lin [Tue, 23 Jul 2024 05:48:14 +0000 (00:48 -0500)]
rs6000: Update option set in rs6000_inner_target_options [PR115713]
When function rs6000_inner_target_options parsing target
options, it updates the explicit option set information for
rs6000_opt_masks by rs6000_isa_flags_explicit, but it misses
to update that information for rs6000_opt_vars, and it can
result in some unexpected consequence as the associated test
case shows. This patch is to fix rs6000_inner_target_options
to update the option set for rs6000_opt_vars as well.
PR target/115713
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_inner_target_options): Update option
set information for rs6000_opt_vars.
Kewen Lin [Tue, 23 Jul 2024 05:48:00 +0000 (00:48 -0500)]
rs6000: Consider explicitly set options in target option parsing [PR115713]
In rs6000_inner_target_options, when enabling VSX we enable
altivec and disable -mavoid-indexed-addresses implicitly,
but it doesn't consider the case that the options altivec
and avoid-indexed-addresses can be explicitly disabled. As
the test case in PR115713#c1 shows, with target attribute
"no-altivec,vsx", it results in that VSX unexpectedly set
altivec flag and there isn't an expected error.
This patch is to avoid the automatic enablement when they
are explicitly specified. With this change, an existing
test case ppc-target-4.c also requires an adjustment by
specifying explicit altivec in target attribute (since it
requires altivec feature and command line is specifying
no-altivec).
PR target/115713
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_inner_target_options): Avoid to
enable altivec or disable avoid-indexed-addresses automatically
when they get specified explicitly.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr115713-1.c: New test.
* gcc.target/powerpc/ppc-target-4.c: Adjust by specifying altivec
in target attribute.
Kewen Lin [Tue, 23 Jul 2024 05:47:49 +0000 (00:47 -0500)]
rs6000: Escalate warning to error for VSX with explicit no-altivec etc.
As the discussion in PR115688, for now when users specify
-mvsx and -mno-altivec explicitly, compiler emits warning
rather than error, but considering both options are given
explicitly, emitting hard error should be better.
So this patch is to escalate some related warning to error
when both are incompatible.
PR target/115713
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Emit error
messages when explicit VSX encounters explicit soft-float, no-altivec
or avoid-indexed-addresses.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/warn-1.c: Move to ...
* gcc.target/powerpc/error-1.c: ... here. Adjust dg-warning with
dg-error and remove ineffective scan.
For prefetchi instructions, RIP-relative address is explicitly mentioned
for operand and assembler obeys that rule strictly. This makes
instruction like:
prefetchit0 bar
got illegal for assembler, which should be a broad usage for prefetchi.
Change to %a to explicitly add (%rip) after function label to make it
legal in assembler so that it could pass to linker to get the real address.
Jeff Law [Tue, 23 Jul 2024 03:48:28 +0000 (21:48 -0600)]
[5/n][PR rtl-optimization/115877] Fix handling of input/output operands
So in this patch we're correcting a failure to mark objects live in scenarios
like
(set (dest) (plus (dest) (src))
When handling set pseudos, we transfer the liveness information from LIVENOW
into LIVE_TMP. LIVE_TMP is subsequently used to narrow what bit groups are
live for the inputs.
The first time we process the block we may not have DEST in the LIVENOW set (it
may be live across the loop, but not live after the loop). Thus we can totally
miss making certain objects live, resulting in incorrect code.
The fix is pretty simple. If LIVE_TMP is empty, then we should go ahead and
mark all the bit groups for the set object in LIVE_TMP. This also removes an
invalid gcc_assert on the state of the liveness bitmaps.
This showed up on pru, rl78 and/or msp430 in the testsuite. So no new test.
Bootstrapped and regression tested on x86_64 and also run through my tester on
all the cross platforms.
The dg-do directive appears after dg-require-effective-target in
g++.target/powerpc/pr106069.C. That doesn't work the way that was
presumably intended. Both of these directives set dg-do-what, but
dg-do does so fully and unconditionally, overriding any decisions
recorded there by earlier directives. Reorder the directives more
canonically, so that both take effect.
Patrick Palka [Tue, 23 Jul 2024 01:30:49 +0000 (21:30 -0400)]
c++/coroutines: correct passing *this to promise type [PR104981]
When passing *this to the promise type ctor (or to its operator new)
(as per [dcl.fct.def.coroutine]/4), we add an explicit cast to lvalue
reference. But this is unnecessary since *this is already always an
lvalue. And doing so means we need to call convert_from_reference
afterward to lower the reference expression to an implicit dereference,
which we're currently neglecting to do and which causes overload
resolution to get confused when computing argument conversions.
So this patch removes this unneeded reference cast when passing *this
to the promise ctor, and removes both the cast and implicit deref when
passing *this to operator new, for consistency. While we're here, use
cp_build_fold_indirect_ref instead of directly building INDIRECT_REF.
PR c++/104981
PR c++/115550
gcc/cp/ChangeLog:
* coroutines.cc (morph_fn_to_coro): Remove unneeded calls
to convert_to_reference and convert_from_reference when
passing *this. Use cp_build_fold_indirect_ref instead
of directly building INDIRECT_REF.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr104981-preview-this.C: New test.
* g++.dg/coroutines/pr115550-preview-this.C: New test.
Reviewed-by: Iain Sandoe <iain@sandoe.co.uk> Reviewed-by: Jason Merrill <jason@redhat.com>
The below tests suites are passed for this patch
1. The rv64gcv fully regression test.
2. The rv64gcv build with glibc
gcc/ChangeLog:
* config/riscv/iterators.md (ANYI_DOUBLE_TRUNC): Add new iterator
for int double truncation.
(ANYI_DOUBLE_TRUNCATED): Add new attr for int double truncation.
(anyi_double_truncated): Ditto but for lowercase.
* config/riscv/riscv-protos.h (riscv_expand_ustrunc): Add new
func decl for expanding ustrunc
* config/riscv/riscv.cc (riscv_expand_ustrunc): Add new func
impl to expand ustrunc.
* config/riscv/riscv.md (ustrunc<mode><anyi_double_truncated>2): Impl
the new pattern ustrunc<m><n>2 for int.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/sat_arith.h: Add test helper macro.
* gcc.target/riscv/sat_arith_data.h: New test.
* gcc.target/riscv/sat_u_trunc-1.c: New test.
* gcc.target/riscv/sat_u_trunc-2.c: New test.
* gcc.target/riscv/sat_u_trunc-3.c: New test.
* gcc.target/riscv/sat_u_trunc-run-1.c: New test.
* gcc.target/riscv/sat_u_trunc-run-2.c: New test.
* gcc.target/riscv/sat_u_trunc-run-3.c: New test.
* gcc.target/riscv/scalar_sat_unary.h: New test.
Jan Hubicka [Mon, 22 Jul 2024 21:01:50 +0000 (23:01 +0200)]
Fix handling of ICF_NOVOPS in ipa-modref
As shown in somewhat convoluted testcase, ipa-modref is mistreating
ECF_NOVOPS as "having no side effects". This come from time when
modref cared only about memory accesses and thus it was possible to
shortcut on it.
This patch removes (hopefully) all those bad shortcuts.
Bootstrapped/regtested x86_64-linux, comitted.
Jakub Jelinek [Mon, 22 Jul 2024 17:47:17 +0000 (19:47 +0200)]
c++: Some cp-tree.def comment fixes
While reading the fold expression and concept tree comments, I found
various spots referring to non-existent macros etc.
The following patch attempts to sync that with what is actually implemented.
2024-07-22 Jakub Jelinek <jakub@redhat.com>
* cp-tree.def (UNARY_LEFT_FOLD_EXPR): Use FOLD_EXPR_MODIFY_P instead
of FOLD_EXPR_MOD_P or FOLDEXPR_MOD_P in the comment. Comment
formatting fixes.
(ATOMIC_CONSTEXPR): Use CONSTR_INFO instead of ATOMIC_CONSTR_INFO
and ATOMIC_CONSTR_MAP instead of ATOMIC_CONSTR_PARMS in the comment.
Comment formatting fixes.
(CONJ_CONSTR): Remove comment about third operand. Use CONSTR_INFO
instead of CONJ_CONSTR_INFO and DISJ_CONSTR_INFO.
(CHECK_CONSTR): Use CHECK_CONSTR_ARGS instead of
CHECK_CONSTR_ARGUMENTS.
Jan Hubicka [Mon, 22 Jul 2024 17:00:39 +0000 (19:00 +0200)]
Fix modref's iteraction with store merging
Hi,
this patch fixes wrong code in case store-merging introduces load of function
parameter that was previously write-only (which happens for bitfields).
Without this, the whole store-merged area is consdered to be killed.
PR ipa/111613
gcc/ChangeLog:
* ipa-modref.cc (analyze_parms): Do not preserve EAF_NO_DIRECT_READ and
EAF_NO_INDIRECT_READ from past flags.
Jeff Law [Mon, 22 Jul 2024 16:11:57 +0000 (10:11 -0600)]
[4/n][PR rtl-optimization/115877] Correct SUBREG handling in a destination
If we encounter something during SET handling that we can not handle, the safe
thing to do is to ignore the destination and continue the loop.
We've actually been trying to do slightly better with SUBREG destinations by
iterating into SUBREG_REG. It turns out that wasn't working as expected.
The problem is once we "continue" we lose the state that we were inside the SET
and thus we ended up ignoring the destination completely rather than tracking
the SUBREG_REG object. This could be fixed by restarting SET processing, but I
just don't see this as all that important to handle. So rather than leave the
code as-is, not working per design, I'm twiddling it to use the common 'skip
subrtxs and continue' idiom used elsewhere.
This is a prerequisite for another patch in this series. Specifically I have a
patch that explicitly tracks if we skipped a destination rather than trying to
imply it from the state of LIVE_TMP. So this is probably NFC right now, but
that's a short-lived NFC.
Bootstrapped and regression tested on x86 and also run as part of a larger kit
on the crosses in my tester.
Jan Hubicka [Mon, 22 Jul 2024 16:08:08 +0000 (18:08 +0200)]
Fix modref_eaf_analysis::analyze_ssa_name handling of values dereferenced to function call parameters
modref_eaf_analysis::analyze_ssa_name misinterprets EAF flags. If dereferenced
parameter is passed (to map_iterator in the testcase) it can be returned
indirectly which in turn makes it to escape into the next function call.
PR ipa/115033
gcc/ChangeLog:
* ipa-modref.cc (modref_eaf_analysis::analyze_ssa_name): Fix checking of
EAF flags when analysing values dereferenced as function parameters.
Jan Hubicka [Mon, 22 Jul 2024 16:05:26 +0000 (18:05 +0200)]
Fix accounting of offsets in unadjusted_ptr_and_unit_offset
unadjusted_ptr_and_unit_offset accidentally throws away the offset computed by
get_addr_base_and_unit_offset. Instead of passing extra_offset it passes offset.
PR ipa/114207
gcc/ChangeLog:
* ipa-prop.cc (unadjusted_ptr_and_unit_offset): Fix accounting of offsets in ADDR_EXPR.
Jan Hubicka [Mon, 22 Jul 2024 16:01:57 +0000 (18:01 +0200)]
Compare loop bounds in ipa-icf
Hi,
this testcase shows another poblem with missing comparators for metadata
in ICF. With value ranges available to loop optimizations during early
opts we can estimate number of iterations based on guarding condition that
can be split away by the fnsplit pass. This patch disables ICF when
number of iteraitons does not match.
Bootstrapped/regtesed x86_64-linux, will commit it shortly
aarch64_simd_mem_operand_p checked for a memory with a POST_INC
or REG address, but it didn't check what kind of register was
being used. This meant that it allowed DImode FPRs as well as GPRs.
I wondered about rewriting it to use aarch64_classify_address,
but this one-line fix seemed simpler. The structure then mirrors
the existing early exit in aarch64_classify_address itself:
/* On LE, for AdvSIMD, don't support anything other than POST_INC or
REG addressing. */
if (advsimd_struct_p
&& TARGET_SIMD
&& !BYTES_BIG_ENDIAN
&& (code != POST_INC && code != REG))
return false;
gcc/
PR target/115969
* config/aarch64/aarch64.cc (aarch64_simd_mem_operand_p): Require
the operand to be a legitimate memory_operand.
gcc/testsuite/
PR target/115969
* gcc.target/aarch64/pr115969.c: New test.
Jeff Law [Mon, 22 Jul 2024 14:45:10 +0000 (08:45 -0600)]
[NFC][PR rtl-optimization/115877] Avoid setting irrelevant bit groups as live in ext-dce
Another patch to refine liveness computations. This should be NFC and is
designed to help debugging.
In simplest terms the patch avoids setting bit groups outside the size of a
pseudo as live. Consider a HImode pseudo, bits 16..63 for such a pseudo don't
really have meaning, yet we often set bit groups related to bits 16.63 on in
the liveness bitmaps.
This makes debugging harder than it needs to be by simply having larger bitmaps
to verify when walking through the code in a debugger.
This has been bootstrapped and regression tested on x86_64. It's also been
tested on the crosses in my tester without regressions.
Pushing to the trunk,
PR rtl-optimization/115877
gcc/
* ext-dce.cc (group_limit): New function.
(mark_reg_live): Likewise.
(ext_dce_process_sets): Use new functions.
(ext_dce_process_uses): Likewise.
(ext_dce_init): Likewise.
Fix Rejects allocatable coarray passed as a dummy argument [88624]
Coarray parameters of procedures/functions need to be dereffed, because
they are references to the descriptor but the routine expected the
descriptor directly.
PR fortran/88624
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): Treat
pointers/references (e.g. from parameters) correctly by derefing
them.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/dummy_1.f90: Add calling function trough
function.
* gfortran.dg/pr88624.f90: New test.
This implements the new target hook indicating that for AArch64 when possible
we prefer masked operations for any type vs doing LOAD + SELECT or
SELECT + STORE.
PR tree-optimization/115531
* gcc.dg/vect/vect-conditional_store_1.c: New test.
* gcc.dg/vect/vect-conditional_store_2.c: New test.
* gcc.dg/vect/vect-conditional_store_3.c: New test.
* gcc.dg/vect/vect-conditional_store_4.c: New test.
Tamar Christina [Mon, 22 Jul 2024 09:26:14 +0000 (10:26 +0100)]
middle-end: Implement conditonal store vectorizer pattern [PR115531]
This adds a conditional store optimization for the vectorizer as a pattern.
The vectorizer already supports modifying memory accesses because of the pattern
based gather/scatter recognition.
Doing it in the vectorizer allows us to still keep the ability to vectorize such
loops for architectures that don't have MASK_STORE support, whereas doing this
in ifcvt makes us commit to MASK_STORE.
Concretely for this loop:
void foo1 (char *restrict a, int *restrict b, int *restrict c, int n, int stride)
{
if (stride <= 1)
return;
for (int i = 0; i < n; i++)
{
int res = c[i];
int t = b[i+stride];
if (a[i] != 0)
res = t;
c[i] = res;
}
}
A MASK_STORE is already conditional, so there's no need to perform the load of
the old values and the VEC_COND_EXPR. This patch makes it so we generate:
Jeff Law [Sun, 21 Jul 2024 14:41:28 +0000 (08:41 -0600)]
[PR rtl-optimization/115877][2/n] Improve liveness computation for constant initialization
While debugging pr115877, I noticed we were failing to remove the destination
register from LIVENOW bitmap when it was set to a constant value. ie (set
(dest) (const_int)). This was a trivial oversight in
safe_for_live_propagation.
I don't have an example of this affecting code generation, but it certainly
could. More importantly, by making LIVENOW more accurate it's easier to debug
when LIVENOW differs from expectations.
As with the prior patch this has been tested as part of a larger patchset with
the crosses as well as individually on x86_64.
Jeff Law [Sun, 21 Jul 2024 13:36:37 +0000 (07:36 -0600)]
[PR rtl-optimization/115877] Fix livein computation for ext-dce
So I'm not yet sure how I'm going to break everything down, but this is easy
enough to break out as 1/N of ext-dce fixes/improvements.
When handling uses in an insn, we first determine what bits are set in the
destination which is represented in DST_MASK. Then we use that to refine what
bits are live in the source operands.
In the source operand handling section we *modify* DST_MASK if the source
operand is a SUBREG (ugh!). So if the first operand is a SUBREG, then we can
incorrectly compute which bit groups are live in the second operand, especially
if it is a SUBREG as well.
This was seen when testing a larger set of patches on the rl78 port
(builtin-arith-overflow-p-7 & pr71631 execution failures), so no new test for
this bugfix.
Run through my tester (in conjunction with other ext-dce changes) on the
various cross targets. Run individually through a bootstrap and regression
test cycle on x86_64 as well.
Pushing to the trunk.
PR rtl-optimization/115877
gcc/
* ext-dce.cc (ext_dce_process_uses): Restore the value of DST_MASK
for reach operand.
Mark Harmstone [Thu, 27 Jun 2024 23:36:14 +0000 (00:36 +0100)]
Output CodeView function information
Translate DW_TAG_subprogram DIEs into CodeView LF_FUNC_ID types and
S_GPROC32_ID / S_LPROC32_ID symbols. ld will then transform these into
S_GPROC32 / S_LPROC32 symbols, which map addresses to unmangled function
names.
gcc/
* dwarf2codeview.cc (enum cv_sym_type): Add new values.
(struct codeview_symbol): Add function to union.
(struct codeview_custom_type): Add lf_func_id to union.
(write_function): New function.
(write_codeview_symbols): Call write_function.
(write_lf_func_id): New function.
(write_custom_types): Call write_lf_func_id.
(add_function): New function.
(codeview_debug_early_finish): Call add_function.
Avoid undefined behaviour in build_option_suggestions
The inner loop in build_option_suggestions uses OPTION to take the
address of OPTB and use it across iterations, which is undefined
behaviour since OPTB is defined within the loop. Pull it outside the
loop to make this defined.
gcc/ChangeLog:
* opt-suggestions.cc
(option_proposer::build_option_suggestions): Pull OPTB
definition out of the innermost loop.
Andi Kleen [Wed, 24 Jan 2024 07:54:56 +0000 (23:54 -0800)]
Add tests for C/C++ musttail attributes
Some adopted from the existing C musttail plugin tests.
Also extends the ability to query the sibcall capabilities of the
target.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp:
(check_effective_target_struct_tail_call): New function.
* c-c++-common/musttail1.c: New test.
* c-c++-common/musttail12.c: New test.
* c-c++-common/musttail13.c: New test.
* c-c++-common/musttail2.c: New test.
* c-c++-common/musttail3.c: New test.
* c-c++-common/musttail4.c: New test.
* c-c++-common/musttail5.c: New test.
* c-c++-common/musttail7.c: New test.
* c-c++-common/musttail8.c: New test.
* g++.dg/musttail10.C: New test.
* g++.dg/musttail11.C: New test.
* g++.dg/musttail6.C: New test.
* g++.dg/musttail9.C: New test.
Andi Kleen [Wed, 24 Jan 2024 07:44:48 +0000 (23:44 -0800)]
C++: Support clang compatible [[musttail]] (PR83324)
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
optimizations not scaling. With musttail the interpreter can be instead
written as a sequence of smaller functions that call each other. To
avoid unbounded stack growth this requires forcing a sibling call, which
this attribute does. It guarantees an error if the call cannot be tail
called which allows the programmer to fix it instead of risking a stack
overflow. Unlike computed goto it is also type-safe.
It turns out that David Malcolm had already implemented middle/backend
support for a musttail attribute back in 2016, but it wasn't exposed
to any frontend other than a special plugin.
This patch adds a [[gnu::musttail]] attribute for C++ that can be added
to return statements. The return statement must be a direct call
(it does not follow dependencies), which is similar to what clang
implements. It then uses the existing must tail infrastructure.
For compatibility it also detects clang::musttail
Passes bootstrap and full test
gcc/c-family/ChangeLog:
* c-attribs.cc (set_musttail_on_return): New function.
* c-common.h (set_musttail_on_return): Declare new function.
Andi Kleen [Thu, 16 May 2024 02:38:43 +0000 (19:38 -0700)]
Add a musttail generic attribute to the c-attribs table
The actual handling is directly in the parser since the
generic mechanism doesn't support statement attributes,
but this gives basic error checking/detection on the attribute.
LoongArch: Organize the code related to split move and merge the same functions.
gcc/ChangeLog:
* config/loongarch/loongarch-protos.h
(loongarch_split_128bit_move): Delete.
(loongarch_split_128bit_move_p): Delete.
(loongarch_split_256bit_move): Delete.
(loongarch_split_256bit_move_p): Delete.
(loongarch_split_vector_move): Add a function declaration.
* config/loongarch/loongarch.cc
(loongarch_vector_costs::finish_cost): Adjust the code
formatting.
(loongarch_split_vector_move_p): Merge
loongarch_split_128bit_move_p and loongarch_split_256bit_move_p.
(loongarch_split_move_p): Merge code.
(loongarch_split_move): Likewise.
(loongarch_split_128bit_move_p): Delete.
(loongarch_split_256bit_move_p): Delete.
(loongarch_split_128bit_move): Delete.
(loongarch_split_vector_move): Merge loongarch_split_128bit_move
and loongarch_split_256bit_move.
(loongarch_split_256bit_move): Delete.
(loongarch_global_init): Remove the extra semicolon at the
end of the function.
* config/loongarch/loongarch.md (*movdf_softfloat): Added a new
condition TARGET_64BIT.
Thomas Schwinge [Mon, 15 Jul 2024 09:19:28 +0000 (11:19 +0200)]
GCN: Honor OpenMP 5.1 'num_teams' lower bound
Corresponding to commit 9fa72756d90e0d9edadf6e6f5f56476029925788
"libgomp, nvptx: Honor OpenMP 5.1 num_teams lower bound", these are the
GCN offloading changes to fix:
PASS: libgomp.c/../libgomp.c-c++-common/teams-2.c (test for excess errors)
[-FAIL:-]{+PASS:+} libgomp.c/../libgomp.c-c++-common/teams-2.c execution test
PASS: libgomp.c++/../libgomp.c-c++-common/teams-2.c (test for excess errors)
[-FAIL:-]{+PASS:+} libgomp.c++/../libgomp.c-c++-common/teams-2.c execution test
..., and omptests' 't-critical' test case. I've cross checked that those test
cases are the ones that regress for nvptx offloading, if I locally revert the
"libgomp, nvptx: Honor OpenMP 5.1 num_teams lower bound" changes.
Thomas Schwinge [Fri, 28 Jun 2024 12:05:04 +0000 (14:05 +0200)]
Rewrite usage comment at the top of 'gcc/passes.def'
Since Subversion r201359 (Git commit a167b052dfe9a8509bb23c374ffaeee953df0917)
"Introduce gen-pass-instances.awk and pass-instances.def", the usage comment at
the top of 'gcc/passes.def' no longer is accurate (even if that latter file
does continue to use the 'NEXT_PASS' form without 'NUM') -- and, worse, the
'NEXT_PASS' etc. in that usage comment are processed by the
'gcc/gen-pass-instances.awk' script:
--- source-gcc/gcc/passes.def 2024-06-24 18:55:15.132561641 +0200
+++ build-gcc/gcc/pass-instances.def 2024-06-24 18:55:27.768562714 +0200
[...]
@@ -20,546 +22,578 @@
/*
Macros that should be defined when using this file:
INSERT_PASSES_AFTER (PASS)
PUSH_INSERT_PASSES_WITHIN (PASS)
POP_INSERT_PASSES ()
- NEXT_PASS (PASS)
+ NEXT_PASS (PASS, 1)
TERMINATE_PASS_LIST (PASS)
*/
[...]
(That is, this is 'NEXT_PASS' for the first instance of pass 'PASS'.)
That's benign so far, but with another thing that I'll be extending, I'd
then run into an error while the script handles this comment block. ;-\
gcc/
* passes.def: Rewrite usage comment at the top.
Previously we built vector boolean constants using 1 for true
elements and 0 for false elements. This matches the predicates
produced by SVE's PTRUE instruction, but leads to a miscompilation
on AVX, where all bits of a boolean element should be set.
One option for RTL would be to make this target-configurable.
But that isn't really possible at the tree level, where vectors
should work in a more target-independent way. (There is currently
no way to create a "generic" packed boolean vector, but never say
never :)) And, if we were going to pick a generic behaviour,
it would make sense to use 0/-1 rather than 0/1, for consistency
with integer vectors.
Both behaviours should work with SVE on read, since SVE ignores
the upper bits in each predicate element. And the choice shouldn't
make much difference for RTL, since all SVE predicate modes are
expressed as vectors of BI, rather than of multi-bit booleans.
I suspect there might be some fallout from this change on SVE.
But I think we should at least give it a go, and see whether any
fallout provides a strong counterargument against the approach.
gcc/
PR middle-end/115406
* fold-const.cc (native_encode_vector_part): For vector booleans,
check whether an element is nonzero and, if so, set all of the
correspending bits in the target image.
* simplify-rtx.cc (native_encode_rtx): Likewise.
gcc/testsuite/
PR middle-end/115406
* gcc.dg/torture/pr115406.c: New test.
This patch updates the tests to "defend" this change.
While there, the scans include:
mov\tr1, r[03]}
But if the spill of r2 occurs first, there's no real reason why
r2 couldn't be used as the temporary, instead r3.
The patch tries to update the scans while preserving the spirit
of the originals.
gcc/testsuite/
* gcc.target/arm/fp16-aapcs-2.c: Expect the return value to be
loaded directly from the stack. Test that the swap generates
two moves out of r0/r1 and two moves in.
* gcc.target/arm/fp16-aapcs-4.c: Likewise.
Patrick Palka [Fri, 19 Jul 2024 17:48:12 +0000 (13:48 -0400)]
c++: xobj fn call without obj [PR115783]
The code path for rejecting an object-less call to a non-static member
function should also consider xobj member functions (so that we correctly
reject the below calls with a "cannot call member function without object"
diagnostic).
PR c++/115783
gcc/cp/ChangeLog:
* call.cc (build_new_method_call): Generalize METHOD_TYPE
check to DECL_OBJECT_MEMBER_FUNCTION_P.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-diagnostics11.C: New test.
Paul Thomas [Fri, 19 Jul 2024 15:58:33 +0000 (16:58 +0100)]
libgomp: Remove bogus warnings from privatized-ref-2.f90.
2024-07-19 Paul Thomas <pault@gcc.gnu.org>
libgomp/ChangeLog
* testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Cut
dg-note about 'a' and remove bogus warnings about its array
descriptor components being used uninitialized.
Harald Anlauf [Thu, 18 Jul 2024 19:15:48 +0000 (21:15 +0200)]
Fortran: character array constructor with >= 4 constant elements [PR103115]
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.
bpf: create modifier for mem operand for xchg and cmpxchg
Both xchg and cmpxchg instructions, in the pseudo-C dialect, do not
expect their memory address operand to be surrounded by parentheses.
For example, it should be output as "w0 =cmpxchg32_32(r8+8,w0,w2)"
instead of "w0 =cmpxchg32_32((r8+8),w0,w2)".
This patch implements an operand modifier 'M' which marks the
instruction templates that do not expect the parentheses, and adds it do
xchg and cmpxchg templates.
gcc/ChangeLog:
* config/bpf/atomic.md (atomic_compare_and_swap,
atomic_exchange): Add operand modifier %M to the first
operand.
* config/bpf/bpf.cc (no_parentheses_mem_operand): Create
variable.
(bpf_print_operand): Set no_parentheses_mem_operand variable if
%M operand is used.
(bpf_print_operand_address): Conditionally output parentheses.
Jakub Jelinek [Fri, 19 Jul 2024 06:53:47 +0000 (08:53 +0200)]
c++: Add [dcl.init.aggr] examples to testsuite
When working on the #embed optimization support, I went recently through
all of reshape_init_r* and today I read in detail all the P3106R1 changes
and I believe we implement it that way for years.
To double check that, I've added tests with the current [dcl.init.aggr]
examples but tested in all the languages from C++98 to C++26, of course
guarded as needed for constructs which require newer versions of C++.
The examples come in two tests, one is a runtime test for the non-erroneous
examples, the other is a compile time test for the diagnostics.
The former one includes mostly intact examples with runtime checking (both
to test what is written in the section exactly and to test at least
something with C++98) and then when useful also adds constexpr tests with
static_asserts for C++11 and later.
Tested on x86_64-linux and i686-linux with
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ RUNTESTFLAGS='dg.exp=aggr-init*.C'
Also tested on GCC 11 branch with
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++ RUNTESTFLAGS='dg.exp=aggr-init*.C'
where just the " is a GCC extension" part of one error is left out,
otherwise it passes the same, ditto with clang 14 (of course with different
diagnostics, but verified it emits diagnostics on the right lines), so I
believe we can claim implementation of this DR paper, either in all versions
or at least in GCC 11+.
2024-07-19 Jakub Jelinek <jakub@redhat.com>
PR c++/114460
* g++.dg/cpp26/aggr-init1.C: New test.
* g++.dg/cpp26/aggr-init2.C: New test.
This patch addresses a difference between the hash function and the equality
function for canonical types of template parameters (ctp_hasher). The equality
function uses comptypes (typeck.cc) (with COMPARE_STRUCTURAL) and checks
constraint equality for two auto nodes (typeck.cc:1586), while the hash
function ignores it (pt.cc:4528). This leads to hash collisions that can be
avoided by using `hash_placeholder_constraint` (constraint.cc:1150).
Note that due to the proper handling of hash collisions (hash-table.h:1059),
there is no test case that can distinguish the current implementation from the
proposed one.
* constraint.cc (hash_placeholder_constraint): Rename to
iterative_hash_placeholder_constraint.
(iterative_hash_placeholder_constraint): Rename from
hash_placeholder_constraint and add the initial val argument.
* cp-tree.h (hash_placeholder_constraint): Rename to
iterative_hash_placeholder_constraint.
(iterative_hash_placeholder_constraint): Renamed from
hash_placeholder_constraint and add the initial val argument.
* pt.cc (struct ctp_hasher): Updated to use
iterative_hash_placeholder_constraint in the case of a valid placeholder
constraint.
(auto_hash::hash): Reflect the renaming of hash_placeholder_constraint to
iterative_hash_placeholder_constraint.
Pattern recog to .SAT_TRUNC cannot eliminate MIN_EXPR as above. Then the
backend (for example x86/riscv) will have additional 2-3 more insns
after pattern recog besides the MIN_EXPR. Thus, keep the normal truncation
as is should be the better choose.
The below testsuites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap tests.
3. The x86 fully regression tests.
PR target/115863
gcc/ChangeLog:
* match.pd: Add single_use check for .SAT_TRUNC form 2.
Marek Polacek [Tue, 18 Jun 2024 20:49:24 +0000 (16:49 -0400)]
c++: implement DR1363 and DR1496 for __is_trivial [PR85723]
is_trivial was introduced in
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2230.html>
which split POD into is_trivial and is_standard_layout.
Later came CWG 1363. Since
struct A {
A() = default;
A(int = 42) {}
};
cannot be default-initialized, it should not be trivial, so the definition
of what is a trivial class changed.
Similarly, CWG 1496 concluded that
struct B {
B() = delete;
}:
should not be trivial either.
P0848 adjusted the definition further to say "eligible". That means
that
should not be trivial, either, since C::C() is not eligible.
Bug 85723 reports that we implement none of the CWGs.
I chose to fix this by using type_has_non_deleted_trivial_default_ctor
which uses locate_ctor which uses build_new_method_call, which would
be used by default-initialization as well. With that, all __is_trivial
problems I could find in the Bugzilla are fixed, except for PR96288,
which may need changes to trivially-copyable, so I'm not messing with
that now.
I hope this has no ABI implications. There's effort undergoing to
remove "trivial class" from the core language as it's not really
meaningful. So the impact of this change should be pretty low except
to fix a few libstdc++ problems.
* class.cc (type_has_non_deleted_trivial_default_ctor): Fix formatting.
* tree.cc (trivial_type_p): Instead of TYPE_HAS_TRIVIAL_DFLT, use
type_has_non_deleted_trivial_default_ctor.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wclass-memaccess.C: Add dg-warning.
* g++.dg/ext/is_trivial1.C: New test.
* g++.dg/ext/is_trivial2.C: New test.
* g++.dg/ext/is_trivial3.C: New test.
* g++.dg/ext/is_trivial4.C: New test.
* g++.dg/ext/is_trivial5.C: New test.
* g++.dg/ext/is_trivial6.C: New test.
Ian Lance Taylor [Thu, 18 Jul 2024 18:34:09 +0000 (11:34 -0700)]
libbacktrace: use __has_attribute for fallthrough
Also convert some FALLTHROUGH comments to ATTRIBUTE_FALLTHROUGH.
* internal.h: Use __has_attribute to check for fallthrough
attribute.
* elf.c (elf_zstd_decompress): Use ATTRIBUTE_FALLTHROUGH rather
than a FALLTHROUGH comment.
René Rebe [Fri, 12 Jul 2024 21:17:08 +0000 (21:17 +0000)]
rs6000: Fix .machine cpu selection w/ altivec [PR97367]
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.
use __int128 types that are not supported on all platforms. Update the
tests to check int128 effective target to avoid unsupported type errors
on unsupported platforms.
libatomic: Improve cpuid usage in __libat_feat1_init
Check the result of __get_cpuid and process FEAT1_REGISTER only when
__get_cpuid returns success. Use __cpuid instead of nested __get_cpuid.
libatomic/ChangeLog:
* config/x86/init.c (__libat_feat1_init): Check the result of
__get_cpuid and process FEAT1_REGISTER only when __get_cpuid
returns success. Use __cpuid instead of nested __get_cpuid.
LIU Hao [Mon, 15 Jul 2024 08:55:52 +0000 (16:55 +0800)]
Do not use caller-saved registers for COMDAT functions
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.
Richard Biener [Thu, 18 Jul 2024 11:35:33 +0000 (13:35 +0200)]
middle-end/115641 - invalid address construction
fold_truth_andor_1 via make_bit_field_ref builds an address of
a CALL_EXPR which isn't valid GENERIC and later causes an ICE.
The following simply avoids the folding for f ().a != 1 || f ().b != 2
as it is a premature optimization anyway. The alternative would
have been to build a TARGET_EXPR around the call. To get this far
f () has to be const as otherwise the two calls are not semantically
equivalent for the optimization.
PR middle-end/115641
* fold-const.cc (decode_field_reference): If the inner
reference isn't something we can take the address of, fail.
Fortran: Fix Explicit cobounds of a procedures parameter not respected [PR78466]
Explicit cobounds of class array procedure parameters were not taken
into account. Furthermore were different cobounds in distinct
procedure parameter lists mixed up, i.e. the last definition was taken
for all. The bounds are now regenerated when tree's and expr's bounds
do not match.
PR fortran/78466
PR fortran/80774
gcc/fortran/ChangeLog:
* array.cc (gfc_compare_array_spec): Take cotype into account.
* class.cc (gfc_build_class_symbol): Coarrays are also arrays.
* gfortran.h (IS_CLASS_COARRAY_OR_ARRAY): New macro to detect
regular and coarray class arrays.
* interface.cc (compare_components): Take codimension into
account.
* resolve.cc (resolve_symbol): Improve error message.
* simplify.cc (simplify_bound_dim): Remove duplicate.
* trans-array.cc (gfc_trans_array_cobounds): Coarrays are also
arrays.
(gfc_trans_array_bounds): Same.
(gfc_trans_dummy_array_bias): Same.
(get_coarray_as): Get the as having a non-zero codim.
(is_explicit_coarray): Detect explicit coarrays.
(gfc_conv_expr_descriptor): Create a new descriptor for explicit
coarrays.
* trans-decl.cc (gfc_build_qualified_array): Coarrays are also
arrays.
(gfc_build_dummy_array_decl): Same.
(gfc_get_symbol_decl): Same.
(gfc_trans_deferred_vars): Same.
* trans-expr.cc (class_scalar_coarray_to_class): Get the
descriptor from the correct location.
(gfc_conv_variable): Pick up the descriptor when needed.
* trans-types.cc (gfc_is_nodesc_array): Coarrays are also
arrays.
(gfc_get_nodesc_array_type): Indentation fix only.
(cobounds_match_decl): Match a tree's bounds to the expr's
bounds and return true, when they match.
(gfc_get_derived_type): Create a new type tree/descriptor, when
the cobounds of the existing declaration and expr to not
match. This happends for class arrays in parameter list, when
there are different cobound declarations.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/poly_run_1.f90: Activate old test code.
* gfortran.dg/coarray/poly_run_2.f90: Activate test. It was
stopping before and passing without an error.
projects / thirdparty / gcc.git / log
