Ensure for AQ and AR constraints that the resulting displacement after
adding any positive offset less than the size of the object being
referenced is still valid.
gcc/ChangeLog:
* config/s390/s390.cc (s390_mem_constraint): Check displacement
for AQ and AR constraints.
Harald Anlauf [Thu, 5 Sep 2024 19:30:25 +0000 (21:30 +0200)]
Fortran: fix ICE in gfc_create_module_variable [PR100273]
gcc/fortran/ChangeLog:
PR fortran/100273
* trans-decl.cc (gfc_create_module_variable): Handle module
variable also when it is needed for the result specification
of a contained function.
gcc/testsuite/ChangeLog:
PR fortran/100273
* gfortran.dg/pr100273.f90: New test.
In s390_expand_insv(), if generating code for ICM et al. src is a MEM
and gen_lowpart might force src into a register such that we end up with
patterns which do not match anymore. Use adjust_address() instead in
order to preserve a MEM.
Furthermore, it is not straight forward to enforce a subreg. For
example, in case of a paradoxical subreg, gen_lowpart() may return a
register. In order to compensate this, s390_gen_lowpart_subreg() emits
a reference to a pseudo which does not coincide with its definition
which is wrong. Additionally, if dest is a paradoxical subreg, then do
not try to emit a strict_low_part since it could mean that dest was not
initialized even though this might be fixed up later by init-regs.
Splitter for insn *get_tp_64, *zero_extendhisi2_31,
*zero_extendqisi2_31, *zero_extendqihi2_31 are applied after reload.
Thus, operands[0] is a hard register and gen_lowpart (m, operands[0])
just returns the hard register for mode m which is fine to use as an
argument for strict_low_part, i.e., we do not need to enforce subregs
here since after reload subregs are supposed to be eliminated anyway.
This fixes gcc.dg/torture/pr111821.c.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_gen_lowpart_subreg): Remove.
* config/s390/s390.cc (s390_gen_lowpart_subreg): Remove.
(s390_expand_insv): Use adjust_address() and emit a
strict_low_part only in case of a natural subreg.
* config/s390/s390.md: Use gen_lowpart() instead of
s390_gen_lowpart_subreg().
doc: Add more alias option and reorder Intel CPU -march documentation
This patch is backported from GCC15 with some tweaks.
Since r15-3539, there are requests coming in to add other alias option
documentation. This patch will add all of them, including corei7, corei7-avx,
core-avx-i, core-avx2, atom and slm.
Also in the patch, I reordered that part of documentation, currently all
the CPUs/products are just all over the place. I regrouped them by
date-to-now products (since the very first CPU to latest Panther Lake), P-core
(since the clients become hybrid cores, starting from Sapphire Rapids) and
E-core (since Bonnell). In GCC14 and eariler GCC, Xeon Phi CPUs are still
there, I put them after E-core CPUs.
And in the patch, I refined the product names in documentation.
gcc/ChangeLog:
* doc/invoke.texi: Add corei7, corei7-avx, core-avx-i,
core-avx2, atom, and slm. Reorder the -march documentation by
splitting them into date-to-now products, P-core, E-core and
Xeon Phi. Refine the product names in documentation.
H.J. Lu [Fri, 6 Sep 2024 12:24:07 +0000 (05:24 -0700)]
x86-64: Don't use temp for argument in a TImode register
Don't use temp for a PARALLEL BLKmode argument of an EXPR_LIST expression
in a TImode register. Otherwise, the TImode variable will be put in
the GPR save area which guarantees only 8-byte alignment.
gcc/
PR target/116621
* config/i386/i386.cc (ix86_gimplify_va_arg): Don't use temp for
a PARALLEL BLKmode container of an EXPR_LIST expression in a
TImode register.
gcc/testsuite/
PR target/116621
* gcc.target/i386/pr116621.c: New test.
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.
projects / thirdparty / gcc.git / log
