Add instruction vblend and builtin vec_blend.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_blend): Add.
(s390_vblendb): Add.
(s390_vblendh): Add.
(s390_vblendf): Add.
(s390_vblendg): Add.
(s390_vblendq): Add.
* config/s390/s390-b
Add instructions bdepg and bextg and corresponding builtins.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_bdepg): Add.
(s390_bextg): Add.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/s390.md (UNSPEC_BDEPG): Add.
(UNSPEC_BE
Reflect latest updates for vec_(load,store)_len(,_r) which means that
all types except character based types are deprecated.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_load_len): Deprecate
some overloads.
(s390_vec_store_len): Deprecate some overloads.
Add instruction veval and builtin vec_evaluate.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_evaluate): Add.
(s390_veval): Add.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/s390.md (UNSPEC_VEC_VEVAL): Add.
* config/s39
Add instructions lxa and llxa.
gcc/ChangeLog:
* config/s390/s390.md (*lxa_index): Add.
(*lxa_displacement_index): Add.
(*lxa_index_base): Add.
(*lxa_displacement_index_base): Add.
(*lxab_displacement_index_base): Add.
(*llxa_displacement_index): Add
From: Stefan Schulze Frielinghaus
Bump __VEC__ version to 10305 and add 128-bit integer vector types like
`vector __int128` et al. to the zvector extension.
gcc/ChangeLog:
* config/s390/s390-c.cc (rid_int128): New helper function.
(s390_macro_to_expand): Deal with `vector
Add instruction vgem and vector builtins
vec_gen_element_masks_{8,16,32,64,128}.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_gen_element_masks_128): Add.
(s390_vgemb): Add.
(s390_vgemh): Add.
(s390_vgemf): Add.
(s390_vgemg): Add.
(s390_
On Mon, Jan 20, 2025 at 02:46:40PM +0100, Richard Biener wrote:
> On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > gcc/ChangeLog:
>
> Interesting - I can't find anything about these in the PoP (though I can only
> find the one from Ma
Merge new optabs with the existing implementations for signbit and
isinf.
gcc/ChangeLog:
* config/s390/s390.h (S390_TDC_POSITIVE_ZERO): Remove.
(S390_TDC_NEGATIVE_ZERO): Remove.
(S390_TDC_POSITIVE_NORMALIZED_BFP_NUMBER): Remove.
(S390_TDC_NEGATIVE_NORMALIZED_BFP_NU
On Wed, Jan 15, 2025 at 10:29:03PM -0700, Jeff Law wrote:
>
>
> On 11/29/24 2:15 AM, Stefan Schulze Frielinghaus wrote:
> > Ping.
> >
> > On Fri, Oct 25, 2024 at 11:57:16AM +0200, Stefan Schulze Frielinghaus wrote:
> > > This is a follow-up to
> > &
nd;
> }
> break;
> which likely should be also output_operand_lossage but I haven't tried
> to reproduce that.
AFAICS those shouldn't be constructable via inline asm arguments.
However, I agree that asserts are not ideal here. For example, in
*insv_z10_noshift_cc the
Optimization s390_constant_via_vgbm_p() should only apply to constant
vectors which can be expressed by the hardware, i.e., which have a size
of at most 16-bytes, similar as it is done for s390_constant_via_vgm_p()
and s390_constant_via_vrepi_p().
gcc/ChangeLog:
PR target/118362
*
Previously we optimized expressions of the form a < 0 ? -1 : 0 to
(signed)a >> 31 during vcond expanding. Since r15-1638-gaac00d09859cc5
this is done in match.pd. The implementation in the back end as well as
in match.pd are basically the same but still distinct. For the tests in
vcond-shift.c t
Since r15-3992-g698e0ec89bc096 we optimize x<=y && x>=y to x==y.
Honour signaling NaNs by using option -fsignaling-nans in order to
prevent this.
gcc/testsuite/ChangeLog:
* gcc.target/s390/zvector/autovec-double-signaling-eq-z13.c:
Honour sNaNs.
---
.../gcc.target/s390/zvector/au
s to prepare for a future removal of -m31; though in smaller steps. Thus,
instead of introducing some potential hick ups along the route, I will revert
this patch and will revisit this topic when time for -m31 in its entirety has
come---independent of -mesa/-mzarch.
Cheers,
Stefan
[1] https://gcc.gnu
gcc/ChangeLog:
PR target/119235
* config/s390/s390.cc (s390_hard_regno_mode_ok): Accept only
Pmode for registers AP/FP/RA.
---
gcc/config/s390/s390.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
There exists no .REDUC_PLUS on s390.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-77.c: Skip on s390.
---
gcc/testsuite/gcc.dg/vect/bb-slp-77.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-77.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-7
hat case is X for the first variant, so still just fine. But we won't
> > split that because the splitters only expect scratch.
> >
> > The following patch fixes it by using match_scratch instead of scratch,
> > so that it accepts either.
> >
> > Bo
On Thu, Apr 24, 2025 at 12:49:39PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 24, 2025 at 09:44:45AM +0200, Stefan Schulze Frielinghaus wrote:
> > Yes, every parameter is sign or zero extended if its type is smaller
> > than 64bit.
>
> > Note, on s390 a parameter is eit
non-extended values. Maybe a
check like
REGNO (parm) == REGNO (parm_rtx)
&& REG_NREGS (parm) == REG_NREGS (parm_rtx)
is sufficient?
Cheers,
Stefan
>
> Bootstrapped/regtested on s390x-linux, ok for trunk?
>
> I wonder if we shouldn't do this for 15.1 as well with additional
>
ARALLEL is used
exclusively in case a register pair is required. Though, I'm not sure
whether this is correct or not. There doesn't seem to exist a test for
this. I will look into this.
Note, on s390 a parameter is either passed in a register (pair) or via
memory, but not partly in a register and memory.
Cheers,
Stefan
x-linux, ok for trunk and 15.2 (with
> CALL_EXPR_MUST_TAIL_CALL (call_expr) && added in that case)?
Ok. Thanks for taking care of this!
Cheers,
Stefan
gcc/ChangeLog:
* config/s390/s390.cc: Add z17 scheduler description.
* config/s390/s390.h: Ditto.
* config/s390/s390.md: Ditto.
* config/s390/9175.md: New file.
---
gcc/config/s390/9175.md | 316
gcc/config/s390/s390.cc | 3
The recently announced IBM z17 processor implements the architecture
already supported as arch15. This patch adds support for z17 as an
alternative architecture name for arch15.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename arch15 to z17.
* config.gcc: Add z17.
---
htdocs/gcc-15/changes.html | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index f112af58..d851a744 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -1295,7 +1295,28 @
Deprecate support for the ESA/390 architecture which will be eventually
removed, and encourage the usage of the z/Architecture instead.
Furthermore, default for -m31 to -mzarch whereas previously we defaulted
to -mesa.
gcc/ChangeLog:
* config.gcc: Fail in case of option --with-mode=esa.
init -Wenum-conversion -Wextra -Wunused
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation
> -Wno-stringop-truncation -Wno-override-init -Wno-missing-field-initializers
> -Wno-type-limits -Wno-shift-negative
Currently insn_cost() only considers the source part of a SET.
Implement TARGET_INSN_COST in order to also take the destination into
account. This may make a difference in case of a MEM where the address
is a SYMBOL_REF.
Fixes testsuite/gcc.target/s390/section-anchors.c.
gcc/ChangeLog:
For target VXE3 just emit a 128-bit comparison followed by a conditional
load. For targets prior VXE3, emulate the 128-bit comparison and make
use of a conditional load, too.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_expand_cstoreti4): New
function.
* config/s390/s
Insn tf_to_fprx2 moves a TF value into a floating-point register pair.
For alternative 0, the input is a vector register, however, in the else
case instruction ldr is emitted which expects floating-point register
operands only. Thus, this works only for vector registers which overlap
with floating
+** br %r14
> +*/
> +float
> +sumfirstfloat (V4SF x, V4SF y)
> +{
> + return (x + y)[0];
> +}
> +
> +/*
> +** extractfirst2:
> +** vlr %v0,%v24
> +** br %r14
> +*/
> +float
> +extractfirst2 (V2SF x)
> +{
> + return x[0];
> +}
> +
> +/*
> +** extractsecond2:
> +** vrepf %v0,%v24,1
> +** br %r14
> +*/
> +float
> +extractsecond2 (V2SF x)
> +{
> + return x[1];
> +}
> +
> +/*
> +** extractnth2:
> +** vlgvf (%r.),%v24,0\(%r2\)
> +** vlvgf %v0,\1,0
> +** br %r14
> +*/
> +float
> +extractnth2 (V2SF x, int n)
> +{
> + return x[n];
> +}
> +
> +/*
> +** extractsinglef:
> +** vlr %v0,%v24
> +** br %r14
> +*/
> +float
> +extractsinglef (V1SF x)
> +{
> + return x[0];
> +}
> +
> +/*
> +** extractsingled:
> +** vlr %v0,%v24
> +** br %r14
> +*/
> +double
> +extractsingled (V1DF x)
> +{
> + return x[0];
> +}
> +
> +/*
> +** extractsingleld:
> +** vlr (%v.),%v24
> +** vst \1,0\(%r2\),3
> +** br %r14
> +*/
> +long double
> +extractsingleld (V1TF x)
> +{
> + return x[0];
> +}
> diff --git a/gcc/testsuite/gcc.target/s390/vector/vec-set-1.c
> b/gcc/testsuite/gcc.target/s390/vector/vec-set-1.c
> new file mode 100644
> index ..2eddb58290f6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/vector/vec-set-1.c
> @@ -0,0 +1,67 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -march=z14 -mzarch" } */
> +/* { dg-final { check-function-bodies "**" "" } } */
> +
> +typedef double V2DF __attribute__((vector_size(16)));
> +typedef double V1DF __attribute__((vector_size(8)));
> +
> +/*
> +** setdf0:
> +** vpdi%v24,%v0,%v24,1
> +** br %r14
> +*/
> +V2DF
> +setdf0 (V2DF x, double y)
> +{
> + x[0] = y;
> + return x;
> +}
> +
> +/*
> +** setdf1:
> +** vmrhg %v24,%v24,%v0
> +** br %r14
> +*/
> +V2DF
> +setdf1 (V2DF x, double y)
> +{
> + x[1] = y;
> + return x;
> +}
> +
> +/*
> +** setdfn:
> +** lgdr(%r.),%f0
> +** vlvgg %v24,\1,0\(%r2\)
> +** br %r14
> +*/
> +V2DF
> +setdfn (V2DF x, double y, int n)
> +{
> + x[n] = y;
> + return x;
> +}
> +
> +/*
> +** set1df:
> +** vlr %v24,%v0
> +** br %r14
> +*/
> +V1DF
> +set1df (V1DF x, double y)
> +{
> + x[0] = y;
> + return x;
> +}
> +
> +/*
> +** set1dfn:
> +** vlr %v24,%v0
> +** br %r14
> +*/
> +V1DF
> +set1dfn (V1DF x, double y, int n)
> +{
> + x[n] = y;
> + return x;
> +}
I very much like those tests. Could you add for the sake of completeness
also some SF tests for vec-set-1.c?
> --
> 2.43.5
>
Could you run a bootstrap and regtest?
Thanks,
Stefan
ack whether the implementation of hard register
constraints is sensible at all or whether I should drop this patch.
Cheers,
Stefan
Stefan Schulze Frielinghaus (4):
Hard register constraints
Error handling for hard register constraints
genoutput: Verify hard register constraints
Rewrite register asm int
Implement hard register constraints of the form {regname} where regname
must be a valid register name for the target. Such constraints may be
used in asm statements as a replacement for register asm and in machine
descriptions.
It is expected and desired that optimizations coalesce multiple pseud
This implements error handling for hard register constraints including
potential conflicts with register asm operands.
In contrast to register asm operands, hard register constraints allow
more than just one register per operand. Even more than just one
register per alternative. For example, a v
Currently a register asm already materializes during expand. This
means, a hard register is allocated for the very first access of a
register asm as e.g. in an assignment. As a consequence this might lead
to suboptimal register allocation if the assignment and the using asm
statement are spread f
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
sufficient since
ecific lanes.
>
> Bootstrapped and regtested on s390x.
Ok for mainline.
Thanks,
Stefan
>
> gcc/ChangeLog:
>
> * config/s390/vector.md (VF): New mode iterator.
> (VEC_SET_NONFLOAT): New mode iterator.
> (VEC_SET_SINGLEFLOAT): New mode iterator.
>
On Wed, May 21, 2025 at 07:34:27PM +0200, Stefan Schulze Frielinghaus wrote:
> libstdc++-v3/ChangeLog:
>
> * testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard.
> ---
> Ok for mainline?
Just realized that I can use my super powers ;-) and pushed as ob
libstdc++-v3/ChangeLog:
* testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard.
---
Ok for mainline?
libstdc++-v3/testsuite/std/format/parse_ctx.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
b/libstdc++-v
On Fri, Jun 20, 2025 at 08:23:01PM +0200, Juergen Christ wrote:
> Also provide the vec_extract patterns for floats on pre-z13 machines
> to prevent ICEing in those cases.
>
> Bootstrapped and regtested on s390.
Ok.
Thanks,
Stefan
>
> gcc/ChangeLog:
>
> * c
On Mon, Jun 23, 2025 at 09:51:13AM +0200, Juergen Christ wrote:
> On VXE targets, we can directly use the fp min/max instruction instead of
> calling into libm for fmin/fmax etc.
>
> Provide fmin/fmax versions also for vectors even though it cannot be
> called directly. This will be exploited wit
uot;register_operand" "v")]
> +UNSPEC_VEC_UMULT_HI))]
> + "TARGET_VX")
In commit r12-4231-g555fa3545efe23 RTX smul_highpart and umul_highpart
were introduced which we could use instead of the unspec, now. So one
solution would be to move vec_sm
On Mon, Jan 20, 2025 at 02:59:44PM +0100, Stefan Schulze Frielinghaus wrote:
> On Mon, Jan 20, 2025 at 02:46:40PM +0100, Richard Biener wrote:
> > On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus
> > wrote:
> > >
> > > gcc/ChangeLog:
> >
> &
Ping
On Tue, May 20, 2025 at 09:22:55AM +0200, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672941.html
> with basically the only change of adding more tests like for aarch64 and
> the y constraint or for i386 and
On Wed, Jun 04, 2025 at 05:07:13PM +0200, Jakub Jelinek wrote:
> On Wed, Jun 04, 2025 at 05:02:45PM +0200, Stefan Schulze Frielinghaus wrote:
> > Building a subreg in case of
> >
> > else if (GET_CODE (x) == CONST)
> > {
> > /* Extract the symb
f from:
(mem:QI (const:DI (unspec:DI [(symbol_ref:DI ("foo"))]
UNSPEC_PLT/GOTENT))) */
y = XEXP (x, 0);
if (GET_CODE (y) == UNSPEC
&& (XINT (y, 1) == UNSPEC_GOTENT
|| XINT (y, 1) == UNSPEC_PLT31))
y = XVECEXP (y, 0, 0);
else
return orig_x;
}
is questionable to me. Shouldn't we in this case if also
GET_MODE (orig_x) != Pmode holds, return the SYMBOL_REF wrapped in a MEM
with mode of orig_x instead?
Cheers,
Stefan
From: Stefan Schulze Frielinghaus
My understand is that during check_compile compiler_flags contains all
the options passed to gcc and current_compiler_flags contains options
passed via dg-options and dg-additional-options. I did a couple of
experiments and printf-style debugging which endorsed
manually.
>
> The following patch should fix that.
>
> Ok for trunk/15.2?
Ok.
Thanks,
Stefan
On Tue, Jul 01, 2025 at 06:33:12PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 01, 2025 at 03:47:53PM +0200, Stefan Schulze Frielinghaus wrote:
> > In the past years I have started to use more and more function body
> > checks whenever gcc emits optimal code for a function. With th
On Sat, Jun 21, 2025 at 09:18:43AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > This implements error handling for hard register constraints including
> > potential conflicts with register asm operands.
> >
> > In
On Fri, Jun 20, 2025 at 10:17:20AM -0400, Vladimir Makarov wrote:
>
> On 5/20/25 3:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may
On Sat, Jun 21, 2025 at 09:06:42AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may be
>
On Mon, Jun 23, 2025 at 07:12:58PM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Currently a register asm already materializes during expand. This
> > means, a hard register is allocated for the very first access of a
> >
During jump bypassing also consider insns of the form
(insn 25 57 26 9 (parallel [
(set (reg:CCZ 33 %cc)
(compare:CCZ (reg:SI 60 [ _9 ])
(const_int 0 [0])))
(clobber (scratch:SI))
]) "spaceship-fp-4.c":27:1 1746 {*tstsi_cconly_ext
gcc/ChangeLog:
PR target/117015
* config/s390/s390-protos.h (s390_expand_int_spaceship): New
function.
(s390_expand_fp_spaceship): New function.
* config/s390/s390.cc (s390_expand_int_spaceship): New function.
(s390_expand_fp_spaceship): New function
Currently for a signbit operation instructions tc{f,d,x}b + ipm + srl
are emitted. If the source operand is a MEM, then a load precedes the
sequence. A faster implementation is by issuing a load either from a
REG or MEM into a GPR followed by a shift.
In spirit of the signbit function of the C s
Exploit the fact that instruction VLGV zeros excessive bits of a GPR.
gcc/ChangeLog:
* config/s390/vector.md (bhfgq): Add scalar modes.
(*movdi_zero_extend_A): New insn.
(*movsi_zero_extend_A): New insn.
(*movdi_zero_extend_B): New insn.
(*movsi_zero_extend
Moving between GPRs and VRs in any mode with size less than or equal to
8 bytes becomes available with vector extensions. Without adapting
costs for those loads, we typically go over memory.
gcc/ChangeLog:
* config/s390/s390.cc (s390_register_move_cost): Add costing for
vlvg/vlgv
Computing the address of the thread pointer on s390 involves multiple
instructions and therefore bears the risk that the address of the canary
or intermediate values of it are spilled after prologue in order to be
reloaded for the epilogue. Since there exists no mechanism to ensure
that a value is
_VXE3_DT [(match_operand:VIT_HW_VXE3_DT 1
> "register_operand" "v")
> - (match_operand:VIT_HW_VXE3_DT 2
> "register_operand" "v")]
> - UNSPEC_VEC_SMULT_HI))]
> + (smul_highpart:VIT_HW_VXE3_DT (match_operand:VIT_HW_VXE3_DT 1
> "register_operand" "v")
> +
"register_operand" "=v")
> + (unspec:VFT_BFP [(match_operand:VFT_BFP 1 "register_operand" "v")
> + (match_operand:VFT_BFP 2 "register_operand" "v")
> + (match_operand:QI 3 "
On Mon, Jul 07, 2025 at 01:06:44PM +0200, Juergen Christ wrote:
> Done. Should I send a v3?
If bootstrapped and the new tests are still successful (no need for a
full testsuite run I guess), then feel free to push immediately.
Implement hard register constraints of the form {regname} where regname
must be a valid register name for the target. Such constraints may be
used in asm statements as a replacement for register asm and in machine
descriptions. A more verbose description is given in extend.texi.
It is expected a
This implements error handling for hard register constraints including
potential conflicts with register asm operands.
In contrast to register asm operands, hard register constraints allow
more than just one register per operand. Even more than just one
register per alternative. For example, a v
I need to consider more corner cases. Therefore, I would
like to spend some more time on this before I push this new feature.
In total no huge changes. Still ok for mainline?
Stefan Schulze Frielinghaus (3):
Hard register constraints
Error handling for hard register constraints
genoutput: Ve
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
sufficient since
So far only a per thread canary in the TLS block is supported. This
patch adds support for a global canary, too. For this the new option
-mstack-protector-guard={global,tls} is added which defaults to tls.
The global canary is expected at symbol __stack_chk_guard which means
for a function prolo
> +sum += p[i];
> + return sum;
> +}
> +
> +unsigned int
> +__attribute__((noipa, optimize("Ofast")))
> +reduce_add_uint (unsigned int* p)
> +{
> + unsigned int sum = 0;
> + for (int i = 0; i != 16; i++)
> +sum += p[i];
> + return sum;
> +}
> +
>
anymore and sometimes even harmful. Remove the overwrite to
> align s390 with other backends.
Ok for mainline.
Thanks,
Stefan
>
> Signed-off-by: Juergen Christ
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_option_override_internal): Remove override.
>
On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to
> https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684181.html
>
> I added the last missing pieces namely changelogs, and bootstrapped and
> regtested on
>
> aarc
Added changelog entries.
-- >8 --
If a check-function-bodies test is compiled using -fstack-protector*,
-fhardened, -fstack-check*, or -fstack-clash-protection, but the test is
not asking explicitly for those via dg-options or
dg-additional-options, then mark the test as unsupported. Since these
On Sat, Jul 19, 2025 at 08:26:22AM -0600, Jeff Law wrote:
>
>
> On 7/17/25 2:24 AM, Stefan Schulze Frielinghaus wrote:
> > On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus wrote:
> > > This is a follow-up to
> > > https://gcc.gnu.org/pipe
On Mon, Jul 21, 2025 at 11:03:08PM +0800, Xi Ruoyao wrote:
> On Mon, 2025-07-21 at 16:57 +0200, Stefan Schulze Frielinghaus wrote:
> > The generated file tm-preds.h contains now:
> >
> > static inline size_t
> > insn_constraint_len (char fc, const char *str)
> >
Bootstrapped successfully on s390x and tests dg.exp=asm-hard-reg-\*.c
and s390.exp=asm-hard-reg-\*.c are successful, too. Ok for mainline?
-- >8 --
The GNU extension rawmemchr cannot be used. Therefore, replace it by a
simple loop.
gcc/ChangeLog:
* genpreds.cc (write_insn_constraint_l
static inline size_t
insn_constraint_len (char fc, const char *str)
{
...
if (str[0] == '{')
return ((const char *) rawmemchr (str + 1, '}') - str) + 1;
return 1;
}
For some reason on all targets I tested, string.h is included. I will
have a look and see whether string.h
On Sat, Jun 24, 2023, at 11:01 AM, Jeff Law via Gcc-patches wrote:
> On 6/21/23 02:14, Wang, Yanzhang wrote:
>> Hi Jeff, sorry for the late reply.
>>
>>> The long branch handling is done at the assembler level. So the clobbering
>>> of $ra isn't visible to the compiler. Thus the compiler has to
On Sun, Jun 25, 2023, at 8:49 AM, Jeff Law wrote:
> On 6/24/23 19:40, Stefan O'Rear wrote:
>> On Sat, Jun 24, 2023, at 11:01 AM, Jeff Law via Gcc-patches wrote:
>>> On 6/21/23 02:14, Wang, Yanzhang wrote:
>>>> Hi Jeff, sorry for the late reply.
>>>>
atch lower-cases the single lonesome lingering ULL; all
other suffixes are already lower case.
regards
Stefan
libgcc2.diff
Description: Binary data
() function uses SIGNED instead of
unsigned mask values; cf. __bswapdi2()
Stefan Kanthak
libgcc2.diff
Description: Binary data
ions are now in the systemz file which
uses an "#ifdef __s390x__" in order to distinguish both cases.
The s390 file is just including the systemz one.
Bye,
Stefan
--
libphobos/ChangeLog:
2019-11-27 Robin Dapp
2020-03-23 Stefan Liebler
* configure: Regenerate.
* lib
ared/load.d
libphobos.shared/loadDR.c
libphobos.shared/load_linkdep.d
libphobos.shared/load_loaddep.d
Bye,
Stefan
--
libphobos/ChangeLog:
2020-03-23 Stefan Liebler
* libphobos/libdruntime/core/sys/posix/signal.d:
Add struct sigaction_t for SystemZ.
co
ping
On 3/23/20 6:04 PM, Stefan Liebler wrote:
Hi,
this patch picks up Robin Dapps patch __tls_get_offset-in-separate.S.
See "Bugzilla 91628 - libdruntime uses glibc internal symbol on s390"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628)
The original purpose was to get rid of
ping
On 3/23/20 6:05 PM, Stefan Liebler wrote:
Hi,
the ordering of some fields in struct sigaction on s390x (64bit)
differs compared to s390 and other architectures.
This patch adjusts this order according to the definition of
/sysdeps/unix/sysv/linux/s390/bits/sigaction.h
Without this fix
On 4/1/20 12:54 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
ping
Thanks, I'll send the patch upstream, as it's the same there.
Looks OK to me.
Regards
Iain.
Thanks for committing the patch upstream
On 4/1/20 12:50 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
ping
Hi Stefan,
As I've already said, I think that the name should be __ibmz_get_tls_offset to
make clear that it is an internal function.
Other than that, looks good to me.
Iain.
Hi Iain,
Sorry.
On 4/1/20 6:20 PM, Stefan Liebler wrote:
On 4/1/20 12:50 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
ping
Hi Stefan,
As I've already said, I think that the name should be
__ibmz_get_tls_offset to make clear that it is an internal function.
Other than that,
ieee754_sqrtl>:
0: 68 00 30 00 ld %f0,0(%r3)
4: 68 20 30 08 ld %f2,8(%r3)
8: b3 16 00 00 sqxbr %f0,%f0
c: 60 00 20 00 std %f0,0(%r2)
10: 60 20 20 08 std %f2,8(%r2)
14: 07 fe br %r14
Thanks,
Stefan
Comparisons between memory and constants might be done in a smaller mode
resulting in smaller constants which might finally end up as immediates
instead of in the literal pool.
For example, on s390x a non-symmetric comparison like
x <= 0x3fff
results in the constant being spilled to
ping
On Mon, Jun 19, 2023 at 04:23:57PM +0200, Stefan Schulze Frielinghaus wrote:
> Comparisons between memory and constants might be done in a smaller mode
> resulting in smaller constants which might finally end up as immediates
> instead of in the literal pool.
>
> For example,
On Tue, Aug 01, 2023 at 01:52:16PM +0530, Prathamesh Kulkarni wrote:
> On Tue, 1 Aug 2023 at 05:20, Jeff Law wrote:
> >
> >
> >
> > On 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote:
> > > On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Friel
In certain cases a constant may not fit into the mode used to perform a
comparison. This may be the case for sign-extended constants which are
used during an unsigned comparison as e.g. in
(set (reg:CC 100 cc)
(compare:CC (mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])
(const_int
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" { target
{ vect_bswap || sse4_runtime } } } } */
testsuite/gcc
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.
(vectorize_vec_perm_const_1): Call new function.
* config/s390/vector.
This fixes the rather new tests cmp-mem-const-{1,2,3,4,5,6}.c for sparc.
For -1 and -2 we need at least optimization level 2 on sparc. For the
sake of homogeneity, change all test cases to -O2. For -3 and -4 we do
not end up with a comparison of memory and a constant, and finally for
-5 and -6 th
In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
completely missed the fact that the normal form of a generated constant for a
mode with fewer bits than in HOST_WIDE_INT is a sign extended version of the
actual constant. This even holds true for unsigned constants.
Fixed by
On Sat, Aug 12, 2023 at 09:04:19AM +0800, Xi Ruoyao wrote:
> On Thu, 2023-08-10 at 15:04 +0200, Stefan Schulze Frielinghaus via Gcc-
> patches wrote:
> > In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> > completely missed the fact that the normal f
See <https://gcc.gnu.org/bugs/> for instructions.
I will come back to this tomorrow.
Cheers,
Stefan
On Mon, Aug 14, 2023 at 08:45:21PM +0800, Kewen.Lin via Gcc-patches wrote:
> Hi Juzhe,
>
> on 2023/8/14 20:08, juzhe.zh...@rivai.ai wrote:
> > Hi, Kewin.
> >
> > Co
Ping. Since this fixes bootstrap problem PR110939 for Loongarch I'm
pingen this one earlier.
On Thu, Aug 10, 2023 at 03:04:03PM +0200, Stefan Schulze Frielinghaus wrote:
> In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> completely missed the fact that the nor
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.
(s390_vec_reve_flt): Ditto.
(s390_vclfnhs): Fix
The second argument of these builtins is an unsigned immediate. For
vec_rli the API allows immediates up to 64 bits whereas the instruction
verll only allows immediates up to 32 bits. Since the shift count
equals the immediate modulo vector element size, truncating those
immediates is fine.
Boot
201 - 300 of 418 matches
Mail list logo
