On 5/8/24 10:06, Stefan Schulze Frielinghaus wrote:
> Consider a NOCE conversion as profitable if there is at least one
> conditional move.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (TARGET_NOCE_CONVERSION_PROFITABLE_P):
> Define.
> (s390_noce_conversion_profitable_p):
On 4/30/24 10:34, Stefan Schulze Frielinghaus wrote:
> Starting with r14-2047-gd0e891406b16dc we see through subregs which
> means for f10 in risbg-ll-2.c we do not end up with rosbg_si_noshift but
> rather rosbg_di_noshift which materializes in slightly different start
> index. This saves us an
On 4/30/24 10:32, Stefan Schulze Frielinghaus wrote:
> Starting with r12-2731-g96146e61cd7aee we do not generate code like
>
> _5 = (unsigned int) c_2(D);
> i_6 = _5 << 8;
> _7 = _5 << 20;
> i_8 = i_6 | _7;
>
> anymore but instead
>
> _5 = (unsigned int) c_2(D);
> _3 = _5 * 1048832;
>
> which
The requirements of the vec_xl/vec_xst intrinsincs wrt aliasing of the
pointer argument are not really documented. As it turns out, users
are likely to get it wrong. With this patch we let the pointer
argument alias everything in order to make it more robust for users.
Committed to mainline.
We currently enable the vector extensions also for -march=z13 -m31
mesa which is very wrong.
Not a regression but an obvious fix, so I've committed it to mainline
now. Will have to cherry-pick it for stable branches as well.
gcc/ChangeLog:
* config/s390/s390.cc
Hi Stefan,
due to that missed optimization we currently generate silly code for these two
tests and should
really fix this (after gcc entering stage1). So just skipping it on s390x would
definitely be the
wrong choice I think.
I think our vectorize_vec_perm_const correctly rejects this permute
On 4/22/24 08:01, Stefan Schulze Frielinghaus wrote:
> Starting with r14-9316-g7890836de20912 patterns for vpopct{b,h} are also
> detected. Thus, remove xfails.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/vxe/popcount-1.c: Remove xfail.
Ok. Thanks!
Andreas
> ---
> Ok for
On 4/17/24 03:52, Jiufu Guo wrote:
>
> Hi,
>
> I would like to ping this patch.
>
>
> Jeff (Jiufu Guo)
>
> Jiufu Guo writes:
>
>> Hi,
>>
>> Same like PR101168, this patch is need for s390 to
>> avoid peeking eof after vector keyword.
>> And similar test case is also ok for s390.
>>
>> Is
On 4/12/24 10:16, Stefan Schulze Frielinghaus wrote:
> As mentioned in PR114678 those failures will be fixed by
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html
> For GCC 14 just xfail them which should be reverted once the patch is
> applied.
>
> gcc/testsuite/ChangeLog:
>
>
On 4/9/24 16:31, Juergen Christ wrote:
> Loop vectorizer can generate vector permutes with constant indexes
> where all indexes are equal. Optimize this case to use vector
> replicate instead of vector permute.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (expand_perm_as_replicate):
On 4/8/24 13:43, Ilya Leoshkevich wrote:
> On Sat, 2024-04-06 at 18:58 +0200, Jakub Jelinek wrote:
>> Hi!
>>
>> The following testcase is miscompiled, because we have initially
>> a movti which loads the 0x3f803f80ULL TImode constant
>> from constant pool. Later on we split it into a pair
On 4/4/24 14:22, Jakub Jelinek wrote:
> On Thu, Apr 04, 2024 at 02:19:08PM +0200, Andreas Krebbel wrote:
>> On 4/4/24 13:38, Ilya Leoshkevich wrote:
>>> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>>>
>>>
>>> libsaniti
On 4/4/24 13:38, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
> libsanitizer/ChangeLog:
>
> * sanitizer_common/sanitizer_linux_s390.cpp (AvoidCVE_2016_2143):
> Do not mention MSan and DFSan, which are not supported by GCC.
Ok,
On 3/22/24 10:49, Stefan Schulze Frielinghaus wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/backprop-6.c: On s390 we also have a copysign
> optab for long double. Thus, scan 3 instead of 2 times for it.
> ---
> OK for mainline?
Ok. Thanks!
Andreas
On 3/21/24 15:41, Stefan Schulze Frielinghaus wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/abs-4.c: On s390 we also have a copysign optab
> for long double. Thus, scan 3 instead of 2 times for it.
> ---
> Ok for mainline?
Ok. Thanks!
Andreas
With this fix we make sure that only symbols with a natural alignment
smaller than 2 are considered misaligned with
-munaligned-symbols. Background is that -munaligned-symbols is only
supposed to affect symbols whose natural alignment wouldn't be enough
to fulfill our ABI requirement of having all
On 3/1/24 16:57, Stefan Schulze Frielinghaus wrote:
> According to IBM Open XL C/C++ for z/OS version 1.1 builtins
>
> - vec_permi
> - vec_ctd
> - vec_ctsl
> - vec_ctul
> - vec_ld2f
> - vec_st2f
>
> are deprecated. Also deprecate helper builtins vec_ctd_s64 and
> vec_ctd_u64.
>
> Furthermore,
On 3/1/24 10:29, Stefan Schulze Frielinghaus wrote:
> Similar as to s390_lcbb, s390_vll, s390_vstl, et al. make use of a
> signed vector type for vlbb. Furthermore, a const void pointer seems
> more common and an integer for the mask.
>
> For s390_vfi(s,d)b make use of integers for masks, too.
>
On 2/29/24 13:15, Stefan Schulze Frielinghaus wrote:
> Starting with r14-8319-g86de9b66480b71 fwprop improved so that vpdi is
> no longer required.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/vector/long-double-to-i64.c: Fix scan
> assembler directive.
Should we perhaps
On 2/29/24 13:14, Stefan Schulze Frielinghaus wrote:
> Starting with r14-2047-gd0e891406b16dc two SI mode tests are optimized
> into DI mode. Thus, the scan-assembler directives fail. For example
> RTL expression
>
> (ior:SI (subreg:SI (lshiftrt:DI (reg:DI 69)
> (const_int 2 [0x2]))
On 2/29/24 13:13, Stefan Schulze Frielinghaus wrote:
> RTX X must not necessarily be a SYMBOL_REF and may e.g. be an
> UNSPEC_GOTENT for which SYMBOL_FLAG_NOTALIGN2_P fails.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_secondary_reload): Guard
> SYMBOL_FLAG_NOTALIGN2_P.
Ok.
On 2/19/24 13:39, Ilya Leoshkevich wrote:
> DSE, DCE, and other passes are removing redundant signaling comparisons
> from these tests, but the whole point is to check that GCC knows how to
> emit them. Use -fno-delete-dead-exceptions to prevent that.
>
> gcc/testsuite/ChangeLog:
>
> *
On 1/11/24 14:58, Richard Biener wrote:
> The following adds guards avoiding code generation to
> expand_perm_as_a_vlbr_vstbr_candidate when d.testing_p.
>
> Built and tested on the testcase in the PR.
>
> OK to push as obvious? Otherwise please pick up, test and push.
Ok to commit now. Thanks
With the recently introduced -munaligned-symbols option byte-sized
variables which are resolved externally are considered to be
potentially misaligned.
However, this should rather also be applied to symbols which resolve
locally if they are weak. Done with this patch.
Committed to mainline.
On 12/4/23 11:14, Stefan Schulze Frielinghaus wrote:
> Add missing "s390" while expanding vec_step to __builtin_s390_vec_step.
>
> gcc/ChangeLog:
>
> * config/s390/vecintrin.h (vec_step): Expand vec_step to
> __builtin_s390_vec_step.
Ok, Thanks!
Andreas
On 12/3/23 19:36, Jakub Jelinek wrote:
> Hi!
>
> I've noticed this test regressed on s390x-linux with the addition of the
> switch to modern C patchset. Haven't tried to reproduce the ICE, but as it
> was a backend ICE and FE after warning used to add such casts before (now
> errors), I think
On 11/30/23 16:45, Juergen Christ wrote:
> Commit 466b100e5fee808d77598e0f294654deec281150 introduced a bug in
> s390_md_asm_adjust if vector extensions are not available. Fix the control
> flow of this function to not adjust long double values.
>
> gcc/ChangeLog:
>
> *
On 11/30/23 17:34, Jakub Jelinek wrote:
> On Wed, Nov 29, 2023 at 07:27:20PM +0100, Jakub Jelinek wrote:
>> Given that the s390 backend defines pretty much the same target hook
>> as rs6000, I believe it suffers (at least when using -mvx?) the same
>> problem as rs6000, though admittedly this is
On 11/27/23 13:38, Stefan Schulze Frielinghaus wrote:
> One builtin type slipped through the cracks of the last commits.
>
> Bootstrapped on s390. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390-builtin-types.def (BT_FN_UV8HI_UV8HI_UINT):
> Add missing builtin type.
Ok
On 11/27/23 10:53, Stefan Schulze Frielinghaus wrote:
> Commit 248df13b966f46649e16dc3c8c92b263790ef503 restricted the rotate
> count to immediates. Although the documentation of vec_rli (Vector
> Element Rotate Left Immediate) can be read as if it where restricted to
> immediates, this is not
Ok, thanks!
Andreas
On 11/27/23 10:12, Stefan Schulze Frielinghaus wrote:
> Ping.
>
> On Thu, Nov 16, 2023 at 01:07:30PM +0100, Stefan Schulze Frielinghaus wrote:
>> For the opaque NNP-data type prefer unsigned over signed integer types.
>>
>> gcc/ChangeLog:
>>
>> *
Ok, thanks!
Andreas
On 11/27/23 10:12, Stefan Schulze Frielinghaus wrote:
> Ping.
>
> On Wed, Oct 25, 2023 at 11:27:33AM +0200, Stefan Schulze Frielinghaus wrote:
>> Currently for an unsigned 16-bit comparison between memory and an
>> immediate where the high bit is set, a clc is emitted. This
Ok, thanks!
Andreas
On 11/27/23 10:11, Stefan Schulze Frielinghaus wrote:
> Ping.
>
> On Tue, Nov 14, 2023 at 04:19:59PM +0100, Stefan Schulze Frielinghaus wrote:
>> Remove flags for non-existing operands 2 and 3.
>>
>> Bootstrapped on s390. Ok for mainline?
>>
>> gcc/ChangeLog:
>>
>> *
On 11/15/23 14:15, Juergen Christ wrote:
> Implement flags output for inline assemblies. Only use one output constraint
> that captures the whole condition code. No breakout into different condition
> codes is allowed. Also, only one condition code variable is allowed.
>
> Add further logic to
On 11/15/23 14:15, Juergen Christ wrote:
> Issue two loads when using GPRs instead of one load-multiple.
>
> Bootstrapped and tested on s390. OK for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md: Split TImode loads.
>
> gcc/testsuite/ChangeLog:
>
> *
On 11/15/23 14:12, Juergen Christ wrote:
> When using GNU vector extensions, an access outside of the vector size
> caused an ICE on s390. Fix this by aligning with the vec_extract
> builtin, i.e., computing constant index modulo number of lanes.
>
> Fixes testcase gcc.target/s390/pr89233.c.
>
On 11/15/23 14:29, Stefan Schulze Frielinghaus wrote:
> By default the preprocessed output includes linemarkers. This leads to
> an error if -pedantic is used as e.g. during bootstrap:
>
> s390-gen-builtins.h:1:3: error: style of line directive is a GCC extension
> [-Werror]
>
> Fixed by
On 11/14/23 12:44, Stefan Schulze Frielinghaus wrote:
> The offset for vec_scatter_element of floats should be a vector of type
> UV4SI instead of V4SF. Note, this is an incompatibility change.
>
> Bootstrapped on s390. Ok for mainline?
>
> gcc/ChangeLog:
>
> *
This adds GTY markers to s390_builtin_types, s390_builtin_fn_types,
and s390_builtin_decls. These were missing causing problems in
particular when using builtins after including a precompiled header.
Unfortunately the declaration of these data structures use enum values
from s390-builtins.h.
s390_resolve_overloaded_builtin, when called on NON_DEPENDENT_EXPR,
ICEs when using the type from it which ends up as error_mark_node.
This particular instance of the problem does not occur anymore since
NON_DEPENDENT_EXPR has been removed. Nevertheless that case needs to
be handled here.
On 11/9/23 09:24, Stefan Schulze Frielinghaus wrote:
> For patterns which make use of two modes, do not build the cross product
> and then exclude illegal combinations via conditions but rather do not
> create those in the first place. Here we are following the idea of the
> attribute
On 11/9/23 09:22, Stefan Schulze Frielinghaus wrote:
> Replace expand_perm_with_rot, expand_perm_with_vster, and
> expand_perm_with_vstbrq with a general implementation
> expand_perm_reverse_elements.
>
> Bootstrapped and regtested on s390. Ok for mainline?
>
> gcc/ChangeLog:
>
> *
On 11/9/23 09:22, Stefan Schulze Frielinghaus wrote:
> Replace UNSPEC_VEC_ELTSWAP with a vec_select implementation.
>
> Furthermore, for a vector reverse elements operation between registers
> of mode V8HI perform three rotates instead of a vperm operation since
> the latter involves loading the
On 11/9/23 09:22, Stefan Schulze Frielinghaus wrote:
> Deal with cases where vpdi and vmr{l,h} are still applicable if the
> operands of those instructions are swapped. For example, currently for
>
> V2DI foo (V2DI x)
> {
> return (V2DI) {x[1], x[0]};
> }
>
> the assembler sequence
>
> vlgvg
On 10/25/23 16:50, Juergen Christ wrote:
> Transactional and non-transactional stores to the same cache line cause
> transactions to abort on newer generations. Add sufficient padding to make
> sure another cache line is used.
>
> Tested on s390.
>
> gcc/testsuite/ChangeLog:
>
> *
On 10/16/23 13:20, Stefan Schulze Frielinghaus wrote:
> The normal form of a CONST_INT which represents an integer of a mode
> with fewer bits than in HOST_WIDE_INT is sign extended. This even holds
> for unsigned integers.
>
> This fixes an ICE during cse1 where we bail out at rtl.h:2297 since
On 10/5/23 08:46, Stefan Schulze Frielinghaus wrote:
> gcc/ChangeLog:
>
> * config/s390/s390.md: Make use of new copysign RTL.
Ok. Thanks!
Andreas
> ---
> gcc/config/s390/s390.md | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/config/s390/s390.md
On 9/11/23 08:56, Stefan Schulze Frielinghaus wrote:
> On Mon, Aug 28, 2023 at 11:33:37AM +0200, Andreas Krebbel wrote:
>> Hi Stefan,
>>
>> do you really need to introduce a new flag for U64 given that the type of
>> the builtin is unsigned long?
>
>
Hi Stefan,
do you really need to introduce a new flag for U64 given that the type of the
builtin is unsigned long?
Andreas
On 8/21/23 17:56, Stefan Schulze Frielinghaus wrote:
> The second argument of these builtins is an unsigned immediate. For
> vec_rli the API allows immediates up to 64
On 8/21/23 17:58, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on s390. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390-builtins.def (s390_vec_signed_flt): Fix
> builtin flag.
> (s390_vec_unsigned_flt): Ditto.
> (s390_vec_revb_flt): Ditto.
>
On 8/3/23 08:51, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on s390x. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (expand_perm_as_a_vlbr_vstbr_candidate):
> New function which handles bswap patterns for vec_perm_const.
>
On 8/3/23 08:48, Stefan Schulze Frielinghaus wrote:
> This enables the following tests which rely on instruction vperm which
> is available since z13 with the initial vector support.
>
> testsuite/gcc.dg/vect/vect-bswap16.c
> 42:/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" {
The IBM Z ELF ABI mandates every symbol to reside on a 2 byte boundary
in order to be able to use the larl instruction. However, in some
situations it is difficult to enforce this, e.g. for common linker
scripts as used in the Linux kernel. This patch introduces the
-munaligned-symbols option.
On 7/17/23 17:09, Juergen Christ wrote:
> A vec_cmpge produces a negation. Replace this negation by swapping the two
> selection choices of a vec_sel based on the result of the vec_cmpge.
>
> Bootstrapped and regression tested on s390x.
>
> gcc/ChangeLog:
>
> *
On 7/7/23 15:51, Juergen Christ wrote:
> Do not reinitialize vector lanes to zero since they are already initialized to
> zero.
>
> Bootstrapped and regression tested on s390x.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (vec_init): Fix default case
>
> gcc/Testsuite/ChangeLog:
>
>
A change we have committed back in 2015 relies on the backend
requested ABI alignment to be applied to ALL symbols by the
middle-end. However, this does not appear to be the case for external
symbols. With this commit we assume all symbols without explicit
alignment to be aligned according to the
On 3/20/23 07:33, Kewen.Lin wrote:
> Hi,
>
> One of my workmates found there is a warning like:
>
> libgcc/config/rs6000/morestack.S:402: Warning: ignoring
> incorrect section type for .init_array.0
>
> when compiling libgcc/config/rs6000/morestack.S.
>
> Since commit r13-6545
On 5/16/23 08:43, Stefan Schulze Frielinghaus wrote:
> So far atomic objects are aligned according to their default alignment.
> For 128 bit scalar types like int128 or long double this results in an
> 8 byte alignment which is wrong and must be 16 byte.
>
> libstdc++ already computes a correct
On 5/15/23 09:17, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested. Ok for mainline?
>
> Stefan Schulze Frielinghaus (3):
> s390: Refactor block operation cpymem
> s390: Add block operation movmem
> s390: Refactor block operation setmem
>
> gcc/config/s390/s390-protos.h
On 3/2/23 19:13, Robin Dapp wrote:
> Hi,
>
> we seem to flip flop between the "high" and "not low" variants of load on
> condition. Accept both in the affected test cases.
>
> Going to commit this as obvious.
>
> Regards
> Robin
>
> --
>
> gcc/testsuite/ChangeLog:
>
> *
On 3/2/23 16:24, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
> introducing a runtime check for alignment for 16 byte atomic
> compare-exchange, load, and store.
>
> Bootstrapped and regtested on s390.
> Ok for mainline and
On 3/2/23 19:17, Robin Dapp wrote:
> Hi,
>
> When compiling on a system where binutils do not yet support the 'z16'
> name assembling fails with -march=native which we currently interpret
> as -march=z16 (on a z16 machine). This patch uses -march=arch14
> instead.
>
> Is it OK?
Ok. Thanks!
On 2/27/23 11:13, Robin Dapp wrote:
>> Do you really need a copy of the address register? Couldn't you just do a
>> src = adjust_address (operands[1], BLKmode, 0);
>> You create a paradoxical subreg of the QImode input but vll actually
>> uses the whole 32 bit value. Couldn't we end up with
On 2/11/23 16:59, Stefan Schulze Frielinghaus wrote:
> So far we propagate scheduler state across basic blocks within EBBs and
> reset the state otherwise. In certain circumstances the entry block of
> an EBB might be empty, i.e., no_real_insns_p is true. In those cases
> scheduler state is not
On 2/11/23 17:10, Stefan Schulze Frielinghaus wrote:
> Use constrain_operands in order to check whether there exists a valid
> alternative instead of extract_constrain_insn which ICEs in case no
> alternative is found.
>
> Bootstrapped and regtested on IBM zSystems. Ok for mainline?
>
>
On 2/2/23 09:43, Robin Dapp wrote:
> Hi,
>
> this patch adds LEN_LOAD/LEN_STORE support for z14 and newer.
> It defines a bias value of -1 and implements the LEN_LOAD and LEN_STORE
> optabs.
>
> It also includes various vll/vstl testcases adapted from Kewen Lin's patch
> for Power.
>
>
With this patch a scheduling barrier is created to prevent the insn
setting up the frame-pointer and instructions which save GPRs to the
stack to be swapped. Otherwise broken CFI information would be
generated since the stack save insns would use a base register which
is not currently declared as
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments without having to rely on debug information.
With the -mpreserve-args option
This patch introduces a new reg note which can be used to tell the CFI
verification in dwarf2cfi that a register is stored without intending
to restore from it.
This is useful when storing e.g. register contents to the stack and
generate CFI for it although the register is not really supposed to
GPRs and FPRs are save to the stack
slots which are reserved for stdargs in the register save area.
The introduction of REG_CFA_NORESTORE is a common code change which
has been approved last year already.
Bootstrapped and regtested on s390x. Committed to mainline.
Andreas Krebbel (3):
New reg
On 1/24/23 09:47, Stefan Schulze Frielinghaus wrote:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy. The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
>
On 12/27/22 19:23, Jeff Law wrote:
>
>
> On 12/13/22 01:55, Andreas Krebbel via Gcc-patches wrote:
>> Hi,
>>
>> I need a way to save registers on the stack and generate proper CFI for it.
>> Since I do not intend to
>> restore them I needed a wa
Bootstrapped and regression tested on s390x.
Committed to mainline.
gcc/ChangeLog:
* config/s390/s390.md (*not): New pattern.
gcc/testsuite/ChangeLog:
* gcc.target/s390/not.c: New test.
---
gcc/config/s390/s390.md | 8
gcc/testsuite/gcc.target/s390/not.c
Committed to mainline. Bootstrap and regression tests are clean.
gcc/ChangeLog:
* config/s390/s390.cc (s390_register_info): Check call_used_regs
instead of hard-coding the register numbers for call saved
registers.
(s390_optimize_register_info): Likewise.
Hi,
I need a way to save registers on the stack and generate proper CFI for it.
Since I do not intend to
restore them I needed a way to tell the CFI generation step about it:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606128.html
Is this ok for mainline?
Bye,
Andreas
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments.
With the -mpreserve-args option GPRs and FPRs are save to the stack
slots
This patch introduces a new reg note which can be used to tell the CFI
verification in dwarf2cfi that a register is stored without intending
to restore from it.
This is useful when storing e.g. register contents to the stack and
generate CFI for it although the register is not really supposed to
in dwarf2cfi from complaining about the register saves without restores.
Andreas Krebbel (2):
New reg note REG_CFA_NORESTORE
IBM zSystems: Save argument registers to the stack -mpreserve-args
gcc/config/s390/s390.cc | 263 +-
gcc/config/s390/s390.opt
On 8/17/22 13:50, Stefan Schulze Frielinghaus wrote:
> For a parameter with BLKmode we cannot use REG_NREGS in order to
> determine the number of consecutive registers. Streamlined this with
> the implementation of s390_function_arg.
>
> Fix some indentation whitespace, too.
>
> Assuming
On 10/19/22 08:22, Robin Dapp wrote:
> Hi,
>
> since r13-2746 we hit an ICE when bootstrapping with -m31 and
> --enable-checking=all.
>
> ../../../../libgfortran/ieee/ieee_helper.c: In function
> 'ieee_class_helper_16':
> ../../../../libgfortran/ieee/ieee_helper.c:77:3: internal compiler
>
On 8/22/22 17:10, Robin Dapp wrote:
> Hi,
>
> after discussing off-list, here is v2 of the patch. We now recognize if
> the permutation mask only refers to the first or the second operand and
> use this later when emitting vpdi.
>
> Regtested and bootstrapped, no regressions.
>
> Is it OK?
>
On 8/12/22 16:48, Robin Dapp wrote:
> Hi,
>
> similar to other backends this patch implements vec_set via
> vec_merge and vec_duplicate instead of an unspec. This opens up
> more possibilites to combine instructions.
>
> Bootstrapped and regtested. No regressions.
>
> Is it OK?
>
> Regards
>
On 8/12/22 16:19, Robin Dapp wrote:
> Hi,
>
> vec_select can handle dynamic/runtime masks nowadays. Therefore we can
> get rid of the UNSPEC_VEC_EXTRACT that was preventing further
> optimizations like combining instructions with vec_extract patterns.
>
> Bootstrapped and regtested. No
On 8/12/22 12:13, Robin Dapp wrote:
> Hi,
>
> swapping the two elements of a V2DImode or V2DFmode vector can be done
> with vpdi instead of using the generic way of loading a permutation mask
> from the literal pool and vperm.
>
> Analogous to the V2DI/V2DF case reversing the elements of a
On 8/12/22 12:02, Robin Dapp wrote:
> Hi,
>
> this patch tries to be more explicit by mentioning z15 in s390_issue_rate.
>
> No changes in testsuite, bootstrap or SPEC obviously.
>
> Is it OK?
>
> Regards
> Robin
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_issue_rate): Add z15.
On 8/12/22 12:00, Robin Dapp wrote:
> Hi,
>
> inspired by Power we also introduce -munroll-only-small-loops. This
> implies activating -funroll-loops and -munroll-only-small-loops at -O2
> and above.
>
> Bootstrapped and regtested.
>
> This introduces one regression in
On 8/10/22 13:42, Ilya Leoshkevich wrote:
> On Wed, 2022-08-03 at 12:20 +0200, Ilya Leoshkevich wrote:
>> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>>
>>
>>
>> dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
>> produces an insn that vsel is supposed to
On 8/3/22 12:20, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
> produces an insn that vsel is supposed to recognize, but can't,
> because it's not defined for V2SF. Fix by
This avoids generating illegal (strict_low_part (reg ...)) RTXs. This
required two changes:
1. Do not use gen_lowpart to generate the inner expression of a
STRICT_LOW_PART. gen_lowpart might fold the SUBREG either because
there is already a paradoxical subreg or because it can directly be
On 4/13/22 09:30, Richard Biener via Gcc wrote:
>
> Status
> ==
>
> The gcc-11 branch is now frozen in preparation for a GCC 11.3 release
> candidate and the GCC 11.3 release next week. All changes now require
> release manager approval.
Hi,
I would like to push:
On 4/13/22 12:23, Robin Dapp wrote:
> Hi,
>
> this patch adds the scheduler description for z16. Bootstrapped and
> regtested with --with-arch=z16.
>
> Is it OK?
>
> Regards
> Robin
>
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_get_sched_attrmask): Add z16.
>
On 4/13/22 09:35, Robin Dapp wrote:
> Hi,
>
> this test case checks that we do not ICE but FAILs because of
> -Wint-to-pointer-cast. Silence this warning.
>
> Is it OK?
Ok. Thanks!
Andreas
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
1 - 100 of 1031 matches
Mail list logo
