On 4/14/22 05:10, Kewen.Lin wrote:
> Hi,
>
> The test case pr105250.c is like its related pr105140.c, which
> suffers the error with message like "{AltiVec,vector} argument
> passed to unprototyped" on powerpc and s390. So like commits
> r12-8025 and r12-8039, this fix is to add the dg-skip-if
So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename PF_ARCH14 to PF_Z16.
* config.gcc: Add z16 as march/mtune switch.
* config/s390/driver-native.cc
v2:
- Remove redundant num_zero_width_bf_seen and num_fields_seen
tracking. (Thanks Stefan Schulze-Frielinghaus)
Re-tested with testsuite and ABI tests.
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in
On 4/6/22 17:32, Segher Boessenkool wrote:
> This test fails with error "AltiVec argument passed to unprototyped
> function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
> from 2005) actually tests for any vector type argument. It also does
> not fail on Darwin, not reflected here
On 4/4/22 13:52, Robin Dapp wrote:
> Hi,
>
> some tests expect a convert instruction but nowadays the conversion is
> already done at compile time. This results in a literal-pool load.
> Change the tests accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
>
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> we have been emitting the "higher" variantes instead of the "not less or
> equal" ones for a while. Change the test expectations accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
> *
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> in gcc.dg/Wuse-after-free-2.c we try to detect a use-after-free. On
> s390 the test's while loop is converted into a rawmemchr builtin making
> it impossible to determine that the pointers *p and *q are related.
>
> Therefore, disable the tree loop
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in an FPR only if it has
exactly one member. On the other hand it says that structs of 1,2,4,8
bytes are passed in a GPR. So this struct is expected to be passed
On 3/5/22 09:33, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
> insn not being accepted by assembler.
> My rough understanding is that in the RSY-b insn format the spot
> in other formats used for index registers is used instead for M3 what
On 2/25/22 12:38, Robin Dapp wrote:
> Hi,
>
> the IF_THEN_ELSE detection currently prevents us from properly costing
> register-register moves which causes the lower-subreg pass to assume
> that a VR-VR move is as expensive as two GPR-GPR moves.
>
> This patch adds handling for SETs containing
On 2/7/22 09:11, Jakub Jelinek wrote:
...
> 1) formatting, = should be at the start of next line rather than end of the
>line
> 2) all_masks, always_inline_safe_masks and caller_required_masks aren't
>ever modified, perhaps make them const?
> 3) I wonder if there is any advantage to have
MASK_MVCLE is set for -Os but not for other optimization levels. In
general it should not make much sense to inline across calls where the
flag is different but we have to allow it for always_inline.
The patch also rearranges the hook implementation a bit based on the
recommendations from Jakub
On 2/2/22 12:57, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for
> releases/gcc-11?
>
>
>
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section
On 2/1/22 21:49, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section
When propagating a multi-word register into an access with a smaller
mode the can_change_mode backend hook is already consulted for the
original register. This however is also required for the intermediate
copy in copy_regno which might use a different register class.
Bootstrapped on x86_64 and
On 1/20/22 11:10, Robin Dapp wrote:
> Hi,
>
> this patch is a follow-up patch to the recent ifcvt changes. It
> increased costs for a load on condition to 6. This ensures that we
> if-convert sequences of three regular instructions (of cost 4) e.g. a
> compare and two SETs into two loads on
On 1/20/22 17:13, Robin Dapp wrote:
> Hi,
>
> this patch splits the CCSmode into an integer and a floating point
> variant. This allows ifcvt to consider floating point compares which
> would be rejected before because they could not be reversed.
>
> Bootstrapped and regtested on s390x.
>
> Is
On 1/20/22 23:52, Richard Sandiford wrote:
> cc:ing the x86 and s390 maintainers
>
> soeren--- via Gcc-patches writes:
>> From: Sören Tempel
>>
>> The -fsplit-stack option requires the pthread_t TCB definition in the
>> libc to provide certain struct fields at specific hardcoded offsets. As
>>
On 1/14/22 20:41, Andreas Krebbel via Gcc-patches wrote:
> On 1/14/22 08:37, Richard Biener wrote:
> ...
>> Can the gist of this bug be put into the GCC bugzilla so the rev can
>> refer to it?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
>
>> Can we have a
On 1/14/22 08:37, Richard Biener wrote:
...
> Can the gist of this bug be put into the GCC bugzilla so the rev can
> refer to it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
> Can we have a testcase even?
The testcase from Jakub is in the BZ. However, since it doesn't fail with head
I
On 1/13/22 18:11, Andreas Krebbel via Gcc-patches wrote:
...
> @@ -5949,7 +5959,7 @@ register if floating point arithmetic is not being
> done. As long as the\n\
> floating registers are not in class @code{GENERAL_REGS}, they will not\n\
> be used unless some pattern's constraint
The cprop_hardreg pass is built around the assumption that accessing a
register in a narrower mode is the same as accessing the lowpart of
the register. This unfortunately is not true for vector registers on
IBM Z. This caused a miscompile of LLVM with GCC 8.5. The problem
could not be reproduced
On 11/19/21 10:45, Stefan Schulze Frielinghaus wrote:
...
> diff --git a/gcc/testsuite/gcc.target/s390/2029.c
> b/gcc/testsuite/gcc.target/s390/2029.c
> new file mode 100644
> index 000..1a6df4f4b89
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/2029.c
> @@ -0,0 +1,12
On 11/5/21 20:34, Jeff Law wrote:
>
>
> On 11/5/2021 4:19 AM, Andreas Krebbel via Gcc-patches wrote:
>> This prevents find_cond_trap from being invoked after reload. It may
>> generate compares which would require reloading.
>>
>> Bootstrapped and reg
This prevents find_cond_trap from being invoked after reload. It may
generate compares which would require reloading.
Bootstrapped and regression tested on s390x.
Ok for mainline?
gcc/ChangeLog:
PR rtl-optimization/103028
* ifcvt.c (find_if_header): Invoke find_cond_trap only
With -fstack-check the stack probes emitted access memory below the
stack pointer.
Bootstrapped and regression tested on s390x.
Committed to mainline
gcc/ChangeLog:
* config/s390/s390.h (STACK_CHECK_MOVING_SP): New macro
definition.
---
gcc/config/s390/s390.h | 5 +
1 file
On 11/2/21 18:31, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.c (s390_loop_unroll_adjust): In case of early
> exit free bbs.
Ok. Thanks!
Andreas
On 11/2/21 15:54, Stefan Schulze Frielinghaus wrote:
> The tests require vector extensions which are only available for z13 and
> later while using the z/Architecture.
>
> Bootstrapped and regtested on IBM Z. Ok for mainline?
>
> gcc/testsuite/ChangeLog:
>
> *
On 10/30/21 12:43, Stefan Schulze Frielinghaus wrote:
> Since a recent enhancement of -Waddress a couple of warnings are emitted
> and turned into errors during bootstrap:
>
> gcc/config/s390/s390.md:12087:25: error: the address of 'operands' will never
> be NULL [-Werror=address]
> 12087 |
On 10/8/21 16:23, Stefan Schulze Frielinghaus wrote:
> On Thu, Oct 07, 2021 at 11:16:24AM +0200, Andreas Krebbel wrote:
>> On 9/20/21 11:24, Stefan Schulze Frielinghaus wrote:
>>> This patch implements the rawmemchr expander as introduced in
>>> https://gcc.gnu.org
aa; \
> + /* unaligned + 3rd load */ \
> + q[19] = pattern; \
> + assert ((rawmemchr_##T ([2]) == [19])); \
> + q[19] = (T) 0x; \
> + /* unaligned + 4th lo
On 9/30/21 10:50, Ilya Leoshkevich wrote:
> Hi,
>
> This series contains a backport of kpatch changes needed to support
> https://github.com/dynup/kpatch/pull/1203 so that it could be used in
> RHEL 9. The patches have been in master for 4 months now without
> issues.
>
> Bootstrapped and
The code sequence emitted uses CC internally.
gcc/ChangeLog:
* config/s390/tpf.md (prologue_tpf, epilogue_tpf): Add cc clobber.
---
gcc/config/s390/tpf.md | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/s390/tpf.md b/gcc/config/s390/tpf.md
index
Avoid emitting a strict low part move if the insv target actually
affects the whole target reg.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
PR target/10
* config/s390/s390.c (s390_expand_insv): Emit a normal move if it
is actually a full copy of the
This patch gets rid of the unspecs we were using for the vector merge
instruction and replaces it with generic rtx.
gcc/ChangeLog:
* config/s390/s390-modes.def: Add more vector modes to support
concatenation of two vectors.
* config/s390/s390-protos.h
gcc/ChangeLog:
* config/s390/vector.md (V_HW_64): Remove mode iterator.
(*vec_load_pair): Use V_HW_2 instead of V_HW_64.
* config/s390/vx-builtins.md
(vec_scatter_element_SI): Use V_HW_2 instead of
V_HW_64.
---
gcc/config/s390/vector.md | 7 +++
The patch gets rid of the unspec used for the vector permute double
immediate instruction and replaces it with generic rtx.
gcc/ChangeLog:
* config/s390/s390.md (UNSPEC_VEC_PERMI): Remove constant
definition.
* config/s390/vector.md (*vpdi1, *vpdi4): New pattern
.
As expected various occurrences of the vperm instruction get replaced
with vmr* and vpdi.
I'll commit the patches after giving it a few days for comments.
Andreas Krebbel (5):
IBM Z: Get rid of vec merge unspec
IBM Z: Get rid of vpdi unspec
IBM Z: Remove redundant V_HW_64 mode iterator.
IBM Z
This patch makes use of the vector permute double immediate
instruction for constant permute vectors.
gcc/ChangeLog:
* config/s390/s390.c (expand_perm_with_vpdi): New function.
(vectorize_vec_perm_const_1): Call expand_perm_with_vpdi.
* config/s390/vector.md (*vpdi1,
This patch implements the TARGET_VECTORIZE_VEC_PERM_CONST in the IBM Z
backend. The initial implementation only exploits the vector merge
instruction but there is more to come.
gcc/ChangeLog:
* config/s390/s390.c (MAX_VECT_LEN): Define macro.
(struct expand_vec_perm_d): Define
On 7/23/21 2:47 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/global-array-element-pic2.c: Add -mzarch, add
> an expectation for 31-bit mode.
> *
On 7/28/21 9:43 AM, Richard Biener wrote:
> On Wed, Jul 28, 2021 at 8:44 AM Andreas Krebbel via Gcc-patches
> wrote:
>>
>> There are also memory operands passed for in0 and in1.
>>
>> Ok for mainline?
>
> They can also be constant vectors, I'd just not
On 7/27/21 10:04 PM, Ilya Leoshkevich via Gcc-patches wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> libsanitizer/ChangeLog:
>
> * configure.tgt (s390*-*-linux*): Enable LSan and TSan for
> s390x.
Ok. Thanks!
Andreas
There are also memory operands passed for in0 and in1.
Ok for mainline?
gcc/ChangeLog:
* target.def: Describe in0 and in1 as being either register or
memory operands.
* doc/tm.texi: Regenerate.
---
gcc/doc/tm.texi | 7 ---
gcc/target.def | 7 ---
2 files
On 7/12/21 9:23 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573614.html
> v1 -> v2: Do not use UNSPEC_PLT in 64-bit code and rename it to
> UNSPEC_PLT31 (Ulrich, Andreas). Do
On 6/24/21 12:42 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573348.html
> v1 -> v2: Use ATTRIBUTE_UNUSED, compact op[] array (Andreas).
> I've also noticed that one of the
On 6/22/21 12:20 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> s390 glibc does not need counters in the .data section, since it stores
> edge hits in its own data structure. Therefore counters only waste
> space and confuse diffing
On 6/9/21 2:47 PM, Robin Dapp wrote:
>> I think the real problem is the expander name. That's why it could not be
>> found by optab. The second
>> mode needs to be the int vector mode of op3. With that change the testcases
>> work as expected:
>>
>> diff --git a/gcc/config/s390/vector.md
On 6/2/21 4:21 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> Since commit dd1ef00c45ba ("Fix bug in the define_subst handling that
> made match_scratch unusable for multi-alternative patterns.") the
> workaround for that bug in
_Bool needs to be defined as macro in order to trigger the
context-sensitive macro expansion mechanism.
Bootstrapped and regtested on s390x.
Committed to mainline.
gcc/ChangeLog:
* config/s390/s390-c.c (s390_cpu_cpp_builtins_internal): Define
_Bool as macro expanding to _Bool.
v1 -> v2: build_reference_type_for_mode and build_pointer_type_for_mode now
pick pointer mode if
MODE argument is VOIDmode.
Bootstrapped and regression tested on x86_64 and s390x.
Ok for mainline and GCC 11?
Andreas
gcc/cp/ChangeLog:
PR c++/100281
* cvt.c
Ping
On 4/30/21 8:32 AM, Andreas Krebbel via Gcc-patches wrote:
> The problem appears to be triggered by two locations in the front-end
> where non-POINTER_SIZE pointers aren't handled right now.
>
> 1. An assertion in strip_typedefs is triggered because the alignment
> of the ty
Hi Robin,
On 5/5/21 5:18 PM, Robin Dapp wrote:
...
> diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
> index c80d582a300..7c730432d80 100644
> --- a/gcc/config/s390/vector.md
> +++ b/gcc/config/s390/vector.md
> @@ -36,6 +36,7 @@
> (define_mode_iterator V_HW2 [V16QI V8HI V4SI
On 5/4/21 5:08 PM, Robin Dapp wrote:
> Hi,
>
> instead of selecting bits 62 to (wraparound) 59 from r2 and inserting
> them into r3, we select bits 60 to 62 from r3 and insert them into r2
> nowadays. Adjust the test accordingly.
>
> Is this OK?
>
> Regards
> Robin
>
>
On 5/6/21 9:56 AM, Marius Hillenbrand wrote:
> Hi,
>
> this patch fixes the check of immediate operands to the builtin vec_permi and
> adds a new test for this built-in.
>
> Reg-rested and bootstrapped on s390x.
>
> Is it OK for master? Is it OK for backporting to gcc-11?
>
> Regards,
> Marius
On 5/3/21 1:09 PM, Ilya Leoshkevich wrote:
> On Fri, 2021-04-30 at 08:49 +0200, Andreas Krebbel wrote:
>> On 4/28/21 3:48 AM, Ilya Leoshkevich wrote:
>>> Bootstrapped and regtested on s390x-redhat-linux. Tested with
>>> valgrind
>>> too (PR 100278 is no
On 4/28/21 3:48 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Tested with valgrind
> too (PR 100278 is now fixed). Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568771.html
> v1 -> v2: Use the UNSPEC pattern, which is less
The problem appears to be triggered by two locations in the front-end
where non-POINTER_SIZE pointers aren't handled right now.
1. An assertion in strip_typedefs is triggered because the alignment
of the types don't match. This in turn is caused by creating the new
type with build_pointer_type
On 4/28/21 10:12 AM, Richard Biener wrote:
> On Wed, Apr 28, 2021 at 8:54 AM Andreas Krebbel via Gcc-patches
> wrote:
>>
>> The problem appears to be triggered by two locations in the front-end
>> where non-POINTER_SIZE pointers aren't handled right now.
>>
>&g
On 4/28/21 10:22 AM, Andreas Krebbel via Gcc-patches wrote:
> On 4/28/21 10:12 AM, Richard Biener wrote:
>> On Wed, Apr 28, 2021 at 8:54 AM Andreas Krebbel via Gcc-patches
>> wrote:
>>>
>>> The problem appears to be triggered by two locations in the front-end
&g
On 4/28/21 10:12 AM, Richard Biener wrote:
> On Wed, Apr 28, 2021 at 8:54 AM Andreas Krebbel via Gcc-patches
> wrote:
>>
>> The problem appears to be triggered by two locations in the front-end
>> where non-POINTER_SIZE pointers aren't handled right now.
>>
>&g
The problem appears to be triggered by two locations in the front-end
where non-POINTER_SIZE pointers aren't handled right now.
1. An assertion in strip_typedefs is triggered because the alignment
of the types don't match. This in turn is caused by creating the new
type with build_pointer_type
With the current handling of decl alignments it is impossible to
reduce the alignment requirement as part of a variable declaration.
This change has been proposed by Richard in the PR. It fixes the
align-1.c testcase on IBM Z.
Bootstrapped on x86_64 and s390x. No regressions.
Ok for mainline?
On 4/20/21 9:17 AM, Stefan Schulze Frielinghaus wrote:
> Depending on whether GCC is configured using --with-mode=zarch or not,
> for the 31bit target instructions are generated either for ESA or
> z/Architecture. For the sake of simplicity and robustness test only for
> the latter by adding
On 4/16/21 3:59 PM, Robin Dapp wrote:
> Hi,
>
> checking for an osc break is somewhat brittle especially with many
> passes potentially introducing new insns and moving them around.
> Therefore, only run the test with -O1 -fschedule-insns in order to limit
> the influence of other passes.
Yeah,
On 4/12/21 3:40 PM, Stefan Schulze Frielinghaus wrote:
> Bootstraped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
> alternative in order to load a DFP zero.
Ok, thanks!
Andreas
> ---
>
This fixes the error checking for two of the vector builtins which
accept irregular (e.g. non-contigiuous) ranges of values.
Regression tested on s390x (--with-arch=arch13).
Applied to mainline. Needs to go into 9 and 10 branch as well.
gcc/ChangeLog:
* config/s390/s390-builtins.def
On 4/12/21 3:40 PM, Stefan Schulze Frielinghaus wrote:
> Bootstraped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
> alternative in order to load a DFP zero.
Ok. Thanks!
Andreas
> ---
>
On 3/30/21 12:43 PM, Jakub Jelinek wrote:
> Hi!
>
> These test FAIL on s390*:
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:
> In function 'foo8':
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:71:1:
>
On 3/16/21 1:16 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> When a long double is passed to an asm statement with a "+fvm"
> constraint, a LRA loop occurs. This happens, because LRA chooses the
> widest register class in this case
gcc/ChangeLog:
* config/s390/s390.c (struct s390_processor processor_table):
Binutils name string must not be empty.
---
gcc/config/s390/s390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index
Due to a common code change the comparison in the testcase is emitted
via vec_cmp instead of vcond. The testcase checks for an optimization
currently only available via vcond.
Fixed by implementing the same optimization also in
s390_expand_vec_compare.
Bootstrapped and regression tested on
On 3/4/21 3:08 PM, Ilya Leoshkevich wrote:
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563799.html
> v1 -> v2:
> - Handle constraint modifiers, use AR constraint instead of R, add
> testcases for & and %.
>
> v2:
On 3/3/21 11:50 AM, Ilya Leoshkevich wrote:
> On Wed, 2021-03-03 at 07:50 +0100, Andreas Krebbel wrote:
>> On 3/2/21 11:59 PM, Ilya Leoshkevich wrote:
>>> mul-signed-overflow-*.c execution tests fail on z13, because they
>>> contain z14-specific instructions. F
On 3/2/21 11:59 PM, Ilya Leoshkevich wrote:
> mul-signed-overflow-*.c execution tests fail on z13, because they
> contain z14-specific instructions. Fix by requiring s390_z14_hw
> target.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/mul-signed-overflow-1.c: Run only on z14+.
>
This adds support for 5 new builtins.
gcc/ChangeLog:
* config/s390/s390-builtin-types.def (BT_FN_V4SF_V8HI_UINT): New
builtin signature.
(BT_FN_V8HI_V8HI_UINT): Likewise.
(BT_FN_V8HI_V4SF_V4SF_UINT): Likewise.
* config/s390/s390-builtins.def (B_NNPA): New
Prepare GCC for a future architecture extension.
gcc/ChangeLog:
* common/config/s390/s390-common.c (processor_flags_table): New entry.
* config.gcc: Enable arch14 for --with-arch and --with-tune.
* config/s390/driver-native.c (s390_host_detect_local_cpu): Pick
gcc/testsuite/ChangeLog:
* gcc.target/s390/mul-signed-overflow-1.c: Run only on z14.
* gcc.target/s390/mul-signed-overflow-2.c: Run only on z14.
---
gcc/testsuite/gcc.target/s390/mul-signed-overflow-1.c | 2 +-
gcc/testsuite/gcc.target/s390/mul-signed-overflow-2.c | 2 +-
2 files
On 3/1/21 5:00 PM, Stefan Schulze Frielinghaus wrote:
> As of commit 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1 expressions
> x CMP y ? -1 : 0 are fold into x CMP y. Due to this we do not see
> shifts anymore after expand in our testcases but comparisons. Thus
> replace instructions vesraX by
On 2/18/21 1:57 PM, Ilya Leoshkevich wrote:
> This series fixes PR99134. Patch 1 is factored out from the pending
> [1], patch 2 is the actual fix. Bootstrapped and regtested on
> s390x-redhat-linux. Ok for master?
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html
>
>
On 1/18/21 10:54 PM, Ilya Leoshkevich wrote:
...
> +static rtx_insn *
> +s390_md_asm_adjust (vec , vec ,
> + vec _modes,
> + vec , vec & /*clobbers*/,
> + HARD_REG_SET & /*clobbered_regs*/)
> +{
> + if (!TARGET_VXE)
> +/* Long doubles are
d side of the vector -
in this case the zeroes.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2021-01-11 Andreas Krebbel
* tree-ssa-forwprop.c (simplify_vector_constructor): For
big-endian, use UNPACK[_FLOAT]_HI.
---
gcc/tree-ssa-forwprop.c | 21 +--
On 1/8/21 5:35 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> The destination register is only partially overwritten, so + should be
> used instead of =.
>
> gcc/ChangeLog:
>
> 2021-01-08 Ilya Leoshkevich
>
> *
On 1/8/21 2:14 PM, Ilya Leoshkevich wrote:
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563034.html
> v1 -> v2: Use TARGET_VXE_P instead of TARGET_Z14_P.
>
>
>
> Give end users the opportunity to find out whether long doubles are
> stored in floating-point register pairs or in
On 1/8/21 1:17 AM, Ilya Leoshkevich wrote:
> + s390_def_or_undef_macro (
> + pfile,
> + [] (const struct cl_target_option *opts) { return TARGET_Z14_P (opts);
> },
> + old_opts, opts, "__LONG_DOUBLE_VX__", "__LONG_DOUBLE_VX__");
Shouldn't this rather check TARGET_VXE_P instead?
On 1/5/21 7:37 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on z14. Ok for master?
>
>
>
> Commit 2f473f4b065d ("IBM Z: Do not run long double tests on old
> machines") introduced a predicate for tests that must run only on z14+.
> However, due to a syntax error, the predicate
On 12/3/20 2:22 AM, Ilya Leoshkevich wrote:
> According to
> https://gcc.gnu.org/pipermail/gcc/2020-November/234344.html, GCC is
> allowed to perform optimizations that remove floating point traps,
> since they do not affect the modeled control flow. This interferes with
> two signaling
In s390.c we are still using Pmode for the stack probes. This breaks
with -m31 -mzarch where Pmode != word_mode.
The patch also adds a new target check to s390.exp which allows us to
implement zarch specific checks in the testcases.
Bootstrapped and regression tested on s390x with and without
The probe pattern uses Pmode but the middle-end wants to emit a
word_mode probe check. This - as usual - breaks on Z with -m31 -mzarch
were word_mode doesn't match Pmode.
Bootstrapped and regression-tested on s390x.
gcc/ChangeLog:
* config/s390/s390.md ("@probe_stack2"): Change mode
On 12/2/20 4:08 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560822.html
>
> v1 -> v2:
> - Use SYMBOL_REF_P.
> - Fix usage of gcc_assert.
> - Use GEN_INT.
>
>
>
> Currently GCC
On 12/2/20 2:34 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtesed on s390x-redhat-linux. There are slight
> improvements in all SPEC benchmarks, no regressions that could not be
> "fixed" by adding nops. Ok for master?
>
>
>
> Currently GCC loads large immediates into GPRs from the
On 11/25/20 6:06 PM, Marius Hillenbrand wrote:
> Add two test cases that check for acceptable combinations of float_t and
> FLT_EVAL_METHOD on s390x.
>
> Tested against an as-is glibc and one modified so that it derives
> float_t from FLT_EVAL_METHOD.
>
> gcc/testsuite/ChangeLog:
>
> 2020-11-25
On 11/25/20 6:06 PM, Marius Hillenbrand wrote:
> Historically, float_t has been defined as double on s390 and gcc would
> emit double precision insns for evaluating float expressions when in
> standard-compliant mode. Configure that behavior at compile-time as prep
> for changes in glibc: When
On 24.11.20 12:55, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> Commit 5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in
> vec_cmp") made it possible to create rtxes that describe signaling
> comparisons on z13, which are not
On 23.11.20 22:38, Ilya Leoshkevich wrote:
> Commit 229752afe315 ("VEC_COND_EXPR optimizations") has improved code
> generation: we no longer need "vx x,x,-1", which turned out to be
> superfluous. Instead, we simply swap 0 and -1 arguments of the
> preceding "vsel".
>
> gcc/testsuite/ChangeLog:
On 13.11.20 23:23, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on z13 s390x-redhat-linux. Ok for master?
>
> gcc/testsuite/ChangeLog:
>
> 2020-11-12 Ilya Leoshkevich
>
> * gcc.target/s390/s390.exp (check_effective_target_s390_z14_hw):
> New predicate.
> *
On 12.11.20 13:21, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for master?
>
> gcc/ChangeLog:
>
> * config/s390/vector.md ("vec_vfees"): New insn pattern.
> ---
> gcc/config/s390/vector.md | 26 ++
> 1 file changed, 26
On 12.11.20 13:25, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for master?
>
> gcc/ChangeLog:
>
> * config/s390/vx-builtins.md ("*vfees"): Fix output
> template.
> ---
> gcc/config/s390/vx-builtins.md | 2 +-
> 1 file changed, 1 insertion(+), 1
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
PR target/97326
* config/s390/vector.md: Support vector floating point modes in
vec_cmp.
---
gcc/config/s390/vector.md | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git
Just a preparation to add a lower-case tointvec.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
* config/s390/vector.md: Rename tointvec to TOINTVEC.
* config/s390/vx-builtins.md: Likewise.
---
gcc/config/s390/vector.md | 142 -
101 - 200 of 1039 matches
Mail list logo
