H.J. Lu [Tue, 27 Aug 2024 20:11:39 +0000 (13:11 -0700)]
ipa: Don't disable function parameter analysis for fat LTO
Update analyze_parms not to disable function parameter analysis for
-ffat-lto-objects. Tested on x86-64, there are no differences in zstd
with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".
PR ipa/116410
* ipa-modref.cc (analyze_parms): Always analyze function parameter
for LTO.
The intrin for non-optimized got a typo in mask type, which will cause
the high bits of __mmask32 being unexpectedly zeroed.
The test does not fail under O0 with current 1b since the testcase is
wrong. We need to include avx512-mask-type.h after SIZE is defined, or
it will always be __mmask8. That problem also happened in AVX10.2 testcases.
I will write a seperate patch to fix that.
gcc/ChangeLog:
* config/i386/avx512fp16intrin.h
(_mm512_mask_fpclass_ph_mask): Correct mask type to __mmask32.
(_mm512_fpclass_ph_mask): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512fp16-vfpclassph-1c.c: New test.
liuhongt [Thu, 29 Aug 2024 03:39:20 +0000 (11:39 +0800)]
Check avx upper register for parallel.
For function arguments/return, when it's BLK mode, it's put in a
parallel with an expr_list, and the expr_list contains the real mode
and registers.
Current ix86_check_avx_upper_register only checked for SSE_REG_P, and
failed to handle that. The patch extend the handle to each subrtx.
gcc/ChangeLog:
PR target/116512
* config/i386/i386.cc (ix86_check_avx_upper_register): Iterate
subrtx to scan for avx upper register.
(ix86_check_avx_upper_stores): Inline old
ix86_check_avx_upper_register.
(ix86_avx_u128_mode_needed): Ditto, and replace
FOR_EACH_SUBRTX with call to new
ix86_check_avx_upper_register.
liuhongt [Thu, 15 Aug 2024 04:54:07 +0000 (12:54 +0800)]
Align ix86_{move_max,store_max} with vectorizer.
When none of mprefer-vector-width, avx256_optimal/avx128_optimal,
avx256_store_by_pieces/avx512_store_by_pieces is specified, GCC will
set ix86_{move_max,store_max} as max available vector length except
for AVX part.
So for -mavx2, vectorizer will choose 256-bit for vectorization, but
128-bit is used for struct copy, there could be a potential STLF issue
due to this "misalign".
The patch fixes that.
gcc/ChangeLog:
* config/i386/i386-options.cc (ix86_option_override_internal):
set ix86_{move_max,store_max} to PVW_AVX256 when TARGET_AVX
instead of PVW_AVX128.
Alexandre Oliva [Wed, 26 Jun 2024 05:08:18 +0000 (02:08 -0300)]
[testsuite] [arm] [vect] adjust mve-vshr test [PR113281]
The test was too optimistic, alas. We used to vectorize shifts by
clamping the shift counts below the bit width of the types (e.g. at 15
for 16-bit vector elements), but (uint16_t)32768 >> (uint16_t)16 is
well defined (because of promotion to 32-bit int) and must yield 0,
not 1 (as before the fix).
Unfortunately, in the gimple model of vector units, such large shift
counts wouldn't be well-defined, so we won't vectorize such shifts any
more, unless we can tell they're in range or undefined.
So the test that expected the vectorization we no longer performed
needs to be adjusted. Instead of nobbling the test, Richard Earnshaw
suggested annotating the test with the expected ranges so as to enable
the optimization, and Christophe Lyon suggested a further
simplification.
Co-Authored-By: Richard Earnshaw <Richard.Earnshaw@arm.com>
for gcc/testsuite/ChangeLog
But this is only valid if pa.T is a ptrue. In other cases, the
original would set inactive elements of zd.T to 0, whereas the
combined form would copy elements from zc.T.
gcc/
PR target/114603
* config/aarch64/aarch64-sve.md (@aarch64_pred_cnot<mode>): Replace
with...
(@aarch64_ptrue_cnot<mode>): ...this, requiring operand 1 to be
a ptrue.
(*cnot<mode>): Require operand 1 to be a ptrue.
* config/aarch64/aarch64-sve-builtins-base.cc (svcnot_impl::expand):
Use aarch64_ptrue_cnot<mode> for _x operations that are predicated
with a ptrue. Represent other _x operations as fully-defined _m
operations.
gcc/testsuite/
PR target/114603
* gcc.target/aarch64/sve/acle/general/cnot_1.c: New test.
Not sure how this happend, but: svsudot is supposed to be expanded
as USDOT with the operands swapped. However, a thinko in the
expansion of svsudot meant that the arguments weren't in fact
swapped; the attempted swap was just a no-op. And the testcases
blithely accepted that.
gcc/
PR target/114607
* config/aarch64/aarch64-sve-builtins-base.cc
(svusdot_impl::expand): Fix botched attempt to swap the operands
for svsudot.
gcc/testsuite/
PR target/114607
* gcc.target/aarch64/sve/acle/asm/sudot_s32.c: New test.
Refine constraint "Bk" to define_special_memory_constraint.
For below pattern, RA may still allocate r162 as v/k register, try to
reload for address with leaq __libc_tsd_CTYPE_B@gottpoff(%rip), %rsi
which result a linker error.
Quote from H.J for why linker issue an error.
>What do these do:
>
> leaq __libc_tsd_CTYPE_B@gottpoff(%rip), %rax
> vmovq (%rax), %xmm0
>
>From x86-64 TLS psABI:
>
>The assembler generates for the x@gottpoff(%rip) expressions a R X86
>64 GOTTPOFF relocation for the symbol x which requests the linker to
>generate a GOT entry with a R X86 64 TPOFF64 relocation. The offset of
>the GOT entry relative to the end of the instruction is then used in
>the instruction. The R X86 64 TPOFF64 relocation is pro- cessed at
>program startup time by the dynamic linker by looking up the symbol x
>in the modules loaded at that point. The offset is written in the GOT
>entry and later loaded by the addq instruction.
>
>The above code sequence looks wrong to me.
gcc/ChangeLog:
PR target/116043
* config/i386/constraints.md (Bk): Refine to
define_special_memory_constraint.
The constant C must be an integral multiple of the shift value in
the above optimization. Non integral values can occur evaluating
IMAGPART_EXPR when the shadd constant is 8 and we have SFmode.
2024-08-06 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
PR target/113384
* config/pa/pa.cc (hppa_legitimize_address): Add check to
ensure constant is an integral multiple of shift the value.
Andrew Pinski [Sat, 3 Aug 2024 16:30:57 +0000 (09:30 -0700)]
sh: Don't call make_insn_raw in sh_recog_treg_set_expr [PR116189]
This was an interesting compare debug failure to debug. The first symptom
was in gcse which would produce different order of creating psedu-registers. This
was caused by a different order of a hashtable walk, due to the hash table having different
number of entries. Which in turn was due to the number of max insn being different between
the 2 runs. The place max insn uid comes from was in sh_recog_treg_set_expr which is called
via rtx_costs and fwprop would cause rtx_costs in some cases for debug insn related stuff.
Build and tested for sh4-linux-gnu.
PR target/116189
gcc/ChangeLog:
* config/sh/sh.cc (sh_recog_treg_set_expr): Don't call make_insn_raw,
make the insn with a fake uid.
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.
Paul Thomas [Thu, 18 Jul 2024 07:51:35 +0000 (08:51 +0100)]
Fortran: Suppress bogus used uninitialized warnings [PR108889].
2024-07-18 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/108889
* gfortran.h: Add bit field 'allocated_in_scope' to gfc_symbol.
* trans-array.cc (gfc_array_allocate): Set 'allocated_in_scope'
after allocation if not a component reference.
(gfc_alloc_allocatable_for_assignment): If 'allocated_in_scope'
not set, not a component ref and not allocated, set the array
bounds and offset to give zero length in all dimensions. Then
set allocated_in_scope.
gcc/testsuite/
PR fortran/108889
* gfortran.dg/pr108889.f90: New test.
i386: Use _mm_setzero_ps/d instead of _mm_avx512_setzero_ps/d for GCC13/12
In GCC13/12, there is no _mm_avx512_setzero_ps/d since it is introduced
in GCC14.
gcc/ChangeLog:
* config/i386/avx512dqintrin.h (_mm_reduce_round_sd): Use
_mm_setzero_pd instead of _mm_avx512_setzero_pd.
(_mm_reduce_round_ss): Use _mm_setzero_ps instead of
_mm_avx512_setzero_ps.
Peter Bergner [Mon, 15 Jul 2024 21:57:32 +0000 (16:57 -0500)]
rs6000: Error on CPUs and ABIs that don't support the ROP protection insns [PR114759]
We currently silently ignore the -mrop-protect option for old CPUs we don't
support with the ROP hash insns, but we throw an error for unsupported ABIs.
This patch treats unsupported CPUs and ABIs similarly by throwing an error
both both. This matches clang behavior and allows us to simplify our tests
in the code that generates our prologue and epilogue code.
2024-06-26 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/114759
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Disallow
CPUs and ABIs that do no support the ROP protection insns.
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Remove now
unneeded tests.
(rs6000_emit_prologue): Likewise.
Remove unneeded gcc_assert.
(rs6000_emit_epilogue): Likewise.
* config/rs6000/rs6000.md: Likewise.
gcc/testsuite/
PR target/114759
* gcc.target/powerpc/pr114759-3.c: New test.
Peter Bergner [Wed, 19 Jun 2024 21:07:29 +0000 (16:07 -0500)]
rs6000: ROP - Emit hashst and hashchk insns on Power8 and later [PR114759]
We currently only emit the ROP-protect hash* insns for Power10, where the
insns were added to the architecture. We want to emit them for earlier
cpus (where they operate as NOPs), so that if those older binaries are
ever executed on a Power10, then they'll be protected from ROP attacks.
Binutils accepts hashst and hashchk back to Power8, so change GCC to emit
them for Power8 and later. This matches clang's behavior.
Peter Bergner [Fri, 14 Jun 2024 19:36:20 +0000 (14:36 -0500)]
rs6000: Compute rop_hash_save_offset for non-Altivec compiles [PR115389]
We currently only compute the offset for the ROP hash save location in
the stack frame for Altivec compiles. For non-Altivec compiles when we
emit ROP mitigation instructions, we use a default offset of zero which
corresponds to the backchain save location which will get clobbered on
any call. The fix is to compute the ROP hash save location for all
compiles.
Peter Bergner [Fri, 7 Jun 2024 21:03:08 +0000 (16:03 -0500)]
rs6000: Update ELFv2 stack frame comment showing the correct ROP save location
The ELFv2 stack frame layout comment in rs6000-logue.cc shows the ROP
hash save slot in the wrong location. Update the comment to show the
correct ROP hash save location in the frame.
Richard Biener [Mon, 15 Jul 2024 11:01:24 +0000 (13:01 +0200)]
Fixup unaligned load/store cost for znver4
Currently unaligned YMM and ZMM load and store costs are cheaper than
aligned which causes the vectorizer to purposely mis-align accesses
by adding an alignment prologue. It looks like the unaligned costs
were simply left untouched from znver3 where they equate the aligned
costs when tweaking aligned costs for znver4. The following makes
the unaligned costs equal to the aligned costs.
This avoids the miscompile seen in PR115843 but it's of course not
a real fix for the issue uncovered there. But it makes it qualify
as a regression fix.
PR tree-optimization/115843
* config/i386/x86-tune-costs.h (znver4_cost): Update unaligned
load and store cost from the aligned costs.
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.
[PR115565] cse: Don't use a valid regno for non-register in comparison_qty
Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
with a register, because the value of -1 is actually a valid reference
to register 0 in the case where it has not been assigned a quantity.
Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty'
comparison in `fold_rtx' to incorrectly trigger in rare circumstances
and return true for a memory reference, making CSE consider a comparison
operation to evaluate to a constant expression and consequently make the
resulting code incorrectly execute or fail to execute conditional
blocks.
This has caused a miscompilation of rwlock.c from LinuxThreads for the
`alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()'
expression (where `thread_self' returns the thread pointer via a PALcode
call) has been decided to be always true (with `ent->comparison_qty'
using -1 for a reference to to `rwlock->__rw_writer', while register 0
holding the thread pointer retrieved by `thread_self') and code for the
false case has been optimized away where it mustn't have, causing
program lockups.
The issue has been observed as a regression from commit 08a692679fb8
("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
<https://gcc.gnu.org/ml/gcc-patches/2004-10/msg02027.html>, and up to
commit 932ad4d9b550 ("Make CSE path following use the CFG"),
<https://gcc.gnu.org/ml/gcc-patches/2006-12/msg00431.html>, where CSE
has been restructured sufficiently for the issue not to trigger with the
original reproducer anymore. However the original bug remains and can
trigger, because `comparison_qty' will still be assigned -1 for a memory
reference and the `reg_qty' member of a `cse_reg_info_table' entry will
still be assigned -1 for register 0 where the entry has not been
assigned a quantity, e.g. at initialization.
Use INT_MIN then as noted above, so that the value remains negative, for
consistency with the REGNO_QTY_VALID_P macro (even though not used on
`comparison_qty'), and then so that it should not ever match a valid
negated register number, fixing the regression with commit 08a692679fb8.
gcc/
PR rtl-optimization/115565
* cse.cc (record_jump_cond): Use INT_MIN rather than -1 for
`comparison_qty' if !REG_P.
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.
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.
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.
Code attribute bhfgq is missing a mapping for TF. This results in
unresolved iterators in assembler templates for *bswaptf.
With the TF mapping added the base mnemonics vlbr and vstbr are not
"used" anymore but only the extended mnemonics (vlbr<bhfgq> was
interpreted as vlbr; likewise for vstbr). Therefore, remove the base
mnemonics from the scheduling description, otherwise, genattrtab would
error about unknown mnemonics.
Likewise, for movtf_vr only the extended mnemonics for vrepi are used,
now, which means the base mnemonic is "unused" and has to be removed
from the scheduling description.
Similarly, we end up with unresolved iterators in assembler templates
for mulfprx23 since code attribute xdee is missing a mapping for FPRX2.
Note, this is basically a cherry pick of commit r15-2060-ga4abda934aa426
with the addition that vrepi is removed from the scheduling description,
too.
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.
Although for instructions MVI and MVIY it does not make a difference
whether the immediate is interpreted as signed or unsigned, GAS expects
unsigned immediates for instruction format SI_URD.
gcc/ChangeLog:
* config/s390/vector.md (mov<mode>): Fix output template for
movv1qi.
middle-end: Fix stalled swapped condition code value [PR115836]
emit_store_flag_1 calculates scode (swapped condition code) at the
beginning of the function from the value of code variable. However,
code variable may change before scode usage site, resulting in
invalid stalled scode value.
Move calculation of scode value just before its only usage site to
avoid stalled scode value.
PR middle-end/115836
gcc/ChangeLog:
* expmed.cc (emit_store_flag_1): Move calculation of
scode just before its only usage site.
Jonathan Wakely [Sun, 7 Jul 2024 11:22:42 +0000 (12:22 +0100)]
libstdc++: Fix _Atomic(T) macro in <stdatomic.h> [PR115807]
The definition of the _Atomic(T) macro needs to refer to ::std::atomic,
not some other std::atomic relative to the current namespace.
libstdc++-v3/ChangeLog:
PR libstdc++/115807
* include/c_compatibility/stdatomic.h (_Atomic): Ensure it
refers to std::atomic in the global namespace.
* testsuite/29_atomics/headers/stdatomic.h/115807.cc: New test.
The cpymemdi/setmemdi implementation doesn't fully support strict alignment.
Block the expansion if the alignment is less than 16 with STRICT_ALIGNMENT.
Clean up the condition when to use MOPS.
gcc/ChangeLog/
PR target/103100
* config/aarch64/aarch64.md (cpymemdi): Remove pattern condition.
(setmemdi): Likewise.
* config/aarch64/aarch64.cc (aarch64_expand_cpymem): Support
strict-align. Cleanup condition for using MOPS.
(aarch64_expand_setmem): Likewise.
projects / thirdparty / gcc.git / log
